5 ms·

> I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Web techn

> I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Web technologies are fine, but what we really need is some kind of lightweight browser which allows you to use HTML/CSS/JS, but with far lower memory usage. I found https://ultralig.ht/ https://ultralig.ht/ which seems to be exactly what I am looking for, but the license is a major turn off for most paid services. It makes sense for smaller, indie projects to adopt it, but I haven't seen many "desktop apps" using this in the wild.

winter_blue 3y ago
What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an elegant way). Ultralight (https://ultralig.ht/ https://ultralig.ht/) looks pretty cool. I think another possible option is Servo (https://github.com/servo/servo https://github.com/servo/servo) – it was abandoned by Mozilla along with Rust during their layoffs a while back (but the project still seems to have a decent bit of activity). It would be great if some group of devs could revive the project, or a company could fund such a revival. Eventually, we'll need to reflect on, and explore whether HTML+CSS is really the best way to do layout, and we could maybe perhaps consider porting the Android/iOS layout approach over to desktop. Maybe WPF/GTk/Qt/etc even got things right, and HTML+CSS isn't the best way to do layout.
- rhaway84773 3y ago
  We already know HTML/CSS are not the best way to do layout. We already have many desktop based UI frameworks to create cross platform desktop apps. GTK, QT, etc which are also superior to the single app, limited size focused Android/iOS UI frameworks. More importantly, unlike iOS/Android, they’re even cross platform. HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS which was the original lingua franca of the web, and there are tons of libraries, frameworks, tools, components, etc available in the HTML/CSS/JS world that makes development easier and quicker.
  - whilenot-dev 3y ago
    > HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS The actual reason is a different one IMHO. The implementation of web standards enabled cross-platform engines that provide every UI customization one could possibly need for a SaaS product. This decision included many benefits for businesses and developers alike, such as: - User data stays in the walled garden - Users most probably already have a web-browser installed - Responsibility to keep the runtime (web-browser) up-to-date is on the user side - Automated updates (POV user) - No installation instructions I think it as much as a business decision as it was the decision from developers to bet on HTML/CSS/JS instead of GTK, QT, etc.
- satvikpendem 3y ago
  Flutter does something like this, rendering on a canvas directly and eschewing HTML, CSS and JS altogether. It works pretty well. With WASM in the future though I suspect many other languages will adopt a similar paradigm.
- yencabulator 3y ago
  > directly controlling the DOM from the host language I think your path to this future is getting a DOM API specced for WASM (as in, not going via a Javascript bridge). WASI might help. If and when that happens, then you can repurpose that same API without necessarily needing to compile to WASM. The biggest hurdle is that the current DOM API is a Javascript API, not an API describing e.g. memory layouts.
satvikpendem 3y ago
Tauri is somewhat similar to this, it's much lighter weight than Electron.

winter_blue 3y ago

What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an elegant way). Ultralight (https://ultralig.ht/ https://ultralig.ht/) looks pretty cool. I think another possible option is Servo (https://github.com/servo/servo https://github.com/servo/servo) – it was abandoned by Mozilla along with Rust during their layoffs a while back (but the project still seems to have a decent bit of activity). It would be great if some group of devs could revive the project, or a company could fund such a revival. Eventually, we'll need to reflect on, and explore whether HTML+CSS is really the best way to do layout, and we could maybe perhaps consider porting the Android/iOS layout approach over to desktop. Maybe WPF/GTk/Qt/etc even got things right, and HTML+CSS isn't the best way to do layout.

rhaway84773 3y ago
We already know HTML/CSS are not the best way to do layout. We already have many desktop based UI frameworks to create cross platform desktop apps. GTK, QT, etc which are also superior to the single app, limited size focused Android/iOS UI frameworks. More importantly, unlike iOS/Android, they’re even cross platform. HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS which was the original lingua franca of the web, and there are tons of libraries, frameworks, tools, components, etc available in the HTML/CSS/JS world that makes development easier and quicker.
- whilenot-dev 3y ago
  > HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS The actual reason is a different one IMHO. The implementation of web standards enabled cross-platform engines that provide every UI customization one could possibly need for a SaaS product. This decision included many benefits for businesses and developers alike, such as: - User data stays in the walled garden - Users most probably already have a web-browser installed - Responsibility to keep the runtime (web-browser) up-to-date is on the user side - Automated updates (POV user) - No installation instructions I think it as much as a business decision as it was the decision from developers to bet on HTML/CSS/JS instead of GTK, QT, etc.
satvikpendem 3y ago
Flutter does something like this, rendering on a canvas directly and eschewing HTML, CSS and JS altogether. It works pretty well. With WASM in the future though I suspect many other languages will adopt a similar paradigm.
yencabulator 3y ago
> directly controlling the DOM from the host language I think your path to this future is getting a DOM API specced for WASM (as in, not going via a Javascript bridge). WASI might help. If and when that happens, then you can repurpose that same API without necessarily needing to compile to WASM. The biggest hurdle is that the current DOM API is a Javascript API, not an API describing e.g. memory layouts.

satvikpendem 3y ago

Tauri is somewhat similar to this, it's much lighter weight than Electron.