Some quick thoughts on It's not ignorant at all to ask how browser vendors approach performance. On the V8 side we've discussed bytecode precompilation challenges a few times this year. Here's my recollection of where we stand on the idea:

JavaScript engines like V8 have to work on multiple architectures. Every version of V8 is different. The architectures we target are different. A precompiled bytecode solution would require a system (e.g the server or a CDN) to generate bytecode builds for every target architecture, every version of V8 supported and every version of the JavaScript libraries or bundles bytecode is being generated for. This is because we would need to make sure every user accessing a page using that bytecode can still get the final JS successfully executed.

Consider that if a cross-browser solution to this problem was desired, the above would need to be applied to JavaScriptCore, SpiderMonkey and Chakra as well. It would need to ca

View sites.txt

"We need Webpack presets" and "Webpack and its plugins are too hard to configure correctly" have been the number one cause of developer pain shared with me from large sites adopting Progressive Web Apps and optimising their load performance.

If I was building a Webpack preset pack for performance, I might use the following:

  • Ensure you're using a production build of your framework: new webpack.DefinePlugin({ 'process.env': env })
  • Minify your JS: webpack.optimize.UglifyJsPlugin
  • Compress your resources (GZip): compression-webpack-plugin
  • Split your vendor chunks: CommonsChunkPlugin
  1. Type chrome://flags into your browser
  2. Scroll down to “Enable Developer Tools experiments” and click enable
  3. Restart Chrome
  4. Open up DevTools
  5. Click on the gear icon — it’s typically on the top right or bottom right
  6. Select experiments from the menu on the left
  7. Hit shift 6 times to show hidden experiments
  8. Enable 'V8 Runtime Call Stats on Timeline'

We are hoping to turn this feature on by default soon so the above steps are not needed.

View top10k.txt

Problem: How can we preprocess JavaScript (at build-time or on the server-side) so engines like V8 don't have to spend as much time in Parse? This is a topic that involves generating either bytecode or a bytecode-like-abstraction that an engine would need to accept. For folks that don't know, modern web apps typically spend a lot longer in Parsing & Compiling JS than you may think.

  • Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
  • One angle to this problem is we all ship too much JavaScript. That's one perspective. We could also look at preprocessing.
  • We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
    1. Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu

Frameworks and tooling

ES2015 Modules.

How do you deploy them? What does this look like for Blink + Babel, frameworks? We've got nomodule coming. This looks like:

<script type="module" src="app.js"></script>
<script nomodule defer src="bundle.js"></script>