Replies: 7 comments
-
(just my 2 cents) While this might sound good as an idea, actually implementing this would be pretty problematic IMO. Chromium (and therefore Electron) is a huge beast in terms of code, and while most of that code is probably OS agnostic, the parts that aren't might be bigger than the rest of the OS itself. (citation needed) I would recommend something like NetSurf or another "light" browser, but most of them don't support JS (and WASM). The only "realistic" approach I can see right now (there probably are more), is to write a tiny UI engine from scratch using WASM, though that might also be harder than it sounds. |
Beta Was this translation helpful? Give feedback.
-
As the WASM+WASI ecosystem matures we should start seeing more modules being standardized and implemented, some of those modules could be low level system interfaces to deal with graphics, I had imagined for example that one of those APIs could be a framebuffer for simple stuff or the webGPU API that has an implementation in the wgpu rust project which already many people are using in the Rust graphics world as gpu graphics abstraction, so any of the modern graphics toolkits being developed with that library could in theory be easily adapted to be the high level framework to create UIs of our future WASI OS :) it could get very high level and browser like, there are language interpreters that already compile to WASM like python, I think I've seen a JS one, also DOM implementations and CSS engines are not that far, but much easier to start with "native" Rust based UIs. For electron I highly doubt is possible or practical, I don't think we will see chromium or any browser engine being complied to web assembly, anyway it would need the host runtime to provide all sorts interfaces to run (like graphics primitives mentioned above) and running it in ring 0 seems even harder and riskier 🤔. We are a very long way from seeing a WASI OS with graphics support but definitely possible and very exciting to see small steps being done towards that direction. 😃 |
Beta Was this translation helpful? Give feedback.
-
HTML and CSS for applications is an amazing hack, which people use to build amazing apps. However, it’s still a hack and it has many trade offs. There are much better models for GUIs IMO. |
Beta Was this translation helpful? Give feedback.
-
While I think I agree with the premise that a 'direct draw' (or even a React Native-esk widget abstraction) approach would be more powerful and efficient, the immediate benefit of building an app UI upon the literal immeasurable amount work over the decades in tooling around the DOM shouldn't be overlooked as simply inconsequential. Quite the opposite, the DOM and it's massive trove of tooling seems to call on perhaps making Electron integration a worthy "exception" to the purity of any future app platform*. For example, perhaps Electron (or some light web-view) could run as a special sandboxed process (perhaps running in a sideloaded vm to the OS)? Just my random thoughts here. (*) even some AAA games these days are using overlay web DOMs to accelerate HUD ux development, despite the DOM's inefficiencies |
Beta Was this translation helpful? Give feedback.
-
@jadbox thinking convenience shouldn't be traded with resource usage. electron is just Chromium slimmed down, and it eats TOO many RAM. I would suggest something more in the lines of Flutter than Electron - its native and doesn't require an actual bloated web browser to render a UI. |
Beta Was this translation helpful? Give feedback.
-
Digging this up. By design, all processes are supposed to be sandboxed (I say "supposed to" because it's not exactly true at the moment, for example #112). As someone who has actually tried writing a small GUI toolkit in the past, I clearly don't want to reproduce this experience (at least not with my current level of knowledge). The Electron/Flutter/similar solution seduces me. It would also immediately make a lot of existing applications compatible with redshirt. The problem, as mentioned, is to get them to compile for Wasi. Both Electron/Chromium and Flutter are very black box-y to non-Google employees (like most Google products are). Trying to make them compile would probably lead to a lot of pain and suffering, and in case of success this would probably require a lot of work to keep up with the code updates. I might be wrong, but that's what my intuition tells me. Servo seduces me more, the major problem being the necessary OpenGL support. |
Beta Was this translation helpful? Give feedback.
-
Just an idea, but seems like an interesting idea to use Electron as the desktop shell. The desktop system like panels can all just be a wasm modules too. You could even have the possibility of having the OS cache multiple major versions of Electron to keep backwards compatibility with wasm apps (the Electron version defined in a manifest). I know this Redshirt project is really early, but could this be a possible direction for a shell? If so, I'm willing to put some time into helping.
Beta Was this translation helpful? Give feedback.
All reactions