16 ms·

Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty

Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-details#user-interface https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users don't get to choose their system webview, I wonder if this has the potential to broaden browser diversity a little bit?

andai 6y ago
I heard about a similar project a few months ago but I can't recall the name. I think the downside is that each OS has its own idiosyncratic webview.
- dsizzle 6y ago
  Revery? https://github.com/revery-ui/revery https://github.com/revery-ui/revery
  - lilactown 6y ago
    AFAIK Revery doesn't use webviews, it is based on Skia
- genezeta 6y ago
  Neutralino, maybe? One significant difference regarding webviews is Neutralino on Windows is using an outdated WebControl (MSHTML/Trident based) and this one seems to be using at least WebView (EdgeHTML based) or even WebView2 (Edge-Chromium) if available, both of which are a major improvement.
- alpaca128 6y ago
  I recently discovered NeutralinoJS, but I haven't tried it yet.
hu3 6y ago
> I kind of wonder why it took this long for someone to try this approach. Perhaps a similar approach to https://github.com/webview/webview https://github.com/webview/webview ? "Tiny cross-platform webview library for C/C++/Golang. Uses WebKit (Gtk/Cocoa) and Edge (Windows)"
- flixic 6y ago
  Yes, Tauri's documentation explicitly states that it uses this Webview project.
  - hu3 6y ago
    That's great in the sense that the more solutions using that library, the more mature it gets.
  - baxrob 6y ago
    Tauri has effectively controlled the Webview project for the past year. See https://github.com/webview/webview/issues/305 https://github.com/webview/webview/issues/305
- abeltensor 6y ago
  tauri does use webview but its moving away from it in favor of a rust native solution called WRY.
  - hu3 6y ago
    Interesting. So according to @baxrob, Tauri took over control of https://github.com/webview/webview https://github.com/webview/webview project for the past year. And now I'm told they are moving away from it. I'm left wondering why take over a project if they're going to ditch it. For lack of a better term.
    - nklayman 6y ago
      We didn't take over control, rather we helped setup an independent org around webview and other related repos. At the time, the original author of webview expressed plans to work on it a lot. However, this didn't really happen. Webview is stuck with some nasty bugs and missing features, and none of the members of the Tauri team had enough C experience to fix it efficiently. Instead, we created our own pure Rust solution (https://github.com/tauri-apps/wry https://github.com/tauri-apps/wry). We've already given it way more features than the original webview project, and it doesn't carry the bugs that plagued webview either. The next release of Tauri (about a month or so out) will use Wry, and will have features such as multi-window and fancy window styling (frameless, fullscreen, custom controls, etc...).
dsizzle 6y ago
Revery is another similar project that is trying to be a lightweight alternative to Electron https://github.com/revery-ui/revery https://github.com/revery-ui/revery
- abeltensor 6y ago
  No revery is native. It doesn't use a webview at all; just uses the skia engine; basically a flutter competitor.
vlovich123 6y ago
Well Windows is basically Chrome so your diversity will basically be Chrome & WebKit which is what you have anyway. And having all the fun of web development against multiple browsers with all the headaches of desktop distribution is kind of the worst of all worlds. It'll be interesting to see if this approach finds success (since it may cut down on the size of your binary) but it could easily get abandoned if any significant projects start using this as frontend devs create pressure to simplify the stack across platforms. On Linux it's going to pull in GTK which means a not great experience on KDE (even though KDE does have WebKit hooks like GTK does).
- brundolf 6y ago
  > so your diversity will basically be Chrome & WebKit which is what you have anyway Right now many web apps can brush off doing QA in Safari (and Firefox for that matter). Most regular websites don't have issues, but most of those don't need any vendor-specific fixes in the first place. I've used multiple complex web apps that just break unceremoniously unless you're using Chrome. If web apps that are complex enough to warrant a desktop app are forced to support Safari, that lifts awareness for the entire web/JS ecosystem. That's a win, if it plays out that way. > having all the fun of web development against multiple browsers The difficulty here has gone sharply down since all major browsers are evergreen now (and IE is all-but-gone). Not to mention the availability of tooling like Babel.
  - vlovich123 6y ago
    > Right now many web apps can brush off doing QA in Safari (and Firefox for that matter). Most regular websites don't have issues, but most of those don't need any vendor-specific fixes in the first place. I've used multiple complex web apps that just break unceremoniously unless you're using Chrome. There's billions of active iPhones out there & they ALL use WebKit for webviews as no other browser engine is allowed for iOS apps. MacOS desktop apps are a fraction of that number of users & web view apps are a fraction of that. I just I don't follow this reasoning unless you're saying that this might gain traction across developers who might go & fix the bugs. That might help WebKit (although questionable). It's never going to help Firefox which is the sole remaining engine that doesn't have a strategic play to try to encourage compatibility. > The difficulty here has gone sharply down since all major browsers are evergreen now (and IE is all-but-gone). Not to mention the availability of tooling like Babel. If that were actually true, would you be concerning yourself with getting devs to do more QA on Safari or Firefox? The truth is that it's still hard to write web apps cross-browser and will likely remain hard indefinitely as long as there are > 1 web engines. The point of the web was to make you OS agnostic (ironically recreating the same pattern in desktop development of 2 or 3 major engines as with 2 or 3 major OSes) but with this tech you're combining both dealing with the browser-specific issues & OS-specific issues. Additionally, you're now not only having to maintain compatibility across 3 engines, but all the various versions popular versions of the OS distribution will have shipped. I really struggle to see the value of this approach if I'm concerned with shipping the app & lowering my development costs & increasing velocity to shipping useful features.
the_duke 6y ago
A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app has a web version and you have to deal with it anyway , but thereare a fair amount of Electron only apps. Or even with a web version, the desktop app often has special features not present on the web. But webviews are as much a moving target as browsers and often behave differently from the regular browser version in a myriad of ways, so you need an even bigger testing matrix. Webviews are also hard to properly secure and don't provide the extensive APIs of Electron, which you often have to bake yourself in a wrapper written in, eg, Rust or C++. I say all this as someone who hates how resource hungry Electron apps are and groans each time about yet another one on my machine, but I understand why it is so popular.
- brundolf 6y ago
  > don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web standards at the time (and frankly, web tooling too). Browsers, even the good ones, didn't update themselves automatically. Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!). There was nothing like Babel to smooth over the rough edges, there were no polyfills. And even the standards that existed, when you got the opportunity to use them, mostly sucked. I think, given all that, we can deal with supporting recent-ish Chromium and the latest Safari, if it means bolstering web diversity and saving an order of magnitude in RAM and storage.
  - 908B64B197 6y ago
    > Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!) More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.
