10 ShinyNewJSFramework = 1
    20 Use framework
    30 Do conference speech about how much better it is than JQuery
    40 Hit problem X
    50 Find ShinyNewJSFramework is nigh impossible to debug
    60 Eventually come to loathe framework because of problem X
    70 ShinyNewJSFramework += 1
    80 GOTO 20

I am intrigued and ponder the idea of there being "JS Standard Libs" and wonder which ones will initially get picked for the honor. I don't think it will be React or Angular but definitely "something" like them, even if it is a version of Web Components.

That'll also mark a huge change in performance and download metrics, because if your browser already has your framework built in, your delivered code base is suddenly a fraction of what it was. And then there will be more opportunities there, too - dynamically providing the framework where needed in a separate code split, vs. a browser that does not need it.

We're just at the beginning, really. Browsers stalled for 15 years and have shifted into a period of innovation again.

  Segmentation fault. Core dumped.
  $ ls
  brain.core

I've specifically tried to avoid Choo/Vue/Whatever until there has been real traction in the job market and the community behind that framework. BUT the move from each 'framework' to the next has been a revelation in how to do things better.

I feel comfortable now that React is delivering an ecosystem that is going from strength to strength and has brought a maturity to the front-end javascript ecosystem that was missing. Huge props to the community for that.

- why can't old libraries/frameworks/things evolve, instead of forcing a breaking change? In many other languages evolution seems to preferred to revolution; in JS, evolution seems to be the norm.

- Is that "better and smarter way of working" THAT MUCH BETTER AND SMARTER? When working JS, it seems that a complete overhaul of an application (or of an ecosystem) is required every very few years. Ultimately, software development should lead to business value; does the improvement in generated business value justify the costs associated with such a tech twirl?

Absolutely yes. ReactJS is an application architecture that is a complete rethink of how to structure client side applications, and it is an architecture that is being applied outside JS and the browser because it is so much better. The fundamental concept of one way data flow from parent to child through the application requires a start from scratch approach, and would be severely compromised were it to be implemented as an "additional" evolution of some existing application framework such as AngularJS. Yes - that much better and smarter.

ES2015/ES7 are radically better languages that make hugely important changes to JavaScript. Yes - that much better and smarter.

Transpilers make it possible to run ES2015/ES7 even on browsers that support only ES5 - that is amazing - yes - that much better and smarter.

Build tools such as minifiers and packers and uglifiers perform magic to shrink and optimise code for a range of benefits including end users performance - Yes - that much better and smarter than sending a chunk of raw JS to the browser.

In short, yes, JavaScript is experiencing a continuous wave of really major and significant improvements that justify ditching the previous generation entirely.

I will say however that breaking changes give me the shits abut for the most part I am willing to endure them - I simply must assume that the changes are for the better because I don't have time to really understand every single change in every library that goes into my application - no JavaScript developer does - nor indeed does any Python developer try to understand every change to all the Python libs that they use.

Look at Android for comparison:

- ReactJS: React Native, also any overall architecture like MVVM or MVP.

- ES2015/ES7: JDK 7/8

- Transpilers: Kotlin

- Minifiers/packers: proguard and others

- Gulp and co.: gradle

- Other libraries: android has a number of libraries to handle network requests, image loading, animations etc.

What I'm trying to put across is that JS has transitioned from a language that would show and hide elements of the DOM to a serious language used everywhere.

A good developer takes the time to understand the tooling around their platform and language.

I have just inherited a project written in 100% ES5 and I had forgotten how obscenely verbose JS <= ES5 really was. Every extra line of code is a liability and will slow down app development. Language features support precision and conciseness and that in turn promotes enterprise-level development. A toy language (old JS) can never support a full in-browser application.

Scala, Purescript, Haskell, Elm, ...

1. By far, has the largest ecosystem.

2. If you use a linter, a typechecker (TS or flow), and transpile your code (TS or babel or both), JavaScript is actually a pretty nice language to work in.

Sure it's a chore to set up all the initial tooling, and learn the ins and outs. However, once you're past that, it's usually not worth it to switch.

2. It's still far from the state of the art in PL design and missing:

* Nice static typing with type inference

* Nice guarantees about null access

* Nice guarantees about interop between client and server

* ...

>However, once you're past that, it's usually not worth it to switch.

That is somewhat circular and can be said of virtually anything. That is, for every minute you invest in a tech, the degree to which it is worthwhile to switch to another tech diminishes. I'm speaking primarily about tech like frameworks that is aimed at making us more productive.

The exception might be a truly revolutionary new tech that sharply boosts productivity, but also has a very low learning curve. However, that scenario seems particularly unicorn-ish where JS frameworks are concerned.

But especially when you are working with other developers and a mixture of skill levels, impedance mismatches are useful paper-cuts to try to minimize.

I agree, it's not a strong argument, but it is an applicable argument to the discussion. There are trade-offs in every decision, and this is a consideration in those trade-offs.

With javascript, as far as a I can tell, "change in a library" means you do indeed throw out the library and adopt a new one, then write your entire code again from scratch and repeat the cycle next year. To me, that sounds like madness and just makes me happy I don't have to deal with all this.

Reality is very different from these discussions.

You can with a 10 line HTML file and linking a few CDNs make an interactive application that can reach 1 billion people with no install and no buffer overflows. That's magic. The 90s wish they could do that.