[James-Livesey]

<!-- Bit of a plug but is related and might interest people -->

Firefox OS inspired me to build my own Debian-based operating system that uses web technologies for its UI and apps. It uses Electron as the runtime[0] and works both on desktop (AMD64 arch) and mobile (on the PinePhone). It's very much a work-in-progress project and is by no means complete, but it's progressing nicely over the past few months and I'm sure will become quite a complete OS functionality-wise in no time.

Feel free to check it out here if it piques your interest: https://liveg.tech/os

(There's also plenty of videos that I've previously made that showcase some of the key moments in its development: [1])

Capyloon IMO is also an awesome OS platform that achieves very similar goals to this project, and it'll be great to see what they build next within the world of non-mainstream web-centric operating systems!

--

[0]: A tad controversial, I know — but the rationale is that using one Electron app as the desktop environment means that you don't have to run Slack/Discord/Spotify etc. in their own Electron apps; instead, they can run as web apps that share the same Chromium instance. That way, you don't have completely separate Chromium instances/processes running at once, where they'd otherwise all be consuming lots of RAM due to their startup overhead.

[1]: Playlist: https://www.youtube.com/watch?v=pmOR2J9fDZM&list=PL3aAeH1lqy... — Prism is a prototype smartphone that runs LiveG OS, and gShell is the desktop environment.

[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.

[forgotpwd16]

Looks cool. The fact that same shell runs on both mobile and desktop conceptually reminds me what Canonical was trying to do. Being based on web technologies, couldn't you make a browser runnable demo for the interface? Such as the Flutter-based shell https://web.dahliaos.io is doing.

[James-Livesey]

Oh wow, didn't know that dahliaOS had this! The only barrier that I can see would prevent this from happening for gShell is that web browsers don't support the `webview` element that Electron lets you use (it's basically an iframe but without all the CORS restrictions and the likes, so you can see why browsers don't support it). I suppose one cool side-project would be to set up a service similar to Microsoft's Windows 365 that would stream a desktop environment to something like a `canvas` element — that way, we could get around all the CORS stuff.

Also, yeah what Canonical did with Ubuntu and Ubuntu Touch is pretty cool in terms of convergence (apparently it's really stable, too). I do find having the sidebar UI on mobile a bit odd, but I should imagine that it'd be something to get used to. Phosh and KDE Mobile I think are both convergent, too.

[Tijdreiziger]

My first thought given the name was 'does it have anything to do with Google?' (sorry)

[James-Livesey]

Ahh yeah I can see how people might think that with the name "LiveG"! The previous name was historically "LiveseyGadget" (my surname + "gadget") a long time ago when I came up with some of the ideas, but for all intents and purposes, this got shortened to the now-official name "LiveG" and the meaning behind the name essentially dropped to be more of an open project.

[aliswe]

Because of the double O?

[MaxMatti]

Probably because of the g in the subdomain, kind of makes it feel like "live g[oogle]"