mikewhy 6y ago
> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. As others have mentioned, this is not the first time someone has tried. As for why people might not go for it: - Electron is Chrome. Webview is: Cocoa/WebKit, gtk-webkit2, and Edge (or is that Edge and Edge/Chrome). Yes standards have progressed a ton but there's still inconsistencies and it's nice not having to worry about them. - Electron is JS, so your app is 100% in a single language. In Webview. With these alternatives you now have to use 2 languages. Not the end of the world, but again, nice not having to deal with.
- pjmlp 6y ago
  Which is exactly why everyone pushing for Electron apps has nothing worthy to say about Chrome market share.
flohofwoe 6y ago
It's not a new idea, for instance https://github.com/webview/webview https://github.com/webview/webview ...has a fairly long history. It's great for extremely small application packages (when I tinkered around with it on macOS a few years ago I brought it down to 26 kilobytes). The usual argument against the idea is that Electron gives you a fixed Chromium version to work against, while the system webviews are a moving target with different underlying browser engines.
Brakenshire 6y ago
Pity they can’t use Servo as the rendering engine, even if it only deals with a small subset of style/layout properties. That kind of parallel layout engine should make building fluid 60fps interfaces a lot easier.
- Maledictus 6y ago
  Why can't they?
  - afavour 6y ago
    AFAIK there are no V8 <-> Servo bindings. So in theory (I don’t know Servo well at all) you could render a static HTML document but you’d have no DOM JS APIs to work with.
    - fabrice_d 6y ago
      Servo uses SpiderMonkey as its JS engine, and supports some DOM apis.
    - silon42 6y ago
      you probably wouldn't want it anyway. Using Servo only for rendering and using Rust for everything else would be preferable.
  - nklayman 6y ago
    Servo is quite large and extremely difficult to build from source. We've tried to make it work with Tauri but decided it's not worth it, at least for now.
    - NetOpWibby 6y ago
      This makes me feel better about abandoning my own plans to do the same.
    - mdaniel 6y ago
      Do you have more specifics, and/or have you advised them of the difficulties? It seems to use the same "mach" build process as does firefox, and I build FF developer edition regularly (not every day, but damn near): https://github.com/servo/servo#normal-build https://github.com/servo/servo#normal-build While investigating this, I have deep sympathies for whoever has to work with that taskcluster silliness because yikes that is some A++ grade obfuscation as compared to a .gitlab-ci.yml or .circleci or even the .travis.yml they migrated off of
