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?
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.
> 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.
> Webviews are also a moving target so you need a big testing matrix.
Even worse, an OS update after you ship your app can spontaneously break it on end user's machines without you knowing or being able to do anything about it.
At least with the web, when new browser versions come out, you can fix your site since users essentially "install" it every time they refresh the page. But an installed app that runs on top of a spontaneously updated framework is the worst of both worlds.
But why would the system webview be less resource hungry? If it runs in an own process instance, the only memory you safe is (maybe) the executable code (i.e. maybe 100MB max).
Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save.
The advantage of using the system webview is that you can update this component, in case there are any vulnerabilities or so.
> don't have to deal with all the small but time consuming compatibility quirks.
Good, then developers might start to develop against standards instead of handpicked browsers. Or if they use a future (unstable) standard that is their own headache (as opposed to user’s; which are subsequently in practice forced to use chromium derived browser).
An app developed against a single browser (as opposed to the web standard) should be considered what it is, an ugly hack, and developers that do it should only do it for their own private apps never to be published until it is standard compliant.
One approach that you can take to deal with this is to mentally back way the fuck off the 1990s on what your UI expectations are.
Give up pixel-accuracy and fine-grained control of your app's UI layer, and just treat it how people like Peter Norvig and Chris Lattner treat their home pages.
There isn't any browser with even 0.1% share that can't render those things.
You also don't really have to go as far as those guys do, leaving the font 14-point Times New Roman and using HTML 1 tables. You can add some style, fonts, etc... just don't add anything that would make it _not work_ if somebody opened it in Netscape Navigator 4.
There is definitely a big downside, in that your app won't look all dope and modern. For many apps that is a deal breaker. Also, some UIs really do require a higher fidelity UI. Not all UIs are just like, buttons and menus (although a lot are).
But there is also a big upside: durability, in the sense that your app's UI will work on most 10-year old computers, and most computers 10 years from now.
I wonder if it would make sense for Tauri to support shipping a bundled webview engine for platforms where the native webview is outdated or otherwise problematic for your application? With the idea that you could eventually migrate to system webviews.
That way, you're building with cross-platform in mind but still have the option to pick a stable target if you need it, compared to solutions like Electron where you don't have that choice.
> A major benefit of Electron is that you can develop against a single browser version and don't have to deal with all the small but time consuming compatibility quirks.
Somehow I doubt the ideal solution is to bundle a web browser with every app. Electron feels like a prototype that went out of control.
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/ 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.
Fortunately MacOS users upgrade very quickly. High Serria which is slowly waning at 7% came out in 2017. Compared to windows where twice as many (16%) at still using Windows 7 and won't be able to download the Webview2 update which Microsoft kindly provides.
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!
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
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.
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.
>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?"
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.
> 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.
...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.
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.
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.
> 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.
>> 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.
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.
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.
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.
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.
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.
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.
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).
> 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.
As far as I know that's not accurate and the default webview on Windows is still the old Edge based one, not Chromium.
The plans here are somewhat unknown I think, but right now you have to force the user to download and install (or bundle an installer) for WebView2 or Edge beta channel if you don't want to support old Edge.
Gtk-webkit is also quite different from Safari, you can't assume they are just the same.
This kind of makes me think... is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? Or is this impossible?
It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is simpler - it trades of performance for uniformity of experience across the major platforms.
But I'm wondering if it really has to be this way. Do modern browsers really need 2G of RAM in order to send and receive messages in a chat box (looking at you, Slack).
I like Sciter for the possibilities, but it needs better compatibility with web standards. Being able to port an existing application that uses React -for example- and have it just run would be the cat's meow.
Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.
From what I understand the internals (aka the engine). That is a problem IMO. I understand it's to create a dependency on the maintainer in order to make money, but yeah... it's the reason I've stayed away thus far.
> the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet
Is this really different from the current state of web development? Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. For apps that are basically installable websites (like Slack, which has a perfectly functional webapp) this doesn't seem like that far of a stretch.
> Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum.
Do many companies actually do this though? I've only ever been with companies that test against Chrome. The one time at FF bug was found, that company told that client to switch to Chrome.
I know there was a kerfuffle about Airbnb and Groupon only doing Chrome as well.
Not much different but enough to be dangerous. Older Windows use Trident, 10 still uses EdgeHTML, many people are stuck with old Androids that don't have up to date engines (not sure if Android is a target, wasn't easy to find in their website), and webviews have access to the system in ways a website doesn't (like reading files or using the camera without having to ask for permission or being allowed to issue requests to arbitrary domains).
> is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint?
That's basically the history of Flutter. The initial goal was something like "Web: The Good Parts" and the results of that experiment led them to where they are now.
I've performed a couple experiments remaking Electron apps using Sciter.
My first target was https://github.com/AkashRajpurohit/clipper, a neat little clipboard manager. The owner was gratious enough to officially list my project under the "Clones" section of his readme =D The result was a 6mb file, compared to the original 165mb Electron app.
The second attempt was https://github.com/girkovarpa/temps-lite, an aesthetically-pleasing weather app which was motivated largely by the fact that the original was broken and abandoned yet still had people who wanted to use it. According to the open issues and forks trying to resurrect it, anyway. The file size savings were similar to the former, and they start virtually instantly. Unlike the Electron apps which have a bit of delay and then a blank window before they finish starting up.
This is similar to what Plotly did with their Kaleido project[1] that generates static images of plotly.js visualizations. Instead of using Electron or Selenium, they recompiled Chromium, stripping away a bunch of the parts they didn't need. This resulted in a cross-platform build that is much lighter weight.
> The goal of the Kaleido project is to make static image export of web-based visualization libraries as universally available and reliable as it is in matplotlib and ggplot2.
> To accomplish this goal, Kaleido introduces a new approach. The core of Kaleido is a standalone C++ application that embeds the open-source Chromium browser as a library. This architecture allows Kaleido to communicate with the Chromium browser engine using the C++ API rather than requiring a local network connection. A thin Python wrapper runs the Kaleido C++ application as a subprocess and communicates with it by writing image export requests to standard-in and retrieving results by reading from standard-out.
> By compiling Chromium as a library, we have a degree of control over what is included in the Chromium build. In particular, on Linux we can build Chromium in headless mode which eliminates a large number of runtime dependencies, including the audio, video, GUI toolkit, screensaver, and X11 dependencies mentioned above. The remaining dependencies can then be bundled with the library, making it possible to run Kaleido in minimal Linux environments with no additional dependencies required. In this way, Kaleido can be distributed as a self-contained library that plays a similar role to a matplotlib backend.
Not just that, it allows to ship with much more api's available to the user.
That's why is not always the best approach to appeal to whats people are saying.
Here on HN this was the #1 thing that people used to ask or complain for when the topic was electron.
"They should just integrate with the system browser" was the common saying. But the the burden would be on the developer,who would not only be back to the hellish scenario of multiple browsers implementations but also having to deal with a very skinny SDK to work with.
In the end of the day, the applications deployed on Electron will win, because they will allow developers to do much more and without the application breaking here and there because of the gimmicks of each platform.
When hearing what people say, you must have in mind the kind of the crowd you are listening to. Here on HN for instance is mostly Apple users, mostly developer types, and that's the reason why they ask for the platform browser, after asking for the platform UI, because that's how apple platform users will tend to think.. and the memory thing is the fact that most here are developers.
But that's far from being representative of the whole world of users. So, you might appeal to the particular crowd here on HN, but once you are out there "in the world" you will have a hard time facing contenders that are more resourceful than you, and the worse of all, is that it is by design. You cornered yourself into it because you forgot you are in a bubble..
Wow, at least from the screenshot in the README, the binary size is much smaller. However I think that's just from the fact that they don't bundle the JavaScript engine and the rendering engine into their binary. You're right though, seems abandoned.
I wish Mozilla would do the same move as well. I remember in 2000's I had a Mozilla ActiveX that I could bundle in my applications and instant web browser without IE crap (back then was Mozilla vs IE only, Chrome was still in its infancy).
Nowadays Mozilla it seems they don't even export the old ActiveX, let alone to have their own webview equivalent.
It seems like Electron is decently optimizable for a lowish memory footprint. Both the Element and Discord desktop client run with consistently ~50MB RAM each.
You _are_ measuring the total RAM usage, right? Something like `free -m` right before starting the application, and then after it warms up?
Every time I see these "electron is not heavy, it only uses X MBs of RAM", it turns out that the author looked at a single electron process (out of typically 5-10), and then only measured RSS, completely ignoring shared memory.
Are you sure about that? Most of the time, Electron apps are split into multiple processes, and the task manager (by default) only shows the main one. Order your processes by name and I'd be surprised to see the total under 150MB.
React Native is fantastic as a user on macOS and Windows. Personally I think if there’s any hope of winning the Electron crowd over that’s it. I like to develop with stronger typed languages than JS, but there's clearly demand given electron’s popularity.
To be clear to everyone: Electron and React Native are not alike. Electron is a big web browser. React Native work completely differently: It neither renders, computes, or runs the same. React Native uses the Hermes engine, puppeteering native components.
No there isn't (with resigned sobbing tone) there isn't. Everything GUI related on desktop is depressing prehistoric garbage that still takes ages to make and if god forbid you want something nice you might as well shoot your self.
Downloaded the demo app for macOS; feels like an alien UI even though effort was clearly made to use system widgets. On the positive side, the app is only 4 MB and consumes 50 MB at runtime, so at least they've succeeded in that important aspect.
If I'm not mistaken, this is just because the CSS styling isn't that good, right? Take Slack (which uses Electron) as an example: it looks almost the same on Windows and Mac, but it looks good — because the styling (through CSS) is good.
You're talking about how the app looks, but GP was talking about how the app feels.
Slack looks nice but feels quite broken. For example, its non native context menus are beautiful, but do not dismiss properly, do not support single-click selection, do not support spacebar to pick, do not support type-select...
When I use Slack I am constantly frustrated that things don't work the way my other Mac apps work.
Its consuming more than that at runtime I believe, you just don't see it because its using webkit in another process?
I recall some discussion along those lines.
I think most companies that already decided on the electron UX vs dev effort tradeoff will happily trade user resources for a guaranteed, uniform browser version target. It makes a big difference in development and testing.
Yea, but as a user, it's disappointing, and kind of impossible for me to push back on this trend. I can avoid using these apps, but it's an impotent show of protest. It won't make a difference. User experience, native look and feel, and the user's RAM are all being sacrificed on the altar of More Comfortable Developer Experience.
Same here for Windows. Feels like using a video game UI. Probably is the basic styling, but I'm really liking the file size (2.6MB) and mem usage (app.exe using 2.7MB with the "Desktop App Web Viewer" instance using 22MB) otherwise.
The demo app has very basic styling, it isn't designed to be pretty. Since a Webview with HTML/CSS/JS is used for the GUI, you can style your app however you want.
I think a better electron would be an Electron that you can build only with the features you use(i.e I don't use websql, I don't need CORS, web notifications, nfc, bluetooth, hundreds of legacy js and css features, no pdf/print support etc). I'm pretty sure that if you can drop all the stuff you don't use you get better performance/efficiency.
It goes deeper than that. Frickin’ Spotify has a manual toggle for whether or not I want Hardware Acceleration turned on or not. It’s not the only one. I don’t have any way to know which setting doesn’t spin up my laptop fans and burn me. How about just building your app in such a way that I don’t have to manually configure that. We’ve had music players since the 90’s, I don’t see why this is so hard.
Electron apps are usually quite heavy because they bundle Chrome. Tauri doesn't and instead relies on webview, which uses a different browser engine dependent on your platform, with all the incompatibilities that come with it.
> Tauri doesn't and instead relies on webview, which uses a different browser engine dependent on your platform, with all the incompatibilities that come with it.
Isn't windows system webview now a chromium fork? This should make incompatibility on the major platforms now much less of an issue.
> Today, Tauri uses Rust for the backend - but in the not too distant future, other backends like Go, Nim, Python, Csharp etc. will be possible. This is because we are maintaining the official Rust bindings to the webview organisation and plan to let you switch out the backend for your needs. Since our API can be implemented in any language with C interop, full compliance is only a PR away.
Sounds promising. I’d love a web view front end for Python as an alternative to tkinter.
Each Electron application seems to think it's the only one running in a computer. It's the only way, I imagine, they think it's acceptable the amount of resources they need to run.
As a developer shipping executables to MacOS, Windows, and Linux today this is the only assumption I can make. I cannot assume that dependencies exist or are the correct version, I can't assume the user knows that package managers exist or that the dependencies shipped by the package managers are correct, I can't assume anything exists on PATH or LD_LIBRARY_PATH, and I can't even assume that libc or libc++ on a system will work with the executable I compiled on mine.
Meanwhile 16GB of memory is becoming common and 1TB SSDs cost less than $100. So taking up a little bit more space saves me time and money and reduces the cost to ship to my customers. Oh well.
The problem is that every app developer is starting to believe the same thing, so we just end up with more and more bloat. Computer hardware has never been more powerful but because of bloated apps actual performance feels -- to this user -- the same as it was in 2010.
It isn't your fault that you have to do this, it is that our industry hasn't created enough quality, easy to use, cross platform gui libraries for popular languages, such that the only viable place to turn is to use a whole web browser.
Readit News
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?
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.
> 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.
Even worse, an OS update after you ship your app can spontaneously break it on end user's machines without you knowing or being able to do anything about it.
At least with the web, when new browser versions come out, you can fix your site since users essentially "install" it every time they refresh the page. But an installed app that runs on top of a spontaneously updated framework is the worst of both worlds.
Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save.
The advantage of using the system webview is that you can update this component, in case there are any vulnerabilities or so.
Good, then developers might start to develop against standards instead of handpicked browsers. Or if they use a future (unstable) standard that is their own headache (as opposed to user’s; which are subsequently in practice forced to use chromium derived browser).
An app developed against a single browser (as opposed to the web standard) should be considered what it is, an ugly hack, and developers that do it should only do it for their own private apps never to be published until it is standard compliant.
Many Windows installers package one or more Visual Studio Redistributable packages into the installer. Is that not possible for these installers?
Give up pixel-accuracy and fine-grained control of your app's UI layer, and just treat it how people like Peter Norvig and Chris Lattner treat their home pages.
There isn't any browser with even 0.1% share that can't render those things.
You also don't really have to go as far as those guys do, leaving the font 14-point Times New Roman and using HTML 1 tables. You can add some style, fonts, etc... just don't add anything that would make it _not work_ if somebody opened it in Netscape Navigator 4.
There is definitely a big downside, in that your app won't look all dope and modern. For many apps that is a deal breaker. Also, some UIs really do require a higher fidelity UI. Not all UIs are just like, buttons and menus (although a lot are).
But there is also a big upside: durability, in the sense that your app's UI will work on most 10-year old computers, and most computers 10 years from now.
https://developer.microsoft.com/en-us/microsoft-edge/webview...
Old one is, of course, kept for compatibility reasons.
That way, you're building with cross-platform in mind but still have the option to pick a stable target if you need it, compared to solutions like Electron where you don't have that choice.
Deleted Comment
Somehow I doubt the ideal solution is to bundle a web browser with every app. Electron feels like a prototype that went out of control.
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/ 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.
https://gs.statcounter.com/windows-version-market-share/desk...
https://gs.statcounter.com/os-version-market-share/macos/des...
Really depends on your market I guess and how much legacy webview browser support you need.
Or really how much you'd need to add polyfills like `@babel/preset-env` to keep the JS equal.
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
Like other replies have mentioned, it's not a new idea
DeskGap uses the native OS Webviews. 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
Quark is a fork of Electrino: 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-us...https://github.com/webview/webview
https://docs.wxwidgets.org/trunk/classwx_web_view.html
https://github.com/r0x0r/pywebview
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.
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
The scary power of Google.
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.
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.
Perhaps a similar approach to https://github.com/webview/webview ?
"Tiny cross-platform webview library for C/C++/Golang. Uses WebKit (Gtk/Cocoa) and Edge (Windows)"
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.
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
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.
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 will consider webView again when WASM gets native DOM access and audio/video decoding becomes available (performance wise) in WASM.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.
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.
Deleted Comment
Elevating a new stack is a good consolation prize.
it didn't - there is already a few projects like that, with Neutralino being the most notable.
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).
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.
As far as I know that's not accurate and the default webview on Windows is still the old Edge based one, not Chromium.
The plans here are somewhat unknown I think, but right now you have to force the user to download and install (or bundle an installer) for WebView2 or Edge beta channel if you don't want to support old Edge.
Gtk-webkit is also quite different from Safari, you can't assume they are just the same.
It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is simpler - it trades of performance for uniformity of experience across the major platforms.
But I'm wondering if it really has to be this way. Do modern browsers really need 2G of RAM in order to send and receive messages in a chat box (looking at you, Slack).
Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk
10 times more compact than Tauri, 20 times less than Electron.JS
Yet it has Rust API ( https://github.com/sciter-sdk/rust-sciter ), that if someone need "Made with Rust" label :)
And it works even on Windows 2000, do you remember that thing? See: https://sciter.com/necromancing-sciter-on-windows-2000/
Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.
Deleted Comment
Is this really different from the current state of web development? Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. For apps that are basically installable websites (like Slack, which has a perfectly functional webapp) this doesn't seem like that far of a stretch.
Do many companies actually do this though? I've only ever been with companies that test against Chrome. The one time at FF bug was found, that company told that client to switch to Chrome.
I know there was a kerfuffle about Airbnb and Groupon only doing Chrome as well.
https://www.reddit.com/r/AirBnB/comments/dv7v6n/customer_sup...
https://thenextweb.com/dd/2017/11/28/please-build-websites-w...
Maybe in theory all platforms are considered, but in practice many companies just do one and the others mostly just work.
Now most of the time changes aren’t even needed. Besides maybe the odd Firefox or Safari thing.
That's basically the history of Flutter. The initial goal was something like "Web: The Good Parts" and the results of that experiment led them to where they are now.
There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.
My first target was https://github.com/AkashRajpurohit/clipper, a neat little clipboard manager. The owner was gratious enough to officially list my project under the "Clones" section of his readme =D The result was a 6mb file, compared to the original 165mb Electron app.
The second attempt was https://github.com/girkovarpa/temps-lite, an aesthetically-pleasing weather app which was motivated largely by the fact that the original was broken and abandoned yet still had people who wanted to use it. According to the open issues and forks trying to resurrect it, anyway. The file size savings were similar to the former, and they start virtually instantly. Unlike the Electron apps which have a bit of delay and then a blank window before they finish starting up.
> The goal of the Kaleido project is to make static image export of web-based visualization libraries as universally available and reliable as it is in matplotlib and ggplot2.
> To accomplish this goal, Kaleido introduces a new approach. The core of Kaleido is a standalone C++ application that embeds the open-source Chromium browser as a library. This architecture allows Kaleido to communicate with the Chromium browser engine using the C++ API rather than requiring a local network connection. A thin Python wrapper runs the Kaleido C++ application as a subprocess and communicates with it by writing image export requests to standard-in and retrieving results by reading from standard-out.
> By compiling Chromium as a library, we have a degree of control over what is included in the Chromium build. In particular, on Linux we can build Chromium in headless mode which eliminates a large number of runtime dependencies, including the audio, video, GUI toolkit, screensaver, and X11 dependencies mentioned above. The remaining dependencies can then be bundled with the library, making it possible to run Kaleido in minimal Linux environments with no additional dependencies required. In this way, Kaleido can be distributed as a self-contained library that plays a similar role to a matplotlib backend.
1. https://medium.com/plotly/introducing-kaleido-b03c4b7b1d81
That's why is not always the best approach to appeal to whats people are saying.
Here on HN this was the #1 thing that people used to ask or complain for when the topic was electron.
"They should just integrate with the system browser" was the common saying. But the the burden would be on the developer,who would not only be back to the hellish scenario of multiple browsers implementations but also having to deal with a very skinny SDK to work with.
In the end of the day, the applications deployed on Electron will win, because they will allow developers to do much more and without the application breaking here and there because of the gimmicks of each platform.
When hearing what people say, you must have in mind the kind of the crowd you are listening to. Here on HN for instance is mostly Apple users, mostly developer types, and that's the reason why they ask for the platform browser, after asking for the platform UI, because that's how apple platform users will tend to think.. and the memory thing is the fact that most here are developers.
But that's far from being representative of the whole world of users. So, you might appeal to the particular crowd here on HN, but once you are out there "in the world" you will have a hard time facing contenders that are more resourceful than you, and the worse of all, is that it is by design. You cornered yourself into it because you forgot you are in a bubble..
https://github.com/pojala/electrino
Not really. Targeting the web platform and not aiming for perfect compatibility or looking the same isn't that hard.
Nowadays Mozilla it seems they don't even export the old ActiveX, let alone to have their own webview equivalent.
You _are_ measuring the total RAM usage, right? Something like `free -m` right before starting the application, and then after it warms up?
Every time I see these "electron is not heavy, it only uses X MBs of RAM", it turns out that the author looked at a single electron process (out of typically 5-10), and then only measured RSS, completely ignoring shared memory.
Tauri may be it, but the desktop SO needs this moment, I don't want to see 50 years on and Electron is still being used.
I've had some nice experiences using PyInstaller to create desktop apps.
To be clear to everyone: Electron and React Native are not alike. Electron is a big web browser. React Native work completely differently: It neither renders, computes, or runs the same. React Native uses the Hermes engine, puppeteering native components.
We got Electron, and other browser based toolkits.
Slack looks nice but feels quite broken. For example, its non native context menus are beautiful, but do not dismiss properly, do not support single-click selection, do not support spacebar to pick, do not support type-select...
When I use Slack I am constantly frustrated that things don't work the way my other Mac apps work.
Dead Comment
Electron apps are usually quite heavy because they bundle Chrome. Tauri doesn't and instead relies on webview, which uses a different browser engine dependent on your platform, with all the incompatibilities that come with it.
Isn't windows system webview now a chromium fork? This should make incompatibility on the major platforms now much less of an issue.
Sounds promising. I’d love a web view front end for Python as an alternative to tkinter.
Meanwhile 16GB of memory is becoming common and 1TB SSDs cost less than $100. So taking up a little bit more space saves me time and money and reduces the cost to ship to my customers. Oh well.
Oh if only that was enough. My Safari is currently using 25.33GB¹ and and it regularly goes over 30.
> 1TB SSDs cost less than $100
Ah, if only it was that easy.
¹ (According to iStat Menus; it's harder to see in Activity Monitor due to the separate processes.)
[1]https://news.ycombinator.com/item?id=26120743
Dead Comment