4 ms·

> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roa

by leleat 3mo ago

> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just slightly less bad). Or is there still an advantage to a "shared runtime" in that case? [0]: https://docs.deno.com/runtime/desktop/comparison/ https://docs.deno.com/runtime/desktop/comparison/

tonyedgecombe 3mo ago
In case anybody else wondered CEF is the Chromium embedded framework. https://github.com/chromiumembedded/cef https://github.com/chromiumembedded/cef
- echelon 3mo ago
  The biggest weakness of a framework like Tauri is the choice to target system webviews instead of bundling a browser runtime. It seems great to be able to cut hundreds of megabytes out of your app installer, but the platform differences wind up being a complete and ongoing pain in the ass. Tauri support on Windows is phenomenal. Tauri on Mac runs into lots of WebKit/Safari issues, especially on older Mac machines that have an older engine that doesn't support modern web APIs. Your app can crash or be left non-functional. You'll find out about these runtime bugs in the wild randomly, and patching for some customers can take days, if not weeks. Linux support is hellish, and it's best to not even try targeting Linux with Tauri. Tauri is in the process of adding CEF support. It should probably become the default build target for all platforms.
  - oooyay 3mo ago
    I use Wails which is Tauri but for Go and I don't have the kind of issues you're mentioning. Maybe that is a difference between Wails and Tauri but I don't think the system WebView is a significant factor.
    - echelon 3mo ago
      Are any of your Mac users using an 10-year old WebView? We frequently ran into that. And there's nothing that can be done about it except engineering around it. I also doubt it works well on Linux. The performance of webkitgtk is like running an emulator inside an emulator.
      - larrysalibra 3mo ago
        Can you either at build time or runtime specify a minimum macOS version? No one running macOS 26 (for example) is using a 10 year old WebView.
        jcelerier 3mo ago
        But a lot of people are still running macOS < 10.15
  - synchrone 3mo ago
    Regular Tauri app (aptakube) user on linux here: the experience is very adequate and smooth, I have no complaints. Speed benefits relative to Electron (similar app: K8S Lens) alone are enough to deal with many possible issues. Could be attributed to app developers going the extra mile, but I suspect it's the framework choice.
    - moogly 3mo ago
      Targeting and building Tauri apps for Wayland, specifically, is a massive headache due to assorted webkitgtk bundling/incompatibility madness.
  - FooBarWidget 3mo ago
    Web developers already have to deal with different browsers, versions and API coverage.
    - umpalumpaaa 3mo ago
      The beauty of shipping a desktop app would be to not have to deal with that though… also those built in web views are usually older than average.
  - jakelazaroff 3mo ago
    This point of view always confuses me, because web developers already need to deal with platform differences. Especially if your app app also runs in a browser, like Slack and Discord — at that point, what issues do the differing system webviews cause that you don't need to deal with anyway just targeting browsers? It's also funny to me as someone who's been building websites for 20+ years at this point, because the platform differences used to be much, much worse. Coincidentally, I just saw this article, which makes the case nicely: https://www.bram.us/2026/06/21/do-websites-need-to-function-exactly-the-same-on-every-platform/ https://www.bram.us/2026/06/21/do-websites-need-to-function-...
    - c-hendricks 3mo ago
      webkitgtk isn't just quirky, it's also much slower compared to more popular browser engines and is particularly bad with RAM usage.
      - paddy_m 3mo ago
        is webkitgtk different than the engine used in safari?
        c-hendricks 3mo ago
        Not necessarily? As far as I know they come from the same WebKit source. But the bridge between WebKit and the OS is of course specific to each system. WebRTC is still experimental in webkitgtk while caniuse says Safari supported it back in 2017. I remember encountering one bug with Final Form that triggered rarely in Safari, 100% in Webkitgtk, and never in Chromium. Here's the developer of Tauri saying it's hard to recommend webkitgtk / Linux support: > So if you need good linux support now/soon i can't 100% recommend tauri (for Linux) as of now. (I used to be more "forgiving" but with webkitgtk getting worse/more unstable each release i changed my mind) https://github.com/orgs/tauri-apps/discussions/8524#discussioncomment-7993948 https://github.com/orgs/tauri-apps/discussions/8524#discussi...
    - echelon 3mo ago
      > This point of view always confuses me, because web developers already need to deal with platform differences. On Mac, I use Firefox and Chrome. However, if I use a Tauri app on Mac, I have to use dated WebKit. It's out of a Tauri developer's control.
  - v3ss0n 3mo ago
    LOL , then back to electron. I raised that since day one of Tauri.
  - jauntywundrkind 3mo ago
    Tauri's cef-rs is indeed quite good. I think it's available, ready, works: it's just that there aren't many folks using Tauri and only a fraction of them are aware/interested in exploring further. https://github.com/tauri-apps/cef-rs https://github.com/tauri-apps/cef-rs Huge fan, this should definitely be the default. The user experience is incomparable. One thing I'd like to verify: can the OS effectively use shared mem for cef across multiple different cef-rs apps? I really hope so. In this time of RAM being scarce, this optimization could be such a benefit.
  - cdud3 3mo ago
    Or use QtWebEngine which uses Chromium under the hood, provides a stable and rich API and enables sharing rather then bundling the browser runtime + is Cross-Platform + security updates are handled too.
  - DanielHB 3mo ago
    > It seems great to be able to cut hundreds of megabytes out of your app installer Your points are valid, but the big upside is that the default system webview is very likely to already be loaded in memory before your app starts. And if multiple apps use the default system webview all of them will load that same dynamically linked binaries only once. I don think the RAM savings are that significant on modern systems, but it greatly speeds up app first-loading times.
