5 ms·

I'd like to call out the somewhat related problem of website rot. Meaning, the websites is online, it once worked perfectly, but becomes increasingly dysfunctio

by fleddr 4y ago

I'd like to call out the somewhat related problem of website rot. Meaning, the websites is online, it once worked perfectly, but becomes increasingly dysfunctional due to technical deprecations. The soft obligation to use HTTPS these days has deranked old HTTP-only websites in search, making them hard to find. These websites are also "defaced" with browser warnings or some subresources may not load at all. Embedded maps no longer work, since Google regularly breaks their API. Facebook login or other FB plugins no longer work, since it needs a yearly checkup of your account and there's the new requirement of needing to have a privacy policy. Those are just some examples of websites partially breaking through no fault of its creator, if you'd agree that the web should be backwards-compatible.

asddubs 4y ago
also, even if those older http sites get a certificate, any embedded scripts that point at http URLs, even if those URLs are also available on https, will not load and break. Especially hard to fix if you have user generated HTML on there. Same for http download links from https websites, will not work anymore. anything that used cookies on embedded resources will also be broken because of the missing samesite header (same for third party cookies obviously) if google really goes through with removing alert/prompt/etc from their browser like they said they were planning to a while back, so so many things will break
- EamonnMR 4y ago
  Notification prompt is 10x more annoying than alert ever was.
  - deleted 4y ago
    [deleted]
- fleddr 4y ago
  I'm uniquely bothered by this problem as I visit many such dysfunctional sites. I'm active in the (hobbyist) field of documenting species. There's thousands upon thousands of websites created by amateurs containing unique niche content. For example, somebody might have made it their lifelong hobby to document every species of bee in their territory. It's a fragmented mess of incompetently produced websites, but I find it incredibly charming and in the spirit of the original web. Above all, it is their content that has lasting value. The people behind it are good, generous. That's why it makes me so angry when their work is cast aside like this. Things not just technically breaking, in many cases simply disappearing altogether from search results.
  - generalizations 4y ago
    I wonder if manually curating a list of such valuable websites would be a useful resource for constructing search engine algorithms. I mean, if I was building a search engine algo, I wouldn't necessarily know how to find the websites you describe, much less optimize for them.
  - 8n4vidtmkvmk 4y ago
    you should make copies of those sites before they disappear if you care. maybe dont rehost them without the authors consent though
lucideer 4y ago
> due to technical deprecations This struck me as a wolf whistle, and the immediate follow-on paragraph confirmed that suspicion. HTTPS enforcement is a major migration, yes, but other than IPv4 (sadly a long way off) it's the only "technical deprecation" of any kind I can think of that websites have dealt with. Implying these kinds of deprecations are commonplace, rather than 2 in 30-40 years, is a little odd. > Google [...] Facebook Embedded maps & Like/Share buttons are not "technologies", they're product offerings from service-providers. Businesses change their offerings over time, this is common in all industries & not a problem specific to websites / the internet / tech.
- bcrosby95 4y ago
  If you want to get that technical, then even https enforcement is the changing of a product offering.
  - lucideer 4y ago
    If you want to get that technical, sure, why not. I don't understand what point you're trying to make though. Ultimately, ask yourself this question: if I set out to make a website in 1992 that I hoped would be around in 2022 after zero maintenance, would it be possible and why not. The only reason it wouldn't is my visitors are starting to enforce HTTPS. There's literally no other blockers. The backward compatibility within the web as an ecosystem is extreme. Going back to the original point - if I'm building a long lasting website in whatever year Google Maps embeds became available, should I reasonably expect a map embed pulling from someone else's server to work forever?
- dhzhzjsbevs 4y ago
  > Implying these kinds of deprecations are commonplace, rather than 2 in 30-40 years, is a little odd. Large parts of the web are powered by npm. The vast majority of those sites, if not actively developed, will not be able to build within a year's time.
  - lucideer 4y ago
wjamesg 4y ago
Wouldn’t all this not be an issue with static websites? We should have more static
- CaptArmchair 4y ago
  No. Static vs. dynamic is a concern regarding how HTML / CSS gets rendered by the backend. HTTPS certificates, embedding of 3rd party scripts, outdated HTML / JS / CSS,... are concerns that live entirely in the browser. Whether you use a SSG or a CMS, you still need to do upkeep of all of those: make sure your certificates are up to date, make sure you have the latest embed script, make sure you keep your site isn't build on top of brittle API's and frontend frameworks, make sure your site keeps following changing SEO practices, etc. On another note, if you use a CMS - e.g. WordPress - the availability of your site is directly tied to the operational availability of the CMS and the stack it depends on. So, that means upkeep and maintenance of the CMS become immediate concerns. If you use a SSG that only spits out HTML / CSS, that's far less of a concern: if your SSG breaks, the site doesn't break down. Of course, YMMV in the age of hybrid solutions where a static layout and a popular JS framework is send to the client which fetches fragments via GraphQL API's from a backend, which implies a coupling between frontend and backend.
