Skip to content

2025 Chromium Embedding: Experiences and challenges

Jump to bottom Edit New page
Manuel Rego edited this page Jun 12, 2025 · 1 revision

WEH 2025 - Chromium Embedding: Experiences and challenges

Q&A notes

Electron questions:

  • Do you have a solution for distributed builds?

    • We have a solution that a few contributor are allowed to use. It was built in around four months after the goma-> reclient migration. It supports Windows, Mac and Linux.

  • What about the Google services that Chromium integrates?

    • Electron strips //chrome which is where most of these integrations exist, we base on the content layer.

  • What kinds of Wayland bugs do you have (mentioned Wayland support in the slides)?

    • They are tagged "wayland" in our bug tracker.

CEF questions:

3-5 days to do an version update on top of the chromium layer! things are much more stable nowadays.

  • sharing instances of chromium, do you think it could increase dependency on MS or Apple?

    • We are looking to have our own install, not provided by MS or Apple. We will start testing it soon and will provide access to everyone later. The plan is not to have platform holder dependency.

  • Q about trust...

    • We don't want everyone building their own version of chromium, but there's obviously going to be some chain of trust involved.

  • 1 day and a half was mentioned as a combined build time for all the CEF platforms. I build WebKit in 15 minutes...

    • Build times got much worse. 90 minutes for a release build.

  • HOw to be productive?

    • We run overnight. I don't do clean builds but once a month, only incremental builds.

  • Electron takes 2 hours to build!

  • Marshall: as an application developer, if there was a shared runtime you could distribute with your application, would you have used or built everything?

    • Two audience members answers positively

  • I have a library that uses cef, I understand it's a bit of a weird situation. I would prefer to build myself.

  • You ship your own webengine and if you dont' ship often, you won't get security updates. If CEF would provide API stability and provide those updates, it would make applications more secure. For me, the only consideration would be performance, how to resolve dinamically the symbols, when you dynlink a big library you load a lot of symbols. Do you know the impact of loading time vs linking statically.

    • It depends a lot on the disk, a spinning disk you will have problems. In Windows there's the capability to preload a DLL. e.g. Chrome loads a DLL that contains Chromium, that DLL could be preloaded. An entry-level machine, eight-core intel laptop, loading a dll is 20% and rest is link, initialization. Snapshots can substantially reduce that. VS code can create them.

  • Support for android, ios

    • Did you see android_desktop on Chromium? If you connect a big screen to an Android device. My main reluctnce is how closed the environment is.

  • I think there's another way to desktop applications bundling chromium, there's isolated web apps, if we were to ship applications as a PWA, and run the backend in ome container that shipped in the same machine (Chrome or some trusted version of Chromium, Edge...)

    • intersting point, i was sad when Google discontinued native extensions, Chromium seems to be leaning in this direction of splitting things and we might be able to have a "chromium kernel" in the future, but it would be much easier to use what they provide.

  • In the case of electron and cef, they target one user process per application and that increases memory use. In LG, we had the WAM that shared the native part out of the browser process. I could imagine an electorn runtime that could have node.js services independenty in a way that could be shared, not only disk space or memory but also rendering resources. It's an idea extending what we did in WAM.

    • It's also a matter of trust, what's in memory and if you trust it or not, that's why google moves to isolatoin so they don't have to trust. e.g. if there's a service rendering my personal data, do I want a random game using it too.

  • Separating browser ui and features, their release cycle from the web engine. that would be interesting. I'm wondering, what you think of using CEF for a full-featured browser, what could be the challenges or limitations?

    • I agree it would be a great end result. Specialty browsers use their own UI with CEF as the render engine and have different cycles. The browser has a lot of behaviors, click, drag, a look and feel in the browser itself, we don't have a way to allow apps to customize this behaviour and look and feel, maybe with the views framework, but it would be hard (didn't register too well)

  • every time we update slack t o a new major version we break something in the app but the browser is much more tolerant. I'm curious if spotify or other apps have the same problem.

    • we have this design for the shared instance, which we will share soon, we also pin versions because of this issue. os changes are a killer too, apple for example doesn't give you much heads-up. A desktop platform has many more rough edges where users can have problems.

https://www.webengineshackfest.org/

Add a custom sidebar
Clone this wiki locally