People are saying the front end is changing too fast. Whenever there is new progress in the front end, peers will ridicule, do not update, learn not to move. Change is too fast, where is fast, what has changed, I said from the short three years of front-end development, to reflect these years of change.
Although I have only three years of development experience, I have experienced large and small projects due to my outsourcing experience. These projects use both the latest technology and older technologies that were maintained along the way four or five years ago. The following from a few aspects to discuss.
1 Language change
First of all, HTML, ACTUALLY I don’t know much about the previous version of HTML5, because since I entered the field, when H5 was the hottest, I only know that HTML5 will have some new tags, such as video, canvas, and some new storage schemes, such as SessionStorge. Most modern browsers support these changes.
Then there’s CSS. The change is CSS3, of course, with some new animation properties like Transition and layout properties like Flex, which can be used with HTML5 to create some cool page effects. I know only so much about the changes, because I have not experienced CSS2 and older.
The browser has a process to support these changes in HTML and CSS, which has to mention the IE series. When I started, the project was also required to be compatible with IE7, so I found a series of Internet Explorer hacks, but NOW I forget how to use them, even IE has not been opened for a long time. I recently opened Microsoft’s Browser to try Edge, which has the Chrome kernel replaced. Look, in three years, Microsoft has changed its core.
The most important thing is js changes. ES6 was released in 2015. At that time, I was not involved in programming and did not know JavaScript was a sub-language. Of course, most browsers do not fully support the new syntax and rely on Babel to translate into ES5.
Speaking of ES6, coffeescript should also be mentioned. I came across it in an old project and found that there was a lot of syntax, such as arrow functions, similar to ES6. Coffeescript seemed to be popular before ES6 was released, so it was chosen for the technology. Of course, after ES6 was released, everyone switched to this “orthodox” standard, and CoffeesCRPT fell apart.
Nodejs, the server-side version of nodeJS, has also made its way into real projects in recent years, rather than just being used as a front-end tool. From what I’ve experienced and know, NodeJS is likely to land more in large companies like Alibaba and startups. Large companies have major backend languages. Nodejs does not have the ability to leverage the position of Java, PHP, etc., but it can help the front end expand its business boundaries. For example, as a BFF layer, it can both free the back end and enable the front end. Small startups may be flexible with people and technology, and prefer a unified front-end language, so NodeJS is naturally competitive.
I don’t use Typescript, but I’ve heard that a lot of the front ends are recommended for projects, and the bigger the project, the better. For example, vscode is a big open source project that’s already developed in Typescript.
2. Changes in code organization structure
In fact, the code organization structure is related to the size of the project, for example, an active page, may be the most traditional HTML, CSS, JS completely satisfied, if you have to add webpack and so on.
It also changes with the development of JS modularity. Before ES6, JS did not provide modularity natively.
Traditional development, simple front-end three musketeers is enough, as long as the HTML page to introduce CSS and JS, at the same time to ensure the introduction of JS order, otherwise it may report errors. In addition, multiple developers often have naming conflicts, so there are basic module encapsulation such as function encapsulation, object encapsulation, and IIFE closure.
Later, along with nodeJS commonJS module specification, there are AMD and CMD module tools on the browser side. At the same time, NPM packages are becoming more and more popular. Now the front end should be NPM install.
By ES6, there will be modular syntax with native support. Of course, the browser is not fully supported yet.
3. Framework (library) changes
There is no denying that the era of Jquery is gone forever. But the company I work for still has many old projects developed with jquery, because the company used Vue or React in the past. When I used jquery, I used its Ajax method at least, at most. As a result, I have to consult documentation every day when DEALING with jquery and Zepote, and appreciate the hassle, chaos, and unmaintainability of manually changing the DOM one by one.
Backbone after Jquery… And Angular and other MVC frameworks, which greatly improved the efficiency of front-end development. Of course, when I started, they were not so popular, curious, and I did not meet them on the project. All right, just a quick mention here as a mark of respect.
Then React came along and quickly became a framework leader thanks to the high performance of JSX and Virtual DOM. React was used in the project last year, about a year ago.
When I started to contact the front end in 2016, I learned the latest Vue, which was very friendly to me as a novice, and I also had access to official first-hand documents. I got a cab job on Vue. But honestly, I like React.
So far, the projects I’ve been working on this year include Jquery (old projects, of course), React, and Vue.
4. Tool changes
It’s probably all Webpack now, because if you use Vue or React, you basically have to use WebPack.
It used to be Grunt or gulp, they were just process tools, but Webpack does have a modular package of tools.
5. Changes in development methods
Nothing more than development – joint adjustment – test – on-line constant process. But when it comes to the stage of development – joint investigation, the changes have changed a lot. As a front end, except for purely static pages, you basically have to rely on the back end. In simple terms, it is the change of front and back end separation. Now let’s do a comparison.
The time when the front and back ends are not separated, for example:
The front-end project is a part of the back-end project, such as a Java back-end project. At the beginning of development, I need to set up a single branch, install the Java environment, install IntelJ IDEA and Gradle, and then start the Java project, develop HTML, CSS and JS in the front-end, and negotiate interface format with the back-end. And then create some fake data to complete the basic process. After the back-end development is completed, the code is merged and the data returned by the real interface is used for joint adjustment. On-line also does not need front-end operation, directly following the end project on-line.
It’s a pain in the neck because you’re not familiar with the tools at the back end and often the service doesn’t start up or gets an error. In fact, this is not the most painful, there was a project, the back end is Php, the front end to develop samrtPHP module, but also have to log in the development machine, in Linux environment, using VIm to write code, is not killed.
Separation of front and rear ends:
Now basically, the front and back ends are separated, and the front and back ends are only connected through interfaces. This is cool, the front end only needs the front end of the set of environment, nodeJS, WebPack, etc., as long as the interface documentation is determined, you can develop whatever you want.
In addition, the front-end creates the BFF (Backend for Frontend) layer through NodeJS. The connection ports take over, and the back-end only needs to provide basic microservices. You don’t have to worry about asking the back end to return this, this, this field.
Further, the front end is now starting to use NodeJS to start SSR (server rendering) to solve the problem of white screen generated by client rendering.
Changes happen all the time. Only by summarizing these changes can we better grasp the present and predict the future trend.