Welcome to my blog

History of the front-end

The front end develops rapidly, the new technology emerges in endlessly, do not keep pace, you will become the front wave, will be eliminated by The Times. I vaguely remember the pleasure of writing the MVC framework at the beginning, referred to as web1 era.

The most common question back then was what is an MVC, and the route controller listens for a path change and updates the data to the database, and returns a message with HTML text. The interaction of the page uses Ajax, so data can be updated without refreshing the page. The UI uses bootstrap responsive layout, and jquery is used to write a bunch of DOM operations and event processing. Talk about the drawbacks:

  1. Ajax requests don’t have the ability to remember transaction states, which reset when you pop up a popup or scroll to a location from another route back to the current route. Because the routing

2. Jquery is nice to use, but a bunch of JS DOM manipulation, event manipulation is very troublesome 3. Data interaction is frequent, and data changes in a module lead to many template updates, which require a lot of manual view processing operations

Until the emergence of the single page mechanism, the front-end appeared MVVM architecture, referred to as the Web2 era. At this time, the front and back end began to separate, and the division of labor of programmers became more obvious, one focused on data processing, the other focused on user interaction. It takes a lot less work and allows you to focus on one aspect of your development. Whether it’s vue’s watch subscriber mode plus proxy hijacking of Object.defineProperty. Or react fiber Diff Render. View changes are handled much less, and basically a lot of DOM and text operations are handled by react.js or vue.js. Jquery also slowly faded from the scene. In addition, vue-router and react-router-dom have their own routing processes. The same update data does not refresh the page but has the ability to record the page state. But how about just vue.js or react.js? For example:

<head>
  <link rel="stylesheet" ref="./index.css"/>
  <link rel="stylesheet" ref="./header.css"/>
  <link rel="stylesheet" ref="./content.css"/>
  <link rel="stylesheet" ref="./slider.css"/>
  <link rel="stylesheet" ref="./footer.css"/>
  <link rel="stylesheet" ref="./common.css"/>
  <script src="./react.js"></script>
  <script src="./reactDOM.js"></script>
</head>
<body>
	<div id="app">
	</div>
</body>

<script>
    import Header from 'Header.js'
    import Content from 'Content.js'
    import Slider from 'Slider.js'
    import Footer from 'Footer.js'

    Class App extends React.Component {
        return (
            <>
                <Header />
                <Conetent>
                    <Slider/>
                    <article/>
                </Content>
        <Footer />
            </>
        )
    }

    ReactDOM.render(<App/>.document.querySelector('#app'))
</script>
Copy the code

Obviously, if the page has a lot of content, for example, it will have the following disadvantages:

  • CSS naming, you have to make sure that you don’t have duplicate names in so much content that they mess up the style
  • I can only write using ES6 syntax, not to mention whether the browser supports it or not, I think it is not possible to use CommJs or Amd syntax (I think it should be unified syntax, unified specification to write EMS).
  • There’s a saying in JS that everything is an object, can you say HTML, CSS everything is JS, we all know that

Ast abstract syntax tree, all languages can be translated

  • You may write a lot of useless code, but it will be executed at compile time
  • I want to use SCSS, what about less
  • After my project goes live, I want to compress CSS, JS and reduce the size of the package
  • , etc.

So there are packaging tools, such as Webpack, rollup, gulp, etc. Packaging tools are great but there are drawbacks. If an application is bulky, it takes a long time to compile and build the first time, and then it takes a long time to update the code. Therefore, the appearance of vite is used. Although the ecology is not perfect, the eyes of expectation are indispensable. Differences between Vite and packaging tools:

Vite is a development server based on the browser’s native ES Imports. Parsing the imports in the browser, compiling and returning them on the server side on demand, bypassing the concept of packaging entirely, and making the server available on demand. Not only does it have Vue file support, it also handles hot updates, and the speed of hot updates does not slow down with the increase of modules. For production environments, the same code can be packaged in Rollup.

Vite does not have a packaging and build process in a development environment

The ESM import syntax written by the developer in the code is sent directly to the server, which runs the ESM module content and sends it to the browser. Modern browsers then make HTTP requests for each imported module by parsing script Modules, and the server continues to process and respond to these HTTP requests.

This is how it should be. In a development environment, the code is syntax-translated and not packaged (assembled into chunks containing multiple modules based on the dependencies between entry and module, and each Chunk converted into a separate file). When the corresponding module changes, it should re-request and respond to the module’s import request.

All Vite Server logic basically relies on middleware implementation. These middleware, after intercepting the request, do the following:

Handles ESM syntax, such as converting import third-party dependencies in business code to browser-aware dependencies (absolute paths are found in NPM packages, relative paths are found in projects)

Instant compilation of.ts,.vue and other files;

Compile Sass/Less modules that need to be precompiled;

Establish socket connection with the browser to achieve HMR.

However, the development has not stopped. With the development of NodeJs, front-end toolchain and engineering have been developed. The front-end is no longer just CSR (client rendering), which is not conducive to SEO if the page is rendered entirely by JS. NodeJs is used to realize a gateway, module code is homogeneous, and data initialization, CSS processing and data water injection operation are carried out before react rendering into HTML fragments. The result of a search engine request to access a page is not an empty DIV, but HTML text with content. In addition, the initialization of the data is already done at the gateway layer, so the page does not need to reload the data when the browser first renders and then initialize it before rendering. Although SSR is good, but also increased the front-end learning cost. There is now an NSR(Edge rendering) strategy that leverishes CDN capabilities. ESR will cache the static part of the page on THE CDN, so that when users visit the page, they can quickly return the static content to users. Meanwhile, IT also initiates a request for the dynamic part of the content on the CDN node. After the dynamic content is obtained, it continues to return the dynamic content to users in the way of stream