Is the front end going back to operate the real dom age?

Write at the beginning

• I have written two articles recently, one is: petite-vue source code analysis and the source code analysis of the Nuggets editor, and found that the framework Svelte
• In addition to the recent React17, everyone is gradually using vite in the production environment, so I have today’s thinking

Look at the technological evolution of the front-end

• The era represented by the original Javascript - Jquery , for example, the introduction of Jquery as long as

<script src="cdn/jquery.min,js"></script>

• Then there were gulp webpack and other construction tools. React and Vue also started to catch up at this time. Then came a lot of engineering auxiliary tools, such as babel create-react-app and other scaffolding that provide a complete set of services.

• This also brings problems. Of course, this is npm . Before starting the project, a large number of dependencies must be installed. Even if there are optimized dependency management tools such as yarn pnpm`, the root cause of this problem should not be solved by tools. But the essence of the problem is to rely on localization, code and dependencies need tool help to run in the browser

  The summary is: the existing development model makes the project too heavy. For example, if I want to use a scaffolding, I just want to write a helloworld demo. As a result, it asks me to install 500mb . Different scaffolding products have different configurations and products. different

Ideal development model

• 1. No need for auxiliary tool configuration. I don’t need tools like webpack to help me pack. The modular browser itself supports it, and it’s a specification. For example, vite claims to be non-packaged and uses the esm modularization supported by the browser itself, but it does not solve the dependency problem, because the dependency problem itself is a dependency problem, not a tool problem.

• 2. do not need to install dependencies, everything can import from remote , I think webpack5 of Module Federation design, on account of this, the following is the official explanation:

  • Multiple independent builds can form an application. There should be no dependencies between these independent builds, so they can be developed and deployed separately.
  • This is often referred to as a micro front end, but it is not limited to this.

But this may not be the best practice, there is currently import from http , for example

import lodash from 'https://unpackage/lodash/es'

• Someone here will ask again, don’t you always want to send requests? You have to pull them remotely every time you start it. It's better to do it locally. import from http I think it just solves a problem, that is, it does not need to manually install the dependency to the local disk

• I wrote some time ago, run Node.js locally in the browser
  

  This technology is called WebContainers technology. If you are interested, you can go to the previous article of my public account.

• Wait, don't worry. These are just the beginning. New technologies often need to be explored to maximize their value. I think this should be able to completely subvert the existing development model, and it should be within 3-5 years.

Combine several new front-end technology concepts?

• vite 's non-packing concept: directly use the esm modularization supported by the browser
• WebContainers technology: let the browser run node.js
• import from remote , import the dependencies that can be used directly from each remote address
• webIDE is very popular now: Similar to remix editor, all can be done directly in the cloud
• Browser optimization, natural cache support

What will happen?

• All of our start, just start a browser directly
• webIDE in the browser can directly introduce remote dependencies. The browser can run Node.js . esm modules are 060fafca2b50b0. No packaging tools are required. The project startup time and hot update time are very short. The construction can also be directly in the browser. Build in

These seem to solve most of the problems we raised before, back to today’s topic

---

Back to topic

• Will the front end return to the era of dom

• I think there is this trend, such as petite-vue and Svelte .

  Because I wrote petite-vue source code analysis of 060fafca2b515a before, let’s talk about Svelte

Svelte

Svelte is a completely new way to build user interfaces. Traditional frameworks such as React and Vue need to do a lot of work in the browser, and Svelte puts this work in the compilation phase of building the application.

• It is different from the use of virtual (virtual) DOM. The code written by Svelte can update the DOM like a surgical operation when the state of the application changes

---

• The above is the official introduction. Let’s take a look at https://zhuanlan.zhihu.com/p/97825481 article 060fafca2b51f7. It feels like he wrote it very well. Just copy some of it here.
• React and Vue are both runtime-based frameworks. The so-called runtime-based framework means that the code of the framework itself will also be packaged into the final bundle.js and sent to the user's browser.

• When the user performs various operations on your page to change the state of the component, the runtime of the framework will calculate (diff) which DOM nodes need to be updated based on the new component state (state)

  However, the frameworks that are packaged in are too big.
  (I'm still telling my colleagues today that the login site I wrote the year before was made by hand with invincible performance)
  

• 100kb is terrible for a weak network environment. Let's take a look at how much volume has svelte

Popular science

• The virtual dom does not speed up the response speed of the user operating the browser, but it is convenient to use for data-driven views, more convenient to manage, and to a certain extent, slower. The real fastest is always:

  currentDom.innerHtml = '前端巅峰';

  So Svelte not to say how good, but its concept, which may become more and more mainstream in the future

Changes in React17

• Everyone should know that existing browsers cannot directly interpret JSX, so most React users need to use a compiler such as Babel or TypeScript to convert JSX into a JavaScript language that the browser can understand. Many pre-configured toolboxes (such as Create React App or Next.js) also have JSX conversions inside.
• React 17.0, although the React team wants to improve the JSX conversion, the React team does not want to break the existing configuration. This is why the React team worked with Babel to provide a new rewritten version of the JSX transformation for developers who want to upgrade.

• Through the new conversion, you can use JSX alone without introducing React.

  I guess that maybe the React team deliberately promoted the jsx syntax to become the es standard syntax, and I hope it will be greatly improved after separation.

Focus

• Having said so much, you may not understand the point, that is: everyone is thinking about reducing their own load, standardizing the dropped things, and handing it over to the browser. This is also for the future only need to open a browser. , You can complete all the things to pave the way
• And I believe that this day should not be far away, as far as I know, there are already many top teams in the development of this product

Write at the end

• If you have any questions, please leave me a comment below
• If you feel well written, please help my top of the front-end point Watching/Like/Follow Sanlian, it is not easy to be original