lwansbrough 3mo ago
Web devs are used to their target being evergreen, so I suppose you could opt in or out of that model: "just give me what you got".
- Someone 3mo ago
  > Web devs are used to their target being evergreen I would think/hope web developers are used to “just give me what you got”. Any other mindset leads to “you must install <browser> to see this site”. It’s Electron devs that are used to that.
  - coffeebeqn 3mo ago
    I love how we’re now reinventing the browser as a much worse version of itself. What if instead of one or two general Web browsers we make everyone install 10 random versions that can only open one website?
- lopis 3mo ago
  > Web devs are used to their target being evergreen Since when? The browser landscape is much better today than 10 years ago, but no web dev worth their salt assumes anything about the user agent.
- fwlr 3mo ago
  True for this decade, but in the previous decade it was very much the opposite. Before you used any kind of browser api or nice language feature you would feature-detect it: if (typeof Array.prototype.includes === ‘undefined’) { … And if it wasn’t there you would define it yourself, it was called “polyfilling”. This was so commonplace that we built significant tooling like babel to standardize feature detection tests and fallback implementations - for a few years you could write request.then(response => response.json()) And behind the scenes the Rube Goldberg machine would turn this into something that would run in a JavaScript environment that had neither arrow functions nor promises.
- DanielHB 3mo ago
  Oh god I feel OLD reading this.
hun3 3mo ago
System WebView but Electron is now the system
- actionfromafar 3mo ago
  Ah, that's a new systemd module now.
qbane 3mo ago
I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.
- teaearlgraycold 3mo ago
  People build web apps for an array of browsers and huge ranges of versions. I think if you started using some tech to deploy an end user program and knew from the beginning the browser could be updated beneath you it would work just fine. But if you start with a golden version of Chrome and put off updating for too long you’ve let yourself get too comfortable.
  - troupo 3mo ago
    > People build web apps for an array of browsers and huge ranges of versions. en masse they don't. They just target the latest Chrome
    - teaearlgraycold 3mo ago
      De facto they do because functionality built three years ago and tested then is running along side functionality they built yesterday and tested on today’s Chrome. People also do seem to test on iOS Safari because that pain in my ass needs special care on my software. So if a site works on it they either got lucky or tested on an iPhone. It’s generally only other people’s weird tech demo stuff that doesn’t work.
    - threetonesun 3mo ago
      I agree and disagree, you can't target everything, but most (not shit) devs will target at least Safari - 1 or 2, simply because the iPhone market is too good to miss out on. And Safari being, well, Safari, means targeting that is a pretty safe bet for anything else.
      - Semaphor 3mo ago
Lucasoato 3mo ago
Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed. [0]: https://www.riotgames.com/en/news/architecture-league-client-update https://www.riotgames.com/en/news/architecture-league-client...
- chmod775 3mo ago
  When the new client was built, microservices were the hot new buzzword. The new client is some weird plugins/services based architecture. Things that'd barely warrant their own class in a boring OOP-based UI framework are instead now "isolated" services. The reality of this isolation being that if one piece breaks, the whole UI becomes unusable anyways. Dozens of things that in another app would've been just a simple synchronous call now behave like remote procedure calls and messages, forcing all the complexity of distributed systems into a local application for no reason. That's why it runs like ass, breaks if you look at it wrong, and your CPU draws more power when using the client than when playing the game at 200FPS.
- megacelebi 3mo ago
  This is more a function of how mismanaged the project was at Riot (the iron client days, choosing Ember, etc.) which led to the current state of the launcher.
- gavinray 3mo ago
  CEF is + has been the de-facto standard when you have a native app and want to do a web UI. It's not the only option, but it's the most mature with the largest amount of docs + stack overflow questions, so it's a "safe" choice. If you peek into the native resources files of most games/desktop apps, you'll find a good portion of them bundle + use the CEF dll.
- mannanj 3mo ago
  I regularly install and uninstall the league client on Mac based on how I play that game (require fresh installs to raise the playing cost) and their client really sucks. Even freshly installing it, the client inhibits and hijacks mouse clicks from the full screen game when it's open. It took me months to figure out I would have to minimize the game, open and minimize the client (separate app) open, and then clicks would sometimes properly return. Before that I was closing both and playing a game of roulette. By the the time my game was working, I may have already been reported for being afk and the game ended. Edit: other bugs have included starting to download the game and then signing in afterwards (their UI doesn't stop you) and then download progress disappearing, perhaps hanging, and you having no way to know it for a 40gb file unless over an hour has passed and you check disk size and then realize the client doesn't know how to load it. Start over and do a fresh install again, clear cache etc because their cache of the client still thinks somethings being downloaded even though it's not. Also having chat permanently off, results in weird glitches with friends requests and being unable to add new friends. Horrible experience. But since the game is so optimized for addiction and dark patterns these days, and sunk cost, its a game I find myself returning to every once in a while.
