If you are planning a new front-end project or refactoring an existing project, then you need to realize that the current front-end development environment is no longer what it used to be. There are too many choices: React , Flux, Angular, Aurelia, Mocha, Jasmine, Babel, TypeScript, Flow... Their original intention is to simplify development, but they virtually increase the learning cost and also bring trouble to the maintenance of future projects. Uncertainty.
Fortunately, this phenomenon is fading, and the fittest will survive. Excellent projects are slowly settling down, and development methods are becoming clearer. Some developers are trying to use frameworks based on the above technologies for development, which also reduces learning costs to a certain extent.
This article mainly introduces some technologies that I involve and recommend in web application development. Some of them are technically controversial, so I only give a brief introduction and analysis of each technology. All of these opinions are based on my personal experience and contact with the community, so please use them as you see fit.
React is all the rage:
Componentization makes applications easier Development and maintenance
The learning curve is gentle, the core API is concise and clear, and easy to learn
JSX syntax is unconventional and fully utilizes the power of JavaScript
Naturally adapted to Flux and Redux
The community is active and creative, and has contributed many excellent development tools
One-way data flow is more suitable for complex applications and has higher quality than two-way data binding
Supports server-side rendering
Although React is not an all-rounder compared to feature-rich frameworks such as Ember, Aurelia and Angular, React's development environment is more robust. For now, using React is not a technology choice, but a business practice that provides more efficient and effective productivity.
When you want to develop mobile applications, because you have already learned React syntax, you can directly start using React Native to develop cross-platform applications.
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, as recommended here The tool is: Redux.
In order to cooperate with React, Facebook developed Flux, a tool for managing one-way data flow. Although Flux basically supports single data flow, it also brings other problems, such as how to save the state and where. Make Ajax requests and more.
In order to solve these problems, a series of frameworks that imitate the Flux model have been derived: Fluxible, Reflux, Alt, Flummox, Lux, Nuclear, Fluxxor...
At present, it is widely used by the development community One supported implementation is Redux.
In Redux, most components are purely functional components, and there is only one centralized storage and resource center. Redux's instance methods are responsible for the operation and maintenance of the entire data. Compared with Flux, Redux's ideas are clearer.
More importantly, Redux is very easy to learn. Dan Abramov, the author of Redux, is an excellent teacher who has created a series of in-depth and easy-to-understand Redux video tutorials. Become a Redux expert by watching these videos. I once saw a zero-based React team quickly develop a beta product in just a few weeks, and the code was very robust and sophisticated.
The ecosystem surrounding Redux is as robust as Redux itself. From the amazing devtool to the powerful memoization tool reselect, the Redux development community provides developers with everything they need.
Developers may instinctively try to abstract a Redux template. Doing so has many benefits, but please encapsulate the template based on a clear understanding of the needs instead of blindly trying.
It’s time to abandon CoffeeScript because many of its features have similar syntax in ES6, and ES6 is an implementation standard and represents the future development direction of JavaScript. .
The latest browsers already support most of the features of ES6. Babel is a powerful conversion tool for converting ES6 to ES5. Additionally, the degree of transcoding can be adjusted depending on the target browser.
So is there a type system? Both TypeScript and Flow provide static type systems for JavaScript. Using static type checking can effectively catch errors and reduce the amount of testing. For now, I recommend taking a wait-and-see approach to this.
TypeScript is trying its best to make JavaScript develop in the direction of C# or Java, but it lacks many advanced type system features, such as algebraic data types. Additionally, it doesn't handle nulls as efficiently as Flow.
In comparison, Flow is more powerful and captures more error types, but it is difficult to configure. In addition, its support for new JavaScript features is weaker than Babel, and it does not support Windows systems.
From my personal point of view, the type system is not a crucial part of front-end development (it may be controversial here). Until the type system becomes more robust and Babel-friendly, let's wait and see.
Another undisputed tool is ESLint. ESLint supports ES6 syntax and also provides React plug-ins. It is no longer just a code review tool. At present, JSLint is obsolete, and ESLint can replace JSHint and JSCS in a class of its own.
Developers can configure ESLint according to their own needs, but here I recommend configuring it according to AirBNB's development specifications, or you can use ESLint airbnb config directly. Of course, there are still shortcomings in this specification, but maintaining the consistency of the team's overall code can effectively improve the readability of the code.
After you become familiar with ESLint, it is recommended that developers try its rules in depth. The more errors ESLint catches, the more stable the product is.
Forget Bower, let NPM take over. Build tools like Browserify and Webpack have indirectly increased NPM's status in web development. With NPM, version management will be simpler and there will be more contact with the Node.js ecosystem. The current handling of CSS is not yet complete enough.
You may be thinking about how to perform the build on the deployment server? Unlike Ruby's Bundler, NPM uses wildcards to retrieve files, and third-party packages can be modified arbitrarily during code development and before the project is released. Use shrinkwrap files to freeze third-party dependencies in the project. I recommend using User's shrinkwrap to improve the consistency of the output. In addition, developers can also consider using tools like Sinopia to host their own private NPM servers.
Babel will convert ES6 module syntax to CommonJS. CommonJS is a tried-and-true syntax, which means stable and universal. In addition, we can achieve static code analysis using mechanisms like tree shaking (Webpack 2.0 and Rollup already support this feature).
Unless you're happy to add hundreds of script tags to your page, you should try using a build tool to package the page's resources. In addition, you will need some tools to enable browser support for NPM third-party packages. Here, I recommend you to use Webpack.
A year ago, developers had many tools to choose from for the above work, such as JavaScript-based RequireJS, Browserify and Webpack solutions, as well as RollupJS, which is said to be the best optimization for ES6 modules.
After trying all the tools, I strongly recommend developers to choose Webpack:
You can deal with various situations through configuration
Supports mainstream module loading methods (AMD, CommonJS, globals)
Internal mechanism can repair damaged modules
Can handle CSS
Comprehensive caching system
Supports hot reload
Can load most resources
Provide efficient performance optimization solutions
Webpack is also very good at handling large single-page applications, supporting code splitting and lazy loading.
But it is worth noting that the learning curve of Webpack is extremely steep. But once you learn it, you'll have the most powerful build system at your disposal.
What about Gulp and Grunt? In comparison, Webpack is better at handling various resources. Gulp and Grunt are still useful if you need to perform other types of build tasks. For basic tasks like running Webpack, I recommend using NPM scripts directly.
In JavaScript, there are a large number of optional unit testing tools, each of which is stable and robust. If you are just using it for unit testing, then the existing tools will fully meet your needs.
Common testing tools include Jasmine, Mocha, Tape, Ava, Jest, etc. They each have their own strengths.
My requirements for a test framework are as follows:
Can be run in the browser for easy debugging
Fast execution
Easy to handle asynchronous tests
Easy to use in the command line
Yes Third-party libraries compatible with arbitrary assertions and data simulation
The first criterion excludes Ava and Jest.
I like Chai assertions because of its rich variety and full-featured plugins, and Mocha because of its good support for asynchrony. It is highly recommended to use Dirty Chai to avoid certain problems. Webpack's mocha-leader plugin allows developers to automate testing.
For React, developers can refer to AirBNB’s Enzyme and Teaspoon.
I love the features of Mocha very much. If you just want the most basic functions, you can refer to this article to learn about Tape.
JavaScript does not have a core tool library similar to Java or .NET, so developers will mostly reference an external tool library from the outside.
Currently, Lodash is the leader among such tools. In addition, due to its lazy execution characteristics, it is one of the best performing tools available. There is no need to reference all resources when using Lodash, developers can use the functions as needed. In version 4.x, Lodash provides a "Functional Development" mode for developers who prefer functional programming.
If you are familiar with functional programming, you can learn about Ramda. If you decide to use this library, you may need to reference some Lodash functions.
Many React-based applications no longer use jQuery. Unless you are maintaining an old project or using a third-party library that depends on jQuery, there is no need to use it anymore.
I like to keep projects simple and only use fetch in the code. fetch is based on promise, and both Firefox and Chrome encapsulate this interface. For other browsers, you need to provide a putty script. I recommend using isomorphic-fetch to keep functionality consistent across browsers and servers.
Of course, you can also use other excellent third-party libraries to obtain data asynchronously, but I think fetch is enough.
Isomorphic JavaScript refers to JavaScript that runs on both the client and the server. It is often used to pre-render pages on the server to improve performance and facilitate SEO. Isomorphic JavaScript can be implemented using React, but it is not simple. It increases the complexity of the program and limits the tools and third-party libraries available to developers.
If you are building a B2C site, such as an e-commerce website, then you may need to use isomorphic JavaScript. However, for internal sites or B2B applications, performance is not the most important thing, so isomorphic JavaScript is not too important.
Everyone seems to be thinking about what to do with APIs these days. Everyone is jumping on the bandwagon of using RESTfull APIs, and SOAP is a thing of the past. Currently, there are various API protocols in the industry, such as HATEOAS, JSON API, HAL, GraphQL, etc.
GraphQL gives the client the ability to perform arbitrary queries. Paired with Relay, the client's state and cache can be better handled. However, it is still difficult to create a GraphQL server interface, and most of the documentation is for Node.js.
Netflix’s Falcor seems to provide similar capabilities to GraphQL/Relay while also reducing server-side requirements, but it is currently in developer preview and has not yet been used in actual development.
All known specifications have their own shortcomings. Some are too complex, some can only handle data reading but not updating, and some are significantly different from REST. Many developers choose to develop by themselves, but they still encounter the above problems.
I don’t think there is a perfect solution to the above, but I have my own understanding of the API:
Predictable, follow the consistency protocol
Supports obtaining multiple entities in one query
Supports update operations
Easy to debug
Ease of use
So far I have not found a solution that satisfies all of the above criteria.
If you are using RESFful, it is recommended to refer to Swagger to write API.
Electron can use front-end technology to build desktop programs. The Atom editor produced by the GitHub team is based on Electron. Essentially, Electron encapsulates a Node.js internally, which can open a Chrome window to render the UI, and can also access the local API of the operating system, and there is no sandbox mechanism in the browser. Developers can package and distribute applications through Electron.
This is the easiest way to create cross-platform software and take advantage of all the tools mentioned above. Additionally, Electron has complete documentation and an active development community.
You may have heard of the name nw.js. Although it has existed for many years, in comparison, Electron is more stable and easier to use.
Here is a template based on Electron, React and hot reload, give it a try.
Here are some of the people I follow on Twitter:
Dan Abramov, creator of Redux
Christopher Chedeau, a very active React developer, currently working at Facebook
Jeff Morrison, one of the core contributors of Flow
Sebastian Markbåge, one of the creators of React
Pete Hunt
React
For more objects worthy of attention, please refer to React Influencers
It is recommended to read Pate Hunt’s Learning React!
Dan Abramov released a series of video tutorials Getting started with Redux, highly recommended! Additionally, Dan has published a watchlist that is more detailed than the above.
Mark Erikson's React/Redux links collection is also a good learning material.
The JavaScript ecosystem is developing rapidly and becoming increasingly powerful. Best practices in React are solidifying, and the responsibilities and capabilities of surrounding tools are becoming increasingly clear.
The most important thing to remember is: keep it simple and use it only when you need it.
If your application only has two or three screens, then there is no need to use a routing system; if you are creating a single-page application, then you don't even need Redux, just React's own state attribute; if you are creating a For a simple CRUD program, you don't need to use Relay; if you are learning ES6, you don't need to understand Async/Await or decorators in depth; if you just started learning React, you don't need to use hot reloading and server-side rendering ; If you are new to Webpack, you do not need to separate code and merge multiple resources; if you are just learning Redux, you do not need to understand the use of Redux-Form and Redux-Sagas.
Keep it simple and do one thing at a time!
The above is the detailed content of A detailed introduction to the outlook for the JavaScript technology stack. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
