Earlier quoted context omitted.
AMP is just broken HTML, hardly a standard. https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...
I don't understand why they don't just use data-* attributes and stay valid.
Absolute control.
A new approach to web performance
61–70 of 177 posts
Re: A new approach to web performance
#62Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…
About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for…
That's exactly how a site I work on operates. True, changing a link across all pages is a very slow operation (about 50 seconds for 11,000 pages) but a) that's happening in a highly structured and powerful but resource-intensive way (i.e. DOM parsing) b) it happens so rarely that I haven't bothered to optimise it. The main trade-off for an update that happens maybe once every 1-2 months taking 50 seconds is that every single page load is faster. There are other benefits from static files, too - it's much easier to work with content in flat files, 1-per-page, than the kind of complicated database / file / code relationship used by many 'normal' CMSes.
Re: A new approach to web performance
#63Earlier quoted context omitted.
AMP is just broken HTML, hardly a standard. https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...
What about RSS? That offered good performance, was widely adopted and was a real standard working for both publishers and consumers. Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.
I was as annoyed as the next person when Google killed Reader but, to be honest, RSS was killed off for typical users way before that when browser manufacturers dropped/hid support for it. I still use RSS every day, as do many of our customers.
Re: A new approach to web performance
#64That the page is itself an AMP HTML document would be really impressive if it wasn't really simple to make a completely valid html page that looks the same as that one that loads extremely fast on every platform.
I guess this makes my lowly blog now advanced technology, because it doesn't use JavaScript.
Re: A new approach to web performance
#65Earlier quoted context omitted.
What about RSS? That offered good performance, was widely adopted and was a real standard working for both publishers and consumers. Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.
I was as annoyed as the next person when Google killed Reader but, to be honest, RSS was killed off for typical users way before that when browser manufacturers dropped/hid support for it. I still use RSS every day, as do many of our customers.
Indeed, also Google Chrome.
Re: A new approach to web performance
#66This isn't an HTML subset, it's some freakish pseudo-HTML JS library weirdness.
Why not define an actual subset of HTML? You know, like XHTML Strict Mode?
Why must everything be a JavaScript library?!
Re: A new approach to web performance
#67This is obviously Google's response to Facebook's Instant Articles and Apple's News. Behind all the technology is the main business goal of delivering a content platform that has the sponsoring company's ad network baked in to it.
Exactly.
Re: A new approach to web performance
#68Earlier quoted context omitted.
Well, I would say the common argument is that you send an intermediate format to decouple yourself from the specifics of the receiver. HTML is an intermediate format and the client is free to render it how it sees fit for the device on which it is running, which allows compatibility with newer and different clients. It's like shipping some intermediate bytecode doesn't seem to make sense, because every client needs t…
Isn't it obvious? You just need an optimized templating engine that is implemented in the browser instead of js.
Isn't HTML already templating engine for displaying text?
Re: A new approach to web performance
#69Earlier quoted context omitted.
It's easy to forget that html isn't the end product, the end result is lit pixels on some screen (usually). If we send json then that needs to be converted to html and that html needs to be layout and rendered. If we send html we just skip the first step. Displaying a web page isn't "free" for the client just because it's html. The question is this: what kind of overhead is a template rendering task (in js) for a mod…
Crazy thought: detect viewport size on first load and serve pre-rendered PNGs to skip the rendering on client part. Someone probably already developed that.
That is essentially what Opera Mini does/did: requests went through Opera's render farm which would request page and render them (with adaptations) to a packed binary format and send that back to the device. There was also rudimentary JS support in the rendering farm, the device essentially got an image with an interaction map, and interactions would be sent to the server for processing.
Not very configurable though, can't really e.g. customise font size, observe the page or pass it through a screen reader.
Re: A new approach to web performance
#70What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles. This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as and that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can ea…
What are they selling, exactly? Why does this need to be a framework, with js and all that?
I'm not asking cynically, and following it up with "oh, they should just do x instead".... I legitimately do not understand what's going on here. What's the added functionality? I read the article twice, I don't get it. I'm going through the spec, I don't get it. I looked at the article source, I really don't get it, it's just html and common sense.