4 ms·
We already have browsers installed that are designed to render arbitrary cross-platform GUIs based on HTML/CSS. Why can't I write a desktop application that ju
by almostarockstar 7y ago
We already have browsers installed that are designed to render arbitrary cross-platform GUIs based on HTML/CSS.
Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window.
We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist on riding in our own trains.
- monksy 7y agoWhy do I need a browser just to show components on a screen? It's overkill to do that.
- almostarockstar 7y agoI agree, but we're not really talking about simple components on a screen. If that was the case, everybody would be happy to use tcl/tk, or swing or whatever. Plus, it's not overkill when you get the browser for free.
- rkeene2 7y agoWell, I'm happy to use Tcl/Tk -- although using it on a mobile device doesn't result in a usable touch-based interface. Really, that's the crux of the problem is that there are different paradigms that are not just a little bit different but fundamentally different. This is especially annoying on my Chromebook running Android apps -- they very often expect you to be using a touch-based system without a keyboard. The way this works with a docked Chromebook and a mouse is the mouse is treated as a VERY precise finger touch. Additionally, on Android and other touch-based systems you're usually not using a Window Manager so, for example, using an Android mail client on my Chromebook, I can't start the reply in a new window so that I can read the message in one window while simultaneously replying... and I especially can't have a bunch of unfinished replies while reading other emails to gather information for the reply. Creating a meta-layer that can represent the fundamentally different modes from the same data is VERY difficult. HTML and CSS do a terrible job as well unless you model your HTML in a very specific way, which cannot accommodate all GUI semantics.
- monksy 7y agoYou never get the browser for free. It's a heavyweight rendering approach for what you're trying to do.
- simonh 7y agoWith Microsoft embracing Chromium as the built-in Windows rendering engine, enabling multiple Electron apps to run on a single instance, we're moving in the direction of Electron being the standard train your app can live in on any railroad.
- kitsunesoba 7y agoThe most common reason I’ve heard is that devs want to be able to use cutting edge features and the update cycle for OS bundled browsers is too slow to accommodate that. I find this argument a bit silly, because there are few applications that actually need said cutting edge features and even if you’re one of the handful there’s always polyfills, but maybe I’m missing something.
- holy_city 7y ago>Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window. You can: - webview (I mentioned it elsewhere) https://github.com/zserge/webview https://github.com/zserge/webview - sciter https://www.google.com/search?client=firefox-b-1-d&q=sciter https://www.google.com/search?client=firefox-b-1-d&q=sciter - ultralight https://ultralig.ht/ https://ultralig.ht/ Granted it's not "user's preferred browser" but it fits the bill. They all have issues, largely solved by Electron packaging the browser engine with the binary, and even that isn't perfect.
- almostarockstar 7y agoThese go a long way towards what I had in mind. Thanks for posting.
- _bxg1 7y agoThis is a good point. Right now, web UIs on the desktop are effectively living in a world where DLLs were never invented.