flanbiscuit 6y ago
> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Like other replies have mentioned, it's not a new idea DeskGap uses the native OS Webviews. https://github.com/patr0nus/DeskGap/ https://github.com/patr0nus/DeskGap/ Electrino (4 years old) was an experiment where they forked Electron and removed Chromium to replace it with the native OS Web views. https://github.com/pojala/electrino https://github.com/pojala/electrino Quark is a fork of Electrino: https://github.com/jscherer92/Quark https://github.com/jscherer92/Quark There's also a way of building desktop GUIs using Deno, which uses Deno Webview, which is a binding for the same webview library that Tauri uses. https://denotutorials.net/making-desktop-gui-applications-using-deno-webview.html https://denotutorials.net/making-desktop-gui-applications-us... https://github.com/webview/webview https://github.com/webview/webview
- baxrob 6y ago
  Also wxWidgets/wxWebView and pywebview https://docs.wxwidgets.org/trunk/classwx_web_view.html https://docs.wxwidgets.org/trunk/classwx_web_view.html https://github.com/r0x0r/pywebview https://github.com/r0x0r/pywebview
devwastaken 6y ago
Webviews don't work because they solve very different problems. System webviews will always have different features, break things, and are entirely uncontrollable by the software distributor. This means your software will not be resilient to the future. You cannot access the JS engine the same as you can V8 in most webviews. This means you can't interop with C libraries without some performance destroying hack like copying everything into the JS space through sockets. This also means something as simple as reading a file has to, again, cross the sandbox in an inefficient way. You'd have the browser, it's javascript engine, and your own runtime in node or python or however too. Electron develops patches that make chromium more performant and feature ready for desktop. Electron conjoins the chromium and node v8 event loop to take advantage of libuv - again a performance improvement. The decision of webviews and electron is based on what you're trying to do. If it's simple html/JS that's pretty much self contained then sure.
- andrew_ 6y ago
  It's been a minute since I attempted it on Windows, but transparency of borders and borderless windows with the webview on Windows was next to impossible. It's one of the reasons we used Electron. I'm curious to know if they've solved that, but can't find my mention of it.
- saagarjha 6y ago
  If you cared about performance, would you really be using Electron?
  - innocenat 6y ago
    Yes. Why not? HTML/CSS great (from the development POV) for UI, and I can always write the performance critical code in C and linked them to the electron HTML/CSS frontend.
    - saagarjha 6y ago
      Presumably, if copying some data between JavaScript and native code in a slightly roundabout way was an issue, you wouldn't run things through web technology in the first place…
dfabulich 6y ago
People have been trying the WebView approach for years. (Projects include: Quark, Electrino, DeskGap, Revery, and Neutralino.) Historically, it worked terribly on Windows. On Windows, if you used the OS WebView, your Windows 7 users would be forced to use IE11 to run your app, even if they had a newer/better browser installed locally. On Windows 10, you'd get whatever random version of Edge was installed, or the new Chromium-based Edge. In 2021, we're in a new era for Windows WebViews, thanks to Microsoft shipping WebView2 at the end of 2020, which ensures that the OS-provided WebView will be a modern version of Chromium. https://docs.microsoft.com/en-us/microsoft-edge/webview2/ https://docs.microsoft.com/en-us/microsoft-edge/webview2/ Tauri supports WebView2 and I bet it will work a lot better than historical approaches. Support is still pretty dicey on other platforms, though. macOS doesn't have anything like WebView2, so if you want to support a five-year-old version of macOS (which isn't that old in desktop terms), you'll be forced to support and test your app on a five-year-old version of Safari. (The user might have upgraded to a two-year-old version of Safari, but they might not, if they prefer Firefox or Chrome, and that's now your problem.) The easiest and best way to improve the user's experience on old OS versions is to provide your own copy of Chromium, like Electron does. At that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day? Having said that, if you can keep your OS-version support matrix tight, Tauri might work OK for you.
- CommonGuy 6y ago
  We use the WebView approach for Kreya[1], though not with Tauri. We had some occassional issues with Chromium/Safari differences, but otherwise it works fine. We use WebView2 on Windows, Safari on macOS and WebKit2GTK on Linux. Not shipping a whole Chromium installation on each install and update reduces the installer and on-disk size a lot! [1] https://kreya.app https://kreya.app
  - dfabulich 6y ago
    https://kreya.app/docs/getting-started https://kreya.app/docs/getting-started I see issues here! > Apple Silicon (M1) is not yet supported. And on Linux, > you may install Kreya by downloading the tarball. Note that both libgtk-3 and libwebkit2gtk-4.0 dependencies are required. Install them manually if they aren't present on your system. libwebkit2gtk is, itself, _an embedded browser_, 44MB installed size, plus dependencies. It's convenient that you can make Snapcraft install it for you, but that's not really different from making Snapcraft install Electron and running that.
