It would probably take as much ram as KDE (sorry I didn't find a more up-to-date article) because of Electron, but thats it. No different than having various framework libraries pre-loaded. And I assume WebAssembly is gonna become faster as it becomes popular and more people start working on improving it and its tools. We got our editors in js, our terminals in js, and more and more apps built in js, so I would not be surprised if we soon got a desktop environment built in js.
Related: I was thinking the other day when I read about JS' new pipe operator.. One could extend Node REPL to be a js-driven OS shell (I'm not talking about a terminal, btw). Something like PowerShell but instead of passing C# objects, it passes JS objects. And some features to navigate the file system, and to make normal executables and js modules and functions to work better together.
Depends on how much need the world has for writing shell scripts in JS.
Well I was curious too so I tried nwjs and it appears to be much lighter. 72 off the bat, that gives me a little room to play with.
Npm or yarn could serve as a package manager as well. I wonder if I focus on a DE first it might turn into a full distro. One things for sure, I want to make this developer focused and get a community going.
I had some ideas about gtk as well, Broadway gtk 3 lets you run gtk apps in a browser, what if for backwards compatibility, I allowed webviews in a window that launched a gtk app. I'm this close to getting some Ubuntu core and trying to write a prototype.
In terms of terminals I really like your idea, if you release something when pipelines are a thing come back and show me. I had planned to use xterm.js or the aforementioned Broadway compatibility layer.
This project could be bloody interesting.
Node and Wasm is on par with Wasm in browser but with the added benefit of full FS access and multithreading for the guest language. The guest language could be a port of a pre-existing native lib, heck it could even be java native or dart. The apps provide the UI, the ported lib provides the functionality. For those not wanting to create a new UI, Qt now exists in Wasm and gtk has a web backend.
I am actually writing this thing at the moment. The display server is nw.js and the apps are iot.js procceses (node on a diet) each app weights 512kb! And each app can spawn webviews for thier ui, between all of the processes is a TCP server.
Only time will tell if the idea is a good one. Through this development I am keeping my frameworks to a minimum and making the process of making an app fairly open to developer interpretation. Flutter may be a great thing to support as well. But that's going to need more collaboration. I am making the basic working desktop and sticking this in a Ubuntu core distro. We will see where it goes.
Hmm interesting idea. There are just a few things that bug me:
Excellent questions, I don't know the answers get but it going to be a blast finding out. I had some ideas that could answer atleast 2 of your questions.
I'm afraid I don't know, I moved away from c dialects to look at zig and Rust. Developer buy in would be crucial to the success of the project but as far as I can see from wasi and the wapm package manager there are many successful ports.
I'm looking at writing a DE first not a distro I guess. I hope that smarter people like yourself can help me. I am just a humble frontend developer with a fetish for native binaries.
Wow this wasm-kernel thing looks interesting. Not sure yet how this gonna help with kernel tasks beside drivers written in wasm (which is nice on its own), but I think they might find a way to bridge the kernel/userland ring issue in a secure way.
About broadway Gtk - lol wasnt aware that this is even possible with Gtk. I have no clue about wayland internals, at least with good old X it would be quite easy to embed "foreign stuff". Broadway Gtk though does quite an expensive roundtrip - where a 3D acc. desktop/GUI would directly paint into the GPU with all its super fast bells and whistles broadway-gtk seems to render stuff in CPU offscreen, moves the view diff through a socket to the browser where it gets merged into the current view (again CPU). Imho a better approach for a wasm/browser engine driven DE would be to use offscreen-canvas and just clip the content into the right place. Lol macusers gonna cry for their battery life :) Well just some random thoughts on this...
This is exactly the story my friend told me a few months ago. I don't know why, but it's scary to me to even think about this. In my head it's a JS dystopia.
But why? 😉
Probably because it would need a lot more RAM while being slower than a normal DE.
Only one way to find out 😁, I agree with that but I would love to put a prototype together anyway and see what happens.
I think it's an awesome idea. Already been thinking about custom UI components for DE apps.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.