4 ms·

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

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/

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/