4 ms·

ES6 was needed, but I think js should hit the breaks for new language features for a while.

by icholy 8y ago

ergothus 8y ago
I wont agree or disagree yet, but why?
- icholy 8y ago
  Because it's easy to add features, but impossible to take them away.
yanis_t 8y ago
I tend to agree with you. The thing is that most people would agree but at the time everyone wants different features. Me personally I even think we could be better without classes and all that "pretend you're writing Java" nonsense
- shados 8y ago
  > I even think we could be better without classes Absolutely. Classes are also a big part of why there's still a lot of bikeshedding for some new features (class properties, decorators, private fields, etc). Classes are familiar to most developers these days, but they're an absurdly complicated construct. The current implementation in javascript is "maximally minimal", in that the TC39 pushed the minimum they could that was still kind of sortoff useful to get the wheel rolling...but it's still not good enough. They'll need several more updates before they're truly useful. And even when that's all there, they still won't offer much that wasn't already doable, arguably better if less familiar. At the end of the day, ES6 classes were designed back in the days where OOP was getting big in JavaScript. It took so long to release that by the time they were, the field had changed a lot.
- coltonv 8y ago
  I see this idea that adding classes to JS was a bad thing a lot, but even though I don't ever use classes in my codebase, I don't know why it would make sense to remove them before adding new features, or to stall new features because they exist and I don't like them. In my opinion, we should be moving forward with features that make functional paradigms easier, such as the pipeline operator, regardless of the fact that JS has object oriented features. There's no reason to stall new features just because different people want different features, at this moment we're pleasing no one with the slow release cycle.
- tracker1 8y ago
  I tend to prefer more utility/function approaches as much as possible. The exception to sometimes you need to carry context in a way often more simple (in terms of source complexity) to use class syntax. Not in every case, but some.
coltonv 8y ago
I disagree. ES6 made JS much more palatable but it's still behind most modern languages in terms of number of features and in velocity of new features getting introduced. Javascript has actually been extremely slow to get new features compared to other languages. Since ES6 (3 years ago), the only major, mainstream feature that has been added to JS has been async functions, which are awesome, but in that time Python (a language of similar age and global use) has gotten an optional type system, async/await, and _hundreds_ of standard library modules, classes, and functions. In my opinion, JS badly needs more functions in it's standard library, which should move through the proposal policy quickly. However, common sense standard library functions like flatMap have been in the pipeline for years are still not in the final stage. We may not get flatMap, import(), trimStart, or trimEnd in ES2019, they are all stalled in Stage 3. There's no good arguments not to have these in the standard library, but we still have to wait years. In addition to that, JS could really use some language features that make it's core paradigms, functional and object oriented, simpler, and have been in other languages for years. The pipeline operator would make functional programming much easier, and decorators would make object oriented programming easier. These are, in my opinion, common sense features since they are so well received in other langauges, but they get stalled out since they are seen as "bloating" the syntax, or making javascript "too opinionated on how to do something". Meanwhile, people are compiling full fledged functional languages (Reason, Elm, Purescript) to Javascript, because Javascript isn't keeping up with them on features. It could, but the TC39 review process is so slow that it's not worth waiting on. For those reasons, in my opinion, we should really be releasing new language features much quicker.
- WorldMaker 8y ago
  > In my opinion, JS badly needs more functions in it's standard library, which should move through the proposal policy quickly. However, common sense standard library functions like flatMap have been in the pipeline for years are still not in the final stage. We may not get flatMap, import(), trimStart, or trimEnd in ES2019, they are all stalled in Stage 3. There's no good arguments not to have these in the standard library, but we still have to wait years. This is one of the arguments for the pipeline operator, as well. Right now browsers are inherently quite afraid of adding things to Object.prototype, Array.prototype, etc, because doing so breaks things. There are too many ancient JS libraries that patch whatever they want into Object.prototype/Array.prototype, such as MooTools, that threaten to break if the prototypes themselves change from what is expected. This is how flatMap() got stuck into "SmooshGate" and the intentionally absurd proposal that it should be named smooshMap(), because if Browsers add Array.prototype.flatMap it does break versions of MooTools still out in the wild. The pipeline operator is one option (among several proposed options) to move the standard library forward without compromising backward compatibility. Maybe we can't have nice things like `myArray.flatMap()` because it breaks backwards compatibility, but maybe something like `myArray|>flatMap()` is an acceptable compromise.
ravenstine 8y ago
I'd rather that JavaScript as a community take a break from the framework wars. The amount of gained productivity occurring from new frameworks being created is miniscule, and in some ways it detracting. Meanwhile, other language communities have settled on a few frameworks and have allowed them to mature. Out of the gate, React already spawned a bunch of clones that claim to do things better. I'd bet good money that in 3 years React will be tossed aside like AngularJS for the next thing announced by the predominant tech company of the day. Hey, maybe one of Elon Musk's companies makes a JavaScript framework. I'd rather that JavaScript continue to add features so that it remains relevant. I like its ubiquity and the the fact that it's both a server and browser language, and would hate to see it get completely railroaded by other language runtimes that can be compiled to WASM.

