Comment by niftich | Hacker News Reader

Comment by niftich | Hacker News Reader

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.

> 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.

If 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).

Okay, 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.

> My connection is a sub 3ms ping to the nearby datacenters, what exactly is the bottleneck?

Heh, tell that to someone in, say, Australia.

For 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.

I have to wonder what it would be like if, instead of reinventing the page load process using Javascript frameworks, the web had gone in the direction of increasingly refined frameset functionality.

HTML5 sections are very similar to how frames were used. The biggest problems with frames were individual scrolling and opening in anew tab would lose context, both of which are solvable.

On my case I wanted it to have stayed as plain interactive documents.

I contribute to this goal by only allowing native applications on my devices, unless I don't have any good alternative to switch to.

You raise some good points. Within the same website, loading a different server-generated full page will typically load many of the same assets like CSS, and header images, which will remain cached by the client for subsequent loads.

It's true that some markup framing the content is duplicated; incidentally in the olden days we used <frame> tags to separate a site-global navigation from the page-specific content, but that went out of style -- it had URL addressability drawbacks and no convention ever developed to fix it.

But ultimately the client needs to render the View, while the server (at some point presumably) originates the Model. Somehow you have to turn the M into the V, and there have been hundreds of different takes over the last couple decades on how exactly to accomplish this. Classically, every HTML page was the complete view, but then the DOM API was introduced to allow this view to be mutated imperatively after the View has been rendered.

The main innovation of client-side scripting was Ajax, which was explicitly about lazy- and/or continuous loading of small snippets of innercontent, like a single Tweet or a couple Google Maps tiles. This emboldened some to push more and more state onto the client, and now we have entire frameworks that do MVC or MVVM in (client-side) Javascript. If we had a way besides the DOM API to morph one state of the View to another; say, a declarative HTML-diff, or, something like XSLT or JSON-patch, I'm sure people would take it. If this sounds a lot like Virtual DOM, it's because they solve the same problem.

> 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?

If done right there is not much wasted and there is not much to wait for as most of the things which are not new already are cached. Most of the time such slowness results from unnecessary bloat or slow code on the server side.

> The whole point of JavaScript (or any client side code, including mobile apps) is that it vastly improves UX.

In practice it worsens UX more often than not.

> However, are you suggesting clicking a link and waiting for an entirely new page to load is good UX?

Maybe they aren't saying that, but sure I'll bite. Why wouldn't it be good UX? I would challenge anyone to argue that non-JS/static UIs are anything but simple, intuitive and easily teachable. I have had the displeasure of repeatedly having to explain to family/relatives, how to use these "modern" UIs to the point where I'm fairly convinced that none of them have any utility, as far as UX is concerned.

HTML 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.

Sidelining 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.

Reply on news.ycombinator.com