[criddell]

I don't intend for this to be critical. You've created something pretty impressive and are giving it away which is awesome. But since you've acknowledged the decision as controversial I'll say it - web technologies for UI kind of suck compared to just about anything else. They are hard to reason about, they are fragile, slow, and heavy. They are a house of cards build on shifting sands.

Now I know there are people here who hold the exact opposite opinion. They've worked extensively with Carbon/NextSTEP/Cocoa/UIKit, or OS/2 PM, or Win32/WinRT, or even Swing/JavaFX and then moved on to web UIs and love it. I don't get it though. I sometimes wonder if the web UI fans are mostly people who want to work and play on Linux and that's about the only way software makes it onto or off of that platform these days - as Electron apps.

[zagrebian]

> web technologies for UI … slow, and heavy

It’s not the web platform features that are slow and heavy. It’s all the JavaScript on top of it. You can make a UI on the web with just HTML and a bit of CSS. Nothing beats that in terms of performance and small size*. But if you add several MBs of JavaScript frameworks on top of that, then it becomes what you described.

*Try the HTML version of Gmail in your browser https://mail.google.com/mail/u/0/h/. Just HTML and CSS. It’s the fastest email client in the world.

edit: I timed it. HTML Gmail loads and fully renders in about 1 second.

[criddell]

> Nothing beats that in terms of performance and small size

Native controls do. For example, Steve Gibson wrote a DNS benchmarking utility[1] and the executable is 159k. No matter what you do, an HTML & CSS is still being rendered by a slow interpreter.

BTW, when I clicked on that link for HTML GMail, Google made me click through a warning trying to scare me off. I'm not sure why they would care if I use the HTML version.

In the end, I don't think the speed of CSS + HTML controls matters much. It's limiting and not a great choice for an operating system UI toolkit.

[1]: https://www.grc.com/dns/benchmark.htm

[zagrebian]

I don’t understand why you’re mentioning a DNS utility.

[criddell]

You couldn't write a web-based version that was anywhere near as fast and small. A browser sitting there showing a blank page is bigger.

[isaacaggrey]

> Try the HTML version of Gmail in your browser https://mail.google.com/mail/u/0/h/. Just HTML and CSS. It’s the fastest email client in the world.

I use Fastmail on a regular basis and it's snappier than the HTML version of Gmail.

[zagrebian]

How long does it take to load and fully render HTML Gmail on your device? For me, it’s 1.15 seconds, and that’s from the moment I click the above link to the moment rendering is complete.

[James-Livesey]

Yeah I understand, there are certainly a lot of interfaces out there that are built on the web and because of all the JS they use, they can feel really clunky. The reason why using the web as a platform for this system is because it is — in my opinion — the most viable tool we have at the moment to build cross-platform apps and services that work on all modern desktop computers and mobile devices from the same codebase (that is, without having to go down the React Native or Flutter route).

I do consider performance issues with the web to be quite serious, which is why I've avoided large JS frameworks such as React, Angular, Vue etc. and have gone for a lightweight one that was made specifically for the project (mainly as an experiment). The results do show: the system is rather responsive on an original PinePhone (and I should imagine is really smooth on a PinePhone Pro due to its much better specs), and you can get to the LiveG OS lock screen within 10 seconds of booting the system in VirtualBox.

But yeah, I do see what you mean by the web being... clunky in general. You say about the web being "fragile" and "a house of cards built on shifting sands", and yeah, the culture around developing web services has largely been to use waaay too many dependencies to achieve simple tasks.