Live data from Hacker News

Ask HN: Why is everything in JavaScript changing so fast?

news.ycombinator.com

1–10 of 303 posts

Ask HN: Why is everything in JavaScript changing so fast?

#1
Change and variety of options is a good thing, but in js the rate of change in methodologies, frameworks, libraries is so much high. For example angular 2 is not compatible with angular 1, so before you even learn a framework its API is different and when you finally learn it, probably is considered outdated. Why is this happening especially in js?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#3
post #2

I've wondered the same thing. My guess is that it's because node is still pretty new, whereas most other popular languages have been around for a while and the "right" way to do things has already reached some consensus.

I wonder id its worth to learn all those cutting edge libraries now, because whatever code I write today maybe outdated next month and I'll have to learn yet another framework/library/syntax etc.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#4
It may not be the common view, but I think that what you are witnessing is, to a certain extent, "deliberate".

Every framework has a "sponsor". Every strong "sponsor" either has a vested interest in the web, or, a vested interest in some other platform with which the web competes.

The importance and power of the web are obvious. So, it is a dance. "Embrace, extend and extinguish". And, hop, here we go again.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#5
I think it's because of certain new paradigms that are opening up so many opportunities.

With HTML5, CSS3 and ES6 being released, and seeing wide adoption, the web-application layer and APIs suddenly have access to a magnitude more functionality, and we're essentially in the early romantic period where we're pushing these new features to the max, and figuring out what sticks.

Over the next year, we'll settle at the maxima of efficiency and usefulness with the web framework. Despite some negative voices, IMO these are very exciting times for the web :)

Re: Ask HN: Why is everything in JavaScript changing so fast?

#6
One could make the argument that the JavaScript / Node.js community are uber early adopters and push technology more often and further, but I'm not certain that is what is really going on.

However, moving fast does percolate down from the top. Look at Node.js and how often they release new versions.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#8

I'd say the opposite - it's changing way to slow - at least in browsers, where IMHO is the only rational place to use JavaScript. The big change will be the arrival of webassembly.

Mind sharing why you consider node.js and other server-side javascript tools irrational?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#9
I think it's because of historic baggage and politics.

JS used to be a horrible ecosystem where different browsers behaved differently, the language itself had various pitfalls and most code was written in classical script kiddie style. This has been changing for the better for a long time in small steps, but frankly something has always sucked, warranting the next evolution.

The second point is politics: JS is huge these days, and there's still a lot of room for improvement. Everyone wants to be the company behind the de facto standard library for web apps.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#10

I'd say the opposite - it's changing way to slow - at least in browsers, where IMHO is the only rational place to use JavaScript. The big change will be the arrival of webassembly.

Mind sharing why you consider node.js and other server-side javascript tools irrational?

For APIs the lack of typing hurts; only that is now no argument because it is fixed by TypeScript / Babel.

Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints.

Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).

Post reply on HN