I had apps on Google Play and every year I had to upgrade libs, recompile and loose and afternoon (or two) to not win anything, just churn for the sake of churn.
Compare this to plain HTML, CSS & vanilla JS. You can deploy a webapp today and if you are not using any beta JS Chrome API you will be able to use that site in 10 years without touching a line.
Oh yeah there is nothing "better" than needing to upgrade apps a few weeks before Google Play stops accepting updates because no one thought about it or it gets postponed to the "next sprint". Google is also very bad at communicating about these changes - for example, apps now need to support 16 KB page sizes or they will stop accepting updates on 1st November but the only warning I got about this was the one on 1st September (I'm sure they talked about this sometimes in the past in some blog posts but it's impossible to read and memorize everything). But they will send an email for every little tax-related change happening in some remote island even when you don't have any paid apps! Don't forget updating React Native and all dependencies, too (there will be a lot because RN has literally no batteries included) and you will waste weeks with this because things WILL break and you WILL have to replace some dependencies. Don't get me started on Xcode and iOS.
Weird, i just ran an old gulp based bundled project using bun without issues. I think there are problems with web tooling fragmentation but this argument sounds contrived as an attack the web platform. Js code from 10+ years ago runs without modification today which was the point. Tooling changes over time ofc.
I built an app for micro-journaling [0] in 2013. I think the iOS version stopped working in 2016, the Android version maybe a year or two after (I switched to iPhone so don't know for sure).
The interactive demo site I built in JS?
Still works exactly the same.
And I tried to make the apps as backwards compatible as possible.
Maybe AI could help make OS upgrade maintenance easier?
Unfortunely using plain HTML, CSS & vanilla JS feels like being a hipster in the age of using SPA or WebAssembly frameworks for displaying static text.
Unselectable static text is so last year. The cool new thing is these funny blue bits of text with click handlers that, when all the stars align, navigate to a different URL. Somewhere on the road map is context menu support, and the ability to open in a new tab is on the will-never-happen wishlist because no one can figure out how to do it in a cross-platform manner. Showing the target URL in a status bar didn’t even make the wish list.
The <a> tag is only for retro fanatics.
Seriously, I was peeking at the docs for Qwik, one of the cool new supposedly-lighter-weight frameworks the other day, and I was delighted to discover that, in what is obviously intended to resemble ordinary multi-page HTML, the links aren’t links. The long press behavior is utterly, comically wrong. This isn’t even unusual any more. I guess Qwik is proud that the JavaScript needed to emulate links is only 1kb minified and doesn’t add time-to-interactive overhead that scales poorly with page size, but literally every browser has had complete, native, no-script needed support for <a> even if the entire browser was a terminal app! Check it out:
The more relevant comparison is ASP.NET where maintenance is only required to keep up with changing internet standards such as httpOnly cookies or whatever.
I had apps on Google Play and every year I had to upgrade libs, recompile and loose and afternoon (or two) to not win anything, just churn for the sake of churn.
Compare this to plain HTML, CSS & vanilla JS. You can deploy a webapp today and if you are not using any beta JS Chrome API you will be able to use that site in 10 years without touching a line.