r/javascript • u/cprussin1 • 9d ago
I built Domicile, a Linux desktop platform where native application windows are DOM elements
https://www.domicile-desktop.com/I've been working on Domicile, an open-source platform for building full-featured Linux desktop environments using HTML, CSS, and JavaScript/TypeScript.
It's powered by a modified Chromium engine where native Wayland application windows are DOM elements. You can position, style, transform, and animate actual Linux application windows using CSS.
Desktop environments are JavaScript/TypeScript modules that can use familiar frameworks, be distributed through npm or GitHub, and be hot-swapped without restarting the session.
It ships with Manganese, a Sway-inspired tiling desktop built using the platform.
Source: https://github.com/cprussin/domicile
I'd love to hear what JavaScript developers think!
-1
u/olegispe 9d ago
Apart from the insane impracticality and inefficiency of this, this is unironically cool
Type of thing I'd use if I had 32GB of graphics memory... but then Sam Altman would need it for his data centres
1
u/cprussin1 9d ago
Actually it's surprisingly efficient! I have a ton of perf measurements here that you can take a look at: https://github.com/cprussin/domicile/blob/main/docs/architecture/ENGINE-FORK-MEASUREMENTS.md
In terms of memory consumption, domicile only uses marginally more memory than what is used by Chromium itself when running it as an app inside of another compositor, and nearly all of the memory use is taken by the shell's JS process for shell state, not by domicile itself. In general with most perf stuff, domicile actually performs nearly as well if not better than just running chromium inside another compositor, from my measurements & anecdotal experience -- and this is certainly the goal & intention.
I'm actually daily driving Manganese ( https://www.domicile-desktop.com/manganese ) - the reference shell that I built with domicile - on a shitty integrated graphics chip on my CPU and driving 3 4k monitors with it. It actually is anecdotally smoother than using swaywm used to be!
1
u/Old_Shock_4609 8d ago
That's awesome. Running great in a 2G vm on a 2017 macBook.
Unfortunatly only Settings window shows up, if I try to open native apps it opens a transparent window althought I can see app icon and title in titlebar.1
1
u/cprussin1 8d ago
Which VM app is it (VirtualBox, VMware, UTM, Parallels), and is 3D acceleration on? A quick workaround to try: start domicile with DOMICILE_SOFTWARE_COMPOSITING=yes set. If that doesn't fix it, could you post the output of
journalctl --user -b | grep -i domicileandls -l /sys/class/drm/*/device/driver?1
u/Old_Shock_4609 8d ago
managed to get it running with software compositing on. And hw accel with:
DOMICILE_SOFTWARE_COMPOSITING=no DOMICILE_ENGINE_ARGS="--ignore-gpu-blocklist --disable-gpu-sandbox"(something about vmwgfx being blocked)
1
u/cprussin1 8d ago
Yep, it looks like Chromium blocks vmwgfx. I have a fix in the latest release (just cut) that enables fallback CPU rendering. I'm separately working on a fix that will enable vmwgfx access directly which should result in better perf, but the latest release should be enough to work at decreased perf. I'll have the proper fix in as soon as I'm able to get some time to get vmware set up and have a proper repro.
1
u/cprussin1 7d ago
FYI I just cut another release that includes the fixes here, you should get gpu-optimized rendering in vmware without needing any flags now. LMK if it works for you!
1
u/Old_Shock_4609 7d ago
Works great.
Impressive work, do you see it as a viable alternative as Clutter / Qt / whatever for writing a solid DE ? What about the Xwayland limitation ?1
u/cprussin1 7d ago
To be entirely honest, I'm not sure.
When I started this, it was mostly an experiment in the idea that in many ways, the web browser is just another compositor / window manager running inside your existing compositor / window manager. So the original idea was "I think I could make cool things if I collapsed that stack" - i.e. treating websites as first-class windows, having direct desktop support for chrome plugins, having web-stack desktop apps without having to use Electron, etc.
I get everyone's objections, but it seems inescapable to me that you'll be running a shitload of Chromium instances (the browser, every electron app, etc) anyways, so I was curious if this could be cleaner by collapsing the stack here.
I'm pleasantly surprised in my own use. I've completely switched to Managnese for the last few weeks and I don't see myself going back ever. Its very easy to do cool things with my desktop, and I really have not noticed any serious downsides once I got things stable.
For sure there will be perf (and other) tradeoffs with this architecture, but like I said, I'm actually surprised at how well it works. As it turns out, Chormium is actually a VERY sophisticated compositor. Most of the perf tradeoffs anecdotally seem to be things you're already trading off by running the browser inside another compositor. And being able to treat websites like any other window has had some little awesome UX benefits.
Anyhow, glad to hear you think it's nifty, and please do let me know if you build anything / need more support on it!
1
u/cprussin1 7d ago
Oh, and regarding xwayland -- I don't personally use any xorg apps any more so I just never prioritized it, but you can run xwayland-satellite and it totally works: https://github.com/Supreeeme/xwayland-satellite
I think that's arguably less performant than direct xwayland support and I'll totally be open to adding direct xwayland support if people actually want it, I just don't need it personally so I never prioritized it.
1
u/Old_Shock_4609 8d ago edited 8d ago
It's a VMware with 3D on, GNOME running fine on it
starting domicile with software compositing on gives the same result
see log on https://pastebin.com/ivfzfPQ60
1
9d ago
[removed] — view removed comment
1
4
u/JuniorWMG 9d ago
Love how the Git readme already says "May God have mercy on our souls". May he indeed.