4 ms·

No wonder: Microsoft needs "class" syntax in JS, they are a driving for behind TypeScript and ES6. Especially interesting, as Javascript has prototype inheritan

by frik 11y ago

No wonder: Microsoft needs "class" syntax in JS, they are a driving for behind TypeScript and ES6. Especially interesting, as Javascript has prototype inheritance. The reason: All of MS code is class-based, and they want it to look similar to C#.

michaelwww 11y ago
"JavaScript will never have mandatory types" says Brendan Eich, who doesn't work for Microsoft last I checked, which I mean to say Microsoft is not the driving force behind ES6. Source: https://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Brendan-Eich-JavaScript-Today-and-Tomorrow https://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Brendan-... [10:04]
- gsnedders 11y ago
  Mandatory types is obvious—it needs to be compatible with existing JS code. Gradual typing is entirely plausible (and I think highly likely), and from there it's easy to add some static lint that ensures a codebase is statically typed.
  - BrendanEich 11y ago
    Agreed. This is not "mandatory types", note well.
epoch1970 11y ago
Developers of large JavaScript codebases have come to realize that class-based OO is exactly what they need. Prototype OO sounds interesting in theory, but in practice it tends to not be what's needed. Projects that use it end up trying to poorly imitate class OO. This wouldn't necessarily be a problem, except it isn't done consistently. There are multiple approaches, some of them which don't mesh well with others. Class-based OO, on the other hand, tends to be much more consistent and well-defined. This consistency improves developer productivity, it keeps the code cleaner, and it allows for greater code reuse between projects. Prototype OO hasn't proven itself in practice, while class OO has again and again.
- jasim 11y ago
  Would love to hear more about this. I've come to favour TypeScript style annotation with passing around hashes into pure functions in ES6.
- Bahamut 11y ago
  Not just that - there are performance implications as well due to browsers being able to use a fixed allocation of memory with classes' properties instead of a dynamically resized amount for objects, which results in less efficient algorithms able to be applied internally for the browser for doing similar operations.
  - gsnedders 11y ago
    In principle, in many cases it's possible to allocate the right amount of space for an object's properties, under the assumption that most objects from a single constructor gain properties in the same order.
- Roboprog 11y ago
  "Those people will go to their graves, never knowing how miserable they are" :-) See 5:30 into video (on ES6): https://www.youtube.com/watch?v=PSGEjv3Tqo0 https://www.youtube.com/watch?v=PSGEjv3Tqo0 I have been doing a fair amount of JS work in an app using Angular this year. I don't use much inheritance of any kind, mostly FP techniques and "objects" (associative arrays) as aggregates. If you use "closure" variables instead of "this", it's pretty easy to graft functions from one aggregate to another for code reuse.

by frik 11y ago

michaelwww 11y ago

"JavaScript will never have mandatory types" says Brendan Eich, who doesn't work for Microsoft last I checked, which I mean to say Microsoft is not the driving force behind ES6. Source: https://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Brendan-Eich-JavaScript-Today-and-Tomorrow https://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Brendan-... [10:04]

gsnedders 11y ago
Mandatory types is obvious—it needs to be compatible with existing JS code. Gradual typing is entirely plausible (and I think highly likely), and from there it's easy to add some static lint that ensures a codebase is statically typed.
- BrendanEich 11y ago
  Agreed. This is not "mandatory types", note well.

epoch1970 11y ago

Developers of large JavaScript codebases have come to realize that class-based OO is exactly what they need. Prototype OO sounds interesting in theory, but in practice it tends to not be what's needed. Projects that use it end up trying to poorly imitate class OO. This wouldn't necessarily be a problem, except it isn't done consistently. There are multiple approaches, some of them which don't mesh well with others. Class-based OO, on the other hand, tends to be much more consistent and well-defined. This consistency improves developer productivity, it keeps the code cleaner, and it allows for greater code reuse between projects. Prototype OO hasn't proven itself in practice, while class OO has again and again.

jasim 11y ago
Would love to hear more about this. I've come to favour TypeScript style annotation with passing around hashes into pure functions in ES6.
Bahamut 11y ago
Not just that - there are performance implications as well due to browsers being able to use a fixed allocation of memory with classes' properties instead of a dynamically resized amount for objects, which results in less efficient algorithms able to be applied internally for the browser for doing similar operations.
- gsnedders 11y ago
  In principle, in many cases it's possible to allocate the right amount of space for an object's properties, under the assumption that most objects from a single constructor gain properties in the same order.
Roboprog 11y ago
"Those people will go to their graves, never knowing how miserable they are" :-) See 5:30 into video (on ES6): https://www.youtube.com/watch?v=PSGEjv3Tqo0 https://www.youtube.com/watch?v=PSGEjv3Tqo0 I have been doing a fair amount of JS work in an app using Angular this year. I don't use much inheritance of any kind, mostly FP techniques and "objects" (associative arrays) as aggregates. If you use "closure" variables instead of "this", it's pretty easy to graft functions from one aggregate to another for code reuse.