This week continues to reflect on the changes at the front end.
This is the fifth installment of this system. The first four are:
- Change of the front end (I) : change and invariance of technology
- Front end change (2) : “unchanged” front end
- Front end change (3) : change and breakthrough
- Front end change (3) : attack front end
I’ve analyzed front-end changes in previous articles. Howe certainly argues that front-end change is “qualitative” rather than “quantitative.” It is not the incremental emergence of a new technical language or framework, but fundamentally the disruptive substitution of one model for another.
In this article, I will discuss and analyze who brought such huge changes to the front end and what happened to the front end over the years.
Let me start with the history of the front end.
Front-end development history
The diagram above encapsulates the history of important front-end technologies in a timeline. There are several important points in this diagram:
- JQuery was released in 2006
- Chrome&V8 was released in 2008
- NodeJS was released in 2009, the same year ES5 was released
- Typescript was released in 2012
- React was released in 2013
- Vue was released in 2014
These nodes are worthy of reference.
As I explained in the previous article, JQuery is completely different from React and Vue.
JQuery is the best known framework of the “pre-front-end” era, while React and Vue are the best known frameworks of the “post-front-end” era. The difference between them is not so much quantitative as qualitative.
It was clear that the launch of v8 engines in 2008 and NodeJS in 2009 were the two technologies that caused the front-end to change dramatically.
V8 engine
The V8 engine is a JavaScript engine, which is an open source engine from Chrome.
What does a JavaScript engine do? In a word, yes
Translate JavaScript into code that the OPERATING system’S CPU can “read”
Now in 2021, there are not many of them, and the mainstream ones are as follows:
- Chrome’s V8 engine
- Mozilla’s SpiderMonkey engine
- Apple’s JavaScriptCore engine
In addition, React Native programmers probably know Hermes, which is a type of engine.
In fact, very few can make engines, which are incredibly complex and probably comparable to operating systems. The V8 engine is said to have millions of lines of code.
V8 engine is C++ implementation, its basic principle is to translate JS code into machine code, and then the CPU to execute.
Chrome’s V8 engine is for its own use, because a very important part of the browser’s job is to interpret and execute JS. So the V8 engine was originally designed by Chrome for the browser.
This was fine, until NodeJS came along in 2009, breaking the v8 engine from being exclusively in the browser.
NodeJS came out of nowhere
In 2009,NodeJS was introduced, and its website defines and describes it as:
Node.js® is a JavaScript runtime based on the Chrome V8 engine.
As for what NodeJS is, I have drawn a brief diagram of its architecture:
As you can see from this architecture diagram, it uses a V8 engine.
Just a quick word about what these things are:
libuv
A C library for asynchronous event loops. At runtime, it is responsible for an Event Loop, a thread pool, file system I/O, DNS-related and network I/O, and a few other important functions.
C-ares, Crypto (OpenSSL), Zlib, etc
Provides access to the underlying functions of the system, including networking, compression, and encryption.
Bindings
Bridge layer, responsible for JavaScript and C, C++ interaction
C/C++ Addons
Allows you to add additional C or C++ libraries, but you need to write Addons for them so that JS can call them.
In fact, if we look beyond V8 and JS, it’s a C/C++ environment, right? This is why NodeJS is cross-platform. Because C/C++ supports all systems.
What about the V8?
Why can a C/C++ environment write code in JS?
As I mentioned earlier, Chrome’s V8 engine is responsible for translating JS code into machine code. This is why NodeJS needs a V8 engine. Because of this engine, you can write server-side code using NodeJ to call system low-level apis such as networks, files, etc.
Many things grow on trees that are intended to grow
NodeJS wasn’t originally intended to optimize or change the front-end code. It was probably originally intended to:
Provide a new back-end coding solution in addition to traditional Java
As we all know, Java has always been the dominant server-side coding language. Java is a cross-platform language that is derived from the VIRTUAL machine JVM.
The advent of NodeJS clearly offers an alternative that is very different from Java
- Instead of using Java, it uses the more populist JavaScript language to write back-end code
- Instead of a Java thread-blocking implementation, it is based on an asynchronous + event loop implementation, which is much more efficient than thread-blocking.
- More importantly, it seems to unify the front-end and back-end coding. The backend code is no longer two different groups of people who struggle to communicate, but a group of people who speak the same language.
Because of these advantages, NodeJS was appreciated in its early days. This is where NodeJS is aiming to become a back-end programming language.
Some years ago, my company used NodeJS to write back-end services for some time.
Of course, NodeJS has not succeeded in its attempt to replace Java as the dominant programming language on the back end, at least in this respect.
I’ll talk a little bit about that later on.
A careless tree will have shade
From the perspective of the front end development timeline, NodeJS didn’t have much impact on the front end itself at first, so React didn’t arrive until 2013, four years after NodeJS appeared.
At least for the first few years, being able to write back-end server code with NodeJS doesn’t make much sense for front-end development. Front-end people are still writing JS, using JQuery, and still spinning around in JS+HTML+CSS.
NodeJS ‘ability to use JS to interact natively with native operating systems has not impacted Java on the back end, but it has brought a result that it may not have anticipated at the beginning:
It changes the way front-end coding is done
As I mentioned earlier, in the “pre-” front-end phase, front-end coding is always in JS+HTML+CSS. No matter how efficient and efficient Chrome’s V8 engine is, it just helps browsers execute and parse JS more efficiently. It doesn’t bring any ability for JS to interact with the native OPERATING system.
The ability of THIS JS to interact with native operating systems, such as reading and writing local file systems, networks, etc., is crucial for the front-end to enter the “post-front-end” phase.
Imagine that without this ability to interact with native systems, some of today’s mainstream front-end technologies and tools would not exist:
- React relies on this ability to translate JSX into JS
- Less,sass these programmatic CSS, there is no way to translate CSS
- The front-end package management NPM has no ability to read and write local file systems, so dependency management is out of the question
- Typescript will no longer exist, will V8 engines recognize TS? TSC translates TS into JS files for browser recognition
In fact, almost everything you code on the front end today, if you think about it for a second, relies on this ability to interact with native operating systems.
NodeJS, as a language explicitly intended to compete with Java in the back-end space, has certainly failed. But it was a huge success as an implicit support for revolutionary changes in front-end technology.
So, when a programmer downloads and installs NodeJS in 2021, chances are he’s not writing a back-end service with NodeJS, he’s writing front-end code.
This is where NodeJS is right now, far more on the front end than the back end.
Return of the King
So there’s no question that NodeJS is the king of the front-end.
In the “post-” front-end phase, any of the major technologies can have alternatives:
- You can choose Vue if you don’t like React,
- You can also choose between typescript and javascript,
- You can also switch between less, Sass, and CSS, none of which you have to use.
Nodejs is the only thing you can’t choose, no matter what you use, you have to download and install NodeJS, depending on the environment.
It doesn’t require you to write back-end programs, and you probably won’t even know it’s there in front end coding, but it’s essential to almost every mainstream technology you use in the current front end.
Unless, in one way or another,
Once again, you fall back into the “front” stage of using JQuery, writing HTML, and styling with CSS. It’s not impossible. Even in 2021, you can still do that.
Do you think it’s worth it, no matter what position you’re on, knowing that it’s not a choice, it’s degradation.
We can’t go back to that “before” front-end.
Leading change
The change in the front end doesn’t just affect itself, some of the best frameworks, it doesn’t just borrow ideas from other ends, it even goes further and does better in some aspects than others.
So that the other end has to go back and learn the concept of the front end.
One example is the declarative UI on the front end
I’ve been writing mobile native development for a few years now, and writing front-end development in 2020 feels very different on the UI.
While imperative UI programming is still dominant on mobile, React is already declarative UI programming
Obviously, declarative UI programming is better, so now both Jetpack on Android and Swift UI on iOS are learning from react, which is also the way of declarative UI programming. Although these have not become the mainstream of mobile, the trend of declarative UI is irreversible.
In the next article, I will continue to explore and analyze the changes in the front end, covering the changes in the front end (vi) : From imperative UI to declarative UI
Taoofcode. cc – Use our little power to spread the code path visit myDDD – full stack domain driver official website: myddd.org