listenallyall 4y ago
But they are the fault of the creator -- first, by including content entirely reliant on the whims and generosity of 3rd parties wholly outside the author's control. And secondly, using the content and not doing the minimum needed to maintain it. Would you also say it is "no fault of the creator" if s/he did not renew the domain registration? It's a bit like mowing your lawn once and assuming you're entitled to a perfectly manicured lawn forever.
- eloisius 4y ago
  Some of my favorite websites about cycling were created by now deceased webmasters. Luckily they are mirrored, but I’m very thankful that they used regular old HTML and images and aren’t rotting after a mere 11 years.
- fleddr 4y ago
  That is a perspective with zero empathy. These people are amateurs with near-zero resources generously sharing their content with the world. They may have all kinds of reasons for being unable or unwilling to continuously update their site. The bigger point is that when you create a website according to web standards, it should keep working indefinitely. As for 3rd party integrations, especially when they're enormous (Google, Facebook) they should do the maximum possible to not break anything. The very point of an API is that it's a contract.
chrisjshull 4y ago
Hi, I happen to work on Google's Maps JavaScript API, and we actually take great pains to avoid breaking our APIs as much as possible. We take very seriously the implications that breaking changes can have for websites all across the internet, and know that many sites are not under active development. This page covers the breaking changes from the last few years: https://developers.google.com/maps/deprecations#completed_deprecations https://developers.google.com/maps/deprecations#completed_de... (Keep in mind that the top portion of the page covers features still in the deprecation period - meaning they still work. And that this page covers deprecations in other APIs like Android and iOS.) My favorite: the deprecation period for v2 of the Maps JS API lasted 11 years after the introduction of the v3 Maps JS API. Happy to hear about experiences to the contrary, but I thought a little insight might be appreciated.
- the__alchemist 4y ago
  Y'all have done great work. I have a page that uses the Maps API - haven't touched it in ~7 years. No problems.
- fleddr 4y ago
  Thanks for responding, you're a good sport. Indeed I'm looking at this from a long time frame. From recollection the main breaking changes I'm aware of: 1. The change from v2 to v3, like you mentioned. 2. The new requirement to always include an API key. 3. The visual update to touch-sized controls, distorting especially tiny embedded maps.
  - deleted 4y ago
    [deleted]
  - chrisjshull 4y ago
    Appreciate the feedback. #2 is actually a pretty interesting one - while clearly a change in the API’s output, we were careful to make it so that maps without API keys actually still work (though they do get a heavy visual indication that they need to get an API key). That being said, when we are talking about such large timeframes, is it fair to portray that as “regular” breaking changes?

by fleddr 4y ago

asddubs 4y ago

also, even if those older http sites get a certificate, any embedded scripts that point at http URLs, even if those URLs are also available on https, will not load and break. Especially hard to fix if you have user generated HTML on there. Same for http download links from https websites, will not work anymore. anything that used cookies on embedded resources will also be broken because of the missing samesite header (same for third party cookies obviously) if google really goes through with removing alert/prompt/etc from their browser like they said they were planning to a while back, so so many things will break

EamonnMR 4y ago
Notification prompt is 10x more annoying than alert ever was.
- deleted 4y ago
  [deleted]
fleddr 4y ago
I'm uniquely bothered by this problem as I visit many such dysfunctional sites. I'm active in the (hobbyist) field of documenting species. There's thousands upon thousands of websites created by amateurs containing unique niche content. For example, somebody might have made it their lifelong hobby to document every species of bee in their territory. It's a fragmented mess of incompetently produced websites, but I find it incredibly charming and in the spirit of the original web. Above all, it is their content that has lasting value. The people behind it are good, generous. That's why it makes me so angry when their work is cast aside like this. Things not just technically breaking, in many cases simply disappearing altogether from search results.
- generalizations 4y ago
  I wonder if manually curating a list of such valuable websites would be a useful resource for constructing search engine algorithms. I mean, if I was building a search engine algo, I wouldn't necessarily know how to find the websites you describe, much less optimize for them.
- 8n4vidtmkvmk 4y ago
  you should make copies of those sites before they disappear if you care. maybe dont rehost them without the authors consent though

lucideer 4y ago

> due to technical deprecations This struck me as a wolf whistle, and the immediate follow-on paragraph confirmed that suspicion. HTTPS enforcement is a major migration, yes, but other than IPv4 (sadly a long way off) it's the only "technical deprecation" of any kind I can think of that websites have dealt with. Implying these kinds of deprecations are commonplace, rather than 2 in 30-40 years, is a little odd. > Google [...] Facebook Embedded maps & Like/Share buttons are not "technologies", they're product offerings from service-providers. Businesses change their offerings over time, this is common in all industries & not a problem specific to websites / the internet / tech.

