Item — HN Reader

The only constant in mobile development is churn.

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.

6 comments

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.

Now compare this to Windows. You can run a Win32 program built in the 1990s, and it would work fine.

I wish that were true.

Modern windows won't even play crysis without a binary patch.

Half the 90s was DOS and Win16 which got dropped a while back. Still, I salute them for supporting backward compatibly much longer than most.

My java apps from uni days still work on windows and non-arm macs. With a little tweaking for opengl links, arm works too.

My old uni android apps still work on android last i checked. With a recompilation my ios apps work on ios too.

However, with absolutely zero work, ALL of my web stuff across all time works just like it used to even the angular 1 stuff.

It is why i love web so much. It is the ultimate distribution platform with so little needless churn.

Can you still build your old projects? The ones developed using node6?

I do not agree on this statement at all.

NVM is great, as long as the packages still exists, you can just switch to node6 for this one build.

Node6? You know js doesnt need node to build right? First stuff primary non-node based bundlers and script tags to libraries. I know old school.

And yet some bundles did / do run on node.

Regardless, the fragmentation you emphasize here is yet another issue why you'd probably have issue building a 10 year old project.

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.

Oh boy, do inhave a lot of projects I want your magic fingers to build for me since you will never have any issue just doing it on bun!

This hits too close to home.

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?

[0]: www.ifeelio.com

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.

> for displaying unselectable static text

FTFY (but seriously, why do so many sites do that?!?)

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:

https://qwik.dev/docs/getting-started/

Fake <a> tags are so yesterday. Everybody knows you should actually render all text on a canvas using a custom WebGL renderer for the best UX.

Wow. That is insane.

That is crazy.

Mobile experience.

It makes sense in some places; buttons, mostly so quickly tapping a button doesn’t zoom or whatever.

I agree that a lot of people are lazy and block text selection sitewide though because it’s easy and makes the PM go away.

If the PM didn't even request it explicitly.

SVG is the future /s

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.

Server rendered HTML should be the default.