Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have never really worked too in depth in Javascript. So just starting to dig into it more, I have learned about the "new" syntax for JS: MDN
I understand that basically it is exactly the same as before just with a different way to construct the code.
Obviously there is always a reason to learn techniques and variations, but what would make it worth my time to learn prototyping syntax, when using the updated syntax is more familiar to learn?
*One reason I can think of is just for understanding examples from before ES6. Almost everywhere the code is written with prototyping.
The only reason to avoid the class syntax is if you want your code to run in an environment where the class keyword is not supported. And, even then, you could write with class and transpile your code to ES5 compatible code if you wanted.
So, there's really no reason to avoid using class.
but what would make it worth my time to learn prototyping syntax
Even though you may code with class, here are some good reasons to fully understand how the prototype object works:
Javascript is a prototype-based language. Even though it is now using the class keyword, it's a prototype-based language, not really a class based language. You should know and understand what that means.
Older code will be written using assignments to the prototype so you will want to be able to quickly understand how that code works.
The class syntax is just manipulating the prototype under the covers so fully understanding how the class syntax works requires fully understanding how the prototype works.
There are programming structures that are sometimes very useful that the class syntax cannot create such as mixins where you may still need to work with the prototype.
So, I would suggest learning how objects are defined with the prototype object because then you will understand what the class syntax is actually doing. It's not particularly hard. Reading a few articles about how the prototype object works and then creating an object and then deriving from it using the .prototype object syntax is all you really need to do to get a handle on it. Then, I'd suggest creating the exact same object definition and then deriving from it using both the class syntax and by assigning to the prototype and then you can really see the parallels.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Typescript is the language used for developing Javascript applications. I don't understand why new language was created instead of using matured and evolving language such as C#. C# could have been used for transpiling the code to Javascript. There are many third party and open source project which does this job. C# now supports closures, dynamic keyword, so transpiling C# to javascript would have been easy. From the syntax as well it also seems that Typescript is influenced from C#.
So questions is
Why Microsoft has developed a new language called Typescript instead of creating C# to Javascript transpiler? C# could have been used for the same purpose.
Is there any technical/other reason behind it?
Why Microsoft has developed a new language called Typescript instead
of creating C# to Javascript transpiler? C# could have been used for
the same purpose.
Is there any technical/other reason behind it?
Technically yes, but no. C#'s rules are extremely different than JavaScript's. They may look the same, but they are very far apart. (It's kinda like saying Java and JavaScript are the same, because they both use brackets, and they both start with Java.) TypeScript extends the JavaScript language. You can still write JavaScript in TypeScript. You couldn't do that if you used C#.
Here are some examples. In C# you can have multiple constructors. JavaScript (like Highlander) there can be only one.
C# allows method overloading. JavaScript....Nope.
JavaScript can have a variable number of parameters in a method call. You can have a method which takes 5 parameters and call it with 5, 4, 0, or 7 if you like. C# can't handle this.
Now you could generate JavaScript code from C#, but really you're just forcing the use of a subset of JavaScript to accommodate the use of C#. TypeScript is an entirely new language to work within the bounds of JavaScript, while providing some structure that strongly typed languages allow.
Typescript is a strict superset of Javascript, meaning almost all valid JS is also valid Typescript. It was made for interoperatibility with Javascript. C# could never be on the same level. Lots of different semantics that might not be immediatly obvious, but are definitely difficult.
Syntax might be similar, but the two languages are on a completely different level feature wise.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Is it necessary to learn TypeScript first before attempting to learn AngularJS 2?
It's not necessary to learn TypeScript but I would definitely recommend that you do learn it. TypeScript is excellent. Not only that, but TypeScript is actually great and very solid
Check this answer
The official stance of the AngularJS team is that it will be
completely optional. You could write your whole application in the
JavaScript we know today (ECMAscript5). But to be honest, there are
some serious issues with that version.
no real classes and inheritance (only prototype)
no type checking
no module system (loading parts of javascript)
If you still want to write it in ECMAscript, you'll have to write more
code to do the same, and ergo have a higher chance at bugs getting
into your code.
You could write it in ECMAscript 6, which is the next version.
Unfortunately it's not supported yet in most browsers. But you can
already use it, and then compile your code to ECMAscript 5 during the
deploy fase (you can setup GRUNT to do this)
Finally you could use Typescript. It offers everything ECMAscript
offers and more. Learning it should not feel like learning a new
language, since JavaScript is also valid in Typescript. They just
added some syntactical sugar to make it more powerful and useful. You
will still have to compile it to ECMAscript 5 during deploy.
Via - Bert Verhelst | Quora Discussions
This question already has answers here:
Use of 'prototype' vs. 'this' in JavaScript?
(15 answers)
Closed 9 years ago.
I've been reading through JavaScript: The Good Parts and I'm currently on "Chapter 5: Inheritance."
From what I understand, using functional inheritance is preferred because it allows privacy for the properties and variables of an object while still allowing them to be called using methods outside of the object. However, it does seem like there is an advantage for prototypal inheritance because you can create a prototype object fairly easily (which makes understanding what the object is, to me, a little more concrete).
When should I choose one over the other? Should I always use functional inheritance whenever possible? Or are there "better" guidelines that I can follow to make that determination?
I've seen very little code that uses functional techniques as the primary form of inheritance. The vast majority I've seen uses prototypal inheritance. It's fast and easy to implement, and seems most natural to JavaScript.
That's not to say that functional inheritance should never be used, but I think you'll find prototypal more than sufficient for most applications.
Let's not also forget that you can still use some functional techniques within your prototypal inheritance, like giving each object it's own version of a function that closes over a variable in the constructor. So it doesn't need to entirely be one or the other.
Most important is to understand the concepts of prototypes and functions/closures. This alone will give you what you need to know in order to make appropriate decisions.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Steve Yegge recently posted an interesting blog post on what he calls the universal design pattern. In there he details using prototypes as a modelling tool, instead of classes. I like the way this introduces less coupling compared to inheritance. But that is something one can get with classes as well, by implementing classes in terms of other classes, instead of inheritance. Does anyone else have success stories of using prototypes, and can maybe help explain where using prototypes is advantageous compared to classes. I guess it comes down to static modelling versus dynamic modelling, but more examples would be very welcome.
One interesting bit is that it's easy to make a prototype-based language act OO but it's difficult to make an OO language act prototype-based.
Alex Arnell's inheritance.js is a short and sweet chunk of code that makes JavaScript act OO, complete with access to the parent 'Class'.
Here's one of John Resig's solutions to the same problem: http://ejohn.org/blog/simple-javascript-inheritance/.
Chapter 16 of Programming in Lua describes object orientation in Lua. Specifically, section 16.2 gives a nice example of inheritance.
It's not entirely clear what OO as prototype would look like, aside from composition versus inheritance as you mention.
A prototype language makes complex inheritance behavior easy. You can implement multiple inheritance, mixin-like behavior, or just pick and choose what you want from one object to add to another.
Wikipedia's article mentions: "Advocates of prototype-based programming often argue that class-based languages encourage a model of development that focuses first on the taxonomy and relationships between classes. In contrast, prototype-based programming is seen as encouraging the programmer to focus on the behavior of some set of examples and only later worry about classifying these objects into archetypal objects that are later used in a fashion similar to classes."
That's not to say the prototype paradigm is all pros and no cons. If OO is more restrictive, it's because it chooses to be. I can see where all that flexibility might get you into trouble if you aren't careful.
Prototypes are a form of inheritance, it's just that objects inherit attributes and behavior directly from other objects, instead of getting their attributes and behavior from their class, which inherits from other classes.
For examples, check out any object oriented code in a prototype based language like, for example, JavaScript.
For those interested, NewtonScript was (is) a dual language: you had prototypes and you had classes. You could choose whether to inherit from a class, from a prototype or from both.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are some good resources to learn best practices for Javascript? I'm mainly concerned about when something should be an object vs. when it should just be tracked in the DOM. Also I would like to better learn how to organize my code so it's easy to unit test.
Seconding Javascript: The Good Parts and Resig's book Secrets of the Javascript Ninja.
Here are some tips for Javascript:
Don't pollute the global namespace (put all functions into objects/closures)
Take a look at YUI, it's a huge codebase with only 2 global objects: YAHOO and YAHOO_config
Use the Module pattern for singletons (http://yuiblog.com/blog/2007/06/12/module-pattern/)
Make your JS as reusable as possible (jQuery plugins, YUI modules, basic JS objects.) Don't write tons of global functions.
Don't forget to var your variables
Use JSlint : http://www.jslint.com/
If you need to save state, it's probably best to use objects instead of the DOM.
I disagree to the "use a framework" statement to some degree. Too many people use frameworks blindly and have little or no understanding of what's going on behind the curtains.
I liked JavaScript:The Good Parts by Douglas Crockford although it's focused entirely on the language and ignores the DOM altogether.
If you don't feel like reading you can watch this video: JavaScript the good parts by Doug Crockford.
Probably the single most important thing is to use a framework, such as jQuery, or prototype, to iron out the differences between browsers, and also make things easier in general.
YUI Theatre has a bunch of videos (some with transcripts) by Steve Souders, Douglas Crockford, John Resig and others on JavaScript, YUI, website performance and other related topics.
There are also very interested google tech talks on Youtube on jQuery and other frameworks.
You can pick up a lot from Pro JavaScript Techniques, and I'm looking forward to Resig's forthcoming Secrets of the JavaScript Ninja.
As an addendum to the Crockford book, you may also want to check out this piece Code Conventions for the Javascript Programming Language. I also have a slightly different suggestion: instead of using a JS library off the bat, why not create your own? You may write a crappy library (as I did), but you'll learn something in the process. You have existing examples you can use as models. Also, to help give you an understanding of JS design patterns, I shall recommend another book, 'Pro Javascript Design Patterns'.