I thought embedding a web UI into a native desktop application would be the easy part.
After all... macOS has WebKit. Linux has GTK WebKit. Windows has WebView2.
One API per platform, smaller installers, native look & feel. Sounds perfect.
Then reality arrived.
macOS š
Honestly, this was the easiest platform.
System WebKit is there.
It behaves consistently.
No additional runtime.
No installer surprises.
Exactly what you'd expect from a platform component.
10/10
Linux š§
Things became... more interesting.
GTK WebKit works, but suddenly packaging starts to matter.
An AppImage built on one distribution may refuse to start on another because some required WebKitGTK library isn't available.
Your application itself is perfectly fine.
The user's system just doesn't happen to provide exactly the version your build expects.
You quickly discover that "works on my machine" has many regional dialects.
7/10
Windows šŖ
This one surprised me the most.
Unlike macOS, the web view isn't really just "there."
Using WebView2 means depending on the Edge WebView runtime.
If the runtime isn't installed, congratulationsāyou now need another installer.
So your installer may install something whose purpose is to allow your application to display HTML.
Not exactly the dependency story I was hoping for.
2/10
Meeting in the middle
At some point I asked myself:
Why am I spending time debugging operating-system packaging instead of building my application?
So I tried CEF (Chromium Embedded Framework).
Yes...
The application becomes larger.
Quite a bit larger.
But in exchange:
ā¢ Same rendering engine everywhere.
ā¢ Same JavaScript engine everywhere.
ā¢ Same debugging experience.
ā¢ Same HTML/CSS behavior.
ā¢ No Linux WebKit dependency lottery.
ā¢ No separate WebView runtime installation on Windows.
ā¢ One code path across all desktop platforms.
Ironically, shipping your own browser turned out to be simpler than relying on the browser already "provided" by the operating system.
It's one of those engineering decisions that looks wasteful on paper but ends up reducing complexity everywhere else.
Sometimes carrying the extra megabytes is cheaper than carrying platform-specific surprises.
Curious what others have settled on.
Are you using native web views, CEF, or something else for cross-platform desktop applications?
Top comments (2)
I guess this explains the rise of electron applications.
I looked into CEF briefly a while back. Only far enough to see it was a viable option but a lot of work. I'm developing a cross platform C++ framework which has reached the partly built web server stage. I'm not even considering providing a browser component given how massive they are so I guess CEF will be back on the table eventually. Desktop UI first though.
Desktop UI is tricky when the goal is a consistent look and feel. For me alternatives were using some kind of immediate mode UI like Dear ImGui or .Net solutions like Avalonia. I didn't want to get into the rabbit hole of 3d acceleration or installing runtimes along with the app so ended up with embedding CEF. It's not that bad actually, people even use it for off-screen rendering of pages for game engines - like displaying rich documentation pages inside the game.