Talking about front-end "new" technology, "Technology

Talking about front-end "new" technology, "Technology

Recently, some "Predecessors" (everyone knows who they are) have been calling on Weibo every day. I believe many people are bored. I had a quarrel with him, and contaminated everyone's timeline. I'm sorry. However, I don't think it's really hard for such a spam to get started.

Attitudes towards new things

I believe in a very simple principle when talking about technology: I have no right to speak without research. For things I don't know, I either shut up or study and try again. In my opinion, this is a basic conservation of technical discussion. Technology will always bring new things out, and you will leave if you do not enter the technology. More importantly, the front-end is a relatively new field than the entire software engineering and computer science system. In recent years, the development of the front-end ecology has been absorbing and learning from other fields, whether it is development philosophy, engineering practices, or the platform itself (standards, browsers ). The front-end of the so-called "rooted in strength" is just a stage of exploration in the entire development process. Many of the best practices in that era are no longer applicable to today. Past experiences are valuable, but without understanding new things themselves, it is difficult to make a correct judgment. It should be emphasized that learning new things is not to ignore abuse of actual needs, but to obtain enough information to make more reliable judgments. In this regard, a person's attitude is to constantly emphasize his or her eight years of experience and the importance of "experience and observation", but to despise and resist the exaggeration of new things, rather than spending an hour or two to learn about the world on Weibo. For example, when he criticized Angular/React, he criticized Angular/React based on a preset like "moving the set of server MVC to the front-end". He told the duck about it as a whole; when talking about his own Widget + OO, I didn't even understand the similarities between this set of thinking and the new component-based framework. In this biased way of thinking, how can we make reliable decisions? Being a technical leader is simply irresponsible. Blindly following the trend is not advisable, and blindly resisting is not advisable. You must have your own judgment, but this judgment should be based on sufficient first-hand information.

Why should we use new technologies 』?

Then, let's talk about why these new technologies have a market. First, make it clear that any technology is applicable to different scenarios. After evaluating a technology, we find that it is not suitable. This is normal, for example, the project type, scale, historical burden, and the learning ability of the team are all factors restricting the technical selection. However, this does not prevent us from analyzing what problems a technology solves and whether these problems exist in our actual needs. Next we will analyze one item:

