Overall, there is not much change in the general trend. There are no specific technologies in mind, but rather an overall (strategic) view. So, here are the points:
Front-end architecture governance. The micro front end “popularizes” low-code platforms and reverts past the front end, which seems to have been the last point all along.
Front-end architecture Governance
Front-end architecture governance is a complex issue, and we got caught in a dilemma: there was so much to do, but the flexibility of JavaScript frustrated us at every step. So, at some point, there are limits to what we can govern. Some of the common ones are: build optimization, componentization, microfront-end, etc.
Large front-end applications
The scale of a single front-end application is in itself relatively rare – in terms of scale. But when it does, it often takes a lot of work to manage the entire front-end application and develop some tools. Fortunately, there are already plenty of tools out there, and you can write a lightweight automated CSS refactoring tool like Lemonj.
To be honest, if we don’t manage the color variable in CSS properly, then overall normalization becomes a new problem.
Journey to the specification
I don’t want to waste my time on this topic, but it’s really frustrating.
Brothers and sisters, use TypeScript whenever you can, use TypeScript whenever you can, use Lint whenever you can, use Git Hooks + Husky! Use Angular when you can for large front-end projects.
Micro front end ‘pervasive’
Since 2018, when I started to promote the micro front-end architecture, the infrastructure of this architecture pattern has become more and more mature. We can clearly see that it has moved from the big front end teams to the small front end teams. The main intention of adoption has also changed somewhat. What started out as a microfront end for large application architectures became, over the years, an evolutionary solution, a smooth migration of older systems, in many of the consulting projects I worked on.
The micro front-end framework is mature
After I wrote mooA, the first micro-front-end framework in China, more and more commercial-grade micro-front-end frameworks were born in China: Qiankun, NGX-Planet and so on. Each of these frameworks has its own applicable scenarios, and I will not expand them here.
One thing is for sure: these frameworks rarely directly meet the needs of most projects — for business-specific reasons. So I’ve been designing more and more micro-front-end evolutions over the last few years.
Progressive evolution scheme
For a normal business development project, the micro front-end architecture is not an overnight move, but an evolution. Thus, related progressive evolution schemes are derived, such as:
Meta-micro front-end framework. In 2020, because a company needs a more competitive micro front-end framework, so I think of: meta micro front-end framework. I haven’t taken the time to imagine such a framework, but similar ideas have been adopted. Multiple loader mode. To the microfront-end framework, it is, in a sense, just an application loader. The loader is used to load applications with different frameworks, such as Angular, Vue and React. For applications that do not use this framework, a new loader is required. Thus, the multi-application loader pattern was born. Custom micro front-end frameworks. Adapt the existing micro front-end framework to fit the existing business architecture. Therefore, as an architectural pattern of front-end legacy system rewrite, microfront-end will become more and more popular.
Low code platform back to nature
After a few years of fire in the middle platform, known as the “front-end middle platform” low code platform is also more and more popular in the whole market. In this industry, developers have three areas: No code, low code, and Pro code, and when developers combine these three areas into one system, the system becomes very strange.
In my opinion, since the audience is different and the level of the audience is different, we should have three separate, separate systems. Just because they can share infrastructure doesn’t mean they’re a system.
Reinventing the User Experience
For a low-code/no-code platform, the complexity of the platform is primarily caused by the business it is intended to host. For a low-code platform that just does H5 or forms, the design itself won’t be too complicated. As there are more and more scenarios, the system becomes more complex until the user can’t understand it.
Things happen in their own way, and when the platform meets its needs, the natural next step is to reinvent the user experience.
Building the Developer Experience
PS: This little section is mostly from my personal point of view and may be representative of some developers.
From an individual perspective, drag and drop can be very costly for developers. If something can be encoded, if it can be solved by pressing buttons, then it will definitely improve efficiency. As a simple example, when designing a low-code platform, we name components, such as headers. So, we can generate DSLS representing pages/components directly with snippets such as VS Code, much faster than I can just drag and pull on the page.
Writing DSLS dynamically is better than dragging and dropping.
Beyond the front
Backend engineer, first it’s an engineer, then it’s a backend engineer. Front end engineer, first he’s an engineer, then he’s a front end engineer.
When thinking about a problem, we should also consider the problem from the overall point of view, and then look at how to global optimization from their own point of view, which is the difference between experienced programmers and ordinary programmers. Therefore, from a higher perspective, the problems are different, such as global optimization of BFF, such as Serverless architecture, etc.
Serverless integration
For a large number of small applications, using Serverless + applets directly is a very cheap and fast solution. At least up front, the cost of trial and error is so low that you don’t have to worry about servers and concurrency or waste a lot of server resources.
Regardless of the technology stack, you should try the Serverless architecture in 2021.
Go back to cross-language
Rust, Web Assembly, or Kotlin, or some new language, could be a new way for developers in other fields to write code that runs in the browser.
For over a year now, it seems to everyone that I’ve been fooling front-end developers into writing Rust. The reason is that behind it is Mozilla — which runs fast on top of a browser and is a system programming language — which can try a lot of very interesting traditional applications.
other
Finally, let me close with an old question — depth versus breadth?
The answer to this question is actually quite simple, and quite shocking. It depends on the size of the team we’re on, and when the team is big enough, we have a better chance of trying out some particularly interesting new technology, or optimizing the technology in a particular area. The same applies to the back end.