4 ms·

> (note the use of the word changing, not improving) I find it interesting that you say that. Has JavaScript changed for the worse? That's not how I've seen

> (note the use of the word changing, not improving) I find it interesting that you say that. Has JavaScript changed for the worse? That's not how I've seen it, since a lot of problems like the lack of real modules, no async/await, lack of syntactic sugar for "classes", no `for (const x of y)`, weird variable scoping, no constants, bound functions(i.e. fat arrow functions), have been solved. I can't see how JS has gotten worse. Some parts of the community are worse, perhaps. It's been years since React has been released, and people still seem to believe that React should be used for anything and is the only tool for any "serious" web development.(I'm not ragging on React itself, but the people who treat it like the new jQuery) Overall, JS devs are still trying to out-innovate each other by monkey-branching paradigms, which I think is the real churn with JS. I guess that's related to your final statement. The perceived churn of JS to me is self imposed to some extent. I've been doing Ember development exclusively for the last 4 years and haven't had a problem finding employment or contract work. If I can make a living working with what people consider a "dead" framework, then that's a sign that you don't need to chase the latest and greatest JS fad.

wwright 6y ago
FWIW, many people have the opinion that classes were a bad design. (I’m of the opinion that closures and anonymous objects do everything you’d need from a class, but better.) The other language improvements are definitely unanimous wins though.
game_the0ry 6y ago
> Has JavaScript changed for the worse? Clarification - I don't think JS has changed for the worse, but I do not think it is clear that all the changes have been for the better, both for the language and the ecosystem. I see it as a double edged sword. Take the example of handling asynchronous operations - async/await is good solution for that. But now you will be working in code bases with callbacks, promises, async/await, and possibly even generators - with generators being an example of an area that was not a clear improvement in the right direction, but an experiment now obsolete because of async/await. I'm a fan of improvement, but nowadays I try not to pick up the latest trend for concern that it might be obsolete in the near future. You demonstrate this - you picked something you like (ember) and just stuck with it. Ember solves problems, it works, no reason to refactor your ember projects to react.
- cpr 6y ago
  Quite the contrary: Generators are quite useful in their own right, independently of asynchronicity.
lhorie 6y ago
> That's not how I've seen it, since a lot of problems [...] have been solved "Solved" is an overstatement. The javascript ecosystem is house of cards. Modularity is far from solved, for example support for the browser field in package.json is all over the place, hoisting leading to phantom dependency bugs is another clusterfuck. A large number of popular packages want to own module resolution or parsing or both (jest, typescript, CRA, storybook, yarn v2, to name just a few), leading to inconsistencies between tools. Not too long, create-react-app broke because of some oversight from some library author over some package.json field lead to a broken publish. Bizarre bugs from the tree-shaking vs side effects dichotomy. The existence of things like yarn resolutions and patch-package and proxyquire. Abysmal symlink support. The list just goes on and on. You _can_ get little pockets of very tightly integrated experience w/ comprehensive toolsets like Angular, Ember or to some extent CRA, but if you need to venture outside in a non-trivial way, the pain of fragmentation is real.
- ravenstine 6y ago
  Those are mostly problems with Node.js, not JavaScript itself. But fair point since they are part of the JavaScript ecosystem and I did mention a framework. The different module implementations are a problem, but at least there's a standard that they are mostly emulating now and native support will eventually work and be adopted, especially with HTTP2+. "Solved" might be an overstatement, but there's still been a ton of improvement. ES5 is a madhouse compared to what we have now.

wwright 6y ago

FWIW, many people have the opinion that classes were a bad design. (I’m of the opinion that closures and anonymous objects do everything you’d need from a class, but better.) The other language improvements are definitely unanimous wins though.

game_the0ry 6y ago

> Has JavaScript changed for the worse? Clarification - I don't think JS has changed for the worse, but I do not think it is clear that all the changes have been for the better, both for the language and the ecosystem. I see it as a double edged sword. Take the example of handling asynchronous operations - async/await is good solution for that. But now you will be working in code bases with callbacks, promises, async/await, and possibly even generators - with generators being an example of an area that was not a clear improvement in the right direction, but an experiment now obsolete because of async/await. I'm a fan of improvement, but nowadays I try not to pick up the latest trend for concern that it might be obsolete in the near future. You demonstrate this - you picked something you like (ember) and just stuck with it. Ember solves problems, it works, no reason to refactor your ember projects to react.

cpr 6y ago
Quite the contrary: Generators are quite useful in their own right, independently of asynchronicity.

lhorie 6y ago

> That's not how I've seen it, since a lot of problems [...] have been solved "Solved" is an overstatement. The javascript ecosystem is house of cards. Modularity is far from solved, for example support for the browser field in package.json is all over the place, hoisting leading to phantom dependency bugs is another clusterfuck. A large number of popular packages want to own module resolution or parsing or both (jest, typescript, CRA, storybook, yarn v2, to name just a few), leading to inconsistencies between tools. Not too long, create-react-app broke because of some oversight from some library author over some package.json field lead to a broken publish. Bizarre bugs from the tree-shaking vs side effects dichotomy. The existence of things like yarn resolutions and patch-package and proxyquire. Abysmal symlink support. The list just goes on and on. You _can_ get little pockets of very tightly integrated experience w/ comprehensive toolsets like Angular, Ember or to some extent CRA, but if you need to venture outside in a non-trivial way, the pain of fragmentation is real.

ravenstine 6y ago
Those are mostly problems with Node.js, not JavaScript itself. But fair point since they are part of the JavaScript ecosystem and I did mention a framework. The different module implementations are a problem, but at least there's a standard that they are mostly emulating now and native support will eventually work and be adopted, especially with HTTP2+. "Solved" might be an overstatement, but there's still been a ton of improvement. ES5 is a madhouse compared to what we have now.