Linkbait 39

More like a link-late, but here it finally is.

Tim Kadlec takes a look at how fast AMP really is, spurred on by Ferdy Christiant’s research that we featured earlier. Tim concludes that the main performance benefit comes from AMP pages being served from Google’s CDN. Other than that AMP pages are mildly more performant than non-AMP pages, mostly because it arranges some optimizations and resource loading for you. The cost, however, is a slightly slower Start Render time, because the scripts that arrange all those optimizations and loading have to run before the AMP page is ready to be shown.

Right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.

Steve Yegge shares his thoughts on the current state of Android. While Google still retains control over Android itself, it may be losing its grip on important auxiliaries:

We’ve seen that there are at least three coordinated types of attack happening in different dimensions: The developer ecosystem (React Native and friends), the store (Amazon’s app store and Cyanogen’s rumored successor), and the lightweight in-app marketplaces (Facebook and WeChat, so far). Google’s reactions to each of these threats so far have been… well, let’s just say they’re still on top. For now.

Does that matter? Yes, for tech shops it does.

If you think there’s any risk at all that Google might lose control of Android, then your best bet is to use a cross-platform framework, because it hedges your bet via improved portability.

React Native, in other words. If it can survive the current storm aimed against Facebook — but it probably can, because it can always be spun off.
Why I quit Google is an interesting article about self-defeating “objective” promotion criteria at Google.
Steve Faulkner clarifies how the HTML/CSS DOM, which can be changed by, among others, the flexbox order property, isn’t reflected in the browser’s accessibility tree. This is a reaction to last time’s discussion about CSS variable use for table sorting.
Chris Coyier shows how to make notched boxes in kind-of Battlestar Galactica style. Nice.
Excellent article on dealing with huge collections of DOM nodes — think tables with 1,000 rows. Vanilla JavaScript remains by far the best option performance-wise. Also, don’t bother optimising your core JavaScript loops and stuff — instead, optimise DOM handling. Clear DOM subtrees through innerHTML. On the other hand, don’t destroy nodes you may need later on — re-building them is way more expensive than keeping them around in memory.And no, this is nothing new. Ten years ago I would have given the same advice. But it’s good to know that the old rules are still being supported by the current data.
Food for thought:

I’m beginning to think JS may be bifurcating into two largely disjoint communities. The “sw engineers” comfortable with pre-deployment tool chains and the “explorers” who want “live programming" tools

I’m not 100% sure what Allen means by live programmers, and when I wanted to ask them I hit on my own definition and tweeted that instead.I think that the big split in JavaScript land is between those who firmly keep their eyes on browsers as our development platforms, and those who want to abstract away browsers.And yes, I think the first group is right and the second one is wrong, and that the second one will run into problems due to not understanding the platforms it’s creating software for.
This article calls the front-end/back-end division an antipattern. While I disagree with that premise, most of the article treats how back-enders look down on front-enders, and why that attitude should end — which is something I agree with.

Frontend engineers now solve the same kinds of problems as their backend counterparts, using the same kinds of solutions, and it is harmful to continue arbitrarily dividing us.
To be clear, I’m not saying that we all need to be experts in everything. […] While it is perfectly valid to dislike a particular technology, such as CSS, the industry’s culture of contempt for frontend work feeds into the outdated divide between frontend and backend, and detracts from building fast-moving, competitive teams and companies.

Such as CSS. Thar’s a problem I’ll have to get back to one of these days.Pointing out that front-end can be as complex as back-end, and doing so in a back-ender-friendly way, is a good idea. Still, the article manages to ignore browsers as a developer platform entirely, despite the fact that mentioning them would have made its point even stronger. But maybe back-enders don’t want to hear about browsers because they’re terrified of them.
According to Tobie Langel contributing to OSS has ROI roughly equal to using OSS. Twenty years ago large companies were leery of using it; now they’re leery of contributing to open source. So we have to convince them.
Insights and data, baby! The StackOverflow developer survey and the Design Census have been released. These surveys always yield interesting data.
Seems like an awful place to work for the health-unconscious such as myself.
Chronicles of Crime is a board game that incorporates an app, VR, and QR codes. Apps and VR have been done before in board games — the wonderful Alchemists was the poster child for apps in games — but as far as I know nobody yet combined them (i.e. let the app do more than just show VR), and nobody yet added QR codes, which are supposed to be a dying technology.
Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).