Linkbait 37
We are an equal opportunity linkbait. Last week we bashed Facebook; this week we bash Google.
- Tim Kadlec on AMP — again.
The web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.
This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.”
The fact that Google tries to use our ideology is one thing. The fact that we continue to fall for it is quite another.
Why a subset of HTML you ask? Well, mostly because web developers suck at their jobs and have loaded the web with a ton of JavaScript no one wants. Can't fault Google for wanting to change that. That part I can support. The less JavaScript the better.
And here we’re back smack bang in the middle of the problem. Today’s average web developer doesn’t have the faintest clue what he’s doing and can’t do it anyway without sixteen libraries and frameworks. Solve that problem and AMP goes away.
(Masculine pronoun used deliberately, and if there were a white pronoun I’d also have used it. I more and more think that frameworks and libraries are the things mediocre white men need to survive in today’s front-end world.)
- It’s useful to post a repeat link to an older The Register article that calls for killing AMP before it kills us.
Except that, hilariously, to create an AMP page you have to load a, wait for it, yes a JavaScript file from Google. Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version.
and
If we reject AMP, AMP dies.
In order to reject AMP we need to tone down significantly on the frameworks. Could happen, but right now it’s not happening.
- Ferdy Christiant agrees with the performance findings. He studied AMP’s performance profile (supposedly its biggest advantage) and found that his test AMP page is not noticeably faster than a regular web page. Also, he found that AMP is effectively preloading assets for a better perceived performance. If your goal is to improve perceived performance, this is a clever idea. Ferdy adds, however, that this gives Google, owner of the world’s most important search, an unfair advantage, especially since it does not run this preloading trick on non-AMP pages, while I suppose it could if it wanted to.
- Luke Stevens feels Google is forking the web. This is reinforced by the news that AMP will now get a JavaScript component as well; something that was purposely omitted so far. But it will of course be a special type of JavaScript that (only?) offers simple DOM methods that are ’sanitized” by the AMP app itself.
In other words, a subset of JavaScript that will (surprise!) turn out to be not enough for AMP developers, who will either demand more and thus import the web’s performance problems to AMP, or leave AMP altogether, which leads to a win for the web.
In any case, it makes it less and less clear what AMP is supposed to be a solution to. And people have tried and failed to fork the web so often that I am not terribly worried right now.
- Mike Monteiro calls for some sort of licensing for designers. This is an interesting idea, but from experience with attempting the same on the front-end side I’ll warn him it’s an uphill battle. On the other hand, my attempt was more than ten years ago, and meanwhile the world has changed.
While discussing this article I had an idea: how would designers and back-end developers feel about front-end certification? Would they think it’s a good idea?
Designers who agree with Mike should ask themselves something similar: would developers care? Possibly, I’d say.
- Patterns for writing manageable CSS without a framework. Simple, solid, sensible advice for managing your CSS. From a purely visual standpoint you can achieve the same by using a CSS framework, but
My preference for manually writing layout styles is to reduce dependencies, write less-complicated markup (not littered with wrappers and generic class names), and retain the greatest control possible. By writing my own layout system, I can make exceptions for certain cases without relying on “overrides”. When there are edge cases, exceptions can be easily made without hideous hacks upon CSS written by someone else.
Makes sense.
- Turns out Mozilla created a JSON feed for browser compatibility data. Interesting idea; I toyed with it ages ago but was too
lazy busy to actually implement it.
As far as I know, except for individual MDN pages, there is no interface yet where you can easily access the information (yeah, I know I could write one myself, but time constraints, and my profound lack of experience with GitHub).
Still, excellent idea, as long as the data is valid. I occasionally have beef with MDN data, and I also think they do not cover enough browsers. UC and Opera Mini, for instance, are missing. World wide web, remember?
(Via Jens Grochtdreis)
- A very neat trick: CSS-only sortable tables. Say again? CSS only? Yup.
How? By clever use of CSS variables. Read and make your head explode with possibilities.
- For the mobile history buffs among us: a long look back at the fall of Nokia during the tenure of Stephen Elop, drawn mainly from Finnish inside sources.
- Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).
