How Dropbox Hacks Your Mac

AMP is not the solution. Anyone willing to use AMP to reduce bloat could also just not add bloat to HTML pages in the first place. And, using AMP itself adds bloat[1]. I couldn’t even read the author’s AMP version without enabling JavaScript.

[1] https://www.ampproject.org/docs/get_started/create/basic_mar...

I can read all mentioned pages with NoScript enabled. But fully agreed that static pages such as blogs shouldn't require JS to show the primary content.

That depends. What about blog posts that have inline JS demos?

That would be a reasonable exception. Of course, I'd only give the page a 5/5 rating if the JS code would be still readable even if no output would be produced.

Clearly that's an exception, I don't think that really needs to be discussed or considered when talking about static blogs not needing JavaScript.

One example: in my static blog I provide very nice maths using MathJax, but I also provide fallback PNG renders of the formulae. The small JS my blog has, it reads these pictures' alt texts and renders the latex if found. This stuff is not rocket science, people just don't want to spend time on this kind of stuff.

AMP is bastardized HTML used as an excuse to making a website fast in the first place. I totally agree.

Additionally, AMP wants to become the arbiter of the mobile web. Just look at their list of "Supported ad networks." [1]

Who gave them the authority?

AMP worries me greatly.

[1] https://github.com/ampproject/amphtml/blob/master/builtins/a...

This is what really confuses me about AMP. All it does, really, is force authors to strip their page down to core, performant components.

Another way to do that is to strip your page down to core, performant components without loading a JS library from Google. But Google dangles the carrot of improved SEO with AMP, so everyone has to do it anyway.

(note: they don't actually prioritise AMP pages, they prioritise page load speed. But AMP pages are put inside a Google CDN, so, what do you know, they load fastest)

They've been pretty good about accepting PRs to support any ad network from what I've heard: https://github.com/ampproject/amphtml/pulls?utf8=%E2%9C%93&q...

Yes, just as ABP has been good about accepting PRs to add "unobtrusive ads" - until they started demanding money.

NEVER give this power to a central authority that's not democratically controlled.

And yet, some people still do that mistake.

You might want to switch to katex instead - and katex can also be run on the server to return HTML directly.

I agree that their current process should become more democratic, and that this is a real concern. There is also benefit in moving quickly to try and solve a real problem and prove that this approach will work. I'm still cautiously optimistic.

> Anyone willing to use AMP to reduce bloat could also just not add bloat to HTML pages in the first place.

AMP is not meant for page authors — usually, they are painfully aware of how much bloat they add. They don't have a choice when sustainability is in the balance.

AMP is for the ad networks. It draws sane restrictions to what they can do. On their end, ad networks agree to that because Google is a large partner of them and because the worst possible outcome would be having everybody use ad blockers.

> They don't have a choice when sustainability is in the balance.

This is not solved by AMP, it's absolutely the choice of publishers.

> AMP is for the ad networks.

Not really, you can see their official roadmap. Many of the original principles have already changed and many of the intrusive ad formats are already back in (like autoplay outstream video units). The only real optimization is better async loading which could already be done with proper coding by publishers and ad networks.

All open source projects have some kind of "central control" in the sense that they can accept or reject pull requests and define what the official version is.

But you can fork them, so it should be okay, right?

> just not add bloat to HTML pages

This isn't really a solution when many authors use a CMS, like WordPress and others, where the bloat is built-in. Sure you can write a custom theme etc, but not everyone (1) has the ability to do that, and (2) wants to dedicate the time to do that.

Exactly, but I can’t fork AMP – as Google decides which fork gets preferred treatment by them

Echoing others, as blog posts go, that's the exception and not the rule. Inline demos are furthermore not "primary content" but supplementary material.

KaTeX looks very good, but currently I let org-mode do the backend lifting for me. Maybe if I rewrite my blog engine once again... ;-)

At least use it on the client then – it’s a lot faster than MathJax :)

Creating AMP pages requires just as much ability and time.