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

JavaScript is being redefined. The language is flexible enough because of prototypal inheritance that every method can be redefined at runtime. ES6 added many missing features.

That's unusual. These frameworks extend the language. Angular's developers reasoned that anyone smart enough to figure out Angular 1 will be able to migrate their code to Angular 2. It's looking more like C++ and less like CSS. :)

Take a look at Meteor's code sometime. It does things I never expected possible with JavaScript.

First, Web technologies (not just JS but HTML, CSS, DOM, etc) are implemented by multiple browsers, who compete and have other agendas, as well as backend and non-Web platforms. This underlying technologies are just messy in a way that only a world-wide, massively distributed, twenty-year-old platform can be.

There's nothing quite like this anywhere else in tech, as most platforms are dominated by a single vendor. Imagine what Windows development would be like if, in addition to the need for backwards compatibility, there were three or four competing vendors of Windows, each with different feature sets and bugs.

Second, tools and libraries can overcome many of these problems, but these fixes come with costs, including library maintenance, cognitive overhead, security risks, complex build and deployment processes, and retraining and hiring issues. Because JavaScript is used across many industries and teams of all sizes, what is perfect for one may be completely inappropriate for another. Many projects, like GWT, meet the needs of the environments in which they were designed, while being so much a product of those environments that they become anti-productive elsewhere. So we have a very diverse set of tools on top of a very messy and relatively old set of underlying technologies.

Finally, many new programmers come into this incredibly diverse, sometimes frustrating, environment every year. It is an environment that encourages open-source contribution. It's no surprise that many new tools and libraries are released every year, and some of them gain adoption.

> For example angular 2 is not compatible with angular 1

That's not the problem, angular 1 and angular 2 are 2 completely different frameworks that share the name and the team only. The team wanted to piggyback on the fame of the first version, but they share absolutely nothing conceptually. and contrary to what the Angular team says there is no "upgrade path", you need to learn the stuff from scratch once again.

The problem is, and the Angular team will find out very soon, "second systems" unless they provide huge advantages over the first version, are always a failure.

I think all the churn is a sign of several problems. First, the language was not designed to do what people are trying to use it for. Second, I question whether the framework makers are familiar with "native" UI APIs (e.g. Java, Qt, NextStep), which solved a lot of these problems years ago. Notice the lack of churn in native UI APIs (exception of Microsoft). Third, it seems like the frameworks try to build on top of HTML, which I think is a mistake, because HTML was not designed for layout flexibility and pixel-perfectness (unlike native widget APIs). Furthermore, HTML was poorly designed for anything but simple word-processor documents: why is there no element that is inline-block?! That's the first thing I end up assigning to everything. But the whole declare-your-document approach is inherently too simplistic for much beyond a word-processor document. Note that PostScript, and PDF which is an enhancement, has been pretty stable and standard for years, which indicates it is a good solution to the problem. Ultimately, you need to be able to program your documents and put pixels exactly where you want them. But even just sending over a blank HTML page and then having JavaScript add everything programmatically is probably better-suited, despite having to ultimately get squeezed into the HTML approach.

In my opinion, we need to realize that webapps are not documents, and document-oriented HTML is the wrong tool. I don't think things will get better until we start looking at webapps as essentially drawing on the screen, like native UI APIs. I think we need a standardized virtual machine, like a lightweight JVM (or, better, a heavyweight Lua), which would allow people to use whatever language they prefer, as long as it can compile onto the instruction set. Static-type people can use a statically-typed language, and dynamic types can use dynamically-typed languages. Make an instruction set that maps well onto native CPU instructions, and provide well-thought out input and drawing primitives. We essentially need a PostScript for apps.

Because when asked if (9999999999999999 == 10000000000000000), they return true.