1. CSS pre-/post-Processor
For example, Sass, Less, Stylus, and PostCSS. CSS is designed in many ways that are not conducive to Engineering and affect development efficiency. This is the problem that CSS pre-/post-processors need to solve.
(1) The default global namespace. In the global namespace, any rule may have a global impact, which is not conducive to modular multi-person collaboration. At the same time, if the selector priority is not strictly written, it will soon be difficult to manage, then generate various! Important hack. This cannot be completely solved with the help of the pre-processor, but with the help of nesting, the writing experience can be improved.
(2) As a DSL, there is no abstraction capability: no variables, no functions, no operators, no mixing and inheritance, poor reusability of code, and a large number of duplicates are often required, however, the flexibility for reuse by combining class names is very limited. These can be mitigated with the help of the pre-processor, or even abstract common techniques, such as a mix to solve vertical center, greatly enhancing the CSS code writing efficiency and maintainability.
(3) file organization: too many requests are generated when other files are introduced through Native @ import, and the pre-processor can directly merge them into one file, so there is no concern in the file organization.
(4) Smart avoiding repetitive work: the prefix is automatically added based on the target browser range.
2. JavaScript Compiler
For example, Babel, CoffeeScript, and TypeScript. The goal of compiling JavaScript is to improve development efficiency and maintainability. Taking Babel as an example, the prototype inheritance of JS itself, almost everyone had previously implemented a set of OO simulation, and now there is a native class extends syntax, Which is unified from the language level; the parameter structure and default value of the function avoid the pitfalls of manual default value allocation and parameter 0; The Arrow function avoids the pitfalls of this context; block-level let/const avoids var hoisting pitfalls; templateString avoids tedious manual String concatenation; better Unicode support; ES2015 module (why, see this speech/else n. github. io/empirenode-2015/#/); there are also async await essential improvements to asynchronous process processing. A better language, a standard that has been officially released, with different browser support situations. Someone has written a tool that can be used today, someone's attitude towards this is "creating problems without any problems 』...
CoffeeScript and TypeScript obviously have their main audiences: Ruby developers and Java/C # developers. At this time, someone is about to move out of the "pseudo front-end" big hat. The question is, you have no idea who can make the front-end, and the front-end culture will not be affected by these two things. The significance of these two things is that they can improve the development efficiency of specific groups, and few people will use them because they follow suit, but because they do conform to the development habits of some people. If you don't belong to those people, it doesn't mean that these things are meaningless. They are sprayed and shot while they are lying down. (Web Front-end learning and communication group: 328058344 chat prohibited, not welcome !)
3. modular/build tools
For example: RequireJS, SeaJS, Webpack, Browserify, and SystemJS. The importance of modularization must not be repeated. Even a "Predecessor" is using RequireJS. The first two have gradually declined. Why are there the following three? One of the core values lies in the module-standard package management solution. Because of its compatibility with the Node package format, npm can be used as the package management mechanism in the next three solutions. With the Package Manager, you can separately encapsulate the basic libraries of different projects, ensure API compatibility through the semver version, and reuse the code logic as needed in multiple projects, you can also directly use a large number of third-party libraries published on npm. Furthermore, with the componentization framework mentioned below, cross-Project reuse of UI components can be realized. SeaJS/spm and Arale actually have this vision, but Yu Boming's smart discovery of the direction of the community has chosen to avoid repeated efforts.
On the other hand, it is a new front-end packaging idea brought about by the powerful extension mechanism of these new tools (especially Webpack): not just JavaScript, it treats HTML, CSS, and other static resources as "modules. In actual development, there is not only a dependency between JavaScript modules, but also between HTML, CSS and other static files. In actual development, the relative path relationships between these static resources in the development environment and production environment are often different, this leads to a lot of tedious steps in the development environment to the production environment, such as rewriting the URL referenced by static resources (version stamp, static resource domain name/CDN ), image optimization: inline, module splitting, and On-Demand Loading Based on the file size. These trivial things can be solved manually, but we need efficiency! Efficiency! Once the configuration is complete, developers can focus on the application itself rather than other things. In addition to the foreign solutions mentioned above, there are also excellent similar solutions in China. Finally, we can provide a better development experience based on building tools. The hot-load of Webpack replaces a single module without reloading the page after code modification, which improves the development experience. For example, you need to modify a component that can be viewed after N operations are performed to open the application. If you need to repeat these operations once, the efficiency is too low.
4. componentized framework
For example, React, Angular 2, and Vue. In my opinion, the modern componentized framework provides three core values:
(1) declarative DOM ing from data to DOM. Whether it is virtual dom render or template, the essence is to describe in a declarative manner "based on such data, the interface should finally be presented to the user 』. In most scenarios, you do not need to perform imperative DOM operations. Declarative code is simpler and easier to maintain than imperative code.
(2) How components are organized. Is each part of a component scattered in multiple files, or is there a reasonable way to organize it? How do I publish components and reuse them in multiple projects? In this regard, the React option is to put everything into JS, while Vue implements a single file Component format similar to Web Component based on the build tool (it can also be split and support pre-processor ). Angular 2 currently either separates multiple files or directly uses HTML/CSS as a string inline.
(3) how to combine and communicate components. The common points here are declarative> imperative: render child components in the parent component by using tags in the render function/template, so that the data driver component exists, in this way, you can naturally obtain the tree structure of the component, instead of using this as an imperative. add (child) to manage the component tree. In terms of data communication, the top-to-bottom one-way data transmission is usually adopted, while the child component can provide feedback to the parent component through event bubbling or passing a callback. Note that the sub-component cannot arbitrarily rewrite the status of the parent component, whether it is a trigger event or a call callback, in the end, the parent component determines what happened to the parent component. This ensures that the child component is decoupled from the parent component, so that the child component can be transplanted or reused. In large applications, we also need to consider how to clearly understand the consequences of an event, so that a developer can quickly understand the intention of another person's code, so that the application will not get out of control as the scale grows? This is an attempt by state management solutions such as Flux Redux to solve the problem. Its core is to make the side effects controllable, and 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 highly cohesive component should contain the js logic, HTML structure, and CSS required by the component. However, due to the global namespace problem of CSS, it is always a problem to follow the local CSS of components, especially portability. At present, there are several solutions: CSS in JS, CSS modules, and Shadow DOM represented by React (implemented by browsers ), and local CSS/template rewriting during Vue/Angular 2 compilation. Each of the several solutions has its own merits, but the core is to solve the global namespace problem of CSS to a certain extent, so that the CSS that follows the component does not affect the outside and achieves portability, in this way, components are truly highly cohesive. Highly cohesive components can be independently distributed as packages to achieve cross-Project reuse.
5. Testing/code standardization tools
According to a senior, he gave up writing tests because of insufficient time. Why is it not enough time? Because the tool is outdated and the development efficiency is too low. In addition, for tests written in ancient versions such as Qunit and YUI test, you must manually open a browser for testing without code coverage information. Now, the code specifications include ESLint, unit testing includes Karma, and integration testing includes CasperJS/Nightwatch. The code coverage uses istanbul. After the configuration is complete, one line of commands will automatically report the results and coverage of multiple browsers, if you build a continuous integration environment, you don't even need to manually run it, just push it to the repository. These things do not need to be understood by everyone in the team. Architects can build a good foundation. New users only need to use them, but they can greatly improve the overall code quality.

Once said so much, it is nothing more than a demonstration that the emergence of new technologies will always occur because there are corresponding problems that can be solved. Its core demands are to improve development efficiency and maintainability, this is exactly what engineers should pursue. There is definitely a cost in the process of researching, configuring, and promoting any new technology. You think it is not worth the cost to solve these problems. It does not mean that others do the same, it does not mean that you are qualified to despise others' efforts to solve the problem. As for speculation about others' reputation, what else can I say in addition to being a villain?