Future-oriented front-end development model
Before, I have introduced you to the
webcontainer technology, which is the technology that allows Node.js to run in the browser.
- The Web has evolved to the point where it can provide most of the functionality of locally installed applications. With the powerful features of WebAssembly, modern browser APIs (such as Web/ServiceWorker and SharedArrayBuffer), and increased access to hardware, the elements that unlock the full potential of the Web have been created, and the boundary between native applications and Web-based applications has never been so narrow. In the past, solutions like Electron helped fill this gap by creating a sandbox for web-based applications to access system-level resources. By standardizing around WASI and other interfaces, we can actually have a portable runtime that matches the functionality of the native application, while maintaining the security and consistency of the Web that we expect. Although WASI aims to bring modular system interfaces, there is still a need for an operating system for WASI modules to interface in the browser. WebContainer provides a small portable container and operating system designed for modern applications. The WebContainer working group aims to bridge this gap and help accelerate the world's transition to WebAssembly-based computing.
It all stems from the fact that I received this email. I wrote in the article before that this technology may subvert the current front-end development model. How will it subvert?
The pain of the front-end status quo
- The pain of dependency management: To use some well-known cli, you need to install a lot of dependencies with npm or yarn or pnpm. I just want to write a helloworld, which may reach 1G of dependencies. If it is a mac computer, delete these node_modules files when not in use It’s okay, but when you delete windows, it may be very slow, causing the computer to get stuck, and you will encounter permissions issues, etc.
- The pain of setting up the environment is difficult: first install nodejs and npm, otherwise the project will not run locally. It is obviously a page boy, but you have to contact nodejs. It is not friendly to novices, and there may be pits in various operating systems.
- There are too many tools and can’t be unified: we may have to write code in webstorm/vscode, and then install the xx plug-in, and the habits of colleague A and colleague B may be inconsistent, so the plug-in may not be universal, write code in the editor, debug in browsing , Other tools can’t be unified
I just want to be a front-end, browser-oriented programming, but you let me install so many things, in order to break the silver, I will bear it! ?
webcontainer technology may help us solve these pain points
When node.js can run in the browser, we don't need to install vscode, node.js and various plug-ins on the computer, just open the browser and enter (for example,
Feel it, open the browser and you can program, the feeling of millisecond-level startup and hot update
Some people will say, aren't you just a webIDE? But webIDE lacks the ability of
webcontainer , 06110ee9b4cf94 is capable of node.js.
For example, if I write nodejs in the browser, I can execute my commands, install the corresponding dependencies, etc.
The above two points have solved our node_modules black hole and the pain points of installing various software on the computer. I only need to install a browser, I can write React, write nodejs, write next, and write whatever I want.
The point that excites me the most-comfort
Entering the next project, it only takes a few seconds from the installation of the dependencies to the startup. You must know that if you are in daily development, this time may take a few minutes
Try to install lodash
yarn add lodash -D
About 7 seconds, all operations are completed in the browser environment, pay attention to the browser environment
But how to localize the code on webIDE?
Button on the URL, one-click localization, as long as two seconds, the code will be local
The hot update is completely closed in the browser from code writing to compilation and packaging, and all actions are completed as long as a browser is opened.
Is it very fragrant? Is it very comfortable? Open a browser to get everything done.
Talk about the current problems of this development model
1. Run in the browser sandbox environment. In the browser environment, cross-domain situations will occur, which means that the database, mysql, and redis connections will be limited (Google Chrome may support native sockets in the future, and it has been private. The students who develop the communication protocol should know what this is, this is the issue address, and it is currently in the open state)
2. The bottom layer uses a specific Turbo package manager, not npm or yarn, and is specifically optimized for the browser (this seems to be compatible as long as it is compatible)
3. It is still in beta status and the official version has not been released yet
4. Compatibility issues, some browsers are not compatible with Web/ServiceWorker and SharedArrayBuffer
5. Packaging is currently not esm
Principle of this technique
- The source code is not yet open, the following are based on documents and guesses from me
In my opinion, the webcontainer technology is more like a wasm framework and library. For example, if nodejs can run in the browser, then this nodejs must be a wasm binary file. After webcontainer is introduced, nodejs can run on In the browser
Like some installation-dependent cache optimizations, ServiceWorker's tcp network request capabilities are used, as well as intercept requests, optimizations, and so on. This can also be used later when the computer is offline
Package installation, like npm yarn, is installed on the local disk, but in the browser environment, it is not installed on the local disk. According to the official statement, every time you enter an environment, it is cleaned again and needs to be installed again. , I’m not sure here, because the official said that packaging is not esm, which means that you may process the dependencies yourself and then package and build. Maybe the content is placed in memory during installation, and it does not fall into the disk, or it exists. In the cache of ServiceWorker (here I found that some files will be cached or exist in the cache of ServiceWorker)
At present, this technology is not mature, but it is strongly recommended to try it. The concept of stackblitz is great. One browser can handle everything, but the biggest problem is that the native socket capability has not been released, but it has been done. Anyone at IM or Electron knows that if the browser releases native socket and has the technology of webcontainer, in the future we really only need to install a browser and it will be done.
After watching two things
If you think this content is very inspiring for you, I would like to invite you to help me with a few small things
1. Click "Watching, Like, Follow" so that more people can see this content (click "Watching", bug -1 😊)
2. Follow the WeChat public account "Front End Peak", let me continue to push selected good articles for you
I am Peter Tan, a front-end development engineer in a small factory. I like to do architecture, and I have a certain research on performance optimization and cross-platform development. I also like to do self-media and blockchain. Welcome to follow me