Skip to content

Comment on A Non-Business Case for Supporting Old Browsersparent

Comments

Web applications are a bit more complicated, but that complication is self-inflicted. We developers choose to to hijack users' devices for work that should be done on the server in the name of providing a better user experience, and we make our work harder in the process.

I think you are absolutely right with "self-inflicted" --- it brings to mind the frequent discussions here about Slack and their web-based client using hundreds of MB to gigabytes of memory for what is essentially "IRC with some images". Not too long ago they "stopped supporting" older browsers, which was basically a kick in the face to everyone for whom it was working perfectly fine before.

I remember using "webchats" in the late 90s/early 2000s with IE6 (or could be 5/5.5, not sure) on machines with probably 1/100th the processing power and memory of ones today, and they worked perfectly well; complete with things like animated emoticons (they weren't called "emoji" yet) and GIFs that didn't even lag the system unlike what happens today, and that was on a single-core CPU!

A possibly fun project is to create a Slack clone that works with that resource constraint, and uses their API; they have a WebSocket interface which older browsers are obviously not capable of using, but I believe there's a classic AJAX API too.

Use a Matrix bridge if you really need Slack, and pick one of the web-based Matrix clients, or build your own. Some are extremely lightweight.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.