Written in the beginning

  • Recently I have written two articles, one is:petite-vueSource code analysis and gold editor source code analysis, found that usedSvelteThis framework
  • In addition, recently, React17 and Vite have been gradually used in the production environment, so I have today’s thinking

Look at the evolution of technology on the front end

  • nativeJavascript - JqueryFor the era represented by, for example, the introductionJqueryAs long as
<script src="cdn/jquery.min,js"></script>
  • And then there was anothergulp webpackReact and Vue became popular around this time, followed by a whole host of engineering tools such asbabelAnd there’s a whole package servicecreate-react-appSuch as scaffolding

  • It also poses a problem, of course, this is a question of NPM, before start the project, to install a large number of dependence, even appeared the yarn PNPM ` optimization such as dependency management tool, but the root should not use tools to solve this problem, but the problem is essentially dependent on the localization, code and rely on tools to help is needed to run in the browser

    The summary is: the existing development model makes the project too heavy, for example, I want to use a certain scaffold, I only want to write one
    helloworldLet me show you. It turns out that it let me install
    500mbThe dependence of different scaffold products, configuration is different, the product is different

Ideal development model

  • 1. No auxiliary tool configuration, I do not need Webpack and other tools to help me package, modular browser itself support, and is a specification. For example,viteIt’s not packaged, it’s supported by the browser itselfesmModularity, but it doesn’t solve the dependency problem, because the dependency problem itself is a dependency problem, not a tool problem

  • 2. You don’t need to install dependencies, everything can import from remote. I think the Module Federation design of Webpack5 takes this into account, here is the official explanation:

    • An application can be made up of multiple independent builds, and these independent builds should not have dependencies between them, so they can be developed and deployed separately.
    • This is often referred to as a micro front end, but it is not limited to that.

But this may not be best practice, and there is
import from http, e.g. 

import lodash from 'https://unpackage/lodash/es'
  • Here someone will ask, that you are not to send a request, is to start each time to remote pull, it is better in the local.import from httpI think it just solves a point of not having to manually install a dependency on a local disk

  • Some time ago, I wrote about running Node.js locally in a browser

    This technology is called
    WebContainersTechnology, interested in can go to my public number before the article

  • Wait, wait. These are just the beginning, new technologies need to be explored to maximize their value, and I think this is where the development model will be completely disrupted, and within 3-5 years.

Fusion of several new front-end technology concepts?

  • viteUnpackaged concept: Use browser support directlyesmmodular
  • WebContainersTechnology: Let the browser run directlynode.js
  • import from remoteIntroducing usable dependencies directly from one remote address to another
  • It’s hot right nowwebIDESimilar to:remixEditor, all can be done directly in the cloud
  • Browser optimization, natural cache support

What will change?

  • We started everything by launching a browser directly
  • In the browserwebIDERemote dependencies can be introduced directly and the browser can runNode.js, using all of themesmModular, no packaging tools are required, project startup time and hot update time are very short, and builds can be built directly in the browser

So this seems to solve most of the problems that we’ve been asking before, so let’s get back to today’s topic

Back to the topic

  • Will the front end return to operation nativedomThe age?

  • I think there’s a trend, like Petite-Vue, or Svelte.

    Because I’ve written it before
    petite-vueSource code parsing, we will talk about today
    Svelte

Svelte

SvelteIs a new way of building user interfaces. While traditional frameworks like React and Vue do a lot of work in the browser, SVelte takes care of that work in the compile phase of building your application.

  • Different from using virtual DOM contrast. Svelte writes code that surgically updates the DOM when the application’s state changes
  • The above is the official introduction, let’s take a look at this article on Zhihuhttps://zhuanlan.zhihu.com/p/97825481I think he wrote it very well, so let me just copy some of it here
  • Both React and Vue are runtime-based frameworks. A runtime-based framework is one in which the framework code is packaged into the final bundle. Js and sent to the user’s browser.

  • When a user changes the state of a component on your page, the framework’s Runtime calculates (diff) which DOM nodes need to be updated based on the new component state

    But the frames that are packaged into them are just too big.


    (I’m still telling my colleagues today that I wrote the login site the year before last, which is made by pure native hand and has invincible performance)


  • 100kbAnd for a weak net environment, that’s pretty bad. Let’s seesvelteHow much volume was reduced:

The popular science

  • Virtual DOM does not speed up the user’s ability to manipulate the browser response, just that it is easier to use in data-driven views, easier to manage, and, to some extent, slower. The really fastest is always:

    CurrentDom. innerHtml = 'Front-end Peak ';

    so
    SvelteNot that it’s good, but the idea that it’s going to be more and more mainstream in the future

The change of React17

  • As you probably know, existing browsers don’t interpret JSX directly, so most React users need to use a compiler such as Babel or TypeScript to convert JSX into a JavaScript language that browsers understand. Many pre-configured toolkits (such as the Create React App or NeXT. Js) also have JSX transformations inside.
  • React 17.0 Although the React team wanted to improve the JSX transformation, the React team did not want to break the existing configuration. That’s why the React team partnered with Babel to provide a new rewrite of the JSX transformation for developers who want to upgrade.

  • With the new transformation, you can use JSX alone without introducing React.

    I suspect that perhaps the React team intended to push the JSX syntax to become the ES standard syntax, and that stripping it off would hopefully improve things a lot.

Focus on

  • So much is said, you may not understand the main point, which is: everyone is thinking about lightening their own load, standardizing the things they leave behind and handing them over to the browser, which is also laying the groundwork for the future, you only need to open a browser, you can do everything
  • And I believe that day should not be far away, as far as I know, there are a number of top teams working on this product

Write in the last

  • If you have any questions, let me know in the comments below
  • If you feel well written, help me with my public account:The front-end peakPoint aI'm watching/liking/followingIt’s not easy to be original