It said simple web pages, not web apps. Web apps that use APIs are basically in the same boat as a phone app. Constantly moving API target and platform requirements ever changing.

Just like simple webpages, simple desktop and mobile apps last a long time too. It is only when working on complex applications that use cutting edge apis that churn is a problem

> mobile apps last a long time too

Really? How come half of the apps I've used in the past are listed in the app store as "not compatible with this device, but they can be installed on $device_gone_to_rest_in_drawer_14_years_ago"?

I'm genuinely curious! I thought it was aggressive deprecation of mobile OS APIs that made old apps no longer work on new phones.

Have you tried installing APKs directly?

Both Apple and Google start stripping apps out of the store once they stop shipping updates. And Apple in particular deprecates APIs like they are going out of business.

Not to mention things like the whole 32->64bit transition that dropped all previous iOS apps (and on the MacOS side of things, we've had 4x of those in the past 25 years - classic->OSX, powerpc->intel, 32->64bit, intel->M series)

Google is really the more strict of the two here. On the App Store you can get away with shipping an update from an old version of Xcode once every couple of years, while Google will boot you if you don’t increase your SDK target (which entails updating your whole toolchain and probably several dependencies too) once every year. Deprecations are pretty soft and many of the APIs deprecated well over a decade ago still technically function.

The major platform transitions are harder breaks but are pretty rare. We’re not going to another architecture shift or bit increase for a long time.

Ok but what is serving the simple web page? Do we think that software has been patched or rewritten over the last few decades?

I feel like there is a category error here where people think a website is the HTML that lands in your browser. When actually it is also the technology that received your request and sent the HTML. Even if it’s the same “flat” HTML sitting on the server, a web application is still sending it. And yes, those require maintenance.

Of course, but some technologies are more mature and stable, and maintaining those amounts to set and forget security updates, not rewriting functionality to keep up with changing features etc.

It's not a dichotomy though. If you build with cutting edge platforms, you'll suffer churn as things change underneath you. It's a choice you should make with awareness, but there's no right answer.

I prefer stable mature platforms for professional settings, because you can focus on the business problems and not the technology problems. It's the more fiscally responsible choice as well, given lower platform churn means less work that has no direct business value.

Have we actually had any big webapi deprecations?

I mean, I guess the death of Flash / Java Applets / ActiveX / etc count, but in the javascript world, doesn't feel like we've actually had that many breaking changes

Sure we have. Off the top of my head, and relevant to this article, the websql api was deprecated after 2-3 years of support.

I guess so. Since WebSQL got sniped well before standardisation (and Mozilla never implemented it in the first place), I wasn’t really counting it

More like it was moved to a library

Webapps are rewritten because a developer wanted to use the new shiny, or someone was convinced that everything will be better with the newer frameworks everyone is using. Also, it often goes hand in hand with giving it a more modern look-and-feel.

But the point is not whether webapps are rewritten, but whether they have to be rewritten. I know some old enterprise webapps made with PHP about 10 years ago that are still working fine.

You do have to worry about security issues, and the occasional deprecation of an API, but there is no reason why a web-based service should need to be rewritten just to keep working. Is that true for mobile and desktop apps?

If your webapp is simple a rewrite is no big deal and often cheaper than updating the old. As your project gets large that is no longer true. I work with embedded systems, when everything was small ( 8 bits isn't enough for anything else - new feature often means removing something else) we of rewrote large parts to get one new feature. it was easy to estimate a new project and we came in on time. As projects get bigger (32 and 64 bits are now available) we can't do that we can't afford a billion dollar project to rewrite every year.

>but there is no reason why a web-based service should need to be rewritten just to keep working

I mean most webapps of any size are built on underlying libraries, and sometimes those libraries disappear requiring a significant amount of effort to port to a new library.

Matlab, at least the language, has changed quite a bit when I was using it. Eg they added being able to pass functions as first class values.

But that was more than a decade ago, I guess?

Languages often add features in ways that does not break existing code. I think here we are discussing changes that are backwards-incompatible.

Not really, web pages (which do not depend on specific APIs) still work just fine, they just look antiquated.

Desktop apps in theory can run too, but it depends on what they link and if OS still provides it.

My current hobby project is for DOS. Runs everywhere, mostly thanks to DOSBox, and the API has not changed since 1994 and will never change. For something to run offline and to avoid being stuck forever maintaining code I think this is what I will stick to for most of my future projects as well.

It's not like any modern OS, or popular libraries/frameworks could not provide an equally stable (subset of an) API for apps, but sadly they don't.

I actually think this is rather sensible. If I didn't have to learn DOS from scratch[1] to do it, I would be tempted to use it as a platform for many of my side projects. As you say, it will forever be a desirable platform to maintain (currently in the shape of DOSBox) thanks to the vast quantities of software – especially games – written for it.

[1]: I am young enough that when I last used DOS was before I had started programming, so I never learned it beyond command-line interaction.