Technology This business, will always have new things come out, behind. More critical is that the front-end than the entire software engineering and computer science system, is a relatively new field of Robin Hood, in recent years, the development of the front-end ecology is in other areas to absorb and learn, whether it is the development of ideas, engineering practices or platform itself (specification, browser). The so-called "root is Red" front end, but the whole development process in the exploration of a stage, the best practice of that era, many to today are no longer applicable. While past experience is valuable, it is difficult to produce correct judgments if they do not combine the knowledge of the new things themselves. What is to be emphasized here is that learning new things is not about the misuse of actual needs, but about getting enough information to make more reliable judgments. blindly follow the undesirable, blind resistance is not advisable, to have their own judgment,but this judgment should be based on sufficient amount of information..
Why use "new technology"?
With that in mind, let's take a closer look at why these "new technologies" will have a market. First, be clear: any technology has a choice of applicable scenarios. It is normal for a technology to be evaluated, such as the type of project, size, historical baggage, and the learning ability of the team, which are the factors that restrict the selection of technology. But that does not prevent us from analysing what problems a technology itself solves and whether there are problems with our actual needs. Next we have an analysis:
- CSS Pre/Post processor
For example: Sass, less, Stylus, Postcss. CSS itself is designed to be detrimental to engineering, the impact of development efficiency of the place, which is the CSS pre/post processor to solve the problem.
(1) The default global namespace. Under global namespace, any rule can have a global impact, not conducive to modular multi-person collaboration, and the priority of the selector if there is no strict writing specifications, will soon be difficult to manage, and then generate a variety of!important hack. This is not fully resolved with the help of a preprocessor, but the writing experience can be improved with nesting.
(2) Lack of abstraction as a DSL: no variables, no functions, no operators, no mixing and inheritance, poor reusability of code, frequent duplication, and a very limited amount of flexibility in the way of combining class names. These can be mitigated with the help of a preprocessor,can even abstract the common techniques of mixing, such as a mix to solve the vertical center,greatly enhance the writing efficiency and maintainability of CSS code.
(3) File organization: the introduction of other files through the native @import will result in excessive requests, and the preprocessor can be merged directly into a single file, with no concerns in the file organization.
(4) Intelligent avoidance of repetitive labor: automatically adds prefixes based on the target browser range.
- JavaScript compiler
For example: Babel, Coffeescript, TypeScript. Why compiling JavaScript is essentially the goal: improving development efficiency and improving maintainability. Take Babel as an example, JS itself prototype prototype inheritance, before almost everyone has their own to achieve a set of OO simulation, now has the native class extends grammar, from the language level of unity; function parameter structure and default value, avoid manual default value assignment and parameter 0 pit; The arrow function avoids the pit of this context; block-level Let/const avoids var hoisting pits; templatestring avoids tedious manual string stitching; better Unicode support; ES2015 module (why, see this speech http:/ /benjamn.github.io/empirenode-2015/#/); There are also async await improvements to asynchronous process processing in nature. A better language, a standard that has been officially published, browser support is different, someone has written a tool that you can use today, someone's attitude to it is "no problem also to create problems" ...
Coffeescript and TypeScript obviously have their own main audiences: Ruby developers and java/c# developers. At this time someone has to move out of the "pseudo-front" of the hat, the problem is, who can make the front-end is not your decision, the front-end atmosphere will not be affected by these two things. The meaning of these two things is that they can improve the development efficiency of a particular population, and the people who use them are seldom because they follow suit, but because they do conform to some people's development habits. You do not belong to that part of the person, does not mean that these things have no meaning, they are sprayed really lying also shot.
- Modular/Build Tools
For example: Requirejs, Seajs,webpack, Browserify, Systemjs. The importance of modularity must not be too much to say, even a "predecessor" are using Requirejs. The two of them are fading now, so why do you have these three? One of the core values is the package management scheme based on module specification. Because of the compatibility of the Node package format, the following three scenarios can take advantage of NPM as a mechanism for package management. With the assurance Manager, you can package the cross-project base library in a granular, individual, API-compatible version with Semver versions, reuse code logic on demand across multiple projects, and directly use a huge number of third-party libraries published on NPM.further, you can implement cross-project reuse of UI components in conjunction with the following modular framework. SEAJS/SPM and Arale actually have this vision, but Yuber wisely discovered the direction of the community and chose to avoid duplication of effort.
On the other hand, there is a new front-end packaging idea that comes with the powerful extensions of these new tools, especially Webpack: not just JavaScript, but the HTML, CSS, and other static resources as "modules". Because in real-world development, there is not only a dependency between the JavaScript modules, but also the dependencies between HTML, CSS, and other static files. In actual development, the relative path relationship between these static resources in the development environment and production environment is often different, which leads us to have many tedious steps in the process of the development environment to the production environment, such as rewriting the URL of static resource reference (version stamp, static resource domain name/CDN), picture optimization, According to the size of the file to make inline, module segmentation and on-demand loading and so on, these trivial things can be manually solved, but we want efficiency! Efficiency! Once configured, developers will be able to focus on the application itself rather than other things. In addition to the above mentioned several foreign programs, domestic also has excellent similar scheme FIS.
Finally, we are able to provide a better development experience based on building tools. Webpack's hot reload, which replaces a single module without reloading the page after modifying the code, brings a qualitative boost to the development experience. For example, you're modifying a component that requires N operations to open an app to see it, and if you change it again, it's too inefficient.
- Modular Framework
For example: React, Angular 2, Vue. In my opinion, the modern modular framework provides three core values:
(1) data-to-DOM declarative mapping. Whether it is virtual DOM render or template, its essence is to describe declaratively "based on such data, and ultimately should be presented to the user such interface." In most scenarios, the user usually does not need to do the command-style DOM operation. Declarative code is more concise and easier to maintain than imperative code.
(2) How the components are organized. Are the parts of a component scattered across multiple files, or is there a logical way to organize them? How are components published and reused in multiple projects? In this case, React's choice is to put everything into JS, and Vue is based on the build tool implementation of a WEB-like Component single-file component format (can also be split, while supporting the preprocessor). Angular 2 Now either separate multiple files or directly inline html/css as strings.
(3) How to assemble and communicate between components. The common point here is also declarative > imperative: By Rendering subcomponents in the parent component with a label form in the Render function/template, allowing the data-driven component to exist, thus naturally getting the tree-like component tree structure rather than using this.add (child) This way to manage the component tree. In terms of data communication, there is usually a one-way data transfer from top to bottom, and subcomponents can respond to the parent component by bubbling the event or passing a callback. Note that the point here is that the subassembly does not arbitrarily overwrite the state of the parent component, whether it is triggering an event or invoking a callback, what is ultimately happening to the parent component or is determined by the parent component itself, which ensures that the child component is decoupled from the parent component, which makes the subassembly portable/reusable.in large applications, consider how the consequences of an event can be clearly understood so that a developer can quickly understand the intent of another person's code so that the application does not get out of control as the scale grows. This is the problem that a state management solution like Flux Redux is trying to solve. Its core is to allow the control of side effects, the ultimate goal is maintainability.
In addition to the above three points, there is an additional point, that is, the relationship between CSS and components. Ideally, a high-cohesion component should contain the JS logic, HTML structure, and CSS required for this component. However, due to the previously mentioned problem of CSS global namespace, the following component of the local CSS, especially portability, has been a problem. At this point there are several scenarios: React is represented by the CSS in Js,css Modules,shadow DOM (dependent on the browser implementation), and Vue/angular 2 's compile-time local css/template is overwritten. Several schemes have their own merits, but the core is to some extent solve the problem of CSS global namespace, so that the following component of the CSS no longer affect the external, to obtain portability, so that the components to achieve a true high cohesion. High cohesion components can be distributed independently as packages, enabling cross-project reuse.
- Test/Code Specification tool
According to a "senior" himself said that he was not enough time, so is to give up writing tests. Why time is not enough, because the tool is backward, the development efficiency is too low bai. And with an old test written like Qunit/yui test, you have to manually open a browser test and no code coverage information. Now, the code specification has ESLint, Unit test has Karma, integration test has casperjs/nightwatch, code coverage with Istanbul, configured after a line of command automatic multi-browser test report results and coverage, if a good continuous integration environment, Even without your own manual running, push to the warehouse is OK. These things do not need the team everyone understands, the architect set a good foundation, the new people as long as the use of the line, but can greatly improve the overall code quality.
said so much, nothing but to show that the emergence of new technology, always because there are corresponding problems can be resolved only to appear, its core demand is to improve development efficiency and maintainability, which is what engineers should pursue. Meteor Core Development, vue.js author, Ex-googler. Know @ Yu Yuxi
Source: >
From for notes (Wiz)
Talking about the front-end "new" technology
