Comment by serbuvlad | Hacker News Reader

Comment by serbuvlad | Hacker News Reader

Parent Full thread

> Further (and this one is entirely on you) the real comparision isn't "unixes" it's a graphical env. So compare the complexity and attitude to win32 dialog apis, QT, etc...

Yes these entirely fit the platform/library hard distinction model.

The platform is the small API to create windows, recieve input events and get an OpenGL/Vulkan/DirectX/Metal surface to draw to, as well as the graphics library itself, which is similarly based on primitives.

Everything above that is a library.

> Because the users of those systems don't really want a canvas they have to render everything on... rendering is hard.

Qt isn't a "system". libQt5 Core + Gui + Widgets + Qml is roughly 20MB on a Linux system I can readily check. This is way more than lean enough to ship with every app and even to download-on-first-use and cache for a web app (assuming it was ubiquitous and many websites would want to pull it from cache).

What the system gives is exactly a canvas to render stuff on.

QT base alone is 66mb on arch, not incl deps.

Chrome is ~100mb.

They're right along the same order of magnitude for size. Install size has very little connection to standards/api complexity. It's just a bad argument.

The right discussion (which you're nicely skipping by talking about install size) is "how does the complexity of QT widget selection compare to html?"

And... I find the spaces incredibly similar - this feels decidedly like browsing html components: https://doc.qt.io/qt-6/widget-classes.html

QT gets the perks of being able to remove deprecated items - so I fully expect theirs to be a more minimal set. That's a luxury not afforded to browsers.

So again...

---

> What the system gives is exactly a canvas to render stuff on.

Render fucking how? The deliverable wasn't code, it was an html document. That's the defining history of browsers.

You are missing my point so much...

1. I am sure there are historical reasons for the way things are.

2. Qt is not a platform. XDG/Wayland/Vulkan/PipeWire/D-Bus is the platform. Qt is a library. The platform is (relatively) lean. And the library is more complex. Whether an app is written in Qt or GTK or anything else it should be transparent for the end user. Whether an app is an executable or a website is not transparent, hence different platforms.

3. Rendering in terms of HTML/CSS is certainly valuable, but it can be reduced to a small subset of what it is + libraries.

4. This reduction would be very useful.

5. In this counter-factual reduction, one can just invent a better method for library deliverables, although I suspect a long TTL chached GET from a cannonical source would be much more than sufficient.

> That's a luxury not afforded to browsers.

That's a luxury not afforded to platforms. You cannot remove core Wayland protocols or core Vulkan functions or Linux syscalls.

This generally isn't an issue if you don't bloat them in the first place with things that don't belong in a platform and that belong in a library.

Reply on news.ycombinator.com