But real problems are messy. Tech culture prefers to solve harder, more abstract problems that haven’t been sullied by contact with reality. So they worry about how to give Mars an earth-like climate, rather than how to give Earth an earth-like climate. They debate how to make a morally benevolent God-like AI, rather than figuring out how to put ethical guard rails around the more pedestrian AI they are introducing into every area of people’s lives.
So what happens when these tools for maximizing clicks and engagement creep into the political sphere?
This is a delicate question! If you concede that they work just as well for politics as for commerce, you’re inviting government oversight. If you claim they don’t work well at all, you’re telling advertisers they’re wasting their money.
Facebook and Google have tied themselves into pretzels over this.
A step-by-step guide to building progressive web apps. It covers promises, service workers, fetch, and cache, but seeing as it’s from Google, it also pushes the app-shell model.
This is a handy resource but I strongly disagree with some of the advice in the section on architectures (the same bit that gets all swoonsome for app shells):
Start by forgetting everything you know about conventional web design, and instead imagine designing a native app.
Avoid overly “web-like” design.
What a horribly limiting vision for the web! After all that talk about being progressive and responsive, we’re told to pretend we’re imitating native apps on one device type.
What’s really disgusting is the way that the Chrome team are withholding the “add to home screen” prompt from anyone who dares to make progressive web apps that are actually, y’know …webby.
A great presentation from Laura on how tracking scripts are killing the web. We can point our fingers at advertising companies to blame for this, but it’s still developers like us who put those scripts onto websites.
We need to ask ourselves these questions about what we build. Because we are the gatekeepers of what we create. We don’t have to add tracking to everything, it’s already gotten out of our control.
A wide-ranging post from Andrew on the downsides of Google’s AMP solution.
I don’t agree with all the issues he has with the format itself (in my opinion, the fact that AMP pages can’t have script elements is a feature, not a bug), but I wholeheartedly concur with his concerns about the AMP cache:
It recklessly devalues the URL
Spot on! And as Andrew points out, in this age of fake news, devaluing the URL is a recipe for disaster.
It’s hard to avoid the idea that the primary objective of AMP is really about hosting publisher content inside the Google ecosystem (as is more obviously the objective of Facebook Instant Articles and Apple News).
Funnily enough, I led a brown bag lunch discussion about AMP at work just the other day. A lot of it mirrored Chris’s thoughts here. It’s a complicated situation that has lots of people worried.
Google have released this encoder for JPEGs which promises 20-30% smaller file sizes without any perceptible loss of quality.
I can forgive our answer machines if they sometimes get it wrong. It’s less easy to forgive the confidence with which the bad answer is presented, giving the impression that the answer is definitive. That’s a design problem.
Tim watched the panel discussion at AMP Conf. He has opinions.
Optimistically, AMP may be a stepping stone to a better performant web. But I still can’t shake the feeling that, in its current form, it’s more of a detour.
Here’s the panel I was on at the AMP conference. It was an honour and a pleasure to share the stage with Nicole, Sarah, Gina, and Mike.
The largest complaint by far is that the URLs for AMP links differ from the canonical URLs for the same content, making sharing difficult. The current URLs are a mess.
This is something that the Google gang are aware of, and they say they’re working on a fix. But this post points out some other misgivings with AMP, like its governance policy:
This keeps the AMP HTML specification squarely in the hands of Google, who will be able to take it in any direction that they see fit without input from the community at large. This guise of openness is perhaps even worse than the Apple News Format, which at the very least does not pretend to be an open standard.
This is an interesting use of voodoo magic (or “machine learning” as we call it now) by Google to interpolate data in a small image to create a larger version. A win for performance.
So if AMP is useful it’s because it raises the stakes. If we (news developers) don’t figure out faster ways to load our pages for readers, then we’re going to lose a lot of magic.
A number of developers answered questions on the potential effects of Google’s AMP project. This answer resonates a lot with my own feelings:
AMP is basically web performance best practices dressed up as a file format. That’s a very clever solution to what is, at heart, a cultural problem: when management (in one form or another) comes to the CMS team at a news organization and asks to add more junk to the site, saying “we can’t do that because AMP” is a much more powerful argument than trying to explain why a pop-over “Like us on Facebook!” modal is driving our readers to drink.
But the danger is that AMP turns into a long-term “solution” instead of a stop-gap:
So in a sense, the best possible outcome is that AMP is disruptive enough to shake the boardroom into understanding the importance of performance in platform decisions (and making the hard business decisions this demands), but that developers are allowed to implement those decisions in standard HTML instead of adding yet another delivery format to their export pipeline.
The ideal situation looks a lot more like Tim’s proposal:
I would be much more pleased with AMP if it was a spec for Google’s best-practice recommendations rather than effectively a new non-standard format. By using standard HTML/CSS/JS as the building blocks, they’re starting on the right foot, but the reliance on a Google-decreed AMP JavaScript library, use of separate AMP-specific URLs, and encouragement to use a Google-provided CDN are all worrying aspects.
Google may or may not decide to run your JavaScript, and you don’t want your business to depend on its particular inclination of the day. Do server-side/universal/isomorphic rendering just to be safe.
Google’s Noto (short for no-tofu; tofu being the rectangle of unicode sadness) is certainly ambitious. It has glyphs from pretty much every known alphabet …including Ogham and Linear B!
Henrik points to some crucial information that slipped under the radar at the Chrome Dev Summit—the Android OS is going to treat progressive web apps much more like regular native apps. This is kind of a big deal.
It’s a good time to go all in on the web. I can’t wait to see what the next few years bring. Personally, I feel like the web is well poised to replace the majority of apps we now get from app stores.
Sounds like AMP is a bit of a roach motel. You can check out anytime you like, but you can only leave with great difficulty.
John is rightly puzzled by AMP:
Can someone explain to me why a website would publish AMP versions of their articles?
Sadly, there is an answer to that question: if a website is so bloated and horrible to use that people won’t stick around to read an article, then AMP starts to look like a good option.
But I don’t have an answer for John’s other question:
Why would any website turn their entire mobile audience — a majority share of their total audience, for many sites today — over to Google?
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.
Chris runs through the process and pitfalls of POSSEing a site (like CSS Tricks) to Apple’s News app, Facebook’s Instant Articles, and Google’s AMP.
Hey, whatever you want. As long as…
- It’s not very much work
- The content’s canonical home is my website.
I just want people to read and like CSS-Tricks.