Recently, a “senior” (we all know who it is) called every day on weibo, I believe many people are tired of watching. I kind of got in a fight with him, fouled everyone’s timeline, so I’m sorry in advance. But I feel that let such a person mislead people, really can’t watch, so let’s do something to set the record straight.
Attitude to new things
I believe in a very simple principle when it comes to technology discussions: you can’t have a say without studying it. What I don’t know, I either shut up, or study and try before I speak. In my opinion, this is a basic discipline for technical discussion. In technology, there are always new things coming out. If you don’t advance, you go back. More importantly, compared with the whole software engineering and even the computer science system, the front-end is a relatively new field. In recent years, the development of the front-end ecology is actually to absorb and learn from other fields, whether it is the development concept, engineering practice or platform itself (specification, browser). The so-called “root is right and seedling is red” front is just a stage of exploration in the whole development process, and many of the best practices of that era are no longer applicable today. While past experience is valuable, it is difficult to form a correct judgment if it is not combined with knowledge of the new thing itself. It is important to note that learning new things is not about ignoring the abuse of actual needs, but about gaining enough information to make more informed decisions. At this point, someone’s attitude is one of incessant emphasis on the past eight years of experience and the importance of “experience and observation,” yet disdain and resist the new to an exaggerated degree, preferring to fight on Twitter rather than spend an hour or two climbing the wall to learn about the outside world. For example, he criticizes Angular/React with a presupposition of “moving server MVC to the front end”. While explaining his own Widget + OO, he had no idea what this thinking had in common with today’s new component-based frameworks. How can you make sound decisions with such a biased way of thinking? It’s irresponsible to be a technical leader. Blindly following the trend is not desirable, nor is blindly resisting. We should have our own judgment, but this judgment should be based on enough first-hand information.
Why “new technology”?
With attitude out of the way, let’s dive into why these “new technologies” find a market. Let’s be clear: every technology has its own set of scenarios. It’s not unusual to evaluate a technology and find it not a good fit, as the type of project, size, historical baggage, and the ability of the team to learn are all constraints. But that doesn’t stop us from analyzing what problems a technology itself solves and whether those problems exist in our actual requirements. Let’s analyze them one by one:
1. CSS Pre/post processors such as Sass, Less, Stylus, and PostCSS. The design of CSS itself has a lot of problems that are not conducive to engineering and affect development efficiency, which is exactly the problem that CSS pre/post processors need to solve. (1) Default global namespace. Under the global namespace, any rule may have global impact, which is not conducive to modular multi-person collaboration. At the same time, selector priorities without strict written specifications can quickly become unmanageable, resulting in a variety of! Important hack. This cannot be completely solved with preprocessors, but the writing experience can be improved with nesting. (2) As a DSL, it lacks abstraction ability: there are no variables, no functions, no operators, no mixing and inheritance. The code has poor reusability and often needs a lot of repetition. Moreover, the flexibility of repetition by combining class names is limited. These can be mitigated with the help of the preprocessor, and can even be abstracted from common techniques such as blending to solve vertical centering, which greatly enhances the writing efficiency and maintainability of CSS code. (3) File organization: the introduction of other files through the native @import will produce too many requests, while the preprocessor can directly merge into a file, and there is no concern about file organization. (4) Intelligent to avoid repeated work: automatically add prefix according to the target browser range. JavaScript compilers such as Babel, CoffeeScript, TypeScript. Why compile JavaScript? The goal at heart is still to improve development efficiency and maintainability. Take Babel, the prototype inheritance of JS itself. Before, almost everyone had their own implementation of OO simulation. Now there is the native class extends syntax, which is unified at the language level. Function parameter structure and default values, avoiding manual default value assignment and parameter zero pit; The arrow function avoids the pit of this context; The block-level let/const avoids var colliding. TemplateString avoids tedious manual string concatenation; Better Unicode support; ES2015 module (why, see the speech / / benjamn lot. IO/empirenode – / # 2015 /). And async await is an improvement on the nature of asynchronous process processing. A better language, a standard that has been released, browser support varies, someone wrote a tool that you can use today, someone’s attitude is “create problems if you don’t have problems”… CoffeeScript and TypeScript clearly have their respective primary audiences: Ruby developers and Java/C# developers. The problem is, it’s not up to you to decide who can do the front end, and the ethos of the front end won’t be affected by these two things. The significance of these two things is that they can improve the development efficiency of certain groups of people, and the people who use them are less likely to follow suit, but more likely to use them because they fit the development habits of certain groups of people. Just because you’re not part of the group, doesn’t mean these things don’t make sense, they get sprayed and they get shot lying down. (Web front-end learning exchange group: 328058344 no small talk, not like!) Modularity/build tools such as RequireJS, SeaJS, Webpack, Browserify, SystemJS. Modularity is so important that RequireJS is being used by some of its predecessors. The first two are fading now, so why the last three? One of the core values is a package management solution based on module specifications. Compatibility with the Node package format allows the latter three solutions to leverage NPM as a package management mechanism. With the package manager, you can encapsulate fine-grained base libraries individually across projects, ensure API compatibility with semver versions, reuse code logic on demand across multiple projects, and directly use the vast array of third-party libraries published on NPM. Furthermore, with the componentalization framework mentioned below, it is possible to reuse UI components across projects. SeaJS/ SPM and Arale actually had this vision, but Yip wisely saw the direction of the community and chose to avoid duplication of effort. On the other hand, the powerful extension mechanisms of these new tools (especially Webpack) have led to a new way of thinking about front-end packaging: not just JavaScript, but HTML, CSS, and other static resources as “modules.” Because in real development, dependencies exist not only between JavaScript modules, but also between HTML, CSS, and other static files. Actual development, the development environment and production environment, the relative path of the relationship between static resource is often different, resulting in our past in the process of the development environment to the production environment of online there are a lot of cumbersome steps, such as static resource reference URL rewrite (version stamp, the static resources domain name/CDN), image optimization, Inline according to the file size, module segmentation and load on demand, and so on, these trivial things can be solved manually, but we want efficiency! Efficiency! Once configured, it allows the developer to focus on the app and not on anything else. In addition to several foreign schemes mentioned above, there are also excellent similar schemes FIS in China. Finally, we can provide a better development experience based on build tools. Hot reloading of Webpack, replacing a single module without reloading the page after modifying the code, is a qualitative improvement to the development experience. For example, if you modify a component that takes N actions to see after opening the app, it is inefficient to repeat those actions once you change it. 4. Componentized frameworks like React, Angular 2, and Vue. In my opinion, modern componentization frameworks provide three core values: (1) declarative mapping of data to DOM. The essence of both Virtual DOM Render and templates is to declaratively describe “the interface that should ultimately be presented to the user based on this data”. In most scenarios, the user usually does not need to perform imperative DOM operations anymore. Declarative code is cleaner and easier to maintain than imperative code. (2) The organization of components. Are the parts of a component scattered across multiple files, or are they organized in a reasonable way? How are components distributed and reused across multiple projects? React’s choice is to put everything in JS, while Vue implements a single-file Component format similar to Web Component based on build tools (which can also be split and support preprocessors). Angular 2 currently splits multiple files or directly inlines HTML/CSS as strings. (3) how to combine and communicate between components. The common point here is also declarative > imperative: Make the presence of data-driven components natural by rendering the child component in the parent component with tags in the Render function/template, rather than managing the component tree with commands like this.add(child). In terms of data communication, there is usually one-way data transmission from top to bottom, and the child component can give feedback to the parent component by bubbling up events or passing a callback. The important point here is that the child cannot arbitrarily override the state of the parent, whether it is firing an event or calling a callback. Ultimately, what happens to the parent is determined by the parent itself, which ensures that the child is decoupled from the parent, making the child portable/reusable. In large applications, how can the consequences of an event be clearly understood, so that one developer can quickly understand the intent of another’s code, so that the application doesn’t get out of control as it grows? This is the problem that state management schemes like Flux Redux attempt to solve. The core is to make side effects manageable and ultimately maintainable. In addition to the above three points, there is an additional point, which is the relationship between CSS and components. Ideally, a cohesive component should contain the JS logic, HTML structure, and CSS that the component needs. But because of the CSS global namespace problem mentioned earlier, local CSS that follows components, especially portability, has always been a problem. There are several solutions to this: React for CSS in JS, CSS Modules, Shadow DOM (browser-dependent implementation), and Vue/Angular 2 for compile-time partial CSS/ template overwriting. Several solutions have their own strengths, but the core is that they all solve the problem of CSS global namespace to a certain extent, so that the CSS following components no longer affect the external, to obtain portability, so that components achieve real high cohesion. Highly cohesive components can be distributed independently as packages for reuse across projects. 5. Testing/code specification tools According to one “senior” himself, he gave up writing tests because of lack of time. Why is there not enough time? Because the tools are outdated and the development efficiency is too low. And tests written with older versions like Qunit/YUI test have to be manually tested one browser at a time and have no code coverage information. Now ESLint for code spec, Karma for unit test, CasperJS/Nightwatch for integration test, code coverage using Istanbul, one line of command after configuration automatically report results and coverage for multi-browser test. If you build a continuous integration environment, you don’t even have to run it yourself. Push it to the warehouse. These things don’t have to be understood by everyone on the team, they can be used by the architect, but they can greatly improve the overall quality of the code.
All this is to explain that the emergence of new technology is always due to the corresponding problems that can be solved, and its core appeal is to improve development efficiency and maintainability, which is exactly what engineers should pursue. There are costs involved in researching, deploying, and promoting any new technology, and just because you don’t think solving the problem is worth it doesn’t mean anyone else is, nor does it entitle you to disparage the efforts of others to solve the problem. As for speculating that others are “gaining fame by misinformation”, what else can I say but the heart of a villain?