<i>"Precompiling JavaScript?<p>Every few years, it’s proposed engines offer a way to precompile scripts so we don’t waste time parsing or compiling code pops up. The idea is if instead, a build-time or server-side tool can just generate bytecode, we’d see a large win on start-up time. My opinion is shipping bytecode can increase your load-time (it’s larger) and you would likely need to sign the code and process it for security. V8’s position is for now we think exploring avoiding reparsing internally will help see a decent enough boost that precompilation may not offer too much more, but are always open to discussing ideas that can lead to faster startup times."</i><p>Surprised there was no mention of webassembly, which does exactly this.
I'm always shocked at how reluctant sites are to actually ship less code, and I think some of this comes down to a needed shift thinking in what an application is, what modules are and how to use imports.<p>One thing I've heard recently is "My app is big, so it has a lot of code, that's not going to change so make the parser faster or let me precompile".<p>The problem with this is thinking that an app is a monolith. An app is really a collection of features, of different sizes, with difference dependencies, activated at different times. Usually features are activated via URLs or user input. Don't load them until needed, and now you don't worry about the size of your app, but the size of the features.<p>This thinking might stem directly from misuse of imports. It seems like many devs think an import means something along the lines of "I'll need to use this code at some point and need a reference to it". But what an import really means is "I need this other module for the importing module to even _initialize_". You shouldn't statically import a module unless you need it _now_. Otherwise, dynamically import a module that defines a feature, when that feature is needed. Each feature/screen should only statically import what it needs to initialize the critical parts of the feature, and everything else should be dynamic.<p>In ES2015 this is quite easy. Reduce the number of these:<p><pre><code> import * as foo from '../foo.js';
</code></pre>
and use these as much as possible:<p><pre><code> const foo = await import('../foo.js');
</code></pre>
Then use a bundler that's dynamic import aware and doesn't bundle them unnecessarily. Boom, less JS on startup.
I am surprised at just how much faster the iPhone is than the next nearest Google device (a laptop). I haven't used an Android device for a long time, but I hear the "Apple is overpriced" so often that I assume someone has been checking this out.
Hmm. Usually browsers cache the raw CSS and JS assets - could that be improved so that browsers cache the compiled CSS/JS? That wouldn't help for the first load, of course - but quite a lot for sites like newspapers which are not SPAs but bundle a metric ton of JS cr.p for each page load.<p>edit: Chrome actually does that, as mentioned in the article - but what about Chrome Mobile and Firefox/Safari/IE?
> Ship less JavaScript.<p>Not at all the message I got from this. Because judging by Safari on mobile and desktop, clearly the issue isn't Javascript, it's that for whatever reason, with all the insane resources behind V8 and Android, they're simply unable to get their interpreters to reach the speed of Safari or Edge.<p>I'd understand if nobody could make JS go fast, but clearly Apple and MS are proving in real-world-ready code that JS can be quickly parsed and executed.
Would have like to have seen Firefox's particular handling of this, but it seems like the author's definition of "browsers" (plural) == Chromium.
I love that this article, which is quite good, appears on a site whose every page crashes and boot-loops multiple times in iOS Safari and has to be repeatedly reloaded by the browser, presumably running less of its code each time, in order to correctly render some text with images in it.<p>Sort of gives added point to the thesis, by providing a marvelous example of something you should never, ever do.
I don't think things are going to get better until browser makers (or Google) start forcing things. It's fine to say "Use less JS" but without an incentive, things aren't really going to change.<p>Looking at how HTTPS adoption has grown with Google giving HTTPS sites an SEO boost and Chrome giving scary warnings, I wonder if the solution isn't to do the same with JS. Throw in some SEO incentives for pages with minimal JS and see what the market does.
My take on the JS performance 1) wait for CPU’s of mobile to catch up with current JS flow [not acceptable, but easiest path ] 2) Web Assembly to create native experience or 3) something like Elm as a JS replacement (front end compilation). We know interpreted langs are slow - however JS is slow now where people see it most [Front end]… they don’t see the slow of “back end”. For example, if a user had to wait for “npm install” when they used the server the first time. The JS community has a great habit of adding “all the things” for significant bloat. [module for leftpad, and lots of go-arounds due to the language being bolted on for it’s current use rather than designed from the ground up]. It’s 6am in Cali…so take it with a grain of salt.
> Ship less JavaScript.<p>Except for the fact that it is nearly impossible without a dedicated team for optimizing your code. Because javascript is so hard to optimize and eliminate dead code. With es6 modules that could potentially get better...but good luck with getting the rest of your libraries (and the 5 bajillian level 2+ dependencies that they require) on board with that.<p>A decent first step would be for nodejs to deprecate commonjs and only use es6 modules, and force libraries to update or be deprecated. So lets have this discussion 10 years from now.
I think more people should look into Clojurescript with it's advanced optimizations which I believe could help achieve the goal of "shipping less javascript".
I'm confused.<p>One of the idea behind CDN for javascript/css is to leverage caching by reusing the same resources across websites.
But then optimization tools said we should bundle everything into one javascript, which delay the loading time, but defeat the initial purpose.<p>I wonder if the caching could be more intelligent, by recognizing libraires bundled into the "big" javascript that website delivers, and parse only the new content.
Slightly related: pre-parsing code and loading already initialized application state is available for the Dart VM for a long time now, and the technology yields faster startup times:<p><a href="https://www.dartlang.org/articles/dart-vm/snapshots" rel="nofollow">https://www.dartlang.org/articles/dart-vm/snapshots</a>
Worth noting: Safari 10 is 3X faster at parsing than Chrome 55, according to their chart. (See the MacBook Pro lines.)<p>This is not mentioned or discussed despite all the thoughts on how to speed things up. Anyone know what Safari is doing?
I'm not sure the Angular 2 AOT bit belongs here. Angular 2's AOT just parses your HTML into the backing angular component classes. It's still all Javascript that has to be loaded and parsed.
Wow, I definitely feel this. I just switched from an iPhone to an Android device and it does seem like a second class phone experience.<p>The gap between all recent Apple phones and even the best of the best Google and their partners offer with respect to mobile web perf is staggering.
Why not have the js engine, i.e v8, parse and compile one time, and then refer back to this object code each time to eliminate the startup delay... Either an http header cache-control flag or something similar.
Right,Generally programs store the crude CSS and JS resources - could that be enhanced with the goal that programs reserve the accumulated CSS/JS? That wouldn't help for the principal stack.