How the development world changes (Everything is web-based now)
There are a few trends that I notice in the world of software development that have, thankfully, little to do with AI, but are still worth mentioning and discussing. This is a set of two articles because it seemed I had more to say than I expected.
Everything is web-based now
So, the first one is the disappearance of non-web-based applications. Not the disappearance of the native application, because even electron-based applications are native, and they integrate pretty well in the desktop or mobile environment, but the disappearance of the native application that is not based on some web-technology (HTML, CSS, JS, etc). Even native frameworks end up rendering HTML, so, for example, you can have now on your buttons in a Qt library a subset of HTML being rendered. Gtk does this too. So right now it’s pretty hard to do any sort of civilian rendering without some HTML and CSS parsing, and you might think that this is amazing. I’m not so sure.
The problem is that even doing things that were supposed to be easy you’re doing them in a complicated way; sure, you’re not embedding electron, but you’re still doing some processing that is probably not necessary. And neither HTML is sufficiently well defined to be precise in its rendering, nor CSS is sufficient to be able to do everything it needs to do in an efficient manner. And especially in rendering individual items, CSS is useless: there’s no Cascading when you’re just setting some properties to an individual widget. CSS works well with HTML because HTML is a „this is one document” dying-on-the-hill type of affair, there the cascading part makes sense.
And indeed, they call it a subset, and I get that probably it’s just a catchy name reuse for the sake of allowing web developers to be relatively competent when encountering native applications in the wild, and maybe it makes sense? I can’t tell. I didn’t work on native applications for quite some time, and Qt3 was the best I could use back then. It was an absolutely lovely framework, its influence on the world of software today is not fully appreciated. Just so you know, there is a direct link from the Qt framework to the web browser you’re most likely to use visiting this website.
Rant: Yes, with the exception of Firefox, all current-day browsers are a form of KHTML, an open source project that powered konqueror, the KDE-specific browser. Webkit was forked off KHTML, Apple deciding that it doesn’t want to give anything back to the community it stole from until people went close to suing them, and then they caved, released the source code, Google forked it, etc. etc. The point is that the most important part, the philosophy that these pieces were built on, were sourced from the creative pool of the KDE community, and you can throw into the trash bin all the „Apple created” or „Google created” web browsers. Yes, they invested money in it, money they took off you, indirectly (yes, you’re paying indirectly for the marketing that floods your google searches & stuff). Rant over.
I’m not mad at the current trend of things being web-based - at least there’s a hope that there will be a common vocabulary for designing applications; however, this vocabulary is inconsistent itself. Not only inconsistent, but since the web CSS is way too complex, including animations, timers and whatnot, this makes each situational use of CSS be an incomplete version of the globally available CSS. Yes, CSS is too big, too wide, it tries to do too many things, and it is growing into an inconsistent mess.
So how much CSS will your application framework support? 2.5 meters and 3 kilograms, I guess. If you use only the first 2.5 meters to define your application needs it’s perfect, you’ll be supported. YAY!
Probably this needs to be settled in the future, unfortunately, the way things are getting settled is by removing native toolkits altogether and throwing at users a web-archive in an electron wrapper. This is what recently a very poor company did for their Whatsapp Windows client. You’d think that the productivity boost that AI brings would allow the native application to continue being developped, but turns out, no, it’s not the case. And we’re not here to rail on AI either, so let’s move on.
Why did Meta drop the native client? Well, one of the reasons might be in lack of trust in the future of Windows. I get it, I wouldn’t trust Microsoft at this point surviving the 2020s. But I bet this is not the reason, the same way that keeping one or two developers to maintain that application is not such a huge cost for Meta either. It’s not performance either: the whatsapp native client idles at 10-20 MB of RAM, while the web application eats up 1GB of RAM for just it’s idle day-to-day spying activity. So that’s not it either. So the reason is that maintaining the same spyware on different platforms is hard, and it’s easier if you do it in one place, only once. And they don’t give a fuck about you, but you knew that the moment we mentioned Meta.
So everyone jumps on the web-based stuff now. It doesn’t make technical sense, but it makes sense in all other areas. Nobody understands that the technical downsides are important, instead, the world has a very courageous bullshitty approach about this topic, inherited from the times of Moore’s Law: we’ll make crappier software because the hardware is bulky enough to take it. It isn’t.