New JavaScript techniques for rapid page loads

   #header-inner img {max-width: 100%;}

Kind of funny from chrome blog running in Chrome or is it a little sad.

Edit ---- I guess mobile version in desktop causing problem kind of make sense I guess.

1) Changing the file name, so it's a completely new file to the browser and thus downloaded (usually by incrementing the version number, like myApp.1.0.1.js).

2) Setting different cache rules on the server for different file types. If the updates aren't critical, you can let the cache run it's course. So your cache rules could be 1 month for images, 1 day for HTML, and 1 hour for JS files.

Edit: looking at the plv8 code, it doesn't seem to create a new Isolate for every request. So I think for the same instance of PostgreSQL the in-memory cache should also hit.

Can you give a reference for that?

HTML5 Boilerplate, Yeoman's generator-webapp and Google's Web Starter Kit do not come with these script attributes OOTB.

EDIT: ha I just noticed your username. Maybe you can tell me why those projects don't come with async script tags?

This is why my script tags end up in the head now, because I want to place them before the CSS tags, and I want to fetch the CSS before the body starts being displayed.

I tend to use defer rather than async because I want the scripts to execute in the order I add them to the page, and only once the body has been fully constructed.

That said, if you have to support old browsers, make sure you research which ones support async/defer, and which ones have buggy implementations. caniuse.com is your friend.

[*] If I'm wrong with any of the above, please correct me. Just checked your profile and you seem well qualified to contradict me.

In other words, its not, that was kind of my point, however it is cool.

I suspect, the devs had to modularize / logically separate parsing from compiling / executing somewhat before they could complete the next phase (fro chrome 42) which is the script caching part: cached scripts won't need re-parsing before compilation/execution.

Oddly, the native applications rarely seem to have much impact unless it's doing a hard task, like video encoding.

To answer your question, I think that NoScript users tend to appreciate (and even expect) minimalism... consequently some get irritated when even a simple blog can't load without JS. I get the appeal of the minimalist, standards-adhering, machine-parseable website, but it's not a big source of emotion for me :P

I also suspect that a lot of people, like myself, still consider the WWW a linked document system rather than a fat client application terminal, we just want documents with links to other documents, and sometimes simple forms.

I've been a no-script user for 3 days. I'd say the experience is better until I hit a useful site that requires javascript - when this happens it takes one or two attempts to enable javascript properly.

I would not recommend it for people for people who do not like messing around with their browsers. However, I intend to stay with no-script because page loads are faster and incredibly little functionality is missing.

Using NoScript does not mean "functionality missing". It's just disabled by default - and personally, most of the time I find the "missing functionality" unnecessary, and in most of places where it's not I already have a whitelist entry in place.

HN works perfectly. Lots of pages even work better with NoScript, as it basically cuts a lot of bloat. If some don't, enabling JS is one click away.

Anyway, there are lots of pages which are kind of expected to not work correctly without JavaScript - and that's fine. But if for instance Hacker News wouldn't work in its current form without JS, that would be a valid thing to complain about, because there's absolutely no reason for that. There are even some pages that implement loading animation in JS in a way that when JS is disabled, the whole page is obstructed by loader that never disappears - and that's just reckless coding that should be fixed.

It just makes sense to me but I haven't seen anyone working on it just occasionally talking about it. So maybe it doesn't make sense to the people working on web browsers, I dunno.

I'm not suggesting it's likely that this will be an issue, but it's a legitimate question to ask, as there's a long history of people managing to leverage a combination of flaws allowing them to write in a limited set of locations with different flaws allowing them trick some tool into executing what they manage to get written to disk.