4 ms·

I think that the feeling of "too much churn" that surrounds JS development is really people not fully realizing two things: 1 - the magnitude of the language's

I think that the feeling of "too much churn" that surrounds JS development is really people not fully realizing two things: 1 - the magnitude of the language's popularity. 2 - just how young modern javascript really is. Javascript is either the most popular language in the world, or the second most popular after C. Even in in Java's height somewhere in the early 2000s it was never as popular as JS is right now, and it was much more homogeneous in terms of developers - js is written by designers, people with no formal education, even children. Modern javascript is only a few years old, even jQuery came out just 10 years ago, but javascript that was used not as a scripting language really only came with the popularity of chrome and SPAs, somewhere around 6-7 years ago. Taking these things into perspective, I don't think it's reasonable to expect (or request) for JS development to stabilize - Java is still not stable 20 years in, and it was in a similar state of upheaval as JS as recent as 8 years ago. C is so decentralized that we don't even think about it's stability the same way we do other languages - there were (and maybe still are) multiple competing standards for the language itself, and compilers regularly won't compile code that works in other compilers.

pdimitar 9y ago
It's not about (1) other languages having trouble as well, and (2) it sure as hell is not about JS being very popular. It's about this: I wrote a module for my project, I want to import it in my project and everywhere else where it might be useful, in one, SINGULAR way, which doesn't change for at least 18 months, please. I'd like to be able to write ES 2016/2017 and not caring how it gets compiled to ES5; can't you people just finally agree on one way of doing things? You people who mostly (or exclusively) code JS simply don't understand that many of us code in 5+ languages every week and we want to be productive. If I have to read on a new standard and a new and shiny way of managing dependencies every 8-10 weeks and if you think that's okay, then you seem to fail to grasp how unproductive this is. For you it might be a full-time job. For me, and many others, it's a distraction because we have to do a lot of stuff in several languages and we'd much appreciate it if the JS folk would just calm the hell down for a bit.
- bryanlarsen 9y ago
  The article explains the approach that the node.js ecosystem is taking to bend over backwards and maintain full backwards compatibility. Javascript from 1997 still works; write your code 2015 style and it'll still work 20 years from now. You don't have to live on the bleeding edge -- you'll lose tree shaking but you'll gain some sanity.
  - pdimitar 9y ago
    No disagreement on that point. I am talking about new and maintenance projects. My pet peeve is "just install this, just use that, oh and by the way also definitely install this" for things that should either be built-in, or well-standardized (minifiers, tree-shaking, transpiling). And they are not. If I get into a new team and there are 3 devs already writing JS, it's highly unproductive because it feels like you have to very regularly catch up with the JS ecosystem. Not to mention the strong peer-pressure factor of "cool kids use X, Y or Z". And this is a very underestimated phenomena by so many devs -- and it exists in almost every team.
    - bryanlarsen 9y ago
      "minifiers, tree-shaking, transpiling" should not have been part of 1997 Javascript so they have to be added at some point. And this post is part of that standardization that you're asking for.

pdimitar 9y ago

It's not about (1) other languages having trouble as well, and (2) it sure as hell is not about JS being very popular. It's about this: I wrote a module for my project, I want to import it in my project and everywhere else where it might be useful, in one, SINGULAR way, which doesn't change for at least 18 months, please. I'd like to be able to write ES 2016/2017 and not caring how it gets compiled to ES5; can't you people just finally agree on one way of doing things? You people who mostly (or exclusively) code JS simply don't understand that many of us code in 5+ languages every week and we want to be productive. If I have to read on a new standard and a new and shiny way of managing dependencies every 8-10 weeks and if you think that's okay, then you seem to fail to grasp how unproductive this is. For you it might be a full-time job. For me, and many others, it's a distraction because we have to do a lot of stuff in several languages and we'd much appreciate it if the JS folk would just calm the hell down for a bit.

bryanlarsen 9y ago
The article explains the approach that the node.js ecosystem is taking to bend over backwards and maintain full backwards compatibility. Javascript from 1997 still works; write your code 2015 style and it'll still work 20 years from now. You don't have to live on the bleeding edge -- you'll lose tree shaking but you'll gain some sanity.
- pdimitar 9y ago
  No disagreement on that point. I am talking about new and maintenance projects. My pet peeve is "just install this, just use that, oh and by the way also definitely install this" for things that should either be built-in, or well-standardized (minifiers, tree-shaking, transpiling). And they are not. If I get into a new team and there are 3 devs already writing JS, it's highly unproductive because it feels like you have to very regularly catch up with the JS ecosystem. Not to mention the strong peer-pressure factor of "cool kids use X, Y or Z". And this is a very underestimated phenomena by so many devs -- and it exists in almost every team.
  - bryanlarsen 9y ago
    "minifiers, tree-shaking, transpiling" should not have been part of 1997 Javascript so they have to be added at some point. And this post is part of that standardization that you're asking for.