4 ms·
HTML isn't a renderer-output-description-language like PDF or PostScript. It was always intended to deliver content alongside semantic markup and intermixed wit
by niftich 10y ago
HTML isn't a renderer-output-description-language like PDF or PostScript. It was always intended to deliver content alongside semantic markup and intermixed with only basic formatting. Later, nearly all non-semantic tags got deprecated when CSS came of age; together they deliver structure and presentation. The image tag argument is a red herring: in HTML, that the exact resulting render is up to the browser's layout engine based on the CSS and the viewport.
The blog post isn't wrong, but it's also not right. Today's web isn't slow because of HTML's features, shortcomings, or other properties; it's slow because of excessive reliance on client-side scripting, including client-side DOM manipulation, ad serving, tracking, and A/B testing. Turning off Javascript vastly improves pageloads, and did -- once upon a time nearly 10 years ago -- improve UX, but these days more sites break without Javascript than those that don't.
AMP can impose constraints because it's a corporate effort to re-frame content in a way that provides centralized ad serving, tracking, and the like. It gives the content publishers the same tools (ads, tracking) they have to provide themselves with on the open web, while simultaneously benefiting those like Google who will put their own viewport and context around that content. It's not that much different from when an individual wants to publish on Medium or Tumblr, so the platform provides the author with a box to put text in, a dashboard, view tracking, and stuff the author wants, while they get to host interesting content with which to attract an audience for ads. It's a win-win, symbiotic relationship, while on the self-hosted web, every publisher is on their own.
This isn't about HTML vs AMP at all. It's about business models, which are given in AMP, but left as an exercise for the publisher on the open web.
- Benjamin_Dobell 10y ago> Today's web isn't slow because of HTML's features, shortcomings, or other properties; it's slow because of excessive reliance on client-side scripting [...] Turning off Javascript vastly improves pageloads Sure, disabling JavaScript will improve pageloads. However, are you suggesting clicking a link and waiting for an entirely new page to load is good UX? Good UX is instantaneous feedback, client-side code is a requirement... Unless you want some kind of enormous super-spec that is supposed to encompass anything anyone could ever wish to express in pure markup. In which case, good luck getting that supported and rendering quickly. The whole point of JavaScript (or any client side code, including mobile apps) is that it vastly improves UX.
- Alphasite_ 10y agoIf it loads quickly, why not? My connection is a sub 3ms ping to the nearby datacenters, what exactly is the bottleneck? It's not to say there isn't a place for SPAs but I would argue many of these would be better suited to being full fledged desktop apps instead (better performance and snative integration).
- Benjamin_Dobell 10y agoOkay, for you there's no bottleneck, just woeful UI/UX. Seriously, seeing just one stateful element at a time, then pressing "Next". Wow, just wow. I fully expect that when I type the first few digits of my credit card number that the site knows precisely which card provider I'm supplying and updates the UI (highlight the card type) accordingly and immediately update the security code field to request my 3-digit MasterCard CCV vs. a 4-digit AMEX CID. To be clear, I'm not suggesting code needs to run on a client. One day when we all have fast enough connections (with minimal latency), including on mobile network, then perhaps all the code can run server-side and we just be streamed the output (video) - which again, updates in real-time! However, living in the real world as it stands today, client-side scripting is a fantastic solution to a real-world problem i.e. latency and bandwidth constraints, and real-time responsive UIs.
- tlrobinson 10y ago> My connection is a sub 3ms ping to the nearby datacenters, what exactly is the bottleneck? Heh, tell that to someone in, say, Australia.
- detaro 10y agoFor many pages, loading an entirely new page is perfectly fine UX, and way better UX if the alternative is dynamic loading and all kind of performance-eating ad scripts, scroll hijackers, ... If your site is a traditional content-heavy website, you need to load a full page of content with both ways, it doesn't matter that much if you are loading the skeleton around it or not, and there is way less chance of accidentally breaking something. I don't need instantaneous feedback that you have begun to squeeze content through the pipe (if I'm on mobile the content will take time to load anyways, on a wired connection you can deliver a full page quickly enough) Sure, real "apps" are a different thing, but they are not the ones people typically complain about being overloaded with scripts.
- rpgmaker 10y agoSidelining well established standards isn't the solution to the web's problems. This is one of the instances where being open source it's not enough and coming from Google it is actually worrying. A very obvious Trojan horse in my opinion.
- kartickv 10y agoHTML may have intended to deliver semantic markup, but web application developers want pixel-perfect layout. That ship has long sailed. No disagreement about excessive scripting, ad serving and other bloat. But those are orthogonal to my points. Are there some things in AMP that would make HTML faster or improve the UX? If so, let's evolve HTML based on what we learnt.