2016 JavaScript technology Stack Outlook

If you are planning a new front-end project or refactoring an existing project, you need to realize that the current front-end development environment is not the same, there are too many options: React, Flux, Angular, Aurelia, Mocha, Jasmine, Babel, TypeScript, Flow ... Their intention is to simplify the development, but virtually improve the cost of learning, but also to the maintenance of future projects has brought uncertainty.

Fortunately, this phenomenon is the fever, the survival of the fittest, excellent project slowly settling down, the development of the way is more and more clear. Some developers are trying to use a framework based on these technologies to develop, and to a certain extent, reduce the cost of learning.

This article mainly introduces some of the technologies I have involved in WEB application development, some of which are technically controversial, so I will only do a brief introduction and analysis of each technology. All of these ideas are based on my personal experience and contact with the community, so you are also requested to take the necessary.

React

React is a moment of no two:

• Components make applications easier to develop and maintain

• Smooth learning curve, simple and clear core API, easy to learn

• JSX Grammar unconventional, giving full play to the power of JavaScript

• Natural adaptation to Flux and Redux

• The community is active and creative, giving a lot of good development tools

• One-way data streams are more suitable for complex applications than two-way data binding, with higher quality

• Support for service-side rendering

Although React is not all-powerful compared to Ember, Aurelia and Angular, the React development environment is more robust. For now, using React is not a technology choice, but a business activity that provides more efficient and efficient productivity.

When you want to develop mobile applications, because you have learned the React syntax, you can directly get started React Native to develop cross-platform applications.

Redux

Now that we have the ability to develop the view layer, we need to use other tools to manage the state and life cycle in the application, and the recommended tool here is: Redux.

In order to work with React,facebook to develop a tool flux for managing one-way data streams, although flux basically supports single data streams, it also brings other problems, such as how to save states, where to initiate Ajax requests, and so on.

In order to solve these problems, it also derived a series of frameworks to emulate the Flux pattern: fluxible, reflux, Alt, Flummox, Lux, nuclear, fluxxor ...

One implementation that is widely supported by the development community at the moment is Redux.

In Redux, most of the components are purely functional components, and there is only one centralized storage and resource center. The Redux instance method is responsible for the operation and maintenance of the entire data. Redux's thinking is clearer than Flux.

More importantly, Redux is very easy to learn. Redux's author, Dan Abramov, is an excellent teacher who has produced a series of Redux video tutorials. By watching these videos, you can become an expert in Redux. I've seen a 0-based React team quickly developed beta products in just a few weeks, and the code is very robust and sophisticated.

The ecosystem around Redux is as strong as the Redux itself. From magical devtool to powerful memory tools, the Reselect,redux development community provides developers with all the tools they need.

Developers may instinctively try to abstract out a Redux template, which has many benefits, but please encapsulate the template on the basis of understanding the requirements, rather than trying blindly.

ES6 and Babel

It's time to abandon Coffeescript because its many features have similar syntax in ES6, and ES6 is the implementation standard that represents the future direction of JavaScript.

Most of the features of ES6 are now supported by the latest browsers. Babel is a powerful conversion tool for converting ES6 to ES5. In addition, you can adjust the amount of code conversions based on the target browser.

So is there a type system? TypeScript and Flow both provide a static type system for JavaScript, and use static type checking to effectively catch errors and reduce the amount of testing. For the time being, I suggest a wait-and-see attitude.

TypeScript is trying to make JavaScript evolve in the direction of C # or Java, but lacks many advanced types of system features, such as algebraic data types (algebraic-types). In addition, it cannot handle NULL as effectively as Flow.

In contrast, Flow is more powerful and captures more error types, but is difficult to configure. In addition, its support for new JavaScript features is weaker than Babel and does not support Windows systems.

As far as I am concerned, the type system in front-end development is not a critical one (it may be controversial here). Before the type system is more robust and friendlier to Babel, let's just wait and watch it change.

ESLint

Another undisputed tool is ESLint. ESLint supports the ES6 syntax and also provides the React plugin, which is not just a code review tool. At present, JSLint is outdated, ESLint can replace Jshint and Jscs unique.

