[KevanM]

This, so much this.

The skew to web applications rather than websites for tooling has been very disappointin and myopic view of what a 'website' is.

It would make sense if I could give it a root URL and then a robot progressively ran tests over a month and then reported back, but one URL is a drop in a vast ocean for most of us.

[Yaggo]

Properly made "web application" doesn't have to break the web. It can be curled, links work, back button works, etc. You just don't get any interactivity (besides links) without javascript, but it still works as browseable site (rendered server-side). You can have the cake & eat it.

(I'm not saying that every application should behave like that. Often the extra work is not worth it. But a public, content-heavy site should behave like that, whether it was single-page app or tradiotionally implemented.)

[pmlnr]

This is called progressive enhancement and, sadly, nobody seems to be doing it any more.

[SquareWheel]

Progressive enhancement is different than what the parent comment is suggesting. They are describing how to correctly write SPAs and other webapps.

The reason progressive enhancement has fallen away is because Javascript support is now ubiquitous. Your browser has it. Your screen reader has it. Even web crawlers have it.

[PavlovsCat]

> The reason progressive enhancement has fallen away is because Javascript support is now ubiquitous.

WP describes it as

> Progressive enhancement is a strategy for web design that emphasizes core webpage content first. This strategy then progressively adds more nuanced and technically rigorous layers of presentation and features on top of the content as the end-user's browser/internet connection allow. The proposed benefits of this strategy are that it allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth.

It's way, way more than JS.

> They are describing how to correctly write SPAs and other webapps.

In the context of "I have a website, not a web app", and web apps that "don't break the web", i.e. also behave well as web pages. If you are suggesting anyone is building backwards to that from a web app, instead of progressive enhancement, do you know an example?

[SquareWheel]

If I understand your question, you're asking about adding functionality to a webapp to make it feel like a webpage rather than enhancing a page to add new features. The best two examples are actually mentioned above.

1. Using history.pushstate to intelligently add to page history for meaningful changes to the page. This ensures pressing "back" in your browser is still reliable.

2. Using server-side rendering on the first render. This keeps SPAs fast while the payload is being transferred.

Regarding Wikipedia's definition, that's a more broad definition than I'm used to seeing (speaking as a web developer). I've always heard it in reference to falling back gracefully from Javascript - usually with a <noscript> tag.

Supporting mobile, weaker networks, accessibility, etc. fall into much larger categories. Many of these topics require their own discussion and best practices.

Those topics are of course still important today (if not even more so).

[acdha]

> The reason progressive enhancement has fallen away is because Javascript support is now ubiquitous. Your browser has it. Your screen reader has it. Even web crawlers have it.

That's only part of the problem: every day I encounter sites which fail because the developers assumed not just that everyone has JavaScript but that they can load tons of assets reliably and instantaneously. The key part of progressive enhancement is thinking about how to degrade gracefully when everything doesn't work perfectly, which also tends to offer a better experience for anyone who doesn't have a very high-speed near-perfect network connection.

A couple of weeks back, I was using a family member's Spectrum “high-speed” cable modem service at a whopping 5Mbps with latency measured in the hundreds of milliseconds. It really highlighted who was doing progressive enhancement and who was doing “works on my machine” when you saw one page load 90 seconds faster than the other.

[0xffff2]

>A couple of weeks back, I was using a family member's Spectrum “high-speed” cable modem service at a whopping 5Mbps with latency measured in the hundreds of milliseconds.

And that's still great internet compared to some places. I have a house out in the middle of nowhere that is only served by a single satellite internet provider (surrounded by trees that block the view to other providers' sats). I get 20Mbs at ~500-1000ms latency for a few days before I hit the 20Gb cap, then I get 0.5-1Mbs for the rest of the month. Hacker News is one of the few sites on the web that I can browse relatively painlessly when I'm up here.

[acdha]

A couple of years back I was at a conference in Rome. Literally in the heart of the city (the windows overlooked the Forum) and that meant that they had only satellite access because nobody had run cables through the historic buildings. I've never been more glad to have spent time optimizing our site for 2.5-3G performance than when we were demoing it during presentations and it seemed slow but almost everything else was unusable.

[SquareWheel]

I'd put network use in a different category. It is an important issue though.

Thankfully the tools are getting better for this. The recently supported font-display property is a great one. It allows devs to choose how to handle web font rendering over slower internet connections.

Now I just wish more devs would start to take advantage of all the great performance tools available. Those best practices are unfortunately rarely taught.

[acdha]

> I'd put network use in a different category. It is an important issue though.

My rationale for considering it to be included is that as the concept was developed I took the spirit of progressive enhancement to be doing the best with what your users have rather than only catering to people with the same setup you have.

> Now I just wish more devs would start to take advantage of all the great performance tools available. Those best practices are unfortunately rarely taught.

Agreed. I think one of the challenges has been both showing business value from performance — once you're putting things into a cost/benefit comparison it's a lot easier to get people to routinely consider the performance impact of their decisions.

[collinmanderson]

for font-display, do you prefer swap or fallback?

[kaycebasques]

> It would make sense if I could give it a root URL and then a robot progressively ran tests over a month and then reported back, but one URL is a drop in a vast ocean for most of us.

I think this is the end goal. Building the infrastructure to audit a single page is the first step towards that bigger outcome.

Disclaimer: I write the docs for Lighthouse. I'm speaking from my general knowledge of the project but haven't vetted these comments with my team. So consider all comments my own.