After precipitation in recent years , The reform of the front-end members has finally entered a stable period at this stage . Look back on the road that our predecessors have gone through , Mainly in solving the following problems ：
The language features supported by browsers are not very friendly , Impact on development efficiency
The project lacks dependency management , Copy and paste is too inefficient and difficult to control
Tools are needed to compress the code , Compress picture , Generating files hash Used to control browser cache and other functions
Saving code during development can refresh the browser in real time and improve the development experience
In order to solve these problems , The following solutions have emerged ：
babel, take ES6,typescript Convert to browser supported ES5 code
DSL(domain specific language), for example ：less,sass And so on css Extension of ,jsx,vue template,angular
template about html Extension of
npm Dependency management tools
Using tools to deal with compressed code , Compress picture , Generating files hash Etc
utilize live reload,browsersync,hot reload Tool to refresh browser in real time
These solutions become an integral part of our development , So we need a tool to put these together , So there are images before and after grunt,gulp,fis,webpack And other front-end engineering construction tools . After a period of time of update iteration ,webpack The idea that everything is modular and powerful , Gradually stand out from the numerous tools , Become a common build tool in front-end projects .
At this stage , I feel that the construction of front-end projects is becoming more and more important , It's getting more complicated . For a new project , You always need to install a bunch of dependencies ( several hundred M Of node_modules), Then write a bunch of configuration items for the build tool , Finally, business development can be carried out . As the project gets bigger and bigger , It takes a lot of time to start each time . Because the build tool needs to do dependency analysis on the project , compile , Finally, you can output the file that the browser can execute . At this time, the optimization of construction tool configuration is put on everyone's work schedule .
At present, the optimized scheme is constructed , with webpack take as an example , There are mainly the following directions ：
Reducing dependency analysis ：webpack Of resolve to configure ,loder Of exclude to configure
to subcontract , Dynamic loading ：import(),require.ensure()
Extract common parts , Reduce dependencies that need to be compiled ：DllPlugin,externals
Using multithreading , Parallel compilation of multiple processes ：thread-loader,happyPack
But the business code reaches a certain level (5W Above the line ), After the above optimization , The speed has really increased a lot , But my personal feeling is that dev( development environment ) Still a little heavy .
At a certain time @vue/dev-server After this tool , Suddenly there was a flash of light , Thought of a feasible plan . This tool can quickly start a single command .vue
Single file development environment , Let's see what it does first .
A document created according to a document , No, webpack.config Configuration like this , There is no preprocessing output file .
index.html file , Take advantage of the latest chrome Browser supported es module load main.js.
Copy code main.js file , introduce test.vue file , It's the same as the entry file of a normal project .test.vue The code in the file is normal vue Single file format , No show . import
Vue from 'vue' import App from './test.vue'
render: h => h(App)
Copy the code and then look at the resources loaded by the browser , Path following import bring into correspondence with , All types are script(Content-Type:
main.js in ,import Vue from 'vue’ Processed into import Vue from ‘/__modules/vue’. Because of the browser's es
module What is still being proposed has not been realized import-maps characteristic , Therefore, dependency without path is not supported .vue It's what browsers can do vue.js.
test.vue It is the code after the source file is compiled , Because of the original .vue Single file browsers are not supported , Precompiling is required .
thus it can be seen , The tool focuses on using middleware , The following is done ：
Transform dependencies without paths ( Just for a while vue, other npm Package not processed ) Reference address of , Let browser support
precompile .vue file , Convert to browser supported js, be similar to webpack Medium vue-loader
Think about it , At present, the construction tools deal with all the resource files that the project depends on , But a lot of the time , We just develop a module in a page . From an ideal point of view , In fact, we only need to process the resource file that the page depends on . Whenever a resource that the browser cannot execute is loaded ：vue,sass,less etc. , And then translate it / Compilation processing , Finally, output the resource file to the browser .
In fact, there are people in the community who are trying to do the same , such as ：systemjs,github The description is ：Dynamic ES module
loader. Of course, this is not just for browser compatibility es module, The focus is on the implementation of Transform loader function . This feature provides a similar webpack
loader Function of , Corresponding to the matching dependency loader handle . specific loader Processing can be placed in web worker Or through node
server Processing , If it can be compatible with most of them webpack loader It's a good plan .
At present, the idea needs to be verified and implemented , Interested can go to learn about the relevant content , If there is further study , I hope we can exchange views with each other .