jiofih 6y ago
It didn’t take long, this approach was around years before Electron came in. But the reason Electron picked up is precisely the stable APIs with cross-platform compatibility that comes from bundling chromium. You won’t get that here.
ksec 6y ago
What we need is a subset of HTML features that are known to work across all major browser. From Firefox, Safari /WebKit on other MacOS, and Chrome. Or something that compiles to the compatible HTML code for those platform with 100% accuracy. Unless that happens, you are dealing with godzillion number of edge cases in hundreds of different System Browser. But even if such language or subset of feature exist, it will still not be as good or as be limited compared what is possible on top of current Electron. Which means from a user perspective, the Dev is optimising for something they rarely cares about; download size. Given memory CPU and Memory usage to electron.
- eivarv 6y ago
  What we need is a subset of HTML features that are known to work across all major browser. From Firefox, Safari /WebKit on other MacOS, and Chrome. What, you mean like standards? Web standards?
  - ksec 6y ago
    The problem is not all current Web Standards are supported across all System Browsers. So the Subset is meant as lowest common factor. How do get anything to work when you have customers using IE?
deleted 6y ago
[deleted]
hinkley 6y ago
I think my best-case scenario would be an Electron replacement that is not so bloated and also keeps parts of Firefox well-funded and people looking at compatibility. Elevating a new stack is a good consolation prize.
lenkite 6y ago
People have already tried this approach. https://github.com/webview/webview https://github.com/webview/webview https://github.com/yue/muban https://github.com/yue/muban ..and several others too.
themihai 6y ago
>> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. I believe there are dozens of projects using Webview and market themselves as a lightweight "Electron". The development for these apps takes longer (as you need to test for different webview versions/vendors) and the end product is worse as some features are shimmed or you just choose to not support them due the effort required. Of course this depends by project. I've developed a media player and considered webview. Soon enough I've found the limitations of safari, ie webview and even firefox webview on audio/video codecs is a blocker. Next was indexeddb and some random performance issues. It didn't took long to realise that it's hard to compete with native apps using Electron but its even harder using different webview versions. I will consider webView again when WASM gets native DOM access and audio/video decoding becomes available (performance wise) in WASM.
- elonvolo 6y ago
  The dirty little secret is that a software project with two different native codebases is often cheaper, with a faster time-to-market, than a cross platform browser-tech based solution that had just one codebase. The BS of the browser tech world compounded over time and a million edge cases eventually eats up all the one-codebase, cross-platform savings.
morpheuskafka 6y ago
It will, but browser diversity is not what you want for an electron-style app. The whole point of Electron is that it's a browser you control--you set the site permissions, you control the version and updates, you know exactly what it supports. That's what makes longer-lasting, more native experiences possible with a low development cost.
mike_ivanov 6y ago
> why it took this long for someone to try this approach it didn't - there is already a few projects like that, with Neutralino being the most notable.
whywhywhywhy 6y ago
>I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. The current generation of web developers who grew up within the Chrome ecosystem has zero interest in spending time on cross browser support. Even if the user had to install 4GB of chrome runtime they'd still argue it's better than them making it work in Chrome, Edge-Chrome and Safari WebKit. Not saying everyone, maybe my companies hiring process is screwed but every developerbar 1 that I've worked with over the past 4 years has been the same and even getting them to test in one other browser than Chrome is honestly like pulling teeth. Infuriates me as someone who's first job was CSS+HTML supporting IE 5.5-7.0, Firefox, Opera and Safari. The amount of times I've heard "Can't we just tell them to use Chrome?" when talking about users is getting absurd. The lack of understanding that a few hours of their job being slightly more difficult can add up to saving literal lifetimes of time saved or entire data centres of disk space when you extrapolate the savings across your user count. I know its maybe cheap to roll out a Steve Jobs quote but this one still resonates with me. "Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" https://www.folklore.org/StoryView.py?story=Saving_Lives.txt https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
- userbinator 6y ago
  The current generation of web developers who grew up within the Chrome ecosystem has zero interest in spending time on cross browser support. The scary power of Google.
tssva 6y ago
It seems every couple of months there is an alternative to Electron posted here which uses system webviews. A quick search turns up a wide variety of them.
lucideer 6y ago
> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Which is why many many people tried this approach long before Electron came along. Electron has been successful largely because it deviated from this: it swallowed the bitter pill of bundling the heavy duplicated webview in order to ensure a consistent development target.
trustdragon 6y ago
It is a good idea but it is not a new idea the interesting history of these sorts of frameworks is that Google actually created a framework that did this and stopped development on it. the code is still on GitHub. And there's a bunch of other frameworks that use a variety of different languages not just rust as the application language that also have this idea of not bundling chromium but instead using the system webview for rendering HTML and JavaScript. You can find a bunch of different approaches in lists like "alternatives to electron." There's some on GitHub. I took a slightly different approach where instead of using the system web view which I thought you know is going to be inconsistent across systems and it's not going to support the latest HTML JavaScript and security features I used the assumption that the user already has chrome installed which works in a high number of cases or can download and install it if that's not the case. predictably I suppose some people express to satisfaction that it was not using Firefox. using Firefox becomes more possible and more likely I suppose as firefox's support for the dev tools protocol achieves parity with chrome support for that. https://github.com/c9fe/graderjs https://github.com/c9fe/graderjs

