Hacker News Reader

Comment by giantrobot | Hacker News Reader

If your "web page" is essentially just a script tag and relies on content through first and third party APIs it's going to be pretty difficult to keep that running long term.

If an API shuts down, an incompatible change is pushed, or a JS CDN goes defunct in that JavaScript-only site breaks. JavaScript-only sites are pretty fragile.

If the same content was just a normal HTML document it could at least be easily archived. It's also trivial to keep online. Even if some CDN dies and CSS or JS doesn't load it's still readable.

JavaScript developers have never been great about progressive enhancement but it seems of late they've gotten worse. If the sole purpose of a site is to be an app then tons of JavaScript is necessary. But that's a minority of sites. A blog post or news article doesn't need to dynamically build the DOM with JavaScript and short circuit all of a browser's loading and rendering logic.

View on HN

Not everyone builds a site to immortalize content. Some are building businesses and trying to move fast. If an API can serve a website, mobile apps and desktop apps, then maybe that’s the only server I want, I move the rest to the client side. If in 10 years I’m still going, then I’ll keep the websites/apps available. If not, I likely will be too busy failing to care about content archiving. If keeping content on the internet was my goal, I’d build my site what way. But it’s not. Providing useful services is.

I wonder if brick and mortar stores are worried about their place of business if they fail? Not likely.

The internet is diverse, some things will be archived, some won’t.

> Not everyone builds a site to immortalize content.

True, and that is fine. However, by using JS + APIs, we risk that others who want to immortalize content for purposes of historical or cultural research fail to capture quite a bit of our current culture and content. I would be sad if my grandchildren are unable to get a feel for the world I live in like I could get a feel for the world my grandparents lived in by means of archives, magazines, newspapers from their day.

You're conflating web site and web app which I specifically called out. If you're building the new great gig delivery app, using the same API for a mobile app and web app isn't a big deal.

My issue, and I think a serious issue with the web today, is all of the essentially static content treated like it has the same needs as some web app. Your gig delivery app needs to represent the instantaneous state of the database back end. Your blog post does not.

JavaScript-based "sites" are often little better than the Flash sites they've replaced. They're often inaccessible, opaque to search engines, break linking, and are also opaque to microbrowsers [0]. For every site that relies on JavaScript but doesn't have those problems there's dozens that do.

[0] https://24ways.org/2019/microbrowsers-are-everywhere/

Google already archives pages for search in spite of their JS requirements.

If archive.org isn't doing the same, that's a bridgeable tech gap.

archive.org probably doesn't have the same computing power as Googlebot.

Reply on news.ycombinator.com