@analog_cafe Yeah, I work in web dev, so I'm familiar with the concept. I'm also aware that a lot of "programs" are now basically just web apps in a container; I can't say I'm a big fan of that, either!
For instance, it's one thing having something like a Mastodon client being a web app (I'm using Sengi on OSX at the mo, which just the Sengi website in a wrap to make it look "native"), but with tools that you use regularly but actively don't *need* to be online, it doesn't make a lot of sense.
@analog_cafe Even if you get past the need for an internet connection, there's also the overheads involved with a constant connection & a browser. One huge bugbear for me is how many websites (and, by extension, web apps) are designed for the (comparatively) high-end devices and connections the designer/programmer uses, without any consideration of how poorly they will run on old hardware or intermittent or slow internet connections.
@coldkennels I see a lot of websites like that. I promise you this is the result of a subpar effort by the developer and not the technology. Because JavaScript/HTML is more accessible than, say, C++, many programmers making websites are simply not experienced enough to think of performance.
@analog_cafe Ah! Found it.
This is perhaps the best example/explanation of what I meant by web bloat: https://danluu.com/slow-device/
Edit: another way of thinking about this is my battered old 2008 Macbook still runs AnalogExif and ExifTool without issue. But because of the gradual bloat of browsers, it cannot run any current release of any browser - meaning it cannot run *any* web apps.
This push towards the "browser operating system" is rapidly increasing e-waste.
@coldkennels This is a nice resource, I'll have to look into this more. Part of my job is researching and implementing best performance practices. But as I mentioned earlier, because the web is easier to build for, there are more websites (than apps) built by people with more diverse backgrounds, which means that many of them are lacking.
Flipping the script: this table makes 13MB look bad, but what about Mastodon Web (3.2MB JS/CSS/Docs/XHR) to Mastodon iOS (55.4MB + all future requests)?
@coldkennels Follow up to the edit: web browsers are native applications, which are to blame for the lack of backward compatibility. PWAs are 100% backward compatible, which is why you can still browse the new internet on the older browsers on your 2008 Macbook! I'm curious if my blog will still run on your machine, if not, perhaps there's something I can do better. 2008 is not that long ago
@analog_cafe The problem I'm getting at is that browsers themselves are hilariously bloated these days, and a lot of websites don't support older and more lean browsers.
I used Camino for YEARS after it was officially discontinued. It was the fastest & most streamlined browser I've ever used, but most of the modern web just won't display on it at all now.
I jokingly said on here once that if your website will run on the browser on a PSP, you're doing something right. I'll have to check yours!
@analog_cafe Okay, I can report: analog.cafe will not work on a PSP; that browser doesn't like the fact it's forced into https.
However, it *does* work on a Vita, which is quite impressive (that browser is from 2011 and laughably bad). It won't display a single photo for some reason, but hey, at least I can read the text without the Vita running out of memory.
Next week in dumb website testing: can we access Librivox on a Nintendo DS?
@coldkennels Haha, this is fun! It also gave me an idea: if the website can run on Windows XP machines, it can run on computers that power vintage film scanners. I can think of at least one practical use for that!
@analog_cafe what’s the last supported version of Firefox on XP?!
I’ll have to try the PS3 browser next time I turn that on. That was the only web browser I owned for a while back in 2006, and it was surprisingly useable with a USB keyboard and mouse!
@coldkennels Don't know if it's the latest, but the one in the screenshot is Firefox 52
@analog_cafe I guess the Mastodon comparison comes down to caching vs. locally stored material. In theory, a one-off download of the bulkiest parts of the whole process that is never/rarely altered is far better allocation of resources than constantly/regularly redownloading the same thing over and over again.
The problem of course - like I acknowledged - is that a lot of "programs"/apps are just containers for a web app anyway. I checked on Sengi, and sure enough, it's "built" in Electron.