andai 6y ago

I heard about a similar project a few months ago but I can't recall the name. I think the downside is that each OS has its own idiosyncratic webview.

dsizzle 6y ago
Revery? https://github.com/revery-ui/revery https://github.com/revery-ui/revery
- lilactown 6y ago
  AFAIK Revery doesn't use webviews, it is based on Skia
genezeta 6y ago
Neutralino, maybe? One significant difference regarding webviews is Neutralino on Windows is using an outdated WebControl (MSHTML/Trident based) and this one seems to be using at least WebView (EdgeHTML based) or even WebView2 (Edge-Chromium) if available, both of which are a major improvement.
alpaca128 6y ago
I recently discovered NeutralinoJS, but I haven't tried it yet.

hu3 6y ago

> I kind of wonder why it took this long for someone to try this approach. Perhaps a similar approach to https://github.com/webview/webview https://github.com/webview/webview ? "Tiny cross-platform webview library for C/C++/Golang. Uses WebKit (Gtk/Cocoa) and Edge (Windows)"

flixic 6y ago
Yes, Tauri's documentation explicitly states that it uses this Webview project.
- hu3 6y ago
  That's great in the sense that the more solutions using that library, the more mature it gets.
- baxrob 6y ago
  Tauri has effectively controlled the Webview project for the past year. See https://github.com/webview/webview/issues/305 https://github.com/webview/webview/issues/305
abeltensor 6y ago
tauri does use webview but its moving away from it in favor of a rust native solution called WRY.
- hu3 6y ago
  Interesting. So according to @baxrob, Tauri took over control of https://github.com/webview/webview https://github.com/webview/webview project for the past year. And now I'm told they are moving away from it. I'm left wondering why take over a project if they're going to ditch it. For lack of a better term.
  - nklayman 6y ago
    We didn't take over control, rather we helped setup an independent org around webview and other related repos. At the time, the original author of webview expressed plans to work on it a lot. However, this didn't really happen. Webview is stuck with some nasty bugs and missing features, and none of the members of the Tauri team had enough C experience to fix it efficiently. Instead, we created our own pure Rust solution (https://github.com/tauri-apps/wry https://github.com/tauri-apps/wry). We've already given it way more features than the original webview project, and it doesn't carry the bugs that plagued webview either. The next release of Tauri (about a month or so out) will use Wry, and will have features such as multi-window and fancy window styling (frameless, fullscreen, custom controls, etc...).

dsizzle 6y ago

Revery is another similar project that is trying to be a lightweight alternative to Electron https://github.com/revery-ui/revery https://github.com/revery-ui/revery

abeltensor 6y ago
No revery is native. It doesn't use a webview at all; just uses the skia engine; basically a flutter competitor.

vlovich123 6y ago

Well Windows is basically Chrome so your diversity will basically be Chrome & WebKit which is what you have anyway. And having all the fun of web development against multiple browsers with all the headaches of desktop distribution is kind of the worst of all worlds. It'll be interesting to see if this approach finds success (since it may cut down on the size of your binary) but it could easily get abandoned if any significant projects start using this as frontend devs create pressure to simplify the stack across platforms. On Linux it's going to pull in GTK which means a not great experience on KDE (even though KDE does have WebKit hooks like GTK does).

brundolf 6y ago
> so your diversity will basically be Chrome & WebKit which is what you have anyway Right now many web apps can brush off doing QA in Safari (and Firefox for that matter). Most regular websites don't have issues, but most of those don't need any vendor-specific fixes in the first place. I've used multiple complex web apps that just break unceremoniously unless you're using Chrome. If web apps that are complex enough to warrant a desktop app are forced to support Safari, that lifts awareness for the entire web/JS ecosystem. That's a win, if it plays out that way. > having all the fun of web development against multiple browsers The difficulty here has gone sharply down since all major browsers are evergreen now (and IE is all-but-gone). Not to mention the availability of tooling like Babel.
- vlovich123 6y ago
  > Right now many web apps can brush off doing QA in Safari (and Firefox for that matter). Most regular websites don't have issues, but most of those don't need any vendor-specific fixes in the first place. I've used multiple complex web apps that just break unceremoniously unless you're using Chrome. There's billions of active iPhones out there & they ALL use WebKit for webviews as no other browser engine is allowed for iOS apps. MacOS desktop apps are a fraction of that number of users & web view apps are a fraction of that. I just I don't follow this reasoning unless you're saying that this might gain traction across developers who might go & fix the bugs. That might help WebKit (although questionable). It's never going to help Firefox which is the sole remaining engine that doesn't have a strategic play to try to encourage compatibility. > The difficulty here has gone sharply down since all major browsers are evergreen now (and IE is all-but-gone). Not to mention the availability of tooling like Babel. If that were actually true, would you be concerning yourself with getting devs to do more QA on Safari or Firefox? The truth is that it's still hard to write web apps cross-browser and will likely remain hard indefinitely as long as there are > 1 web engines. The point of the web was to make you OS agnostic (ironically recreating the same pattern in desktop development of 2 or 3 major engines as with 2 or 3 major OSes) but with this tech you're combining both dealing with the browser-specific issues & OS-specific issues. Additionally, you're now not only having to maintain compatibility across 3 engines, but all the various versions popular versions of the OS distribution will have shipped. I really struggle to see the value of this approach if I'm concerned with shipping the app & lowering my development costs & increasing velocity to shipping useful features.

the_duke 6y ago

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app has a web version and you have to deal with it anyway , but thereare a fair amount of Electron only apps. Or even with a web version, the desktop app often has special features not present on the web. But webviews are as much a moving target as browsers and often behave differently from the regular browser version in a myriad of ways, so you need an even bigger testing matrix. Webviews are also hard to properly secure and don't provide the extensive APIs of Electron, which you often have to bake yourself in a wrapper written in, eg, Rust or C++. I say all this as someone who hates how resource hungry Electron apps are and groans each time about yet another one on my machine, but I understand why it is so popular.

brundolf 6y ago
> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web standards at the time (and frankly, web tooling too). Browsers, even the good ones, didn't update themselves automatically. Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!). There was nothing like Babel to smooth over the rough edges, there were no polyfills. And even the standards that existed, when you got the opportunity to use them, mostly sucked. I think, given all that, we can deal with supporting recent-ish Chromium and the latest Safari, if it means bolstering web diversity and saving an order of magnitude in RAM and storage.
- 908B64B197 6y ago
  > Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!) More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.

