2015 JavaScript or "pro-Library and far frame"

The JavaScript world seems to be entering a crisis of churn rate (loss rate), in which frameworks and technologies are squeezed out and disappear at an unsustainable rate. But I think society will adapt and adopt new practices to respond to this situation. Developers will shift their goals from the consolidation framework (such as Angular.js and Ember) to a variety of small proprietary library mixes to mitigate production risks and address different issues from external competition.

Loss

2014 years on, it's hard for a JavaScript developer to "undo" a particular library or technology, even a powerful angular, seemingly shaken by recent events.

At the Ng-europe meeting in October 2014, the angular developer team revealed a major update on the Angular 2.0 roadmap. One of the most controversial messages is that NG2.0 will be "backwards incompatible" with the existing angular code. In fact, several key concepts will be discarded in the new architecture, angular developers need to effectively master the new framework.

Clearly, this move has made many people dissatisfied. Is it right or wrong? We don't know, but it feels like the knowledge, practice, and code of the angular developers over the past two years have been arbitrarily discarded. To make matters worse, substitutes are not imminent--this should be a year from now, and opponents believe that once Angular 2.0 was released in 2015, the new project in the hands of developers would experience the fate of "from Birth to death".

There are a lot of unpleasant comments pointing specifically to angular and Google, some of which are pertinent, and some may not. But one of the highest votes was not about angular. It points to the entire JavaScript environment, Reddit's Othermike commented:

I don't understand, I don't understand why some people think it's a good idea, it's scary, because no one has time to understand it, when it changes every 30 seconds.

The problem that othermike reflects is also the problem of loss, too many JavaScript frameworks have changed too quickly.

Is the speed of this change sustainable?

Innovation is great, but this kind of churn rate seems too much, and when the life of the innovation is not guaranteed, it not only makes it impossible for the developer to be big, but also increases the upfront time input--mastering the new framework and technology. Programmers want to create things and become masters of things. But how do programmers get things done when they spend a lot of time learning? How to explore in the dark through unfamiliar technology?

No need to despair

It's bad, but people are smart, developers are resourceful, and the need to write new apps won't let anyone give up, so what do we need to do? Perhaps we can take the following three major lessons:

Treat the new technology with a healthy skepticism. Carefully put the new GitHub project into the product, waiting for something to be generic, bug-corrected, and proven to be no doubt mature.

Don't trust the company's support. Google was not the first to "undercut" the ecosystem that developers relied on. Ask the developers who use Google's Web API to find out. There are always irrational behaviors in the company, and their interests don't always coincide with yours.

More inclined to a specialized library than the overall framework. When you choose a frame, it means that you have made a big, long-term commitment. However, once the framework is proven wrong, you will lose a lot, but if you choose from the library, you can replace part of the front-end stack while retaining the rest.

Library > framework?

In the angular controversy, the Reddit website thread has this question: what technology does JavaScript developers feel like migrating to? Here's what R/javascript has to say:

React.js and Flux (a library and event-driven module with only view view-only)

Ember.js (MVC framework)

Knockout.js (View Gallery)

Backbone.js (MVC framework)

Meteor (Homogeneous frame)

Mithril (MVC framework)

Ember (MVC framework)

No frames, just a bunch of libraries to

Vue.js (View Gallery)

Breeze.js (Database model-only)

Ractive (View Gallery)

Interestingly, the number of options here is not a mature framework, but a professional library--primarily for data-bound DOM. It was suggested that "in the absence of an overall framework, it would be better to do one thing in the case of modular components." "That's what he said:

I really think that's the best answer. There will never be a perfect frame, so you can only use NPM to bring together the relevant features. I found that the documentation for these small components is usually very simple, and you don't have to wait for the next full frame release. You simply throw a question, the author fixes it, pushes it to NPM without disturbing the other components.

If you find that you don't like the tooling language or error handling, you don't have to think about the whole project, just replace the current component in your own way.

I don't know how you feel. Make selection and blending possible by using a small library. By then, when they are replaced, we can swap the front-end stacks with similar. The library is no longer an "either or" proposition, if you prefer angular control to reverse the container, but do not like its data binding. You can choose from NPM in a way that you like data binding. You can incrementally migrate your legacy projects to new technologies, rather than writing them back on the side.

More importantly, when different questions are answered by different libraries, their solutions can be directly compared. If frame A is good for x, it's bad for y, and frame B is quite the opposite, you'll be confused. However, if both libraries A and B are trying to use X, they will be compared in a direct way to independent parts and measurable aspects.

Summarize

The loss rate of front-end JavaScript technology is problematic

People began to tire of the pace of change, forced to alienate

The answer may be "pro-Library and far frame"

Of course, in 2015, how much will we see actually happening? Angular's dominance is entirely likely to remain stable, and if so, the angular needs to seek standards and stabilize the "turmoil" of the last two years. There is, of course, another possibility that there will be bigger things instead of angular positions. An informal combination of flux and browserify seems to be a very obvious candidate.