deeringc 3mo ago
I'd prefer if it just used the system webview rather than downloading and managing an embedded browser itself. Webview2 on Windows for example.
- jitl 3mo ago
  > Small by default, full Node compatibility. The default WebView backend uses the operating system's own webview for small binaries
- andrewaylett 3mo ago
  That appears to be the default, CEF is available if required (hint: it shouldn't be).
deleted 3mo ago
[deleted]
kodablah 3mo ago
I used CEF for a project and Google is detecting CEF via some opaque algorithms and not allowing logins from it. From https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html https://security.googleblog.com/2019/04/better-protection-ag...: > Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.
- iancarroll 3mo ago
  Most apps (on desktop or mobile) open third party auth flows inside the user's default browser, which makes this a non-issue. For one, if you embed the Google login flow into your app then I can't reuse my existing session in my browser. But it also exposes my full credentials to your app for no reason, which is a good thing to avoid.
v3ss0n 3mo ago
A strip down version of electron TBH.

by leleat 3mo ago

tonyedgecombe 3mo ago

In case anybody else wondered CEF is the Chromium embedded framework. https://github.com/chromiumembedded/cef https://github.com/chromiumembedded/cef

echelon 3mo ago
The biggest weakness of a framework like Tauri is the choice to target system webviews instead of bundling a browser runtime. It seems great to be able to cut hundreds of megabytes out of your app installer, but the platform differences wind up being a complete and ongoing pain in the ass. Tauri support on Windows is phenomenal. Tauri on Mac runs into lots of WebKit/Safari issues, especially on older Mac machines that have an older engine that doesn't support modern web APIs. Your app can crash or be left non-functional. You'll find out about these runtime bugs in the wild randomly, and patching for some customers can take days, if not weeks. Linux support is hellish, and it's best to not even try targeting Linux with Tauri. Tauri is in the process of adding CEF support. It should probably become the default build target for all platforms.
- oooyay 3mo ago
  I use Wails which is Tauri but for Go and I don't have the kind of issues you're mentioning. Maybe that is a difference between Wails and Tauri but I don't think the system WebView is a significant factor.
  - echelon 3mo ago
    Are any of your Mac users using an 10-year old WebView? We frequently ran into that. And there's nothing that can be done about it except engineering around it. I also doubt it works well on Linux. The performance of webkitgtk is like running an emulator inside an emulator.
    - larrysalibra 3mo ago
      Can you either at build time or runtime specify a minimum macOS version? No one running macOS 26 (for example) is using a 10 year old WebView.
      - jcelerier 3mo ago
        But a lot of people are still running macOS < 10.15
- synchrone 3mo ago
  Regular Tauri app (aptakube) user on linux here: the experience is very adequate and smooth, I have no complaints. Speed benefits relative to Electron (similar app: K8S Lens) alone are enough to deal with many possible issues. Could be attributed to app developers going the extra mile, but I suspect it's the framework choice.
  - moogly 3mo ago
    Targeting and building Tauri apps for Wayland, specifically, is a massive headache due to assorted webkitgtk bundling/incompatibility madness.
- FooBarWidget 3mo ago
  Web developers already have to deal with different browsers, versions and API coverage.
  - umpalumpaaa 3mo ago
    The beauty of shipping a desktop app would be to not have to deal with that though… also those built in web views are usually older than average.
- jakelazaroff 3mo ago
  This point of view always confuses me, because web developers already need to deal with platform differences. Especially if your app app also runs in a browser, like Slack and Discord — at that point, what issues do the differing system webviews cause that you don't need to deal with anyway just targeting browsers? It's also funny to me as someone who's been building websites for 20+ years at this point, because the platform differences used to be much, much worse. Coincidentally, I just saw this article, which makes the case nicely: https://www.bram.us/2026/06/21/do-websites-need-to-function-exactly-the-same-on-every-platform/ https://www.bram.us/2026/06/21/do-websites-need-to-function-...
  - c-hendricks 3mo ago
    webkitgtk isn't just quirky, it's also much slower compared to more popular browser engines and is particularly bad with RAM usage.
    - paddy_m 3mo ago
      is webkitgtk different than the engine used in safari?
      - c-hendricks 3mo ago
        Not necessarily? As far as I know they come from the same WebKit source. But the bridge between WebKit and the OS is of course specific to each system. WebRTC is still experimental in webkitgtk while caniuse says Safari supported it back in 2017. I remember encountering one bug with Final Form that triggered rarely in Safari, 100% in Webkitgtk, and never in Chromium. Here's the developer of Tauri saying it's hard to recommend webkitgtk / Linux support: > So if you need good linux support now/soon i can't 100% recommend tauri (for Linux) as of now. (I used to be more "forgiving" but with webkitgtk getting worse/more unstable each release i changed my mind) https://github.com/orgs/tauri-apps/discussions/8524#discussioncomment-7993948 https://github.com/orgs/tauri-apps/discussions/8524#discussi...
  - echelon 3mo ago
    > This point of view always confuses me, because web developers already need to deal with platform differences. On Mac, I use Firefox and Chrome. However, if I use a Tauri app on Mac, I have to use dated WebKit. It's out of a Tauri developer's control.
- v3ss0n 3mo ago
  LOL , then back to electron. I raised that since day one of Tauri.
- jauntywundrkind 3mo ago
  Tauri's cef-rs is indeed quite good. I think it's available, ready, works: it's just that there aren't many folks using Tauri and only a fraction of them are aware/interested in exploring further. https://github.com/tauri-apps/cef-rs https://github.com/tauri-apps/cef-rs Huge fan, this should definitely be the default. The user experience is incomparable. One thing I'd like to verify: can the OS effectively use shared mem for cef across multiple different cef-rs apps? I really hope so. In this time of RAM being scarce, this optimization could be such a benefit.
- cdud3 3mo ago
  Or use QtWebEngine which uses Chromium under the hood, provides a stable and rich API and enables sharing rather then bundling the browser runtime + is Cross-Platform + security updates are handled too.
- DanielHB 3mo ago
  > It seems great to be able to cut hundreds of megabytes out of your app installer Your points are valid, but the big upside is that the default system webview is very likely to already be loaded in memory before your app starts. And if multiple apps use the default system webview all of them will load that same dynamically linked binaries only once. I don think the RAM savings are that significant on modern systems, but it greatly speeds up app first-loading times.

lwansbrough 3mo ago

Web devs are used to their target being evergreen, so I suppose you could opt in or out of that model: "just give me what you got".

Someone 3mo ago
> Web devs are used to their target being evergreen I would think/hope web developers are used to “just give me what you got”. Any other mindset leads to “you must install <browser> to see this site”. It’s Electron devs that are used to that.
- coffeebeqn 3mo ago
  I love how we’re now reinventing the browser as a much worse version of itself. What if instead of one or two general Web browsers we make everyone install 10 random versions that can only open one website?
lopis 3mo ago
> Web devs are used to their target being evergreen Since when? The browser landscape is much better today than 10 years ago, but no web dev worth their salt assumes anything about the user agent.
fwlr 3mo ago
True for this decade, but in the previous decade it was very much the opposite. Before you used any kind of browser api or nice language feature you would feature-detect it: if (typeof Array.prototype.includes === ‘undefined’) { … And if it wasn’t there you would define it yourself, it was called “polyfilling”. This was so commonplace that we built significant tooling like babel to standardize feature detection tests and fallback implementations - for a few years you could write request.then(response => response.json()) And behind the scenes the Rube Goldberg machine would turn this into something that would run in a JavaScript environment that had neither arrow functions nor promises.
DanielHB 3mo ago
Oh god I feel OLD reading this.

hun3 3mo ago

System WebView but Electron is now the system

actionfromafar 3mo ago
Ah, that's a new systemd module now.

qbane 3mo ago

I doubt the benefit. Practically every Electron app on a desktop uses different versions of Chromium and many are very out of date because of the risk of breaking when upgrading.

teaearlgraycold 3mo ago
People build web apps for an array of browsers and huge ranges of versions. I think if you started using some tech to deploy an end user program and knew from the beginning the browser could be updated beneath you it would work just fine. But if you start with a golden version of Chrome and put off updating for too long you’ve let yourself get too comfortable.
- troupo 3mo ago
  > People build web apps for an array of browsers and huge ranges of versions. en masse they don't. They just target the latest Chrome
  - teaearlgraycold 3mo ago
    De facto they do because functionality built three years ago and tested then is running along side functionality they built yesterday and tested on today’s Chrome. People also do seem to test on iOS Safari because that pain in my ass needs special care on my software. So if a site works on it they either got lucky or tested on an iPhone. It’s generally only other people’s weird tech demo stuff that doesn’t work.
  - threetonesun 3mo ago
    I agree and disagree, you can't target everything, but most (not shit) devs will target at least Safari - 1 or 2, simply because the iPhone market is too good to miss out on. And Safari being, well, Safari, means targeting that is a pretty safe bet for anything else.
    - Semaphor 3mo ago

Lucasoato 3mo ago

Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed. [0]: https://www.riotgames.com/en/news/architecture-league-client-update https://www.riotgames.com/en/news/architecture-league-client...

chmod775 3mo ago
When the new client was built, microservices were the hot new buzzword. The new client is some weird plugins/services based architecture. Things that'd barely warrant their own class in a boring OOP-based UI framework are instead now "isolated" services. The reality of this isolation being that if one piece breaks, the whole UI becomes unusable anyways. Dozens of things that in another app would've been just a simple synchronous call now behave like remote procedure calls and messages, forcing all the complexity of distributed systems into a local application for no reason. That's why it runs like ass, breaks if you look at it wrong, and your CPU draws more power when using the client than when playing the game at 200FPS.
megacelebi 3mo ago
This is more a function of how mismanaged the project was at Riot (the iron client days, choosing Ember, etc.) which led to the current state of the launcher.
gavinray 3mo ago
CEF is + has been the de-facto standard when you have a native app and want to do a web UI. It's not the only option, but it's the most mature with the largest amount of docs + stack overflow questions, so it's a "safe" choice. If you peek into the native resources files of most games/desktop apps, you'll find a good portion of them bundle + use the CEF dll.
mannanj 3mo ago
I regularly install and uninstall the league client on Mac based on how I play that game (require fresh installs to raise the playing cost) and their client really sucks. Even freshly installing it, the client inhibits and hijacks mouse clicks from the full screen game when it's open. It took me months to figure out I would have to minimize the game, open and minimize the client (separate app) open, and then clicks would sometimes properly return. Before that I was closing both and playing a game of roulette. By the the time my game was working, I may have already been reported for being afk and the game ended. Edit: other bugs have included starting to download the game and then signing in afterwards (their UI doesn't stop you) and then download progress disappearing, perhaps hanging, and you having no way to know it for a 40gb file unless over an hour has passed and you check disk size and then realize the client doesn't know how to load it. Start over and do a fresh install again, clear cache etc because their cache of the client still thinks somethings being downloaded even though it's not. Also having chat permanently off, results in weird glitches with friends requests and being unable to add new friends. Horrible experience. But since the game is so optimized for addiction and dark patterns these days, and sunk cost, its a game I find myself returning to every once in a while.

deeringc 3mo ago

I'd prefer if it just used the system webview rather than downloading and managing an embedded browser itself. Webview2 on Windows for example.

jitl 3mo ago
> Small by default, full Node compatibility. The default WebView backend uses the operating system's own webview for small binaries
andrewaylett 3mo ago
That appears to be the default, CEF is available if required (hint: it shouldn't be).

deleted 3mo ago

[deleted]

kodablah 3mo ago

I used CEF for a project and Google is detecting CEF via some opaque algorithms and not allowing logins from it. From https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html https://security.googleblog.com/2019/04/better-protection-ag...: > Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.

iancarroll 3mo ago
Most apps (on desktop or mobile) open third party auth flows inside the user's default browser, which makes this a non-issue. For one, if you embed the Google login flow into your app then I can't reuse my existing session in my browser. But it also exposes my full credentials to your app for no reason, which is a good thing to avoid.

v3ss0n 3mo ago

A strip down version of electron TBH.