Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Desktop shell - Electron #194

Closed
jadbox opened this issue Jan 6, 2020 · 6 comments
Closed

Desktop shell - Electron #194

jadbox opened this issue Jan 6, 2020 · 6 comments

Comments

@jadbox
Copy link

jadbox commented Jan 6, 2020

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.

@Admicos
Copy link

Admicos commented Jan 6, 2020

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

@olanod
Copy link

olanod commented Jan 6, 2020

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

@lukesutton
Copy link

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.

@jadbox
Copy link
Author

jadbox commented Jan 8, 2020

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

@sr229
Copy link

sr229 commented Mar 23, 2020

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

@tomaka
Copy link
Owner

tomaka commented Apr 28, 2020

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).
Assuming we get it to run, there shouldn't be any issue with running Electron or anything similar on ring 0.

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.

@tomaka tomaka closed this as completed Feb 6, 2021
Repository owner locked and limited conversation to collaborators Feb 6, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants