Where is the bottleneck of front-end development, whether front-end technology has come to a crossroads, and whether full-stack system architecture can change the current predicament? This article will talk about some problems and ideas in the current front-end development according to the author’s own development experience.
primers
A question I’ve been thinking about for the last two years:
If the front end doesn’t have to worry about performance, terminal compatibility, legacy issues, or even technical implementation…
If we assume we have a wealth of technology and don’t have to worry about the above questions, what can the front end actually do that is of value?
Let’s go back five years…
If you’re still front-end development “back then.” The above question is certainly typical of what you have to face. Even what front-end development was all about at the time.
- You’ll stay up late at night trying to accurately reproduce the design, so that you can develop a pixel eye.
- You study optimizations to solve performance problems of a few bytes so that you can read every HTTP header.
- You’ll talk to your colleagues about technical issues and eventually get to the point where you’re talking to the product.
- .
But as time went on, the front-end technology updated iteration, and the development of the Internet. You will find that the problems that once seemed to be no longer problems, or may not be problems for the foreseeable future.
Page loading performance may no longer be an issue, with HTTP2 in technology, 5G in infrastructure, and fast hard drives.
As compatibility issues receded, Chrome became the dominant player and Microsoft had to move in with it.
Many front-end developers already have back-end (or multi-end) technology capabilities, and technology storage may not be an issue, provided you can hire people.
define
What exactly is front-end development, and where is the line between front-end and back-end? I defined it three years ago as:
The front end is responsible for the interface and interactive display; The back-end is responsible for data and business logic;
But it seems to be outdated now, and I feel more and more that there shouldn’t be such a clear line separating the front and back ends, especially at the technical level (except that functional boundaries are good for collaboration). It’s like saying: If you can’t break the rules, you’ll be bound by them.
I’ve always believed that programmers should be able to adapt to new technologies, tools, and ideas faster than the average person. For a simple example, I used to write code that used to use TAB indentation, but then everyone suggested using Spaces, and I refused to change to Spaces at first because it was so hard to get people to change their habits. But when you actually do it for change, you often find a new path. There is also the question of whether to add a semicolon.
Now looking back, the front-end’s role at the system level should be at least the View level. Technology at the view level is closer to the upper layers of the software system and more emotional. Emotional things mean that a color, I think beautiful, he thinks not beautiful, completely belong to personal emotional appeal. So the front end is more focused on the UI, interaction, and overall product-level issues that need to be addressed. A good front end must have keen product insight.
Of course, this is only the most basic responsibility of the front end. At the same time, as the technical role closest to the product, technology is the real hard power of the front end.
In the last year or so, I’ve moved from a front-end role to a back-end Java programmer role. Although I have only been a Java programmer for one year, it is the most time for me to improve my skills. It may be common to think that it is easy to go from back end to front end, and there is a threshold for going from front end to back end, but in my own experience that is not the case.
The Java language is a commercial, highly mature language. No matter the language itself, or the surrounding framework, tools have a very mature and hierarchical systematic abstraction. If you have two or three years of programming experience, it’s very easy to suddenly convert Java, especially Java Web. The Spring framework has shielded programmers from a lot of complexity and has become the de facto mainstream framework for Internet companies.
I specially according to my own learning circuit draw a Java version of programmer learning circuit, for reference only:
We can clearly see the biggest feature of the entire Java architecture: it is incremental, step by step to establish positive guidance for developers.
When I am in the application layer stage, ALL I need to care about is some concepts and methods. After I have the foundation, I can use the Spring framework to get started. After getting started, I can study the source code. That’s when servlets appear. When I was in school, I could not understand the concept of Servlet in Java. Later, I went to work and learned Some Python. When I saw the Servlet in Java again, I immediately understood that it was UWSGI in Python, just an interface. A specification that links a programming language to a server gateway.
Then you can move on to the next step, server/communications. Here you will find the core of the entire network programming Socket, also before the school did not understand the concept of Socket, continue to learn after you will understand that Socket is actually an operating system to provide a programming language ability, with it can establish communication between the server and the client. While (true) {socket.listen()} while (true) {socket.listen()} while (true) {socket.listen()}
In order to solve the performance problem of “while true” listening connections, you will learn about multi-threading and understand the concept of concurrency. You’ve probably heard people talk about the difference between concurrency and parallelism. As you continue to learn, it will become clear that concurrency is more about network IO (hard disk) efficiency, while parallelism is more about multiple/core processor (CPU) efficiency. You’ll notice that there’s a lot of hardware involved in this phase. Memory allocation, CPU calculation, IO multiplexing and so on.
A framework like Spring can truly be called a framework because it not only solves software development problems, but more importantly, concepts like AOP/IoC can completely change the way programming works. Using Spring to develop web applications, combined with Java to build an ecosystem, the entire development process is as natural as breathing.
The software development architecture built by Java is like putting the programmer into a hierarchical cabinet where you don’t have to pay attention to the outside world and just do your part of the job. If you’re interested in the outside world, follow it up a little bit and get out of your closet. Maintain focus and focus while establishing an orderly ascending curve. This is not found in other language systems.
In fact, I had a lot of misunderstandings about Java before I switched to Java, and it wasn’t even my idea to switch to Java. But when you actually become a Java programmer. When you’ve read a code warehouse with millions of lines of code, maintained QPS projects with hundreds of thousands of lines per second, and seen SQL with hundreds of lines of code, you’re in awe of Java and software development, and you have a deeper understanding of technology.
When you go back to the front end and look at JavaScript, you can see the differences and characteristics between them. A lot of the things that were argued before have come to a conclusion.
bottleneck
I’m sure people who have been on the front end a little bit longer (5 + years) have had a feeling in the last two years that there seems to be nothing to play with on the front end. This is because many things have become the mainstream of the front end in fact, and the infrastructure that the front end did not have before is gradually improved. Languages, frameworks, visualizations, cross-ends, games, tools/automation/engineering are all evolving.
TypeScript is definitely mainstream on the language side, and you’re going to have to use it to write front ends whether you like it or not. React framework aspect is already de facto mainstream, there is no need to make choice question. Packaging tool Webpack is also dominant, although many people criticize, but the community ecology, it is difficult to change. Don’t worry about the cross-terminal Electron app. VSCode can do it well and if you can’t, it’s not a matter of selection. PixiJS 6 is already in the works for 2D games/graphics, but I personally don’t want to play 3D yet.
These seemingly mature systems actually have a lot to offer. If you don’t dig deep, you might think that in two years these technologies will be stable and the front end will be unified. This may be naive, but let me give you a few examples of their bottlenecks:
Pre/client framework bottlenecks
React (not specifically referred to React) although React seems to be the mainstream now, it has many problems that have not been solved, even there is no solution. React is essentially a UI Library, not a Framework. The problem a framework solves is at the system level, not at an abstract level. React doesn’t solve the problem of data flow in SPA applications. It doesn’t even solve the problem of state management (or is it a fake proposition?). . A simple problem of state sharing between parent and child components has not yet been solved. Hooks like this are more like Peter to pay Paul.
And there is a cult of functional programming in the React community right now, with hooks acting more like a FIG leaf. The reason most people use hooks is simply because they don’t want to use Class, because Class is bloated, function is simpler. Of course the logic is fine. Functions are simple, but if you write hundreds of lines of code inside a function, you will have to think about how to organize your code when hooks start flying. If Class can be abstracted in a better/more understandable way then why not?
Bottlenecks in the back/server framework
Front-end frameworks are no better than Node.js-based back-end frameworks. Do you really want to write large back-end applications in Express/ koa.js? A framework of this magnitude does not fully support even the simplest three-tier model (model, view, controller) of Web development. Of course, you could argue that small frameworks are inherently focused on one aspect, and that the view and model layers can be handled with other three-party libraries. Yes, that’s possible, but don’t you think node.js has too many third-party libraries? As NestJS notes in its documentation, “many JavaScript libraries do not efficiently solve a problem architecture.” React/Vue/Express/Koa are all relatively independent points, and nothing connects them to form a surface, forming a framework level system. That’s the problem with architecture.
Here’s a bit more, combined with the Java built ecology above, compared to Node.js. I’ll use my own analogy: if you look down and see Node.js, you don’t necessarily see Java when you look up. If you’ve been in front-end development for two or three years and you’ve hit a wall and want to switch to Node.js, you’ll learn about frameworks like Exporess/Koa, but soon you’ll have a serious problem: you won’t be able to go any further. Because when you write a page with Express, you’re faced with all sorts of technical blind spots, and you don’t know what to do.
I also tried to draw a picture of my understanding of JavaScript/ Node.js or the big front-end architecture:
The JavaScript architecture seems to be both front and back, client, server, and even desktop. But the biggest problem is that there is nothing to build relationships with and develop into a system.
Just for fun, DHH, author of the Ruby on Rails framework, tweeted a few days ago:
The general idea is as follows:
Is that what young people are like today in Web development? The underlying logic, pure handwritten connection pool + pure manual SQL, configuration files are all put together. Oh my god! (Express frame written by TJ Daishen used in screenshots)
Then TJ replied:
The general idea is as follows:
Only novice players can write clean, concise, high-performance (black Ruby performance), recognizable SQL instead of writing a 15-layer abstraction.
It’s an interesting twitter conversation between the two. Let’s have some fun.
TypeScript language bottlenecks
TypeScript is mainstream as well, but following TS until now, I’ve found that TS is also running into a bottleneck, not only in terms of TS design goals and ideas, but also in the community and TC39. TS is designed to be a superset of JavaScript, and since it needs to be compiled into JS, this essentially limits the direction of TypeScript. Designers are very cautious about adding a new feature for fear of conflicts with TC39 ES Proposal. The compatibility of compiling to different versions of JavaScript is an issue. So much so that now the new TS language features will only follow the latest ES Proposal released by TC 39. But I personally have my doubts about the efficiency and future of TC 39. The decorator proposal is still in Stage 2, other languages like this have been standard for several years, and the JavaScript community is still in stage-2.
To popularize the ECMA standard process:
- Stage-1: A preliminary idea
- Stage-2: Formal proposal (stage where the decorator is)
- Stage-3: Implementation candidates
- Stage-4: Complete the test
- Each browser JS engine implementation; TypeScript implementation
I think it’s a pretty easy problem to solve here, but imagine: if Microsoft wants to unify the browser and client with a programming language, it’s not impossible. Joining the TC39 organization and developing a true TypeScript native engine, it’s possible to do so in a way that makes you feel bad.
Microsoft’s commitment to open source in recent years is visible to the naked eye, and Microsoft is going to make a difference. I believe many things will change dramatically.
Packaging tool bottlenecks
Not to mention Webpack/Babel, the mainstream of the mainstream. But it’s also the most problematic one. The popularity of Webpack/Babel proves just how bad the front-end infrastructure is. Webpack/Babel is eval. We introduce a new tool to solve a problem, only to inadvertently create a new problem.
The root of the front-end build tool problem lies in the design of node.js package management tools. This was officially acknowledged by Node.js author Ryan Dahl in his talk About Deno, “10 Things I Regret About Node.js”. I’m sure anyone who has implemented a build tool has been beaten by Node Gyp. Node-sass, fsevent pain need not be detailed. Not to mention the hacked node_modules, you have no idea that a simple NPM install command can cause thousands of NPM packages to be installed on your machine.
Of course, every programming language’s package-management tool has to deal with dependencies, and this is a common problem, especially for scripting/interpreted programming languages, Python/Ruby/PHP. Perhaps the Go/Rust approach of packaging source code compilation into a single executable is a better solution.
In the future
People used to complain about JavaScript, denigrate it, and satirize it. But what I see is that it’s getting better. Not only is the language level gradually improved, the toolchain ecosystem is increasingly mature, and more and more people are using it. People are paying more attention to it, and JavaScript developers in general are getting better and better. The environment will only weed out those things that are old and no longer evolve, and those that can adapt will survive.
JavaScript has two advantages that no other programming language has:
- Almost everywhere and without installation, JavaScript is available in every browser. Scripting languages mean that they can be embedded in any host environment: Nginx, Native applications, hardware programming, iot, embedded
- The language has a strong ability to adapt to new iterations of technology. JavaScript itself evolves at a rapid pace due to its rapid iteration, and new features in the language are quickly implemented in production environments. This is a dream compared to Python, where no one can see the real schedule for Python 2 to 3 conversions.
The present situation of front-end development reminds me of a passage in Chao Fault Theory by Su Dongpo:
The worst thing in the world, the worst thing to do, called cure nothing, but in fact there is the worry of the unexpected…
The biggest problem is that some things, on the surface, look ordinary, but in fact there is an undercurrent, as if every moment has the possibility of change. This is where front-end development is most interesting and promising.
As a front-end developer of the new era, it’s all about finding some real breakthrough beneath this seemingly calm surface, or maybe it’s just a simple idea, adapting to the current situation and achieving great results.
Whether front-end or back-end, domestic or foreign, technology is the real core competitiveness, only technological innovation can improve productivity, and for us programmers, programming is the only way to improve hard power. As long as you have passion in your heart, you will always find a way out of it.
Share a small experience
I had the opportunity to attend the TypeScirpt launch in 2018, where TypeScript author Anders Hejlsberg was the speaker. A programmer of nearly 60 years old was on the platform talking about technical solutions and TS design ideas. It is hard to imagine such an old man (actually very young) in his “destiny” stage.
A young man in the QA session asked Anders, “It’s very tiring to be a programmer in China and it’s very hard to keep going (I can’t remember the details).”
Anders said the word “Passion” almost without hesitation. I was instantly impressed. Before that, my understanding of the word “Passion” was confined to the speech speech of successful people. When Anders said the word “Passion” himself, it really felt like a word of gold.
Up to now Anders has been a core contributor to TypeScript, contributing code to it and traveling to promote TypeScript.
Going back to the front end, what is the future of the front end? The long term is uncertain and unpredictable, but in the short term I’m focused on a few things:
- ESBuild: an extremely fast JavaScript Bundler. This tool is the real “Game Changer”. It’s also a packing task, and it’s so fast that you finish the task before you know it. ESBuild is a complete set of parallel ES parsers and code generators written in Go by Figma’s CTO (yes, foreign Ctos write code). Vue’s new build tool will also be used to do the TS packaging function based on the frequent updates recently.
- Deno: A secure JavaScript & TypeScript runtime. The direction of Deno is full of possibilities. In the future, Deno can not only be a JS backend, but also connect with Rust to inject some native capabilities into JS. Then Webasmbly, webGL and other technologies become possible, and the official release date of 1.0 is coming.
- Figma: An online version of Sketch, although not as powerful as Sketch, has the basic capabilities of the design interface. The key is that its whole implementation is based on web technology. The bottom layer C++ is used to render and draw graphics, and the front end interacts with the browser Canvas through Webasmbly, enabling users to experience Native software capabilities on the browser end. Features like AutoLayout are disruptive in terms of the user experience, as it feels natural and non-existent when used. But once you use it, you can’t go back.
If you look closely, all of these new things, they all come from the front end, but they’re not limited to the front end. Maybe this is the future of the front end.
Keelii.com/2020/05/10/…