4 ms·
This is really interesting. I think there's a lot of room for improvement in the tooling, though, and my gut instinct is that theoretically, Browserified/Webpa
by smrq 10y ago
This is really interesting. I think there's a lot of room for improvement in the tooling, though, and my gut instinct is that theoretically, Browserified/Webpacked code can be as fast if not faster than other compiled methods. The reason for this is that the bundler has more structural information about the code it's working with. More information theoretically equals more opportunities for optimization.
Not saying those optimizations will be easy. I'm marginally familiar with both the Browserify and Webpack codebases, and I certainly wouldn't want to be the one to implement any of this. But, assuming all the benchmarks in this post prove to be reproducible (and I'm expecting them to be), I hope that those more familiar with the tooling will be able to build a world where we get to have both the user experience and developer experience we want.
- jahewson 10y ago> the bundler has more structural information about the code it's working with For CommonJS modules this is only true to a very limited extent as the export binding process can run arbitrary code which can't be analysed (it's Turing complete). ES6 modules on the other hand are static and can be extensively analysed without difficulty. This makes, for example tree-shaking pretty easy. Rollup is an ES6 module builder which is doing this already. The future's bright.