ES6 was needed, but I think js should hit the breaks for new language features for a while.

by icholy 8y ago

ES6 was needed, but I think js should hit the breaks for new language features for a while.

ergothus 8y ago

I wont agree or disagree yet, but why?

icholy 8y ago
Because it's easy to add features, but impossible to take them away.

yanis_t 8y ago

I tend to agree with you. The thing is that most people would agree but at the time everyone wants different features. Me personally I even think we could be better without classes and all that "pretend you're writing Java" nonsense

shados 8y ago
> I even think we could be better without classes Absolutely. Classes are also a big part of why there's still a lot of bikeshedding for some new features (class properties, decorators, private fields, etc). Classes are familiar to most developers these days, but they're an absurdly complicated construct. The current implementation in javascript is "maximally minimal", in that the TC39 pushed the minimum they could that was still kind of sortoff useful to get the wheel rolling...but it's still not good enough. They'll need several more updates before they're truly useful. And even when that's all there, they still won't offer much that wasn't already doable, arguably better if less familiar. At the end of the day, ES6 classes were designed back in the days where OOP was getting big in JavaScript. It took so long to release that by the time they were, the field had changed a lot.
coltonv 8y ago
I see this idea that adding classes to JS was a bad thing a lot, but even though I don't ever use classes in my codebase, I don't know why it would make sense to remove them before adding new features, or to stall new features because they exist and I don't like them. In my opinion, we should be moving forward with features that make functional paradigms easier, such as the pipeline operator, regardless of the fact that JS has object oriented features. There's no reason to stall new features just because different people want different features, at this moment we're pleasing no one with the slow release cycle.
tracker1 8y ago
I tend to prefer more utility/function approaches as much as possible. The exception to sometimes you need to carry context in a way often more simple (in terms of source complexity) to use class syntax. Not in every case, but some.

coltonv 8y ago

I disagree. ES6 made JS much more palatable but it's still behind most modern languages in terms of number of features and in velocity of new features getting introduced. Javascript has actually been extremely slow to get new features compared to other languages. Since ES6 (3 years ago), the only major, mainstream feature that has been added to JS has been async functions, which are awesome, but in that time Python (a language of similar age and global use) has gotten an optional type system, async/await, and _hundreds_ of standard library modules, classes, and functions. In my opinion, JS badly needs more functions in it's standard library, which should move through the proposal policy quickly. However, common sense standard library functions like flatMap have been in the pipeline for years are still not in the final stage. We may not get flatMap, import(), trimStart, or trimEnd in ES2019, they are all stalled in Stage 3. There's no good arguments not to have these in the standard library, but we still have to wait years. In addition to that, JS could really use some language features that make it's core paradigms, functional and object oriented, simpler, and have been in other languages for years. The pipeline operator would make functional programming much easier, and decorators would make object oriented programming easier. These are, in my opinion, common sense features since they are so well received in other langauges, but they get stalled out since they are seen as "bloating" the syntax, or making javascript "too opinionated on how to do something". Meanwhile, people are compiling full fledged functional languages (Reason, Elm, Purescript) to Javascript, because Javascript isn't keeping up with them on features. It could, but the TC39 review process is so slow that it's not worth waiting on. For those reasons, in my opinion, we should really be releasing new language features much quicker.

WorldMaker 8y ago
> In my opinion, JS badly needs more functions in it's standard library, which should move through the proposal policy quickly. However, common sense standard library functions like flatMap have been in the pipeline for years are still not in the final stage. We may not get flatMap, import(), trimStart, or trimEnd in ES2019, they are all stalled in Stage 3. There's no good arguments not to have these in the standard library, but we still have to wait years. This is one of the arguments for the pipeline operator, as well. Right now browsers are inherently quite afraid of adding things to Object.prototype, Array.prototype, etc, because doing so breaks things. There are too many ancient JS libraries that patch whatever they want into Object.prototype/Array.prototype, such as MooTools, that threaten to break if the prototypes themselves change from what is expected. This is how flatMap() got stuck into "SmooshGate" and the intentionally absurd proposal that it should be named smooshMap(), because if Browsers add Array.prototype.flatMap it does break versions of MooTools still out in the wild. The pipeline operator is one option (among several proposed options) to move the standard library forward without compromising backward compatibility. Maybe we can't have nice things like `myArray.flatMap()` because it breaks backwards compatibility, but maybe something like `myArray|>flatMap()` is an acceptable compromise.

ravenstine 8y ago

I'd rather that JavaScript as a community take a break from the framework wars. The amount of gained productivity occurring from new frameworks being created is miniscule, and in some ways it detracting. Meanwhile, other language communities have settled on a few frameworks and have allowed them to mature. Out of the gate, React already spawned a bunch of clones that claim to do things better. I'd bet good money that in 3 years React will be tossed aside like AngularJS for the next thing announced by the predominant tech company of the day. Hey, maybe one of Elon Musk's companies makes a JavaScript framework. I'd rather that JavaScript continue to add features so that it remains relevant. I like its ubiquity and the the fact that it's both a server and browser language, and would hate to see it get completely railroaded by other language runtimes that can be compiled to WASM.