I'm convinced that using an embedded browser engine to render app UI is the future. Browser rendering engines are so powerful and versatile and universal I don't see how they can lose.
"But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. 2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly.
I'm excited for the new crop of browser engines because they could fix those deficiencies, opening up browser tech to app developers without hugely compromising the experience.
I am not excited, because HTML is not a great UI framework at all.
It just happens to be the most widespread by accident, because hyperlinked documents - HTML - became huge and then more and more UI elements were bolted on top of it. And suddenly it became the goto, because the plattform run everywhere.
But it is still a ugly mess underneath and you might be right, that it is the future, but it is not a great one. I hope a great one will surface one day and then we can start new with something sane.
"I'm excited for the new crop of browser engines because they could fix those deficiencies"
And I cannot see what fixing those deficiencies could mean other, than throwing most of the standard away. It doesn't mean all of it needs to be thrown away. WebAudio API, WebGPU, etc. all became great standards. But simple UI elements, like a slider or color picker are still just ugly and impossible to make beautiful and behave sane, besides making a new one by hand, or using a libary from someone who did that. But - with WebGPU especially - I am excited for the possibility to build a sane framework on top of some subsets of the browsers capabilities.
> But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. 2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly.
In my observation, Electron's deficiencies go beyond these two. One glaring issue is the UX not conforming to the native OS guidelines/conventions, including things like keyboard based navigation and OS feature integration.
Give me a native app and an Electron (or similar app, including the abominations that are Catalyst apps on macOS), and I'll choose native apps every time.
The Bloomberg Terminal is rendered using Chromium and has been for many years. You don’t need to wait for new browser engines to use the existing ones, but you do need resources to contribute, maintain, bugfix, etc. because there is no such thing as a free lunch.
> I'm convinced that using an embedded browser engine to render app UI is the future.
I think Facebook had the same thoughts at some point and they invested heavily in web tech. Later when that backfired (because of performance issues) they started the React Native project.
The studio is made using their own GUI library and its sleek af. Not even QT holds a candle to it. Would have been nice to have such a project in the open source world.
> Browser rendering engines are so powerful and versatile and universal I don't see how they can lose.
Well browsers are pretty damn heavy for an app that won't use 99% of its functionality. Maybe some of this can be amortized with clever distro work so apps don't have to ship the whole runtime but that hasn't happened yet.
(In fact, it's a little odd to me electron is based on chrome rather than the WebKit that actually ships with macos.... you should be able to ship that sort of app with a few megabytes)
I'd also rather eat glass than be stuck with javascript, easily the most frustrating ecosystem I've ever worked with by a very wide margin. Just the language is ok, but the build pipelines/bundling/transpilation/polyfillls is absolutely miserable to work with and lack of a decent standard library really hurts. It's crazy how we've basically lifted up the concepts of compilation and linking c objects to the world of javascript, just to ship code in a language the browser already fully supports.
Maybe WASM will help but my understanding its use of the DOM is quite awkward and still requires javascript usage.
Sadly it doesn’t change the memory usage much so the technology is still inherently wasteful, but on a certain level it feels like a lost battle - because web technologies often feel like the choice of least resistance when you want GUI software that will run on a bunch of platforms while not being annoying to develop (from the perspective of your run of the mill dev).
>"But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk.
Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget).
>2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly.
I think Servo's killer application would be a mobile-first browser for postmarketOS/Mobian/other mobile Linux distros. It's a weird vacuum because Firefox has its Android port, but when you run Firefox on small linux (touch)screen, the experience is very suboptimal. I'd call it unbearable if it wasn't for bunch of tweaks in form of https://gitlab.postmarketos.org/postmarketOS/mobile-config-f...
Chrome is no better, as it has a very weird hardcoded minimum window width of 500px.
I've long thought its killer feature would be embeddable cross-platform UI and native-wrapped web apps like Electron and Capacitor. For these cases it doesn't need to render the entire public web, but the subset used by the application developers. It's a much more tractable problem.
Chrome had a project a long time ago called Razor whose goal was to make a 120fps streamlined subset of the web platform for those types of use cases. They tried to throw away warts of the web that slowed down parsing and rendering like quirks modes, floats, negative margins, infinite entity expansion, element adoption, and probably most built-in elements, leaving a few core built-ins and custom elements.
Razor apps could have run on the web, and in a Razor runtime. Unfortunately, IMO, they kept removing things until they removed the document, and swapped in Dart for JS and the project became Flutter which is not very web-like at all.
I thought Razor was a neat idea, and Servo could really fill that space well.
The minimum window width is a funny thing, Chrome has been steadily raising the minimum every time they make changes to the UI. It used to have a minimum around 320px and now on some configurations it's nearly 800px. There's an old open bug about it where people periodically comment to complain that it was raised again.
One interesting thing covered in the Ladybird monthly update videos, is that most of the web platform tests are text encoding tests for Asian languages.
If you remove them, Ladybird is closer to 60% and Servo to 50%.
Still good, and the point still stands that they are making amazing progress. But probably more accurate because that last 10%-20% are going to get harder to chip away at.
Be careful you don’t mistake that for web standards compatibility.
There are many tests in there for non-standard Blink-only APIs that Google implemented unilaterally, which both Mozilla and Apple rejected on security and privacy grounds.
For instance WebUSB accounts for 845 tests, and WebNFC accounts for 173 tests. Neither of these are web standards, they are Blink-only Google APIs.
Idiot here:
How long will it approximately take until we see a real Ladybird or Servo browser in production, that is actually usable and e.g. has addons?
Like, will it be 6-12 months, or more like 2-3 years?
These are interesting stats, but it makes me wonder what those tests exactly are. Are there 3.18% of tests that no browser passes? How applicable are most of these tests to real world websites?
If servo (or something like it) succeeds, would that mean potentially being able to swap out chromium in Electron? Would that help with performance / application size?
Long ago it was a goal of Servo to adhere to the Chromium embedding framework, and differentiate itself from Gecko by having a good embedding story. I'm unclear whether that is still a goal of the modern project, however.
I would guess so. Their blog also has a big gap between 2020 [1] (when the Servo team was laid off from Mozilla) and 2023 [2] when they found new funding and restarted development, with nothing else posted in between.
Wondering how useful this would be for the agentic workflows that need browsing. The open deep research tread from yesterday mentioned using a pure text based browser sort of thing to quickly get info.
I have to imagine that the vast majority of those workflows are going to want to blend into real traffic as much as possible, which just means driving Chrome
That's great news! I thought the project had died and that this meant that V8 was the only serious JavaScript engine for the future.
For those who don't know: "Servo is a web browser rendering engine written in Rust, with WebGL and WebGPU support, and adaptable to desktop, mobile, and embedded applications."
[+] [-] infogulch|1 year ago|reply
"But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. 2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly.
I'm excited for the new crop of browser engines because they could fix those deficiencies, opening up browser tech to app developers without hugely compromising the experience.
[+] [-] lukan|1 year ago|reply
It just happens to be the most widespread by accident, because hyperlinked documents - HTML - became huge and then more and more UI elements were bolted on top of it. And suddenly it became the goto, because the plattform run everywhere.
But it is still a ugly mess underneath and you might be right, that it is the future, but it is not a great one. I hope a great one will surface one day and then we can start new with something sane.
"I'm excited for the new crop of browser engines because they could fix those deficiencies"
And I cannot see what fixing those deficiencies could mean other, than throwing most of the standard away. It doesn't mean all of it needs to be thrown away. WebAudio API, WebGPU, etc. all became great standards. But simple UI elements, like a slider or color picker are still just ugly and impossible to make beautiful and behave sane, besides making a new one by hand, or using a libary from someone who did that. But - with WebGPU especially - I am excited for the possibility to build a sane framework on top of some subsets of the browsers capabilities.
[+] [-] AnonC|1 year ago|reply
In my observation, Electron's deficiencies go beyond these two. One glaring issue is the UX not conforming to the native OS guidelines/conventions, including things like keyboard based navigation and OS feature integration.
Give me a native app and an Electron (or similar app, including the abominations that are Catalyst apps on macOS), and I'll choose native apps every time.
[+] [-] diath|1 year ago|reply
[+] [-] apaprocki|1 year ago|reply
[+] [-] petabyt|1 year ago|reply
I think Facebook had the same thoughts at some point and they invested heavily in web tech. Later when that backfired (because of performance issues) they started the React Native project.
[+] [-] weinzierl|1 year ago|reply
I wish we'd get direct DOM access from WASM anytime but I have little hope.
[+] [-] cakealert|1 year ago|reply
NoesisGUI: https://www.noesisengine.com/xamltoy/0e2a866b60bc2b9a724b4c6...
And it even has a studio for paying clients which makes designing a GUI trivial. https://www.noesisengine.com/studio/
The studio is made using their own GUI library and its sleek af. Not even QT holds a candle to it. Would have been nice to have such a project in the open source world.
[+] [-] taurknaut|1 year ago|reply
Well browsers are pretty damn heavy for an app that won't use 99% of its functionality. Maybe some of this can be amortized with clever distro work so apps don't have to ship the whole runtime but that hasn't happened yet.
(In fact, it's a little odd to me electron is based on chrome rather than the WebKit that actually ships with macos.... you should be able to ship that sort of app with a few megabytes)
I'd also rather eat glass than be stuck with javascript, easily the most frustrating ecosystem I've ever worked with by a very wide margin. Just the language is ok, but the build pipelines/bundling/transpilation/polyfillls is absolutely miserable to work with and lack of a decent standard library really hurts. It's crazy how we've basically lifted up the concepts of compilation and linking c objects to the world of javascript, just to ship code in a language the browser already fully supports.
Maybe WASM will help but my understanding its use of the DOM is quite awkward and still requires javascript usage.
[+] [-] horsawlarway|1 year ago|reply
Huge number of Enterprise/productivity apps are shipped on Electron.
It's hard to beat the value proposition on the business side if you need a website for the product.
[+] [-] cyberax|1 year ago|reply
Sciter exists: https://sciter.com/
And it indeed is great for UI.
[+] [-] KronisLV|1 year ago|reply
Wails does that: https://wails.io/
Tauri also does that: https://tauri.app/
That does help with the app sizes quite a bit: https://github.com/Elanis/web-to-desktop-framework-compariso...
Sadly it doesn’t change the memory usage much so the technology is still inherently wasteful, but on a certain level it feels like a lost battle - because web technologies often feel like the choice of least resistance when you want GUI software that will run on a bunch of platforms while not being annoying to develop (from the perspective of your run of the mill dev).
[+] [-] coldtea|1 year ago|reply
Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget).
>2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly.
Huh?
[+] [-] rayiner|1 year ago|reply
[+] [-] nicoburns|1 year ago|reply
By this, do you mean something like a C/C++/Rust API to the DOM?
[+] [-] swoorup|1 year ago|reply
[+] [-] amelius|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] tonyhart7|1 year ago|reply
[+] [-] esad|1 year ago|reply
Chrome is no better, as it has a very weird hardcoded minimum window width of 500px.
[+] [-] spankalee|1 year ago|reply
Chrome had a project a long time ago called Razor whose goal was to make a 120fps streamlined subset of the web platform for those types of use cases. They tried to throw away warts of the web that slowed down parsing and rendering like quirks modes, floats, negative margins, infinite entity expansion, element adoption, and probably most built-in elements, leaving a few core built-ins and custom elements.
Razor apps could have run on the web, and in a Razor runtime. Unfortunately, IMO, they kept removing things until they removed the document, and swapped in Dart for JS and the project became Flutter which is not very web-like at all.
I thought Razor was a neat idea, and Servo could really fill that space well.
[+] [-] kevingadd|1 year ago|reply
[+] [-] fabrice_d|1 year ago|reply
[+] [-] pipeline_peak|1 year ago|reply
Are you suggesting that such an app would get people to go out of their way and use mobile Linux?
[+] [-] PartiallyTyped|1 year ago|reply
[+] [-] culi|1 year ago|reply
If you didn't know you could see the massive progress both projects have made in web compatibility here: https://wpt.fyi/results/?label=master&product=chrome&product...
As of today, browsers pass this percent of tests:
[+] [-] materielle|1 year ago|reply
If you remove them, Ladybird is closer to 60% and Servo to 50%.
Still good, and the point still stands that they are making amazing progress. But probably more accurate because that last 10%-20% are going to get harder to chip away at.
[+] [-] JimDabell|1 year ago|reply
There are many tests in there for non-standard Blink-only APIs that Google implemented unilaterally, which both Mozilla and Apple rejected on security and privacy grounds.
For instance WebUSB accounts for 845 tests, and WebNFC accounts for 173 tests. Neither of these are web standards, they are Blink-only Google APIs.
[+] [-] upcoming-sesame|1 year ago|reply
[+] [-] wobfan|1 year ago|reply
Like, will it be 6-12 months, or more like 2-3 years?
[+] [-] a-dub|1 year ago|reply
[+] [-] yonatan8070|1 year ago|reply
[+] [-] wiz21c|1 year ago|reply
[+] [-] polyaniline|1 year ago|reply
[+] [-] jillesvangurp|1 year ago|reply
[+] [-] pera|1 year ago|reply
[+] [-] dblohm7|1 year ago|reply
[+] [-] monroewalker|1 year ago|reply
[+] [-] kibwen|1 year ago|reply
[+] [-] ramon156|1 year ago|reply
[+] [-] pilaf|1 year ago|reply
1: https://servo.org/blog/2020/11/17/servo-home/
2: https://servo.org/blog/2023/01/16/servo-2023/
[+] [-] Tsarp|1 year ago|reply
[+] [-] infogulch|1 year ago|reply
Show HN: Lightpanda, an open-source headless browser in Zig | 318 points | 11 days ago | 137 comments | https://news.ycombinator.com/item?id=42817439
[+] [-] petesergeant|1 year ago|reply
[+] [-] PartiallyTyped|1 year ago|reply
[+] [-] kuringganteng|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] 6451937099|1 year ago|reply
[deleted]
[+] [-] qwertox|1 year ago|reply
For those who don't know: "Servo is a web browser rendering engine written in Rust, with WebGL and WebGPU support, and adaptable to desktop, mobile, and embedded applications."
[+] [-] vanderZwan|1 year ago|reply
Either way I'm glad that there's a challenge to the browser monopoly and its various technical components of course.