Developers can configure ESLint to suit their needs, but here I recommend configuring it according to Airbnb's development specifications or using ESLint Airbnb config directly. Of course, there are deficiencies in this specification, but maintaining the consistency of the overall code of the team can effectively improve the readability of the code.

When you are familiar with ESLint, it is recommended that the developer try out the rules in depth. The more errors The ESLint captures, the greater the stability of the product.

Npm,commonjs and ES6 Modules

Forget Bower, take over all with NPM. Building tools like browserify and Webpack indirectly improve NPM's position in web development. With NPM, version management will be simpler and more accessible to the node. JS ecosystem. At present, the processing of CSS is not perfect enough.

You might consider how to perform the build on the deployment server? Unlike Ruby's bundler, NPM uses wildcard characters to retrieve files, and third-party packages can be arbitrarily modified in code development and before the project is released. Using the Shrinkwrap file to freeze third-party dependencies in your project, I recommend using the user's shrinkwrap to improve output consistency. In addition, developers can also consider using tools like Sinopia to host their own private NPM servers.

Babel converts the ES6 module syntax to CommonJS. CommonJS is a practiced syntax that means stability and universal, and in addition, we can implement static code analysis using mechanisms like the tree shaking (Webpack 2.0 and Rollup already support this feature).

Webpack

Unless you are happy to add hundreds of script tags to the page, you should try to use the build tool to package the resources of the page. In addition, you will need some tools to allow your browser to support NPM third-party packages. Here, I recommend you to use the Webpack.

A year ago, developers had a number of tools to choose from, such as JavaScript-based Requirejs, browserify, and Webpack solutions, as well as Rollupjs that could best optimize ES6 's modules.

After trying out all the tools, I strongly recommend that developers choose Webpack:

• Configurable to handle a variety of situations

• Support for mainstream module loading mode (amd,commonjs,globals)

• Internal mechanism to repair broken modules

• Can handle CSS

• A comprehensive cache system

• Supports hot reload

• Most of the resources can be loaded

• Provides efficient performance optimization solutions

Webpack is also very good at handling large single-page applications, supporting code segmentation and lazy loading.

It is noteworthy, however, that the learning curve of Webpack is unusually steep. But once you've learned it, you've mastered the most powerful building system.

What about Gulp and Grunt? In contrast, Webpack is more adept at dealing with all kinds of resources. If you need to perform other types of build tasks, then Gulp and Grunt are still useful. For basic tasks like running Webpack, I recommend using the NPM script directly.

Mocha + Chai + Sinon

In JavaScript, there are a number of optional unit testing tools, each of which is stable and robust. If you're just using unit testing, the existing tools are perfectly suited to your needs.

Common testing tools are Jasmine, Mocha, Tape, AVA, Jest, etc., which have their own strengths.

I have the following requirements for a test framework:

• Can be run in the browser, easy to debug

• Fast execution speed

• Easy to handle asynchronous testing

• Easy to use on the command line

• Third-party libraries that can be compatible with arbitrary assertions and data simulations

The first criterion excludes Ava and Jest.

I like Chai assertions because of their rich, full-featured plug-ins, like Mocha because of their good support for asynchrony. It is strongly recommended to use Dirty Chai to avoid certain problems. Webpack's Mocha-leader plugin allows developers to perform tests automatically.

For React, developers can refer to AirBNB's enzyme and teaspoon.

I am very fond of Mocha features, if you want only the most basic functions, you can refer to this article to learn about Tape.

Lodash

JavaScript does not have a core library of Java-or. NET-like tools, so most developers will reference an external tool library externally.

For now, Lodash is a leader in this type of tool. In addition, it is one of the best-performing tools available because of its lazy execution characteristics. Without referencing all resources when using Lodash, developers can use their functions on demand. In the 4.x version, Lodash provides a "functional development" model for developers who prefer functional programming.

If you are familiar with functional programming, you can look at Ramda. If you decide to use this library, you may need to refer to some Lodash functions.

Fetch

Many React-based applications are no longer using jQuery. Unless you are maintaining a stale project or using a third-party library that relies on jQuery, it is no longer necessary to use it.

I like to keep the project concise, using only fetch in the code. Fetch is based on Promise,firefox and Chrome, which encapsulates the interface. For other browsers, you will need to provide a putty script. I recommend using Isomorphic-fetch to maintain the consistency of functionality across browsers and services.

