Igalia Blogs

> because those standardized APIs will stay with us for much longer than they will be useful, wasting everyone's time.

Oh wow. You just described the existing imperative DOM APIs, haven't you? Inflexible implementation wasting everyone's time. When is the last time you used actual DOM APIs? The story of web development has been: "JFC, these things are impossible to work with, let's waste time creating actual useful abstractions on top of them".

> it's a popular concept with good library implementations. We don't need to reimplement it in all major browsers because we already have it working well.

You know what one of the goals of jQuery was? To become a disappearing library. As browser APIs got better and better, the need for jQuery would diminish and it would disappear, becoming just a browser API.

Why would browsers implement querySelector and querySelectorAll? We already had it in jQuery and it was working well.

Why would browsers implement fetch? We already had jQuery.ajax, axios, superfetch and dozens of others, and they were working well.

Why would browsers implement <insert any improvement>? We already have <insert doezns of libraries> and they are working well.

> it is easier to build one library than implement the same spec in all major browsers.

It doesn't mean we should freeze the spec in the same state it was in 1998.

> The concepts of Components, State, Context, Thunks, Fibers, Plugins, etc. are very important differentiators between various virtual…

> There a multiple compositors (GNOME, KDE, Weston, Sway, etc) implementing the protocol differently.

Genuine question. How can I run a mixed environment, then? I can mix and match Qt and GTK apps without any thought in X, and furthermore, I can run Metacity with Plasma, or KWin with one or more gnome-panel instances. (If the processes are still named like that... it's been a while, heh.) Yes, in practice, I will admit I wouldn't probably do that, but the kind of flexibility - that expansive upper bound - is what lets me also go to the other end of the extreme and set up a lightweight environment that does function exactly the way I'd like it to.

I'm a bit scared of "implementing the protocol differently." Meep. How differently? After having read a bit, I see that Wayland is standardized, but still - how well will things interact, in the worst case scenario? With X, it's "...ooookay, so my dock has decided to acquire a titlebar, and I can resize and move it around the screen. This is... nice?" - but with Wayland, would things not appear on the screen at all, for example, or would my session [choices] be genuinely unusable [together] at all?

> Sticking to broken old standards is not going to be the solution. We have to move forward. There are many embarrassing things in X11 -- Wayland gives us an opportunity to start from scratch.

Pragmatically - not nostalgically speaking - I do completely agree.

I actually just stumbled on…

I've been tracking this for awhile and the Raspberry Pi 4 has come a long way since the first triangle!

Jan 31st, 2020 First Triangle - https://www.raspberrypi.com/news/vulkan-raspberry-pi-first-triangle/

Jun 9th, 2020 Vulkan Youtube Demos From Mike Hooper - https://www.youtube.com/watch?v=ygBB3D5vryw

Jun 9th, 2020 Progress Report 2 - https://www.raspberrypi.com/news/vulkan-update-now-with-added-source-code/

Nov 24th, 2020 Vulkan 1 Conformance - https://www.raspberrypi.com/news/vulkan-update-were-conformant/

August 10, 2021 Nearing Vulkan 1.1 conformance - https://blogs.igalia.com/itoral/2021/08/10/an-update-on-feature-progress-for-v3dv/

Oct 26th, 2021 Vulkan 1.1 conformance - https://www.raspberrypi.com/news/vulkan-update-version-1-1-conformance-for-raspberry-pi-4/
Vulkan 1.2 conformance

Aug 1st 2022 Vulkan 1.2 conformance - https://www.raspberrypi.com/news/vulkan-update-version-1-2-conformance-for-raspberry-pi-4/

Lets see if we can hit Vulkan 1.3 conformance next!

The CEO said

> It's 3M+ lines of code across thousands of files. The rendering engine is from-scratch in Rust with HTML parsing, CSS cascade, layout, text shaping, paint, and a custom JS VM.

"From scratch" sounds very impressive. "custom JS VM" is as well. So let's take a look at the dependencies [1], where we find

- html5ever

- cssparser

- rquickjs

That's just servo [2], a Rust based browser initially built by Mozilla (and now maintained by Igalia [3]) but with extra steps. So this supposed "from scratch" browser is just calling out to code written by humans. And after all that it doesn't even compile! It's just plain slop.

[1] - https://github.com/wilsonzlin/fastrender/blob/main/Cargo.toml

[2] - https://github.com/servo/servo

[3] - https://blogs.igalia.com/mrego/servo-2025-stats/

Servo is heavily sponsored by Igalia these days, who pay several full-time developers to work on the project.

https://servo.org/blog/2025/01/31/servo-in-2024/ shows that 26% of the PRs in 2024 were made by Igalia.

Here's a good post explaining the relationship in more detail: https://blogs.igalia.com/mrego/servo-revival-2023-2024/

It says "Things changed in 2023, when Igalia got external funding to work on Servo and get the project moving again" but doesn't name the source of the funding. It might be the NLnet Foundation - https://nlnet.nl/project/Servo/ - but I couldn't find information on the amount of that grant.

https://nlnet.nl/project/Servo/

So much interesting stuff happening in userspace networking these days. It really feels like the pieces are almost there to treat the network as just another part of the stack that you're programming. (Albeit a pretty low-level part!)

If you're interested in Google Snap, you might also want to take a look at Snabb [0], and Rush (Snabb in Rust) [1].

For an example of how this stuff is useful at sub-Google scale, we just open-sourced the Rush-based tools we use to test our WebRTC code [2]

[0] https://blogs.igalia.com/dpino/2017/11/13/snabb-network-toolkit/

[1] https://github.com/eugeneia/rush

[2] https://github.com/daily-co/synthetic-network