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

I think a lot of that has to do with the language changes that came about with ES2015. Before, we were basically stuck with ES5 and ES3, which aren't that great to work with and limited what you could do (easily, at least).

The stuff coming down the pipe (mainly modules, but a lot of ES2017) is really going to get the language to the level where it's going to be natively capable of even supporting a framework on the level of Rails.

My (very) personal opinion: I think, the culture is a important factor here.

There are very great developers in the ecosystem, who write great tools and libraries which become popular, are well maintained and documented. But the majority of the developers are just average developers. As everyone, they attend conferences and bootcamps, and when I then talk to them, the usual thing they learned there were two things: (1) make a blog and write about what you are doing and (2) make some OSS projects or participate in existing projects.

It is very great to have people who create projects and bring in new ideas, it helps create a mature technology. But the truth is, most of the average developers have never been in larger projects, have never been digging into complicated/large open source libraries and have never had to manage larger applications. One of the most important things you learn in such projects is to be calm and think about documentation, architecture and dependencies carefully.

And this leads to the current situation;

- we have a lot of libraries doing the same things, just because developers do this "just create an oss project on GitHub/npmjs" thing without searching for existing solutions

- some hip developers have so many projects that I always ask myself how they are planning to support all these

- when a problem arises, e.g. a bug in a library, many developers these days seem to tend to write their on lib fixing that problem (if it is a small library) or building an internal workaround instead of contributing back to the original project

- on the other hand, there are a lot of project maintainers who ignore issues and pull requests just because they have a very strong opinion about what their library is doing. Oh boy, sometimes it took me days to write a PR which (from my point of view) improved something or added a new feature, carefully followed existing guidelines (code formatting, docs, etc) just to get the answer "nah, that's not my scope. Fork the project or write your own"

- it seems to be easier to convince people with less business experience. They often jump on the next hot train coming along that sounds good. I don't want to exclude me here completely; as I read about React, it started working with it directly - because it seems to solve all the problems I had with Angular and Backbone

- I have the feeling that a lot of developers today (still) have this "read the f*g code" mentality. Even mature libraries developed for years have so bad documentation (even though they have their own .io domain just for it) that I have to read their source to see what parameters I can pass into a function.

I think, browsers/engines/tech companies/... are also part of the problem. For years, JavaScript has been "developed" (language spec) slowly and browser have been adopting features slowly. But then, suddenly, everything exploded. And now we have very awesome features in the language that allow for things that have not been possible before. And in fact, these features deprecate some libraries or frameworks. And instead of abandoning a project by deciding that only bugs will be fixed in the future and no new features will be added, the developers either try to move to the new technology with their product; or are forked by people who were part of the project but didn't like its developers/strategy/whatever and want to use the new opportunity with the new language feature to change things; or get company by another project that does basically the same but started from scratch and uses all new language features; or all together.

As a side note, I work with JavaScript every day and that is only my opinion on the topic. Please don't feel offended.

[edit: typos and formatting]

Yeah, it's very true that JS is much more of a Lisp than a curly-brace language, despite its syntax. But I think the reference is still fitting because JS is an absolutely terrible Lisp. :)

And the story of JS interpreters, JITs, etc. in browsers (and not in browsers) matches the story of C compilers in the essay, just with changes in timing:

C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language. [...]

Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.

The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.

"What's wrong with native apps?" Can you even imagine having a native app for everything we do today in browsers? An app for each Credit Card I hold. A native app for each news site I read. A native app for every social media site. A native app for all the map searches, directions, etc. we all use. Security updates? Nightmare. Multi-OS support? forget about it. We'd all be back to a Windows monopoly. No thanks.

I have gotten to hate most Android apps, constantly sending notifications - spam on the screen, phone on the desk going "ding, ding, ding" all afternoon :-(