bcrosby95 4y ago
If you want to get that technical, then even https enforcement is the changing of a product offering.
- lucideer 4y ago
  If you want to get that technical, sure, why not. I don't understand what point you're trying to make though. Ultimately, ask yourself this question: if I set out to make a website in 1992 that I hoped would be around in 2022 after zero maintenance, would it be possible and why not. The only reason it wouldn't is my visitors are starting to enforce HTTPS. There's literally no other blockers. The backward compatibility within the web as an ecosystem is extreme. Going back to the original point - if I'm building a long lasting website in whatever year Google Maps embeds became available, should I reasonably expect a map embed pulling from someone else's server to work forever?
dhzhzjsbevs 4y ago
> Implying these kinds of deprecations are commonplace, rather than 2 in 30-40 years, is a little odd. Large parts of the web are powered by npm. The vast majority of those sites, if not actively developed, will not be able to build within a year's time.
- lucideer 4y ago

wjamesg 4y ago

Wouldn’t all this not be an issue with static websites? We should have more static

CaptArmchair 4y ago
No. Static vs. dynamic is a concern regarding how HTML / CSS gets rendered by the backend. HTTPS certificates, embedding of 3rd party scripts, outdated HTML / JS / CSS,... are concerns that live entirely in the browser. Whether you use a SSG or a CMS, you still need to do upkeep of all of those: make sure your certificates are up to date, make sure you have the latest embed script, make sure you keep your site isn't build on top of brittle API's and frontend frameworks, make sure your site keeps following changing SEO practices, etc. On another note, if you use a CMS - e.g. WordPress - the availability of your site is directly tied to the operational availability of the CMS and the stack it depends on. So, that means upkeep and maintenance of the CMS become immediate concerns. If you use a SSG that only spits out HTML / CSS, that's far less of a concern: if your SSG breaks, the site doesn't break down. Of course, YMMV in the age of hybrid solutions where a static layout and a popular JS framework is send to the client which fetches fragments via GraphQL API's from a backend, which implies a coupling between frontend and backend.

listenallyall 4y ago

But they are the fault of the creator -- first, by including content entirely reliant on the whims and generosity of 3rd parties wholly outside the author's control. And secondly, using the content and not doing the minimum needed to maintain it. Would you also say it is "no fault of the creator" if s/he did not renew the domain registration? It's a bit like mowing your lawn once and assuming you're entitled to a perfectly manicured lawn forever.

eloisius 4y ago
Some of my favorite websites about cycling were created by now deceased webmasters. Luckily they are mirrored, but I’m very thankful that they used regular old HTML and images and aren’t rotting after a mere 11 years.
fleddr 4y ago
That is a perspective with zero empathy. These people are amateurs with near-zero resources generously sharing their content with the world. They may have all kinds of reasons for being unable or unwilling to continuously update their site. The bigger point is that when you create a website according to web standards, it should keep working indefinitely. As for 3rd party integrations, especially when they're enormous (Google, Facebook) they should do the maximum possible to not break anything. The very point of an API is that it's a contract.

chrisjshull 4y ago

Hi, I happen to work on Google's Maps JavaScript API, and we actually take great pains to avoid breaking our APIs as much as possible. We take very seriously the implications that breaking changes can have for websites all across the internet, and know that many sites are not under active development. This page covers the breaking changes from the last few years: https://developers.google.com/maps/deprecations#completed_deprecations https://developers.google.com/maps/deprecations#completed_de... (Keep in mind that the top portion of the page covers features still in the deprecation period - meaning they still work. And that this page covers deprecations in other APIs like Android and iOS.) My favorite: the deprecation period for v2 of the Maps JS API lasted 11 years after the introduction of the v3 Maps JS API. Happy to hear about experiences to the contrary, but I thought a little insight might be appreciated.

the__alchemist 4y ago
Y'all have done great work. I have a page that uses the Maps API - haven't touched it in ~7 years. No problems.
fleddr 4y ago
Thanks for responding, you're a good sport. Indeed I'm looking at this from a long time frame. From recollection the main breaking changes I'm aware of: 1. The change from v2 to v3, like you mentioned. 2. The new requirement to always include an API key. 3. The visual update to touch-sized controls, distorting especially tiny embedded maps.
- deleted 4y ago
  [deleted]
- chrisjshull 4y ago
  Appreciate the feedback. #2 is actually a pretty interesting one - while clearly a change in the API’s output, we were careful to make it so that maps without API keys actually still work (though they do get a heavy visual indication that they need to get an API key). That being said, when we are talking about such large timeframes, is it fair to portray that as “regular” breaking changes?