3 ms·

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 runn

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.

figassis 6y ago
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.
- ht_th 6y ago
  > 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.
- giantrobot 6y ago
  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/ https://24ways.org/2019/microbrowsers-are-everywhere/
shadowgovt 6y ago
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.
- progval 6y ago
  archive.org probably doesn't have the same computing power as Googlebot.

figassis 6y ago

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.

ht_th 6y ago
> 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.
giantrobot 6y ago
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/ https://24ways.org/2019/microbrowsers-are-everywhere/

shadowgovt 6y ago

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.

progval 6y ago
archive.org probably doesn't have the same computing power as Googlebot.