Of course, other good third-party libraries can get data asynchronously, but I think fetch is enough.

Homogeneous JavaScript

Homogeneous JavaScript is a JavaScript that runs on both the client and server side, and is often used to pre-render pages on the server, improving performance and facilitating SEO. Using React can implement homogeneous JavaScript, but it is not simple, it increases the complexity of the program, restricting the developer's optional tools and third-party libraries.

If you are building a business-to-consumer site, such as an e-commerce site, you may need to use homogeneous JavaScript. However, for the internal site or business-to-business program, performance is not the most important, then the homogeneous JavaScript is not too important.

Api

Everyone seems to be thinking about how to handle the API recently. Everyone in the flow of the use of Restfull Api,soap has become the past time. There are various API protocols in the industry, such as HATEOAS, JSON API, HAL, GRAPHQL and so on.

GRAPHQL gives the client the ability to make arbitrary queries. With Relay, you can better handle the state and cache of the client. However, it is more difficult to create a server-side interface for GRAPHQL, and most of the documentation is for node. js.

Netflix's Falcor appears to offer similar capabilities to graphql/relay, while also reducing the demand on the server side, but it is still in the developer preview State and not yet applied to actual development.

All known specifications are flawed, somewhat overly complex, and some can only handle data reads rather than updates, some of which are significantly different from REST. Many developers choose to develop their own, but they also encounter the above problems.

I don't think the above has a perfect solution, but I have a self-knowledge of the API:

• Predictable, consistent protocol compliance

• Support for fetching multiple entities in a single query

• Support for update operations

• Easy Commissioning

• Easy to use

So far, I haven't found a solution that meets all of the above criteria.

If you are using resfful, it is recommended to refer to Swagger to write the API.

Electron

Electron can build desktop programs using front-end technology, and the Atom editor produced by the GitHub team is created based on Electron. Essentially, a node. JS is encapsulated inside the Electron, which opens the Chrome window rendering UI, as well as access to the operating system's native API, without the sandbox mechanism in the browser. Developers can package and distribute applications via Electron.

This is the simplest way to create cross-platform software, and you can take advantage of all the tools described above. In addition, Electron has complete documentation and an active development community.

You may have heard of Nw.js's name, although it has been around for years, but the Electron is more stable and easier to use than it is.

Here's a template based on Electron, React and hot Reload, try it out.

Extended

Here are some of the things I focus on on Twitter:

• Dan Abramov, founder of Redux

• Christopher Chedeau, a very active React developer, is now working with Facebook

• Jeff Morrison, one of the core contributors to Flow

• Sebastian Markbåge, one of the creators of React

• Pete Hunt

• React

• Please refer to React influencers for more interesting objects.

Suggest reading Pate Hunt's Learning react!

Dan Abramov publishes a series of video tutorials Getting started with Redux, highly recommended! In addition, Dan has published a watchlist, more detailed than the above.

Mark Erikson's React/redux links collection is also a good learning material.

Use on Demand

JavaScript's ecological environment has developed rapidly and is becoming more and more powerful. React's best practices are solidifying, and the responsibilities and capabilities of peripheral tools are becoming clearer.

The most important thing to remember: keep it simple and use it on demand.

If your app has only two or three screens, you don't need to use a routing system; If you're creating a single-page app, you don't even need Redux, just React your own state property, and if you're creating a simple CRUD program, you don't need to use Relay If you are learning ES6, you do not need to have a deep understanding of async/await or decorators; If you are just starting to learn React, you do not need to use hot reload and server-side rendering; If you just touch Webpack, you don't need to separate code and merge multiple resources; If you've just learned Redux, you don't need to understand the use of redux-form and Redux-sagas.

Keep it simple and do one thing at a time!

Links: http://www.w3cplus.com/javascript/state-of-the-art-javascript-in-2016.html Translator: North-South

Original: HTTPS://MEDIUM.COM/JAVASCRIPT-AND-OPINIONS/STATE-OF-THE-ART-JAVASCRIPT-IN-2016-AB67FC68EB0B#.X7L3E5J4T

2016 JavaScript technology Stack Outlook