Servo's progress in 2024
servo.org
servo.org
"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.
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.
* MAUI: Windows, macOS, Android, iOS.
* Avalonia: Windows, Linux, macOS, Android, iOS, browsers.
Personally - I collect quite a few for different things. I almost always have at least chrome, firefox, ungoogled-chromium, and - recently - ladybird installed.
Not to mention a couple different chromium versions for various electron apps (slack, discord, etcher, bitwarden, vscode, postman, etc).
Different browsers do different things well, and electron does the "desktop app" niche better than the others right now. In the same way that ladybird does the "not tracked by corporations" part, and firefox does the "still supports manifest v2 extensions" part.
You can complain all you'd like (and I recognize you from other places hating on electron) and it's fine, but it doesn't change incentive structures for the folks deploying these, and as a full time linux user... I am SO fucking happy to have all the BS apps my company requires "just work" on my computers because of electron.
If you don't want to use software developed with Electron... more power to ya. Go make that choice. Leave the rest of us out of it.
From my side... it'd be great if we can make electron suck less (and trust me, I definitely agree that we can), but right now... it's still a pretty huge win.
Everything else, if there is a Web app, then I use the browser, no need to ship it alongside every single application out there.
It is like those garbage mobile apps, that are exactly the same website that I can access via the Webbrowser, packaged inside a "native" app.
And I say this as someone that works primarly in distributed systems and Web.
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).
Interesting resource, thanks!
Was not expecting the start up values for Tauri, they're abysmal ._. Welp, at least the executables are small.
It's not just how things look, though, there are a ton of differences between browsers in terms of how things behave, too.
- Blink for Windows/Qt hosts.
- WebKit for macOS/GTK hosts.
I remember when web developers actually gave a damn. Just call yourselves Chrome developers because that's what you are now.
Like frontend developers do all the time? Why would this be an issue for apps but not on web? Reminds me of the old ”our website works best in Internet Explorer” banners.
The webviews on windows, Linux (gtk) macOS, iOS, Android all support modern CSS and are basically identical. Speaking from experience.
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.
By this, do you mean something like a C/C++/Rust API to the DOM?
It's incredible what can be done but can be far less responsive than the scaleform it replaces, but this may partially be due to it being a third party mod to the game.
Sciter exists: https://sciter.com/
And it indeed is great for UI.
A company that I'm advising is using it for their industrial IoT control dashboards, and it's great for that purpose.
oh neat, I like learning about “secret weapons” like lisp/erlang
> for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others.
I saw that sentence ending differently in my head...
It just doesn’t seem like a very strong claim, that all these products which don’t really hinge on having great (or even good) UIs consider Sciter to be their secret weapon.
A comparable ecosystem is QML in QT, but Sciter is an order of magnitude leaner and faster.
My friends are using it for an industrial controller that can boot in half a second after a power outage.
I'm not saying that QML is bad, it just is much more massive.
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?
There are legacy parts of browser layout that make it impossible(?) to optimize some rendering while being standards compatible. If you just chose a subset that is fast to implement and focused on being subset you narrow the scope of the project and enable optimizations.
Electron has to implement everything chrome has to support even though the apps running in it will never touch it.
Also web engines have to be heavily sandboxed because you cannot allow internet code break out of the sandbox.
Native apps shipped with electron already ship Node and just waste resources sandboxing stuff with security layers.
Embedded browser engines though are either wrappers for Webkit and Blink (thus also including the "legacy parts of browser layout that make it impossible(?) to optimize some rendering") OR simplistic web rendering engines that are not as capable as Chrome/Webkit for layout and not compatible with all modern CSS/HTML features.
Does your desktop app need a gyro, webrtc and gamepad support? But they're loaded anyway.
I doubt those impose very much (if any) overhead for just being present but unused. In any case, those aren't the things that the OP was talking about; there are plenty of layout-related standards like floats that are almost never used in modern web apps yet inhibit or prevent many optimizations that could potentially significantly increase rendering performance. For a more extreme example, imagine how much faster layout rendering could be if you removed all types of layout other than grid—you'd be able to remove a bunch of checks and all the code that handles edge cases, significantly simplifying the happy path.
Nobody (to my knowledge) has done this because it's not as simple as forking Chromium and removing code. Without the mentioned optimizations, I don't think you'd see much benefit.
I wish we'd get direct DOM access from WASM anytime but I have little hope.
Surely it would be nice, but it's not a real deal breaker
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.
I think that an embedded web rendering strategy for UI within the context of a framework that provides other native interfaces may indeed become a bigger thing
We also know it’s not a case of just Apples native tech being better because MacOS has truly lost to webtech, hard to even name an app built in the last 5-10 years by a 3rd party in Apples own tech. Everything is just Electron or cross frameworks.
Personally I love truly native Mac apps but it’s certainly clear no one else cares and electron is enough.
https://developer.apple.com/support/alternative-browser-engi...
(except through the, purposefully onerous, EU alternative regulations. Which apple charges apps a per-install fee for. Normal apps can only use Webkit, without any plugins or changes)
Was 5-10 years ago was the last time you used MacOS? Or do I live in a bubble? Because your statement sits opposite of my perception of things. Maybe I don't use enough apps to say for sure. I don't use most of these, but here are some that I can think of off-hand. You can tell me if these are too old, some of them may be I don't know.
Starting with ones recently seen on HN:
- pISSStream
- Ice
- Ghostty
- Stats
- NetNewsWire
- Wealthfolio
- Orion Browser
- Iina
- Dato, Velja + most others from Sindre Sorhus
- Proxyman
- Transmission
- SwiftBar
- AppLite
- MonitorControl
- BetterDisplay
- Maccy
- CodeEdit
- Does HandBrake count?
- Zed?
There's also a number of sites/lists dedicated to these types of apps. Sometimes it feels like there are too many apps even.
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.
How do people imagine rendering is implemented in browsers to begin with?
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.
Anyways, to each their own.
If you give me an example use case, I would be able to tell you what I would use, however.
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.
Chrome is no better, as it has a very weird hardcoded minimum window width of 500px.
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.
I heard the YouTube team did something similar for their embedded / resource-constrained environments where the client just renders barebones HTML/JS and only what is needed is implemented in the engine.
That's also an unfortunate story, because they've really lagged on adding features in the past because they generally have no way to update the engine on TVs. So any new feature would take 5-10 years to be usable.
So almost 10 years ago they didn't invest in some core things like web components, and they could have used them by now if they did.
It’s surprising how similar to HTML it’s becoming. I feel like it's sorta an inverse of the Flutter story. Lately I’m working on adding a subset of CSS. Adding padding and margins too seems like a good idea too, etc. Part of me wonders how much of a webpage I could render with it.
And if you do it well enough as a subset it can become the next standard where the modern web is just the subset, you can even integrate it with a legacy render where you fall back to legacy when you detect you cant handle it, and have the fast path for the subset.
And another (mature but proprietary): https://sciter.com/
Are you suggesting that such an app would get people to go out of their way and use mobile Linux?
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:
Chrome: 96.82%
Firefox: 95.41%
Safari: 94.97%
Ladybird: 89.30%
Servo: 78.61%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.
There are tons of other examples of these easy points in the test suite. Ofc text encoding tests are important if we want the internet to truly be global
I guess these percentages are kinda useless by themselves but still useful to track progress when you put them together in a historical graph
https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)
Also there are new tests being added all the time
I was entirely unaware that both Chrome and Safari can trace their roots back to KDE of all projects. I always just assumed big corpos like Google and Apple would just roll their own from scratch.
seems it was a quite complicated matter that included clashes between open source and commercial concerns.
https://web.archive.org/web/20090210230809/http://www.kdedev...
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.
> Status of This Document
> This specification was published by the . It is not a W3C Standard nor is it on the W3C Standards Track.
— https://w3c.github.io/web-nfc/
> We oppose this feature and will not implement it.
> We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification. In addition, we think exposing direct hardware access to the web is a bad idea and compromises the device-independence of the web platform.
— https://lists.webkit.org/pipermail/webkit-dev/2020-January/0...
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
— https://mozilla.github.io/standards-positions/#web-nfc
WebUSB:
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/webusb/
> WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.
— https://github.com/WebKit/standards-positions/issues/68
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
As well as browsers supporting features not endorsed by whatwg, there are plenty of features that they have endorsed that browser vendors didn't bother with.
Yes, the web is a standard platform, Blink is not. Google can’t just spit out any old privacy-violating, insecure garbage specification and call it a web standard just because it’s what they want to build. Google don’t unilaterally decide what the web is.
> there are plenty of features that they have endorsed that browser vendors didn't bother with.
Something can’t become a web standard unless there are two independent implementations. It’s part of the standardisation process. It also disqualifies things like Web NFC and WebUSB from being web standards because Google couldn’t convince anybody outside of Google to implement them.
> Google don’t unilaterally decide what the web is.
They absolutely do.
If something doesn’t work in Safari or Firefox then web developers normally still hold back, so they aren’t de facto standards. We aren’t quite at the point we were when IE dominated the web. But there is a growing number of developers who blame other rendering engines for not blindly going along with whatever Google says, and that needs to be stopped in its tracks not accepted.
It takes just a few weeks on hn to see it's not true and there are a few devs who will point to the usage stats and not care about Firefox. For safari, many people just don't have access to it, so they'll never test in the first place.
I believe the article makes clear that they have.
>Servo main dependencies (SpiderMonkey, Stylo and WebRender) have been upgraded
There’s simply more C++ programmers around, and you need as many bodies as possible for such a large project. There’s also precious few Rust developers with experience with large projects since Servo is the largest project.
Like, will it be 6-12 months, or more like 2-3 years?
IIRC purpose of Servo when it was Mozilla project was:
- Develop large scale project in rust to see pain points
- Have a test bed for pieces that would later be integrated in Firefox
In both cases project succeeded: Quantum CSS (Stylo), WebRender, and some smaller components that I don't recall. I don't think there was ever a goal of building a full consumer-grade browser, at least not within Mozilla.
Show HN: Lightpanda, an open-source headless browser in Zig | 318 points | 11 days ago | 137 comments | https://news.ycombinator.com/item?id=42817439
We skip the graphical rendering of the web page for instant startup, fast execution and low resources usage.
from over an our to under 30 minutes.
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."
Either way I'm glad that there's a challenge to the browser monopoly and its various technical components of course.
Even without SpiderMonkey, we'd still have JavascriptCore from Safari and LibJS from Ladybird.
> 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.
The person you're responding to was basically clarifying what you want to too.
Firefox's SpiderMonkey? Webkit's JSC?