Written in the beginning

  • I have written two articles recently. One is:petite-vueSource code parsing and mining editor source code parsing, found inside the useSvelteThis framework
  • Recently, React17, vite has been gradually used in the production environment, so I have today’s thinking

Look at the evolution of technology on the front end

  • nativeJavascript - JqueryRepresents the era, for example, introducedJqueryAs long as
<script src="cdn/jquery.min,js"></script>
Copy the code
  • And then there was anothergulp webpackReact and Vue became popular around this time, and a whole bunch of engineering AIDS followed, such asbabelAnd there are packagescreate-react-appSuch as scaffolding
  • And that brings up the problem, of course this isnpmBefore starting a project, a large number of dependencies must be installed. Even if an optimized dependency management tool such as Yarn PNPM is used, the root cause of the problem should not be solved by the tool. The essence of the problem is dependent localization

To sum up, the existing development model makes the project too heavy. For example, I want to use a scaffold and I just want to write a HelloWorld demo. As a result, it lets me install 500MB of dependencies

Ideal development mode

  • 1. No need for auxiliary tool configuration, I don’t need webPack to help me packaging tools, modular browser itself support and is a specification. Vite, for example, claims to be unpackaged and uses the ESM modularity that the browser itself supports, but it doesn’t solve the dependency problem, because the dependency problem itself is a dependency problem, not a tool problem

  • You don’t need to install dependencies. Everything can be imported from remote. I think webPack5’s Module Federation design takes this into account.

    • Multiple independent builds can make up an application, and these independent builds should have no dependencies between them, so they can be developed and deployed separately.

    • This is often called a micro front end, but it’s not limited to that.

This may not be a best practice, however, as there is currently import from HTTP, for example

import lodash from 'https://unpackage/lodash/es'
Copy the code
  • Here again some people will ask, that you are not to send requests, are to every time the boot time to remote pull, not as local.import from httpI think it just solves the problem of not having to manually install dependencies to the local disk
  • Some time ago I wrote about running Node.js locally in a browser

This technology is called WebContainers technology. If you are interested, please refer to the previous article on my official account

  • Wait, don’t worry. This is just the beginning. New technologies need to be explored to maximize their value. I think this is where the development paradigm can be completely overturned, and it should be within 3-5 years.

Merge several new front-end technology ideas?

  • viteThe unpackaged concept: directly use what the browser supportsesmmodular
  • WebContainersTechnology: Let the browser run directlynode.js
  • import from remoteTo import usable dependencies directly from a remote address
  • It’s hot right nowwebIDESimilar to:remixEditor, can be done directly in the cloud
  • Browser optimization, natural caching support

What will change?

  • We start everything by simply launching a browser
  • In the browserwebIDE, can directly introduce remote dependency, the browser can runNode.js, the use of theesmModular, no packaging tools required, project startup time and hot update time are very short, and builds can be built directly in the browser

These seem to answer most of the questions we’ve been asking, which brings us back to today’s topic

Back to the topic

  • Will the front end go back to the operation nativedomThe age?
  • I think there’s a tendency, for examplepetite-vue, as well asSvelte.

Since WE’ve written about Petit-Vue source parsing, today we’ll talk about Svelte

Svelte

Svelte is a new way to build user interfaces. While traditional frameworks like React and Vue do a lot of work in the browser, Svelte puts that work into the build phase of building the application.

  • The difference is different from using the Virtual DOM. Svelte writes code that surgically updates the DOM when the application’s state changes

  • Above is the official introduction, we look at the article on zhihu https://zhuanlan.zhihu.com/p/97825481, feeling he was well written, copy some come here directly here

  • React and Vue are both Runtime based frameworks. The runtime based framework is that the framework code itself 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 runtime diff out which DOM nodes need to be updated based on the new component state

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

(today, I still told my colleagues that I wrote the login site the year before last, pure native handmade, performance is invincible)

  • 100kbFor a weak network environment, it’s very bad. Let’s seesvelteHow much volume is reduced:

The popular science

  • virtualdomIt doesn’t make the browser response faster for the user, it just makes it easier for the data-driven view, easier to manage, and, to some extent, slower. The fastest is always:
Currentdom.innerhtml = 'front peak ';Copy the code

So It’s not that Svelte is a great idea, but the idea of Svelte may become more mainstream in the future

The change of React17

  • As you know, existing browsers don’t directly decode JSX, so most React users will need to use a compiler like Babel or TypeScript to convert JSX to JavaScript that browsers can understand. Many preconfigured toolkits (such as the Create React App or Nex.js) also have JSX conversions inside.
  • React 17.0, although the React team wanted to improve the JSX conversion, the React team didn’t want to break the existing configuration. That’s why the React team has partnered with Babel to provide a new rewrite of the JSX conversion for developers who want to upgrade.
  • With the new conversion, you can use JSX alone without having to introduce React.

I guess the React team is trying to push the JSX syntax into being the STANDARD ES syntax, and hopefully it will improve a lot more when it’s separated.

Focus on

  • Having said so much, you may not understand the point, that is: everyone is thinking of reducing their own weight, dropping things standardized, to the browser processing, this is also for the future only need to open a browser, you can complete all the things to pave the way
  • I believe that day is not far off, and I know that there are some top teams working on this product

Write in the last

  • If you have any questions, leave me a comment below
  • If you feel well written, help my public number:The front-end peakPoint aWatching/liking/followingThree in a row, original is not easy