mikewhy 6y ago

> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. As others have mentioned, this is not the first time someone has tried. As for why people might not go for it: - Electron is Chrome. Webview is: Cocoa/WebKit, gtk-webkit2, and Edge (or is that Edge and Edge/Chrome). Yes standards have progressed a ton but there's still inconsistencies and it's nice not having to worry about them. - Electron is JS, so your app is 100% in a single language. In Webview. With these alternatives you now have to use 2 languages. Not the end of the world, but again, nice not having to deal with.

pjmlp 6y ago
Which is exactly why everyone pushing for Electron apps has nothing worthy to say about Chrome market share.

flohofwoe 6y ago

It's not a new idea, for instance https://github.com/webview/webview https://github.com/webview/webview ...has a fairly long history. It's great for extremely small application packages (when I tinkered around with it on macOS a few years ago I brought it down to 26 kilobytes). The usual argument against the idea is that Electron gives you a fixed Chromium version to work against, while the system webviews are a moving target with different underlying browser engines.

Brakenshire 6y ago

Pity they can’t use Servo as the rendering engine, even if it only deals with a small subset of style/layout properties. That kind of parallel layout engine should make building fluid 60fps interfaces a lot easier.

Maledictus 6y ago
Why can't they?
- afavour 6y ago
  AFAIK there are no V8 <-> Servo bindings. So in theory (I don’t know Servo well at all) you could render a static HTML document but you’d have no DOM JS APIs to work with.
  - fabrice_d 6y ago
    Servo uses SpiderMonkey as its JS engine, and supports some DOM apis.
  - silon42 6y ago
    you probably wouldn't want it anyway. Using Servo only for rendering and using Rust for everything else would be preferable.
- nklayman 6y ago
  Servo is quite large and extremely difficult to build from source. We've tried to make it work with Tauri but decided it's not worth it, at least for now.
  - NetOpWibby 6y ago
    This makes me feel better about abandoning my own plans to do the same.
  - mdaniel 6y ago
    Do you have more specifics, and/or have you advised them of the difficulties? It seems to use the same "mach" build process as does firefox, and I build FF developer edition regularly (not every day, but damn near): https://github.com/servo/servo#normal-build https://github.com/servo/servo#normal-build While investigating this, I have deep sympathies for whoever has to work with that taskcluster silliness because yikes that is some A++ grade obfuscation as compared to a .gitlab-ci.yml or .circleci or even the .travis.yml they migrated off of

flanbiscuit 6y ago

> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Like other replies have mentioned, it's not a new idea DeskGap uses the native OS Webviews. https://github.com/patr0nus/DeskGap/ https://github.com/patr0nus/DeskGap/ Electrino (4 years old) was an experiment where they forked Electron and removed Chromium to replace it with the native OS Web views. https://github.com/pojala/electrino https://github.com/pojala/electrino Quark is a fork of Electrino: https://github.com/jscherer92/Quark https://github.com/jscherer92/Quark There's also a way of building desktop GUIs using Deno, which uses Deno Webview, which is a binding for the same webview library that Tauri uses. https://denotutorials.net/making-desktop-gui-applications-using-deno-webview.html https://denotutorials.net/making-desktop-gui-applications-us... https://github.com/webview/webview https://github.com/webview/webview

