Modern web development:
Imagine you went to a restaurant, took a seat, and 20 minutes later you still haven’t been given a menu. You ask where it is, and you’re told “oh, we’re currently cooking you everything you might possibly ask for. Then we’ll give you the menu, you’ll pick something, and we’ll be able to give you it instantly, because it’ll all be ready”.
Single page apps, ladies and gentlemen.
Charlie conducts an experiment by living without JavaScript for a day.
So how was it? Well, with just a few minutes of sans-javascript life under my belt, my first impression was “Holy shit, things are fast without javascript”. There’s no ads. There’s no video loading at random times. There’s no sudden interrupts by “DO YOU WANT TO FUCKING SUBSCRIBE?” modals.
As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!
This has made me appreciate the number of large sites that make the effort to build robust sites that work for everybody. But even on those sites that are progressively enhanced, it’s a sad indictment of things that they can be so slow on the multi-core hyperpowerful Mac that I use every day, but immediately become fast when JavaScript is disabled.
Chrome is going to refuse to parse document.write for users on a slow connection. On the one hand, I feel that Google intervening in this way is a bit icky, but I on the other hand, I totally support this move.
This keeps happening. Google announce a change (usually related to search) where I think “Ooh, that could be interpreted as an abuse of a monopoly position …but it’s for ver good reason so I’ll keep quiet.”
Anyway, this should serve as a good kick in the pants for bad actors (that’s you, advertisers) to update their scripts to be asynchronous.
Google’s search results now include AMP pages in the regular list of results (not just in a carousel). They’re marked with a little grey lightning bolt next to the word AMP.
The experience of opening of those results is certainly fast, but feels a little weird—like you haven’t really gone to the website yet, but instead that you’re still tethered to the search results page.
Clicking on a link within an AMP spawns a new window, which reinforces the idea of the web as something separate to AMP (much as they still like to claim that AMP is “a subset of HTML”—at this point, it really, really isn’t).
Tom’s thoughts on what AMP means for developers and publishers. He was initially sceptical but now he’s cautiously optimistic. Like me, he’s hoping that AMP can force the hand of those third-party advertisers to get their act together.
Publisher’s development teams are very capable of creating fast experiences for mobile users, but they don’t have the clout to coordinate all the additional cruft that is added to the page. However, if all the different publishers dev team’s got together and put their weight behind a single implementation, then we can force third parties to change their habits.
JavaScript and the observer effect.
Ain’t no third party like a Google Analytics third party.
The Google developer relations team are dishing out some inconvenient truths.
First impressions of Google’s RSS killer …no wait, they already killed RSS.
The terminology of applying CSS.