4 ms·

Just like when Meteor was the hottest kid on the block, ES6 came along and pulled the rug out from under me. Now that I'm finally used to ES6, here comes some

Just like when Meteor was the hottest kid on the block, ES6 came along and pulled the rug out from under me. Now that I'm finally used to ES6, here comes some other frankenstein with more flesh bolted on. At what point will Javascript relax and stop reinventing itself and what works? When will stability become a core goal for the Javascript thought-leaders? I haven't worked with .NET and C# for years but I bet I could feel right at home today. I couldn't say the same for Javascript.

eindbaas 9y ago
Why does your app have to be bleeding-edge?
- sergiotapia 9y ago
  If I hadn't migrated to ES6, I would not have been able to use some javascript packages I enjoy. For example: https://github.com/JedWatson/react-select https://github.com/JedWatson/react-select
  - dalailambda 9y ago
    There doesn't seem to be any part of that package that requires ES6 to use. You can use it as an ES6 module, but the commonjs version should work fine as well.
  - tlrobinson 9y ago
    You can transpile dependencies without migrating your whole app (though I'm not sure why you would)
sim0n 9y ago
You don't have to use the hottest new framework or language feature. The JavaScript you're writing now will still be supported while the language evolves and improves.
- kuschku 9y ago
  Nice idea, but false. Your code depends on libraries and frameworks, which constantly change and adapt to the the mood of the time.
  - tlrobinson 9y ago
    So transpile the library. Webpack and others can do it.
    - zmmmmm 9y ago
      If it was just about transpiling, that would be fine. The problem is that some frameworks (eg: React) add on a whole lot more assumptions about how how your app works. Just look at the plethora of blog posts, tutorials and even whole mini-frameworks just to get d3 to work with React.
  - octalmage 9y ago
    Many libraries that use ES6 features distribute the transpiled version through npm or GitHub. If they don't, you can just transpile the library using Webpack then use that. Or you could use codemods to update your code base in an automated way. See: https://github.com/cpojer/js-codemod https://github.com/cpojer/js-codemod
rimliu 9y ago
> At what point will Javascript relax and stop reinventing > itself and what works? I am afraid part of the reason for this is continuous effort to put a square peg into a round hole (by this I mean the "web for everything, JS for everything" attitude), so it will go on for a while.
tlrobinson 9y ago
Before ~2015: "JavaScript is a terrible language!" After ~2016: "Stop improving JavaScript, I can't keep up!" (Not a personal attack, just general sentiment I've observed)
- _pmf_ 9y ago
  To be fair, those are not mutually exclusive options.
- camus2 9y ago
  > After ~2016: "Stop improving JavaScript, I can't keep up!" The bad parts are still here that's the problem. The language didn't improve so much that it got new features. But var, ==, type coercion and co still exist.
  - aaron-lebo 9y ago
    So use a linter which disallows var and some of the worst usages and and use libraries which make up where it's lacking. It's the price of improving the language + backwards compatibility.
    - camus2 9y ago
      A linter never fixed the runtime behavior of a language, this is beside the point. The point is the assumption that Javascript is a better language today.
      - aaron-lebo 9y ago
        You mentioned var, let exists to fix those issues, hence the language just in that one area is better.
  - Vinnl 9y ago
    > But var, ==, type coercion and co still exist. They all have alternatives, and linters can help restrict you to those alternatives. As a developer, that makes it pretty doable. I presume you too can appreciate why they can't simply be removed.
BillinghamJ 9y ago
> I haven't worked with .NET and C# for years but I bet I could feel right at home today You'd be surprised. It is shockingly different now - they are in the early stages of exactly what happened to JS. I'm sure the outcome will be really beneficial for everyone, but at the moment it's very confusing if you aren't constantly monitoring it and keeping up-to-date.
pluma 9y ago
Your mistake was picking Meteor because it was "the hottest kid on the block". It never was as popular as it was made out to be, it was just hyped to no end and super appealing to people who were new to JS (because realtime/webscale/buzzwords). Today Meteor has mostly overcome its initial NIH obsession and thus mostly become irrelevant unless you're already a Meteor user. It's never the right choice to jump on whatever bandwagon is all the rage at any given moment. Just look at what's been around and is still seeing active development if you want something with a long lifetime. Personally to a newcomer to JS who wants something that'll work for a while I would probably recommend Ember or if they want something slightly more newsworthy I would recommend Angular. On the other hand if you want to learn JS as a language and aren't afraid to go through a number of iterations of picking and discarding libraries, I would recommend what I prefer myself: React, followed up by Redux once you've outgrown toy applications.

eindbaas 9y ago

Why does your app have to be bleeding-edge?

sergiotapia 9y ago
If I hadn't migrated to ES6, I would not have been able to use some javascript packages I enjoy. For example: https://github.com/JedWatson/react-select https://github.com/JedWatson/react-select
- dalailambda 9y ago
  There doesn't seem to be any part of that package that requires ES6 to use. You can use it as an ES6 module, but the commonjs version should work fine as well.
- tlrobinson 9y ago
  You can transpile dependencies without migrating your whole app (though I'm not sure why you would)

sim0n 9y ago

You don't have to use the hottest new framework or language feature. The JavaScript you're writing now will still be supported while the language evolves and improves.

kuschku 9y ago
Nice idea, but false. Your code depends on libraries and frameworks, which constantly change and adapt to the the mood of the time.
- tlrobinson 9y ago
  So transpile the library. Webpack and others can do it.
  - zmmmmm 9y ago
    If it was just about transpiling, that would be fine. The problem is that some frameworks (eg: React) add on a whole lot more assumptions about how how your app works. Just look at the plethora of blog posts, tutorials and even whole mini-frameworks just to get d3 to work with React.
- octalmage 9y ago
  Many libraries that use ES6 features distribute the transpiled version through npm or GitHub. If they don't, you can just transpile the library using Webpack then use that. Or you could use codemods to update your code base in an automated way. See: https://github.com/cpojer/js-codemod https://github.com/cpojer/js-codemod

rimliu 9y ago

> At what point will Javascript relax and stop reinventing > itself and what works? I am afraid part of the reason for this is continuous effort to put a square peg into a round hole (by this I mean the "web for everything, JS for everything" attitude), so it will go on for a while.

tlrobinson 9y ago

Before ~2015: "JavaScript is a terrible language!" After ~2016: "Stop improving JavaScript, I can't keep up!" (Not a personal attack, just general sentiment I've observed)

_pmf_ 9y ago
To be fair, those are not mutually exclusive options.
camus2 9y ago
> After ~2016: "Stop improving JavaScript, I can't keep up!" The bad parts are still here that's the problem. The language didn't improve so much that it got new features. But var, ==, type coercion and co still exist.
- aaron-lebo 9y ago
  So use a linter which disallows var and some of the worst usages and and use libraries which make up where it's lacking. It's the price of improving the language + backwards compatibility.
  - camus2 9y ago
    A linter never fixed the runtime behavior of a language, this is beside the point. The point is the assumption that Javascript is a better language today.
    - aaron-lebo 9y ago
      You mentioned var, let exists to fix those issues, hence the language just in that one area is better.
- Vinnl 9y ago
  > But var, ==, type coercion and co still exist. They all have alternatives, and linters can help restrict you to those alternatives. As a developer, that makes it pretty doable. I presume you too can appreciate why they can't simply be removed.

BillinghamJ 9y ago

> I haven't worked with .NET and C# for years but I bet I could feel right at home today You'd be surprised. It is shockingly different now - they are in the early stages of exactly what happened to JS. I'm sure the outcome will be really beneficial for everyone, but at the moment it's very confusing if you aren't constantly monitoring it and keeping up-to-date.

pluma 9y ago

Your mistake was picking Meteor because it was "the hottest kid on the block". It never was as popular as it was made out to be, it was just hyped to no end and super appealing to people who were new to JS (because realtime/webscale/buzzwords). Today Meteor has mostly overcome its initial NIH obsession and thus mostly become irrelevant unless you're already a Meteor user. It's never the right choice to jump on whatever bandwagon is all the rage at any given moment. Just look at what's been around and is still seeing active development if you want something with a long lifetime. Personally to a newcomer to JS who wants something that'll work for a while I would probably recommend Ember or if they want something slightly more newsworthy I would recommend Angular. On the other hand if you want to learn JS as a language and aren't afraid to go through a number of iterations of picking and discarding libraries, I would recommend what I prefer myself: React, followed up by Redux once you've outgrown toy applications.