baxrob 6y ago
Also wxWidgets/wxWebView and pywebview https://docs.wxwidgets.org/trunk/classwx_web_view.html https://docs.wxwidgets.org/trunk/classwx_web_view.html https://github.com/r0x0r/pywebview https://github.com/r0x0r/pywebview

devwastaken 6y ago

Webviews don't work because they solve very different problems. System webviews will always have different features, break things, and are entirely uncontrollable by the software distributor. This means your software will not be resilient to the future. You cannot access the JS engine the same as you can V8 in most webviews. This means you can't interop with C libraries without some performance destroying hack like copying everything into the JS space through sockets. This also means something as simple as reading a file has to, again, cross the sandbox in an inefficient way. You'd have the browser, it's javascript engine, and your own runtime in node or python or however too. Electron develops patches that make chromium more performant and feature ready for desktop. Electron conjoins the chromium and node v8 event loop to take advantage of libuv - again a performance improvement. The decision of webviews and electron is based on what you're trying to do. If it's simple html/JS that's pretty much self contained then sure.

andrew_ 6y ago
It's been a minute since I attempted it on Windows, but transparency of borders and borderless windows with the webview on Windows was next to impossible. It's one of the reasons we used Electron. I'm curious to know if they've solved that, but can't find my mention of it.
saagarjha 6y ago
If you cared about performance, would you really be using Electron?
- innocenat 6y ago
  Yes. Why not? HTML/CSS great (from the development POV) for UI, and I can always write the performance critical code in C and linked them to the electron HTML/CSS frontend.
  - saagarjha 6y ago
    Presumably, if copying some data between JavaScript and native code in a slightly roundabout way was an issue, you wouldn't run things through web technology in the first place…

dfabulich 6y ago

People have been trying the WebView approach for years. (Projects include: Quark, Electrino, DeskGap, Revery, and Neutralino.) Historically, it worked terribly on Windows. On Windows, if you used the OS WebView, your Windows 7 users would be forced to use IE11 to run your app, even if they had a newer/better browser installed locally. On Windows 10, you'd get whatever random version of Edge was installed, or the new Chromium-based Edge. In 2021, we're in a new era for Windows WebViews, thanks to Microsoft shipping WebView2 at the end of 2020, which ensures that the OS-provided WebView will be a modern version of Chromium. https://docs.microsoft.com/en-us/microsoft-edge/webview2/ https://docs.microsoft.com/en-us/microsoft-edge/webview2/ Tauri supports WebView2 and I bet it will work a lot better than historical approaches. Support is still pretty dicey on other platforms, though. macOS doesn't have anything like WebView2, so if you want to support a five-year-old version of macOS (which isn't that old in desktop terms), you'll be forced to support and test your app on a five-year-old version of Safari. (The user might have upgraded to a two-year-old version of Safari, but they might not, if they prefer Firefox or Chrome, and that's now your problem.) The easiest and best way to improve the user's experience on old OS versions is to provide your own copy of Chromium, like Electron does. At that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day? Having said that, if you can keep your OS-version support matrix tight, Tauri might work OK for you.

CommonGuy 6y ago
We use the WebView approach for Kreya[1], though not with Tauri. We had some occassional issues with Chromium/Safari differences, but otherwise it works fine. We use WebView2 on Windows, Safari on macOS and WebKit2GTK on Linux. Not shipping a whole Chromium installation on each install and update reduces the installer and on-disk size a lot! [1] https://kreya.app https://kreya.app
- dfabulich 6y ago
  https://kreya.app/docs/getting-started https://kreya.app/docs/getting-started I see issues here! > Apple Silicon (M1) is not yet supported. And on Linux, > you may install Kreya by downloading the tarball. Note that both libgtk-3 and libwebkit2gtk-4.0 dependencies are required. Install them manually if they aren't present on your system. libwebkit2gtk is, itself, _an embedded browser_, 44MB installed size, plus dependencies. It's convenient that you can make Snapcraft install it for you, but that's not really different from making Snapcraft install Electron and running that.

jiofih 6y ago

It didn’t take long, this approach was around years before Electron came in. But the reason Electron picked up is precisely the stable APIs with cross-platform compatibility that comes from bundling chromium. You won’t get that here.

ksec 6y ago

What we need is a subset of HTML features that are known to work across all major browser. From Firefox, Safari /WebKit on other MacOS, and Chrome. Or something that compiles to the compatible HTML code for those platform with 100% accuracy. Unless that happens, you are dealing with godzillion number of edge cases in hundreds of different System Browser. But even if such language or subset of feature exist, it will still not be as good or as be limited compared what is possible on top of current Electron. Which means from a user perspective, the Dev is optimising for something they rarely cares about; download size. Given memory CPU and Memory usage to electron.

eivarv 6y ago
What we need is a subset of HTML features that are known to work across all major browser. From Firefox, Safari /WebKit on other MacOS, and Chrome. What, you mean like standards? Web standards?
- ksec 6y ago
  The problem is not all current Web Standards are supported across all System Browsers. So the Subset is meant as lowest common factor. How do get anything to work when you have customers using IE?

deleted 6y ago

[deleted]

hinkley 6y ago

I think my best-case scenario would be an Electron replacement that is not so bloated and also keeps parts of Firefox well-funded and people looking at compatibility. Elevating a new stack is a good consolation prize.

lenkite 6y ago

People have already tried this approach. https://github.com/webview/webview https://github.com/webview/webview https://github.com/yue/muban https://github.com/yue/muban ..and several others too.

themihai 6y ago

>> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. I believe there are dozens of projects using Webview and market themselves as a lightweight "Electron". The development for these apps takes longer (as you need to test for different webview versions/vendors) and the end product is worse as some features are shimmed or you just choose to not support them due the effort required. Of course this depends by project. I've developed a media player and considered webview. Soon enough I've found the limitations of safari, ie webview and even firefox webview on audio/video codecs is a blocker. Next was indexeddb and some random performance issues. It didn't took long to realise that it's hard to compete with native apps using Electron but its even harder using different webview versions. I will consider webView again when WASM gets native DOM access and audio/video decoding becomes available (performance wise) in WASM.

elonvolo 6y ago
The dirty little secret is that a software project with two different native codebases is often cheaper, with a faster time-to-market, than a cross platform browser-tech based solution that had just one codebase. The BS of the browser tech world compounded over time and a million edge cases eventually eats up all the one-codebase, cross-platform savings.

morpheuskafka 6y ago

It will, but browser diversity is not what you want for an electron-style app. The whole point of Electron is that it's a browser you control--you set the site permissions, you control the version and updates, you know exactly what it supports. That's what makes longer-lasting, more native experiences possible with a low development cost.

mike_ivanov 6y ago

> why it took this long for someone to try this approach it didn't - there is already a few projects like that, with Neutralino being the most notable.

whywhywhywhy 6y ago

>I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. The current generation of web developers who grew up within the Chrome ecosystem has zero interest in spending time on cross browser support. Even if the user had to install 4GB of chrome runtime they'd still argue it's better than them making it work in Chrome, Edge-Chrome and Safari WebKit. Not saying everyone, maybe my companies hiring process is screwed but every developerbar 1 that I've worked with over the past 4 years has been the same and even getting them to test in one other browser than Chrome is honestly like pulling teeth. Infuriates me as someone who's first job was CSS+HTML supporting IE 5.5-7.0, Firefox, Opera and Safari. The amount of times I've heard "Can't we just tell them to use Chrome?" when talking about users is getting absurd. The lack of understanding that a few hours of their job being slightly more difficult can add up to saving literal lifetimes of time saved or entire data centres of disk space when you extrapolate the savings across your user count. I know its maybe cheap to roll out a Steve Jobs quote but this one still resonates with me. "Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" https://www.folklore.org/StoryView.py?story=Saving_Lives.txt https://www.folklore.org/StoryView.py?story=Saving_Lives.txt

userbinator 6y ago
The current generation of web developers who grew up within the Chrome ecosystem has zero interest in spending time on cross browser support. The scary power of Google.

tssva 6y ago

It seems every couple of months there is an alternative to Electron posted here which uses system webviews. A quick search turns up a wide variety of them.

lucideer 6y ago

> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Which is why many many people tried this approach long before Electron came along. Electron has been successful largely because it deviated from this: it swallowed the bitter pill of bundling the heavy duplicated webview in order to ensure a consistent development target.

trustdragon 6y ago

It is a good idea but it is not a new idea the interesting history of these sorts of frameworks is that Google actually created a framework that did this and stopped development on it. the code is still on GitHub. And there's a bunch of other frameworks that use a variety of different languages not just rust as the application language that also have this idea of not bundling chromium but instead using the system webview for rendering HTML and JavaScript. You can find a bunch of different approaches in lists like "alternatives to electron." There's some on GitHub. I took a slightly different approach where instead of using the system web view which I thought you know is going to be inconsistent across systems and it's not going to support the latest HTML JavaScript and security features I used the assumption that the user already has chrome installed which works in a high number of cases or can download and install it if that's not the case. predictably I suppose some people express to satisfaction that it was not using Firefox. using Firefox becomes more possible and more likely I suppose as firefox's support for the dev tools protocol achieves parity with chrome support for that. https://github.com/c9fe/graderjs https://github.com/c9fe/graderjs