Tauri: An Electron alternative written in Rust(tauri.studio)
tauri.studio
Tauri: An Electron alternative written in Rust
https://tauri.studio/
437 comments
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.
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
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.
Also: a lot of our "Electron" apps are essentially Electron frontends to the existing web frontend.
For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority.
IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.
For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority.
IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.
> That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway.
Coincidentally, Slack doesn't fully work in Safari or traditional Edge. Video calls only work in Chromium-based browsers, and in the Electron app which is of course also Chromium.
This is actually the thing that finally got me to switch back to Chromium last week, after using Safari and Firefox for the better part of a decade. The Electron app sucks, I don't like switching between browsers for usability reasons, and I need to make Slack calls for work.
Coincidentally, Slack doesn't fully work in Safari or traditional Edge. Video calls only work in Chromium-based browsers, and in the Electron app which is of course also Chromium.
This is actually the thing that finally got me to switch back to Chromium last week, after using Safari and Firefox for the better part of a decade. The Electron app sucks, I don't like switching between browsers for usability reasons, and I need to make Slack calls for work.
How does one get the Slack sidebar inside a browser tab? I loathe the Electron app, but don't have a different viable way to manage 30-odd workspaces.
Slack originally was platform specific webviews, and migrated to avoid issues like what is mentioned in this thread. One of the engineers who did it has even commented on HN to explain this.
This is probably the comment you're talking about: https://news.ycombinator.com/item?id=18763449. I was unconvinced then, and I am even more unconvinced now as I run a fully native Cocoa Slack client on my Mac that was written by one person reverse engineering APIs.
Nobody ever said that Slack couldn't be implemented in Cocoa, and it's really not remarkable that someone did it. ;P
You and I both know that one person can write UI in a vacuum, but there's a litany of other challenges that come up when positioning an application across platforms - sharing code, resources, etc. If all you look at it on is a technical level, you're doing the problem a disservice.
You and I both know that one person can write UI in a vacuum, but there's a litany of other challenges that come up when positioning an application across platforms - sharing code, resources, etc. If all you look at it on is a technical level, you're doing the problem a disservice.
That same reasoning is why Google is having a YouTube app on AppleTV which does not use native widgets, so bluetooth keyboards don't work, scrolling is off etc.
It's not that they cannot afford building 10 native AppleTV apps in parallel and pick the best one.
It's not that they cannot afford building 10 native AppleTV apps in parallel and pick the best one.
It also launched 8 years ago; the web has changed a lot since then. Edge wasn't even around until 2015, much less being used for webviews.
This sounds like you didn't look up and read the comment in question. Problems with cross-platform webviews stopped being the HTML/CSS/JS layer long ago; it's integration, availability, and rate-of-updates that are common blockers.
Call me when Microsoft actually ships WebView2 with the OS.
Call me when Microsoft actually ships WebView2 with the OS.
if you would link to that comment it would be helpful
https://news.ycombinator.com/item?id=18763449
"This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.
* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.
* We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."
* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host. "
"This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it.
* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.
* We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."
* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host. "
[deleted]
[deleted]
That's fine for someone who already keeps current with front-end stuff, but someone who is a desktop app developer is more likely to just go native than try to make a desktop app that tracks 3+ browser engines of wildly varying versions (luckily 7 is out of support now, but it still might be desired to support for some desktop apps in which case now you have IE to deal with). Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.
> Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.
I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business decision, not an enlightened technical one.
What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.
I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business decision, not an enlightened technical one.
What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.
> Instead of writing platform specific apps
You've answered your own question as to why people write then.
> What value does electron add to the user?
It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all.
You've answered your own question as to why people write then.
> What value does electron add to the user?
It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all.
> It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all
What value does _this_ add over a web app?
I've been an exclusive Linux user since college so I'm aware of the disadvantages of app/service unavailability (I remember the dark days of running Netflix in a windows VM that I barely had enough RAM to run...).
But what's the advantage of using the Slack app over a browser tab? This is a sincere question, since enough people reference the benefit of faux-native wrapped webapps that I assume there's some value.
I seem to be the only one in my company who doesn't use Slack's app, and I'm always shocked when I see a colleague's computer freeze and have them say "ugh it's almost definitely the Slack app". I work in autonomous vehicle engineering, so these are _monster_ machines I'm talking about, capable of running the entire car's stack locally. The only advantage I can think of are desktop notifications, but 1) I'm pretty sure browsers support those and 2) is that really worth using an app that's amateurish enough that it freezes your computer regularly?
What value does _this_ add over a web app?
I've been an exclusive Linux user since college so I'm aware of the disadvantages of app/service unavailability (I remember the dark days of running Netflix in a windows VM that I barely had enough RAM to run...).
But what's the advantage of using the Slack app over a browser tab? This is a sincere question, since enough people reference the benefit of faux-native wrapped webapps that I assume there's some value.
I seem to be the only one in my company who doesn't use Slack's app, and I'm always shocked when I see a colleague's computer freeze and have them say "ugh it's almost definitely the Slack app". I work in autonomous vehicle engineering, so these are _monster_ machines I'm talking about, capable of running the entire car's stack locally. The only advantage I can think of are desktop notifications, but 1) I'm pretty sure browsers support those and 2) is that really worth using an app that's amateurish enough that it freezes your computer regularly?
I'm on Ubuntu and use the Slack app, which never causes any freezes or anything of the like. The advantages is that i know where it is ( in my taskbar and launcher) compared to it being one of my 500 open tabs, and the taskbar icon shows if i have unread notifications or messages. Furthermore, i can use it with multiple workspaces at the same time.
I feel like the push towards PWA where you "appify" those websites rather than running another instance of a full blown browser would be good indeed.
Ah yes, the panel icon. This makes a lot of sense, thank you! My os is _heavily_ customized (i3 + wmctrl + heavy scripting), so I forget sometimes what the standard floating-window workflow looks like and how difficult it can make it to manage and quickly access important windows/tabs.
> It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all.
I prefer web versions of those apps on Linux than electron. Sorry, I want to run just one browser and it is not Chrome based one.
And for sure Electron apps don't allow that ease of cross platform development as one thinks, I would argue that it is on the same level as a native app with good abstraction library (see Telegram client source on github).
It is more that they don't want to hire desktop developers (or just ones that want to learn something else than JS).
I prefer web versions of those apps on Linux than electron. Sorry, I want to run just one browser and it is not Chrome based one.
And for sure Electron apps don't allow that ease of cross platform development as one thinks, I would argue that it is on the same level as a native app with good abstraction library (see Telegram client source on github).
It is more that they don't want to hire desktop developers (or just ones that want to learn something else than JS).
For an app with no source available publicly, I would much rather have a web app in a sandbox than a "native" app (whether native or electron-style) that I would have to trust.
Electron exists because there's a horde of developers whose only tool is a JavaScript hammer, so every problem looks like a nail. That's how you end up rewriting `dd` for Chrome[π].
π: https://www.balena.io/etcher/
π: https://www.balena.io/etcher/
My god... a 200+ MB install footprint, 200+ MB of RAM usage, requires a beefy GPU just to render its window. How did we get here?
I think we got there also by desperation of lacking good cross-platform GUI toolkits.
The current state is, you either use something that looks like Windows 95 in all platforms, or web app.
What the web made possible is to anyone to create a decent custom UI with little effort. I still remember how messed up was to create a custom component for Java Swing, which I believe is still one of the easiest to do. How would you do that for QT? GTK? WxWidgets? etc
The current state is, you either use something that looks like Windows 95 in all platforms, or web app.
What the web made possible is to anyone to create a decent custom UI with little effort. I still remember how messed up was to create a custom component for Java Swing, which I believe is still one of the easiest to do. How would you do that for QT? GTK? WxWidgets? etc
I'll take Win95 in a heartbeat; consistent, accessible, responsive and clear. Vastly superior to the majority of web interfaces.
Also totally inflexible, you better have the right-sized screen/resolution: too small and you can't see that "ok" button; too large and you'll have a ridiculously small and crammed winform to fill/see your information.
Take a look at Telegram client, looks great on Linux, not sure how it looks on macos or Windows.
Interesting Telegram has both a native (Swift/Obj-C not sure which) and an cross-platform-codebase app for macOS. The former is called Telegram for macOS and the latter Telegram Desktop. Both are on the app store even. So it would actually be a very good case to compare performance, etc. The native one presumably shares a lot of code with iOS which is probably why it exists at all, and it supports secret chats. Otherwise they have similar but slightly different design and features.
However, I think the Telegram Desktop client is not Electron either, it is just regular C++ compiled on different systems.
However, I think the Telegram Desktop client is not Electron either, it is just regular C++ compiled on different systems.
Yes, Telegram Desktop is a normal C++ app: https://github.com/telegramdesktop/tdesktop
So a cross-platform is quite easy, Electron one would need to be tested for different webviews on each system.
So a cross-platform is quite easy, Electron one would need to be tested for different webviews on each system.
I might be crazy, but for me it's faster and more convenient to download and run Etcher than to read up on dd command arguments and device paths. Storage space is plentiful for me. RAM isn't an issue as it's only run once in a blue moon.
Is it crazy bloated and resource hungry for what it does? Undeniably! Does it matter? Not for me.
Electron resource use can be painful for apps that are running constantly, like Discord, VSCode and Slack. For utilities like Etcher, who cares.
Is it crazy bloated and resource hungry for what it does? Undeniably! Does it matter? Not for me.
Electron resource use can be painful for apps that are running constantly, like Discord, VSCode and Slack. For utilities like Etcher, who cares.
I realize I'm replying six days later - but I can't help mentioning that the "dd situation" is even crazier than it first appears: you can just use `cp foo.iso /dev/sdb` or `cat > /dev/sdb`.
https://unix.stackexchange.com/a/189091/220387 https://eklitzke.org/the-cult-of-dd
https://unix.stackexchange.com/a/189091/220387 https://eklitzke.org/the-cult-of-dd
The actual duplication is done in the Node.js runtime, not the V8 runtime inside of the Chromium GUI layer.
I do wish they had a command-line version that just ran node without Chromium, but there is a use-case to have a simple foolproof application like this; these days there are a lot of people who need to image drives like this and would be best not to mess with dd on their first time.
And dd doesn't exist for Windows so you've got to use some tool or another like this.
I do wish they had a command-line version that just ran node without Chromium, but there is a use-case to have a simple foolproof application like this; these days there are a lot of people who need to image drives like this and would be best not to mess with dd on their first time.
And dd doesn't exist for Windows so you've got to use some tool or another like this.
In fairness, for some reason Etcher works sometimes when other things don't.
It might be because it is slower and doesn't overheat my usb sticks, I don't know, but if nothing else works you can try etcher.
(Not sure how I found out, can have been something I read or a recommendation by a colleague 3 a 7 years ago or something.)
It might be because it is slower and doesn't overheat my usb sticks, I don't know, but if nothing else works you can try etcher.
(Not sure how I found out, can have been something I read or a recommendation by a colleague 3 a 7 years ago or something.)
Honestly, this site is the only place I really hear about the supposed horror of electron. The resource issue doesn't seem to effect me or people in the 7 slacks I'm in all day.
My 6 year old MacBook runs slack, Xcode, android studio, safari, chrome, messages, vs code, vim, iterm2, preview, battle.net and hearthstone all the time without issue, really.
I think for the average user, they'd rather have more features across platforms more quickly than a smaller resident memory footprint and install size.
My 6 year old MacBook runs slack, Xcode, android studio, safari, chrome, messages, vs code, vim, iterm2, preview, battle.net and hearthstone all the time without issue, really.
I think for the average user, they'd rather have more features across platforms more quickly than a smaller resident memory footprint and install size.
For a counter-anecdote, I've seen the Slack app freeze up colleagues' workstations many times, and these are monster machines designed to run an autonomous vehicle stack on raw sensor data.
> I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app
The point is that its effectively a web app.
> What value does electron add to the user?
They have a desktop app faster than if it was being built natively.
The point is that its effectively a web app.
> What value does electron add to the user?
They have a desktop app faster than if it was being built natively.
Or at all, how many Electron apps would bother with native Linux clients for example. Some maybe but certainly not all and probably not most either.
Electron app is not a native Linux client, it is just a browser app.
If you ran that app in a tab it gives you much better performance and less memory used.
That all depends on how the app is written. The idea of Electron is to bring the web app frontend experience to apps which are fundamentally not able to run in a browser, such as VS Code, Etcher, etc. Writing to raw device files, listening to ports, using the full CPU resources and timers not available in the browser, using more memory, etc.
If you just package an existing website into an Electron app that is a waste of time and user resources. Electron is intended to combine a web-based presentation/UI layer with a Node.js layer that supports access to native resources, unlimited storage, persistence outside the browser, etc. If you are not making meaningful use of these capabilities a PWA would be sufficient.
Overall, I do prefer native apps, although there are examples out there such as VS Code that have achieved UI excellence without it. Although, I really only like that on macOS... on Windows I prefer the older Windows Forms style rather than the new Modern UI, and on Linux there is a bit of style mismash between Qt and GTK apps already.
If you just package an existing website into an Electron app that is a waste of time and user resources. Electron is intended to combine a web-based presentation/UI layer with a Node.js layer that supports access to native resources, unlimited storage, persistence outside the browser, etc. If you are not making meaningful use of these capabilities a PWA would be sufficient.
Overall, I do prefer native apps, although there are examples out there such as VS Code that have achieved UI excellence without it. Although, I really only like that on macOS... on Windows I prefer the older Windows Forms style rather than the new Modern UI, and on Linux there is a bit of style mismash between Qt and GTK apps already.
> What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.
Exactly, one can look at Telegram app, it is clean, polished and open source client written as a native app that works across many platforms (and one of few that has Linux client).
Exactly, one can look at Telegram app, it is clean, polished and open source client written as a native app that works across many platforms (and one of few that has Linux client).
Electron should be banned for the environments sake if the other reasons doesn't persuade, it's inefficient computation to energy ratio using Electron apps, when there is a lot of users like with VSCode or Slack it probably affects the global climate in a negative way
I see a lot of people in the tech industry deeply concerned with human impact on the environment and our diminishing prospects of repairing it without drastically altering our lifestyles.
At the same time the general consensus in the tech industry towards the steady increase in power requirements for everyday computing seems to be indifference.
These two viewpoints cannot be reconciled.
Every month when this Electron discussion comes up there are so many who dismiss the egregious resource usage outright on the basis that it's trivial for modern computers. I'm one of those people who use Thinkpads in 2021 for my personal computing and have no problems with it. I will never buy a Mac, and I don't want to unnecessarily spend hundreds of dollars on a modern system when refurbished ones from a decade ago work so well. I avoid Electron apps on the basis that they flatten my battery quickly. I switched from using vscode to vim on my x200 and my battery life tripled, I'm not even exaggerating here either.
These two viewpoints cannot be reconciled.
Every month when this Electron discussion comes up there are so many who dismiss the egregious resource usage outright on the basis that it's trivial for modern computers. I'm one of those people who use Thinkpads in 2021 for my personal computing and have no problems with it. I will never buy a Mac, and I don't want to unnecessarily spend hundreds of dollars on a modern system when refurbished ones from a decade ago work so well. I avoid Electron apps on the basis that they flatten my battery quickly. I switched from using vscode to vim on my x200 and my battery life tripled, I'm not even exaggerating here either.
No, they are completely reconcilable. The amount of power it takes to run a powerful consumer CPU is trivial compared to the amount of power used in many other common applications like heating, vehicles, etc. This effect is particularly pronounced when you consider that laptops use way less energy than desktops (on average) and mobile computing as a whole is displacing desktops outside of niches like PC gaming.
The environmental issue doesn't make sense IMO, but increasing hardware requirements does have real impact on accessibility.
The environmental issue doesn't make sense IMO, but increasing hardware requirements does have real impact on accessibility.
These effects scale. If every single laptop uses a small amount more power than is necessary, the relatively minor increase in energy use for one computer totals up to a significant increase in overall energy usage. Not to mention the unnecessary obsolescence of hardware. The externalities of manufacturing new hardware - and disposing of old hardware - are extremely significant. Just so what? So my perfectly good 10 year old laptop has enough RAM to run 6 Electron apps at once?
Sure, your ceiling lights use less energy than your fridge. That's not a justification for everyone to completely ignore turning them off when not needed.
Sure, your ceiling lights use less energy than your fridge. That's not a justification for everyone to completely ignore turning them off when not needed.
Even if they add up, they still pale in comparison to the amount of energy you can offset with a couple of windmills.
> it's inefficient computation to energy ratio
Probably true.
> affects the global climate in a negative way
If electricity consumption of all computers in the world doubled because of Electron apps, the total annual electricity consumption would increase by 0.01%. So probably false.
Probably true.
> affects the global climate in a negative way
If electricity consumption of all computers in the world doubled because of Electron apps, the total annual electricity consumption would increase by 0.01%. So probably false.
In 2012 PCs (only PCs, not network appliances, not data centers, not phones...) were estimated at 1.5% of global electricity use, so you're off by a good margin. And that is deeefinitely not negligible, nor is the need (and eco impact) to buy newer computers because a 2016 MacBook Pro is unusable when your work requires 4/5 electron apps side by side.
I stand corrected. Turns out I forgot to multiply by 365 days/year. The real figure is indeed in the ballpark of 2%.
No joke, if it weren't for the resource usage of vscode and the couple of other Electron apps I rely on, I wouldn't consider upgrading my workstation (which is already new enough to be energy efficient enough but maxes out at 24GB RAM) but here we are.
Maybe not banned but they could do a carbon tax like they do with motor vehicles. Or maybe like with appliances where you have an energy rating, with stickers telling you how much electricity it will use per year, possibly with tax incentives to pick the most efficient.
Problem is: how to test that? Even with the most straightforward tests, there are cheaters. Appliances have a special "eco" mode to meet the specs that most people won't use because it barely does the job. And for cars, well, VW have shown us how far companies are ready to go.
Problem is: how to test that? Even with the most straightforward tests, there are cheaters. Appliances have a special "eco" mode to meet the specs that most people won't use because it barely does the job. And for cars, well, VW have shown us how far companies are ready to go.
I run three browsers on my desktop, because the number of things that don't work properly in anything except recent Chrome is enough that I keep encountering issues, I don't want to use Chrome for my regular browsing, and both Safari and Firefox have issues on some sites.
On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome. It's still great hardware in perfect condition though, everything that does run on it is perfectly smooth and so on, and I still use it. Youtube in particular is fine. Literally the only reason to buy a new one would be to satisfy the software treadmill.
My old phone didn't run Chrome (or Safari). It had Firefox. The only reason I switched to a newer phone, using Android, was because of sites that gradually didn't run well on Firefox any more. That was annoying, having to ditch a perfectly great phone and replace it with something better for the web but worse for other things.
I have a Macbook Pro at home. I'm pretty happy with it, it's still a fine machine, I use it for work every day. It runs the latest Safari that's safe to run on it, but that's not the latest Safari, because it would have problems running the most recent OS.
This brave new world of "I'm sure we'll be fine supporting recentish Chrome and latest Safari" is a world of exclusion. I don't like the memory usage of Electron, but I prefer it to applications that are a bit broken!
Also, to be honest, I've been looking at memory usage. Electron uses much less than any of the three big browsers. You may know that Chrome famously starts a new process for each tab, and Safari does too. Firefox isn't far behind. As a result, the memory saved by running a new page in an already running browser compared with Electron isn't as much as it was long ago, back in the days when tabs shared memory. This is visible with Safari, as the website name shows up in the system utility for viewing process memory.
I know, that feels wrong somehow, but it's true.
Finally, when using a system WebView, will that save memory if it's opening a separate instance of the system's browser? It must be separate in some ways, if opening an application that uses a WebView doesn't open all your saved tabs from last time the browser was open. (And it's a horrible experience if opening an application does open all the other tabs.)
On my tablet, a number of current websites don't run even on Chrome, because the tablet isn't particularly new, so it doesn't have current Chrome. It's still great hardware in perfect condition though, everything that does run on it is perfectly smooth and so on, and I still use it. Youtube in particular is fine. Literally the only reason to buy a new one would be to satisfy the software treadmill.
My old phone didn't run Chrome (or Safari). It had Firefox. The only reason I switched to a newer phone, using Android, was because of sites that gradually didn't run well on Firefox any more. That was annoying, having to ditch a perfectly great phone and replace it with something better for the web but worse for other things.
I have a Macbook Pro at home. I'm pretty happy with it, it's still a fine machine, I use it for work every day. It runs the latest Safari that's safe to run on it, but that's not the latest Safari, because it would have problems running the most recent OS.
This brave new world of "I'm sure we'll be fine supporting recentish Chrome and latest Safari" is a world of exclusion. I don't like the memory usage of Electron, but I prefer it to applications that are a bit broken!
Also, to be honest, I've been looking at memory usage. Electron uses much less than any of the three big browsers. You may know that Chrome famously starts a new process for each tab, and Safari does too. Firefox isn't far behind. As a result, the memory saved by running a new page in an already running browser compared with Electron isn't as much as it was long ago, back in the days when tabs shared memory. This is visible with Safari, as the website name shows up in the system utility for viewing process memory.
I know, that feels wrong somehow, but it's true.
Finally, when using a system WebView, will that save memory if it's opening a separate instance of the system's browser? It must be separate in some ways, if opening an application that uses a WebView doesn't open all your saved tabs from last time the browser was open. (And it's a horrible experience if opening an application does open all the other tabs.)
Running tabs in a separate process has been a boon IMO. It’s better security and a crashed tab doesn't bring the browser down and an unresponsive tab can be killed independently.
I agree, however that is part of the argument for why Electron RAM usage should be compared against browser tabs, instead of assuming that Electron must be using a lot more ust on principle because it's separate.
One major benefit of running webapps in an actual browser like Firefox, instead of Electron, is that I can have uBlock and a handful of other defensive plugins, to prevent shady things happening behind my back.
but, conversely, browsers tend to have access to a lot of ident/auth goods that a standalone electron wouldn't, even if you're using containers. also it's perhaps harder to phish someone running an electron app because outside webpages open a real browser.
> 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.
More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.
Some corporations did that. Most didn't. The main reason IE dominated was that most people didn't care, and stuck with the default. The main reason old versions of browsers were more common than new ones was that self-updating browsers hadn't become a thing yet, and most people didn't care, and just stuck with the default. The reason most browsers stay up-to-date now is that modern browsers are all configured to self-update by default, and most people don't care, and stick with the default.
I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default, and most people don't care, and just stick with the default.
I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default, and most people don't care, and just stick with the default.
> I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default
I'm not aware of any Windows machines shipping with Chrome pre-installed. But as soon as you use any website that's owned by Google you get spammed with install links for Chrome.
I'm not aware of any Windows machines shipping with Chrome pre-installed. But as soon as you use any website that's owned by Google you get spammed with install links for Chrome.
An entire generation is being raised on Chromebooks. I wish Boot2Gecko and Firefox OS weren’t a bit ahead of themselves and had better ugh marketing.
Entire generation where? Let's say I saw exatly 1 guy with a chromebook through my life, and likely chromebooks weren't even officially sold in my country. And still Chrome is the most popular browser here.
Chromebooks outsold Macs in 2020 and schools all over the US are pushing Chromebooks on students because they're affordable and accessible to most people.
https://www.geekwire.com/2021/chromebooks-outsold-macs-world...
https://www.geekwire.com/2021/chromebooks-outsold-macs-world...
So it looks like we are talking about the States. Meanwhile Chrome dominates pretty much globally, and it doesn't correlate with Chromebooks adoption.
I remember there was a long period where everything would bundle Chrome. One wrong checkbox and your computer would be infested. Adobe Reader was one prominent example.
My experience was that IE finally got bad enough (around version 8), and Chrome got good enough, that even "grandmothers" started having everyone telling them to use Chrome, and it was so incredibly superior that you didn't have to be technical to appreciate it.
Now the reason everyone uses it is because it's psychologically the new "default", whether it is on the actual system or not. Everybody knows that's just what you do when you get a new computer: you go install Chrome. And the irony is that even now, with Edge being basically the same thing, most people don't bother to re-evaluate that default assumption that "the windows browser is bad". They just use Chrome.
Now the reason everyone uses it is because it's psychologically the new "default", whether it is on the actual system or not. Everybody knows that's just what you do when you get a new computer: you go install Chrome. And the irony is that even now, with Edge being basically the same thing, most people don't bother to re-evaluate that default assumption that "the windows browser is bad". They just use Chrome.
> most people don't bother to re-evaluate that default assumption that "the windows browser is bad"
That's one way to look at it.
Another way is to say that Microsoft has lost customer's trust and now has to work extra hard to earn it back.
IMO they've learned their lesson, at least for now, but it would also be great if others could learn from Microsoft's mistake too.
That's one way to look at it.
Another way is to say that Microsoft has lost customer's trust and now has to work extra hard to earn it back.
IMO they've learned their lesson, at least for now, but it would also be great if others could learn from Microsoft's mistake too.
Chrome didn't even exist until 2008. Firefox existed and had a foothold, but it was very much a minority. IE was >50% until 2010 and remained the single most popular browser until 2012: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#/m...
what happened in 2018-07?
In 2008, when IE7 came out, I cried of joy. I turned 22 that year, so the 7 years with only IE6 and Firefox was a significant chunk of my life. Firefox showed us that the web wasn't finished and could still be improved, and then came Firebug which made Firefox first web dev the obvious choice. But the vast majority still used IE6, so there was always a miserable step in the project of fixing all the IE bugs. After doing it for years and knowing your foe, it was by then a relatively quick and manageable experience. The real pain was in knowing all the CSS2 features and other goodies that could never be used. Seeing Microsoft recognizing that, yes indeed, the web wasn't finished in 2001 was actually an emotional moment at that point.
So yeah, the situation is without doubt much better now. I think people tend to forget (or aren't aware) that Microsoft actively said "there's no more work to be done here" and stopped all progress for 7 years. There's been some progress on the web since 2014, as a point of comparison.
So yeah, the situation is without doubt much better now. I think people tend to forget (or aren't aware) that Microsoft actively said "there's no more work to be done here" and stopped all progress for 7 years. There's been some progress on the web since 2014, as a point of comparison.
I've had to say this a fair few times here, but I'll keep saying it.
IEDevToolbar, which Firebug was pretty much a clone of, came out a year before Firebug. And it took Firebug years to catch up in feature parity, as far as I remember.
So, firebug didn't make it the dev tool of choice. We all just hated microsoft. And tabbed browsing was great.
IEDevToolbar, which Firebug was pretty much a clone of, came out a year before Firebug. And it took Firebug years to catch up in feature parity, as far as I remember.
So, firebug didn't make it the dev tool of choice. We all just hated microsoft. And tabbed browsing was great.
I was young and dogmatic, so I did admittedly despise Microsoft back then. I can't recall I ever heard of IEDevToolbar, though. Did it really feature the DOM tree view where you could do CSS manipulation? I always had the impression that it was a Firebug invention, but I could be wrong about that.
The DOM inspector view in Firefox predates Firebug by years. My memory might be a bit shaky, but it may even have existed in Mozilla Web Browser?
It really looked like a 'DOM tree/tree of Javascript classes' though, not really like the inspector we have today.
It really looked like a 'DOM tree/tree of Javascript classes' though, not really like the inspector we have today.
What?
I used that IE toolbar setup for years, and it _never_ worked as well as Firebug did.
I used that IE toolbar setup for years, and it _never_ worked as well as Firebug did.
Make no mistake, it's still a dumpster fire. Just maybe less raging.
I worked on a highly complex web app for ~3 years, and we made a point to support Firefox, so whenever somebody had a Firefox-specific bug we wouldn't tell them to just use Chrome, we'd fix it. We only had 2-3 Firefox-specific issues in that entire time.
I have heard that mobile safari can be a bit more unruly than the rest, though it isn't really relevant to the question at hand
I have heard that mobile safari can be a bit more unruly than the rest, though it isn't really relevant to the question at hand
Similar. Built a very complex app officially aimed at oldIE but made a point of ensuring it worked on other browsers too, largely on a skunkworks basis. A few years later (when we're no longer actively working on the app) everyone switched to Chrome and it Just Worked. Someone tried it on an iPad and it Just Worked (modulo some fat-finger challenges with small UI affordances).
At the time, jQuery was a big help in this, especially in hiding the event model mess. Things are a lot better now. Although I do wish we had a strict compatibility-checking layer that'd warn you if you used any feature of the web platform that wasn't supported by everything you wanted to support.
At the time, jQuery was a big help in this, especially in hiding the event model mess. Things are a lot better now. Although I do wish we had a strict compatibility-checking layer that'd warn you if you used any feature of the web platform that wasn't supported by everything you wanted to support.
Anecdotally I wrote some JavaScript just today (I'm not a frontend dev but I write some simple stuff for fun sometimes). It seemed to me that every modern feature you'd care about is now widely supported. I used the JS fetch API and template strings and these things just work in modern browsers. I even encoded my web fonts in WOFF2 only, because it's so widely supported that I didn't see the point in bothering with WOFF1 too.
Tauri also uses MSHTML (Internet Explorer) on Windows. And there's no way I'm going back to developing for that.
Isn't IE just using Chrome now? Or do you mean support for old IE?
> 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.
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.
It's not hard to silently auto-update an Electron app's internals; I assume the same is true for Tauri
The issue would occur if the auto-updater itself broke as a result of an OS upgrade
Seeing as the auto-updater wouldn't have anything to do with the webview, I don't see how that's any more likely to happen in this case than it would be in Electron, or any other desktop application for that matter
[deleted]
Need a docker for electron
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.
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.
100 MB / app is significant, especially on laptops.
Slack used to use so much memory on Linux that I couldn't afford to run the desktop app and ran it inside a Firefox tab for years... seems to have gotten better somehow.
Slack used to use so much memory on Linux that I couldn't afford to run the desktop app and ran it inside a Firefox tab for years... seems to have gotten better somehow.
[deleted]
They’re not inherently more efficient (other than the reduced application size), but Safari and Edge are both more resource-efficient than Chrome.
Dynamically loaded system libraries use shared memory. You can load it once for the entire system.
That's what I mean by executable code. But that is only really minor (<100MB or so) compared to the remaining resource usage.
Ah, sorry, I missed that in your comment.
> 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.
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.
"standards" - in practice, it's "what Google wants".
This is about desktop and not web development though. I agree that pages available on the web should be standard compliant and work with all browsers.
On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?
On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?
Because then you'll get a more efficient app that people don't constantly complain about?
Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.
Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.
Especially on MacOS where Webkit usually behave differently? Like, why would webkit still require webkit prefix for Web Audio API, which is like 8 years old at this point.
To me, develop for Electron is more fun than normal web because I don't have to check whether the new web feature I am using is available everywhere (especially Safari) yet.
To me, develop for Electron is more fun than normal web because I don't have to check whether the new web feature I am using is available everywhere (especially Safari) yet.
Apart from the install size which is still not optimal, it is very much possible to write an efficient Electron app, as evidenced by Discord and Element.
That Slack, the poster child of bad Electron apps performs so badly must therefore have different reasons. Exactly the same way you can write websites in a way that is more or less efficient you can write Electron apps of varying degrees of efficiency.
That Slack, the poster child of bad Electron apps performs so badly must therefore have different reasons. Exactly the same way you can write websites in a way that is more or less efficient you can write Electron apps of varying degrees of efficiency.
Discord is efficient now? I have to restart it on a regular basis because it starts using 5+ GB of ram.
An alternative to Electron should be built using Servo and Deno, both written in Rust.
I agree, however last time I checked Servo was not that stable.
Yes, it doesn't yet render pages as good as other browsers, but we can tweak our code for it. 10x better performance and 100x less memory usage is a win.
> WebView2 has to be installed separately
Many Windows installers package one or more Visual Studio Redistributable packages into the installer. Is that not possible for these installers?
Many Windows installers package one or more Visual Studio Redistributable packages into the installer. Is that not possible for these installers?
I question how major that benefit is. I think strict Electron-only apps are not really that common. All the ones I use have a web version.
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.
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 have to post it here because it's on top: On Windows the new WebView is Chromium.
https://developer.microsoft.com/en-us/microsoft-edge/webview...
Old one is, of course, kept for compatibility reasons.
https://developer.microsoft.com/en-us/microsoft-edge/webview...
Old one is, of course, kept for compatibility reasons.
Yes, but it is not installed by default. You have to install it separately, at least for now,which makes things a lot more complicated if you want your app to rely on it.
Edge is pushed to the vast majority of PCs, and on those machines, I believe it provides a system-level webview2 component. You can choose to package your own webview2 into your app if you want the extra compatability that offers at expense of app size and ram usage
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.
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.
>> I wonder if it would make sense for Tauri to support shipping a bundled webview engine for platforms where the native webview is outdated
I guess you can ship an electron version for these platforms where native webview sucks. Chances are that once you do the electron app you start doubting the benefits of shipping a webview based app.
I guess you can ship an electron version for these platforms where native webview sucks. Chances are that once you do the electron app you start doubting the benefits of shipping a webview based app.
[deleted]
A major benefit of Electron to Google is the amount of FOSS developers helping to turn what is left of the Web into ChromeOS.
any idea when windows webview will switch over to Chromium?
> 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.
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.
Nearly every successful technology is a prototype that went out of control :)
That doesn't mean we shouldn't try and improve on things given the opportunity, but it's not an indictment either
That doesn't mean we shouldn't try and improve on things given the opportunity, but it's not an indictment either
I think they're overstating the browser compatibility problem too. It was really bad 15 years ago, but today it is almost a non-issue. Between significantly improved standardization of web technologies, and new tricks like polyfills, I think it has become pretty uncommon for apps to not just work on multiple browsers without any tinkering.
"almost a non-issue" doesn't sound very convincing to me.
As someone who doesn't write GUIs often, I just don't want to have to worry about it at all. What's the cost of electron over webviews? 100mb hdd space? On the other side of the trade, never having to worry about cross platform concerns again? Not having to support or test on multiple platforms?
Seems like a no brainer to me. But it's entirely possible, even likely, that I'm putting too much faith in electron, or that there are better options I just don't know about.
As someone who doesn't write GUIs often, I just don't want to have to worry about it at all. What's the cost of electron over webviews? 100mb hdd space? On the other side of the trade, never having to worry about cross platform concerns again? Not having to support or test on multiple platforms?
Seems like a no brainer to me. But it's entirely possible, even likely, that I'm putting too much faith in electron, or that there are better options I just don't know about.
I really don’t share your point of view, but I understand it, for me feels like we as developers are getting worse and worse with the time, we get every year more powerful machines but our software is getting worse every year, who cares about performance if is cheap to develop, maybe if our apps uses less resources it would have less impact in the environment (less energy consumption is better for everyone, except for the lazy developers).
I really hate electron apps, for example you have teams, that is written in electron, in linux is somehow better than the web version but is just way worse than the windows/mac versions, in web you can view 2 cams, linux 4 but in mac and windows you have more cams at the same time and also a lot of features that are missing in linux, so I don’t see too much the benefits of electron here, just pure laziness of microsoft not willing to invest in a better cross platform app.
I really hate electron apps, for example you have teams, that is written in electron, in linux is somehow better than the web version but is just way worse than the windows/mac versions, in web you can view 2 cams, linux 4 but in mac and windows you have more cams at the same time and also a lot of features that are missing in linux, so I don’t see too much the benefits of electron here, just pure laziness of microsoft not willing to invest in a better cross platform app.
I also hate electron apps, I refuse to install them on my personal machine, and use a(n independent) web browser.
Efficient software is great, the cool parts of the projects I work on are efficient. In my case, the GUI doesn't need to scale in the same way, and I'm pretty confident the customer would rather have better cross platform support (at a lower cost than if we had to test a bunch of OS web views) than 100MB of their disk back.
But yeah, there are plenty of examples of software I use where I disagree. Although this is often based on my aesthetic dislike for an inelegant system, than on any kind of resource constraint.
Efficient software is great, the cool parts of the projects I work on are efficient. In my case, the GUI doesn't need to scale in the same way, and I'm pretty confident the customer would rather have better cross platform support (at a lower cost than if we had to test a bunch of OS web views) than 100MB of their disk back.
But yeah, there are plenty of examples of software I use where I disagree. Although this is often based on my aesthetic dislike for an inelegant system, than on any kind of resource constraint.
> I just don't want to have to worry about it at all
And in doing so you're prioritizing your needs over all of your users'. I think it's fair to claim that a minor convenience to you, at the cost of inconvenience to all your users, might be something you may want to deal with.
And in doing so you're prioritizing your needs over all of your users'. I think it's fair to claim that a minor convenience to you, at the cost of inconvenience to all your users, might be something you may want to deal with.
Actually it's the opposite. I know my users care more about cross platform support, or any other feature I could whip up, rather than 100MB HDD space.
I cordially dislike Electron apps, but once one factors in opportunity cost given limited developer manpower, the trade-off you're choosing to make here is quite likely entirely rational.
I would prefer to live in a world where I didn't believe the last sentence to be true, but in the current world I still think it is :)
I would prefer to live in a world where I didn't believe the last sentence to be true, but in the current world I still think it is :)
[deleted]
I use Chrome, Safari and Firefox on a Mac.
In my experience, unfortunately it isn't true that apps work with very high reliability. This is why I use multiple browsers. I don't want to use Chrome, and I encounter new websites with functionality that don't work properly in Safari or Firefox quite regularly. Some of this is even quite basic functionality.
From things like shopping carts where the final payment button doesn't work in Firefox (nothing happens), to video conferencing that sort-of works in Safari but then the audio breaks while it is reliable in Chrome.
Even GitHub doesn't render properly in Safari occasionally (the page is full of weird size text and giant rectangles). But that's almost certainly a Safari bug.
In my experience, unfortunately it isn't true that apps work with very high reliability. This is why I use multiple browsers. I don't want to use Chrome, and I encounter new websites with functionality that don't work properly in Safari or Firefox quite regularly. Some of this is even quite basic functionality.
From things like shopping carts where the final payment button doesn't work in Firefox (nothing happens), to video conferencing that sort-of works in Safari but then the audio breaks while it is reliable in Chrome.
Even GitHub doesn't render properly in Safari occasionally (the page is full of weird size text and giant rectangles). But that's almost certainly a Safari bug.
This is exactly the problem I was suggesting might be improved by an increase in browser diversity. 9/10 times, the issue isn't the browser itself, the issue is that the dev didn't bother to test and find the (handful of often small and easy to fix) bugs in other browsers. If they were forced to do QA - and ideally, had to adhere better to the actual standards to make their own jobs easier - you might have an easier time using those apps (and the libraries they depend on) in other browsers.
I think this is more a problem with developers working in Chrome and using Blink-specific features. I stopped having compatibility issues with my apps when I moved to Firefox years ago.
Some of it is Blink-specific, but some of it is silly Javascript stuff. How else do you explain a shopping cart final payment button not working.
I like development in Firefox too. When I was doing it intensively (just ~2 years ago), I found some of the CSS I was using behaved differently between Gecko, WebKit and Blink, though (and differently again in Android's pre-chrome browser), so I reconfirmed that I do need to test some things across all browsers. By differently, I don't mean prefixed browser-specific CSS (although there is that), I mean standardish things like table row height calculations showed up significantly differently, certain border highlights, and a number of WebKit rendering bugs that Gecko did not have. Key-event based text editing and wheel events are also significantly different, even more so when you include the common mobile browsers.
I like development in Firefox too. When I was doing it intensively (just ~2 years ago), I found some of the CSS I was using behaved differently between Gecko, WebKit and Blink, though (and differently again in Android's pre-chrome browser), so I reconfirmed that I do need to test some things across all browsers. By differently, I don't mean prefixed browser-specific CSS (although there is that), I mean standardish things like table row height calculations showed up significantly differently, certain border highlights, and a number of WebKit rendering bugs that Gecko did not have. Key-event based text editing and wheel events are also significantly different, even more so when you include the common mobile browsers.
> How else do you explain a shopping cart final payment button not working.
Given the megabytes of JavaScript on many websites, the chances that some of it depends on some random VM internal quirk is quite high.
Given the megabytes of JavaScript on many websites, the chances that some of it depends on some random VM internal quirk is quite high.
At least with writing uncomplicated web applications it was still quite easy to have it compatible with the major browsers, you just had to test the web application with them as you wrote it to make sure. Compatibility problems didn't even come up very much while building it if you stayed reasonably within the boundaries of standards that were well entrenched. The biggest issue was how little CSS IE6 supported, if you did anything fancy with CSS and it didn't work with IE6 you had to include an IE6 specific hack, fortunately that was easy and worked completely fine with other browsers.
There were problems with internal off the shelf applications whose user interface was built for IE6 only. The funny thing is those applications still worked well with the Firefox of the time, but IE9 broke compatibility with them and the applications didn't work on IE9, but IE10 got released and was compatible with them again.
There were problems with internal off the shelf applications whose user interface was built for IE6 only. The funny thing is those applications still worked well with the Firefox of the time, but IE9 broke compatibility with them and the applications didn't work on IE9, but IE10 got released and was compatible with them again.
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.
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.
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
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/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.
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.
The Apple Silicon (M1) issue is because .NET (which we use for our "backend") doesn't support it yet.
Linux does not have a core WebView out of the box, so libwebkit2gtk is the closest alternative. Not optimal, but it works. Looks like Tauri uses libwebkit2gtk too.
Linux does not have a core WebView out of the box, so libwebkit2gtk is the closest alternative. Not optimal, but it works. Looks like Tauri uses libwebkit2gtk too.
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.
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.
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.
Webview2 supports Windows 7 according to the link in the comment you're responding to.
> 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/
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
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
Also wxWidgets/wxWebView and pywebview
https://docs.wxwidgets.org/trunk/classwx_web_view.html
https://github.com/r0x0r/pywebview
https://docs.wxwidgets.org/trunk/classwx_web_view.html
https://github.com/r0x0r/pywebview
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.
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.
If you cared about performance, would you really be using Electron?
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.
>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
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 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.
The scary power of Google.
Revery is another similar project that is trying to be a lightweight alternative to Electron https://github.com/revery-ui/revery
No revery is native. It doesn't use a webview at all; just uses the skia engine; basically a flutter competitor.
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.
Why can't they?
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.
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.
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
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
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
This makes me feel better about abandoning my own plans to do the same.
> 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.
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.
Which is exactly why everyone pushing for Electron apps has nothing worthy to say about Chrome market share.
It's not a new idea, for instance
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.
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.
> 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 ?
"Tiny cross-platform webview library for C/C++/Golang. Uses WebKit (Gtk/Cocoa) and Edge (Windows)"
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)"
Yes, Tauri's documentation explicitly states that it uses this Webview project.
That's great in the sense that the more solutions using that library, the more mature it gets.
Tauri has effectively controlled the Webview project for the past year. See https://github.com/webview/webview/issues/305
tauri does use webview but its moving away from it in favor of a rust native solution called WRY.
Interesting. So according to @baxrob, Tauri took over control of 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.
I'm left wondering why take over a project if they're going to ditch it. For lack of a better term.
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). 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...).
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.
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.
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.
AFAIK Revery doesn't use webviews, it is based on Skia
I recently discovered NeutralinoJS, but I haven't tried it yet.
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
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
> 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.
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 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.
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.
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.
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.
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.
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?
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.
[deleted]
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.
People have already tried this approach.
https://github.com/webview/webview
https://github.com/yue/muban
..and several others too.
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.
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.
> 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.
it didn't - there is already a few projects like that, with Neutralino being the most notable.
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).
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.
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.
> 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.
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.
> Well Windows is basically Chrome
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.
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.
Starting from 20h2 version Edge is based on Chromium. And I remember when that rolled out plenty of people were irked by Microsoft simply automatically installing it (the new Edge Canary) without asking for permission.
The latest WebView2 is based on Edge Chromium AFAIK.
https://developer.microsoft.com/en-us/microsoft-edge/webview...
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).
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).
"is this impossible?"
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/
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/
Too bad it's kickstarter campaign to make it open source failed.
Can it play videos?
Yes. Check https://github.com/c-smile/sciter-sdk/tree/master/samples/vi...
But Sciter do not have codecs embedded. Instead
a. it [re-]uses streaming services of underlying OS;
b. has interface for the hosting application to supply its own video streams.
This way some applications use WebRTC as video sources, some use ffmpeg library to provide video streams. Video playback architecture is app dependent usually. Sciter provides to them "video rendering site".
That's idea of Sciter - to reuse underlying OS services as much as possible.
For example Sciter has spellchecking but only if OS provides spellchecking API (and usually they do).
But Sciter do not have codecs embedded. Instead
a. it [re-]uses streaming services of underlying OS;
b. has interface for the hosting application to supply its own video streams.
This way some applications use WebRTC as video sources, some use ffmpeg library to provide video streams. Video playback architecture is app dependent usually. Sciter provides to them "video rendering site".
That's idea of Sciter - to reuse underlying OS services as much as possible.
For example Sciter has spellchecking but only if OS provides spellchecking API (and usually they do).
[deleted]
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.
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.
Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.
It depends on what application you have in mind.
React needs web browser compatibility layer to work in Sciter.JS as React was designed strictly for browsers.
For that matter: PReact ( https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ;
MithrilJS ( https://mithril.js.org/ ) works as it is also.
SvelteJS works as it is with Sciter.JS too.
Also Sciter.JS has its own native implementation of JSX ( it's built in JS core of Sciter.JS) and also DOM extended by native element.patch(vdom) that makes "reactivity" to work in Sciter.JS with native speed.
Yet quite a lot of UI components are natively built-in. For example:
https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/
React needs web browser compatibility layer to work in Sciter.JS as React was designed strictly for browsers.
For that matter: PReact ( https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ;
MithrilJS ( https://mithril.js.org/ ) works as it is also.
SvelteJS works as it is with Sciter.JS too.
Also Sciter.JS has its own native implementation of JSX ( it's built in JS core of Sciter.JS) and also DOM extended by native element.patch(vdom) that makes "reactivity" to work in Sciter.JS with native speed.
Yet quite a lot of UI components are natively built-in. For example:
https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/
I think the project is great and I admire your work, but I'm confused about how you position it.
Being "almost" web compatible is not a recipe for success, as it's bound to cause confusion and frustration among folks that want it to be an Electron alternative.
Either embrace Web APIs entirely (perhaps a smaller compatible subset), or just position it as something else entirely, like Flutter.
Being "almost" web compatible is not a recipe for success, as it's bound to cause confusion and frustration among folks that want it to be an Electron alternative.
Either embrace Web APIs entirely (perhaps a smaller compatible subset), or just position it as something else entirely, like Flutter.
"how you position it"
Hmm... and how do I do that? What's your impression?
Sciter.JS is "an embeddable HTML/CSS/JS UI engine" and that's it.
Yes, it is possible to use it without touching native side like ElectronJS, see: https://quark.sciter.com/ , but that's not the primary use case. So far it has around 400 mln installations in embedded form as part of other products, see: https://sciter.com/#customers
If you want you can treat it as Flutter that uses time proven and familiar HTML/CSS/JS resource definitions instead of Dart. Dart is close to JS but not JS, Flutter has some DOM but not HTML DOM, it has some style system but quite rudimental one.
Hmm... and how do I do that? What's your impression?
Sciter.JS is "an embeddable HTML/CSS/JS UI engine" and that's it.
Yes, it is possible to use it without touching native side like ElectronJS, see: https://quark.sciter.com/ , but that's not the primary use case. So far it has around 400 mln installations in embedded form as part of other products, see: https://sciter.com/#customers
If you want you can treat it as Flutter that uses time proven and familiar HTML/CSS/JS resource definitions instead of Dart. Dart is close to JS but not JS, Flutter has some DOM but not HTML DOM, it has some style system but quite rudimental one.
I think your description is technically correct, it is an UI engine that uses the HTML, CSS and JS languages.
But to most folks, that sounds like a "web browser/view engine", which it is not. Does it pass the Acid2 / Acid3 test?
The power of ElectronJS is not its use of HTML, CSS and JS, but the fact that it is a web browser engine and one can share the millions of frameworks, libraries and muscle memory built for the web in their desktop applications.
But to most folks, that sounds like a "web browser/view engine", which it is not. Does it pass the Acid2 / Acid3 test?
The power of ElectronJS is not its use of HTML, CSS and JS, but the fact that it is a web browser engine and one can share the millions of frameworks, libraries and muscle memory built for the web in their desktop applications.
Modern browsers do fail on ACID tests anyway. display:flex broke old box model.
> one can share the millions of frameworks ...
For your *desktop* application you need just one, not millions of them.
> libraries and muscle memory
Not a problem, here I am using Remarkable [1] as it is: https://github.com/c-smile/sciter-js-sdk/tree/main/samples/m..., in other places I may use LeafletJS for showing maps, etc. Essentially all libraries for JS/NodeJS should work out of box.
Problem is that desktop UI has different UI model from a web page. Web page / Web app is usually "endless paper tape" opened full screen - has defined width but no height - no need for vertical alignment for example.
And desktop UI is usually different - small or vertically and horizontally space limited windows, etc.
In Sciter you can show element as popup one - in separate window that can be rendered outside of your [small] app window, consider this popup: https://sciter.com/wp-content/uploads/2021/02/select-table.p... , good luck with recreating this in browser. By the way that <select> element is defined as:
Also this
TL;DR: Web and desktop UIs use inherently different models. You can share parts between these two different platforms but only parts, really.
[1] Remarkable JS: https://github.com/jonschlinkert/remarkable
> one can share the millions of frameworks ...
For your *desktop* application you need just one, not millions of them.
> libraries and muscle memory
Not a problem, here I am using Remarkable [1] as it is: https://github.com/c-smile/sciter-js-sdk/tree/main/samples/m..., in other places I may use LeafletJS for showing maps, etc. Essentially all libraries for JS/NodeJS should work out of box.
Problem is that desktop UI has different UI model from a web page. Web page / Web app is usually "endless paper tape" opened full screen - has defined width but no height - no need for vertical alignment for example.
And desktop UI is usually different - small or vertically and horizontally space limited windows, etc.
In Sciter you can show element as popup one - in separate window that can be rendered outside of your [small] app window, consider this popup: https://sciter.com/wp-content/uploads/2021/02/select-table.p... , good luck with recreating this in browser. By the way that <select> element is defined as:
<select>
<tr role=option value="1">
<td>Option 1</td>
<td>*Short*</td>
<td>123456</td>
</tr>
<tr role=option value="2">
<td>Option 2</td>
<td>******* LOONG ********</td>
<td>123456</td>
</tr>
<tr role=option value="3">
<td>Option 3</td>
<td>*Short*</td>
<td>123456</td>
</tr>
</select>
Also this
<frameset cols="200px,*">
<section>A</section>
<section>B</section>
</frameset>
TL;DR: Web and desktop UIs use inherently different models. You can share parts between these two different platforms but only parts, really.
[1] Remarkable JS: https://github.com/jonschlinkert/remarkable
That’s awesome, I’m gonna play with it over the weekend. Thanks!
sciter is a really wonderful piece of software. it's performance has been really impressive when I was benching it against qt
> 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.
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.
And in recent years this has gotten much easier. Cross browser support used to be a pain in the ass.
Now most of the time changes aren’t even needed. Besides maybe the odd Firefox or Safari thing.
Now most of the time changes aren’t even needed. Besides maybe the odd Firefox or Safari thing.
Funnily enough in my experience it's usually Chrome and Safari that do weird things, which as a Firefox user always gets me dinged on PR reviews :p
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).
But we know from web statistics that these are very few people and shrinking every year.
That is not how it works on Windows, as you have to ship either the Webview2 runtime or installer with your app - otherwise you’re stuck with the old rendering engines.
At which point, it’s just easier to ship Electron.
At which point, it’s just easier to ship Electron.
Shipping Electron and bundling the WebView2 runtime are practically the same level of difficulty.
Making an installer is not that hard, and you should have enough respect for your users' compute resources to go through the modicum of effort it takes.
Making an installer is not that hard, and you should have enough respect for your users' compute resources to go through the modicum of effort it takes.
>Making an installer is not that hard, and you should have enough respect for your users' compute resources to go through the modicum of effort it takes.
No. As shown by the slew of other comments in this thread, it's not just about getting the runtime to load. You still have other issues involved.
You should have enough respect for your own time and money to ship the product and not open yourself up to a litany of cross-platform issues. Your job is not to fix OS vendors failing to get a common UI framework in place.
Signed, someone who has literally dealt with cross-platform-webviews in a shipping product in the past six months, and who builds native Mac apps.
No. As shown by the slew of other comments in this thread, it's not just about getting the runtime to load. You still have other issues involved.
You should have enough respect for your own time and money to ship the product and not open yourself up to a litany of cross-platform issues. Your job is not to fix OS vendors failing to get a common UI framework in place.
Signed, someone who has literally dealt with cross-platform-webviews in a shipping product in the past six months, and who builds native Mac apps.
Tauri's Bundler will automatically take care of shipping the Webview2 runtime, so there won't be any extra work required of you.
> 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.
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.
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.
Most companies today use frameworks that have good cross-compatibility so it tends to just work. In my opinion though, a responsible web developer is going to test on multiple browsers at the very least.
Safari is huge. Doing Chrome only is suicide. Thankfully, cross browser compatibility is much easier these days, specially if you don’t use flex or grid.
In a previous company we had to do FF and Chrome. Not IE though, which was a big time saver. QA ran all their test cases on the latest stable of both FF and Chrome, and features would not be deployed to prod if they didn't work on both browsers.
Yes, absolutely. Every company that I've ever worked at had a list of officially supported browsers that included Chrome, FireFox, Safari and Edge/IE. QA engineers would make sure to rotate through various browsers while testing, and for crucial features would run through every scenario in every supported browser's oldest and newest supported versions.
Pretty much the only reason to use Saucelabs is browser compatibility testing.
We don't run everything through it, but we run karma to make sure the code runs and the right events fire. It is still possible to write code that runs everywhere but IE.
We don't run everything through it, but we run karma to make sure the code runs and the right events fire. It is still possible to write code that runs everywhere but IE.
> 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.
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 mean, where are they now? Promising or DoA? I fear touching it because of it being a Google project (killedbygoogle.com)
We're pretty bought into Flutter. No cross platform toolkit is perfect but Flutter is miles ahead of everything else. For a not very scientific analysis: https://trends.google.com/trends/explore?date=today%205-y&q=...
It’s definitely not miles ahead of just about anything.
It has significant tradeoffs and fits some projects better than others.
React Native has quite a few benefits over Flutter. Especially if building for the web, I’d actually say Flutter is only usable now if you don’t build your web app with it. Which in my cost benefit analysis makes it miles behind RN, but of course, that’s why it depends.
It has significant tradeoffs and fits some projects better than others.
React Native has quite a few benefits over Flutter. Especially if building for the web, I’d actually say Flutter is only usable now if you don’t build your web app with it. Which in my cost benefit analysis makes it miles behind RN, but of course, that’s why it depends.
They’re putting a lot of resources behind and it actually is thriving. They have a real financial interest as there’s pretty thorough firebase support. It’s also reviving their Dart language.
As someone that’s using it, it is improving very quickly. Web support is getting quite good.
As someone that’s using it, it is improving very quickly. Web support is getting quite good.
Have you seen how Sciter.JS has been developing https://github.com/c-smile/sciter-js-sdk
There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.
There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.
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.
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.
1. https://medium.com/plotly/introducing-kaleido-b03c4b7b1d81
> 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
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..
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..
Electrino, but looks abandoned:
https://github.com/pojala/electrino
https://github.com/pojala/electrino
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.
> 3 (maybe more) UI's on platforms
Not really. Targeting the web platform and not aiming for perfect compatibility or looking the same isn't that hard.
Not really. Targeting the web platform and not aiming for perfect compatibility or looking the same isn't that hard.
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.
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.
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.
>~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.
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.
Doesn't RSS include shared mappings? That's why metrics like PSS and USS were introduced.
But that aside, yeah Discord is pretty heavy. My current instance which is only connected to a single server is eating 555 MB PSS, or 846MB RSS. Definitely not a lightweight at all.
But that aside, yeah Discord is pretty heavy. My current instance which is only connected to a single server is eating 555 MB PSS, or 846MB RSS. Definitely not a lightweight at all.
I think the desktop seriously needs a production, RAM and developer friendly breakthrough that isn't Electron.
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.
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'm really hoping Flutter or Kotlin Desktop have a breakthrough here soon. Personally, I'm rooting for Flutter, but I'll take what I can get.
It would be fun that Dart finally takes over Javascript this way (Flutter is written in Dart, which was originally written to be the new Javascript)
I wish the dart language was more common than typescript. but this is very hard.
What do you like about Dartlang? Every time I've looked at it it's seemed like a rather uninspired language, almost like a slightly more dynamic Java (and an older Java too). I've never used it for anything production though.
I think that's one of the draws so the language honestly. Familiar, structured, and easy to pick up if you already know a c syntax language.
There's React Native for Windows/macOS, though if you don't like Electron I doubt that's very appealing either.
I've had some nice experiences using PyInstaller to create desktop apps.
I've had some nice experiences using PyInstaller to create desktop apps.
Depends on why OP doesn't like Electron.
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.
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.
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.
I started getting in the habit of using Typescript with JS. It's annoying at first, but worth it for any decent sized codebase. All the bugs from JavaScript's unexpected type conversions just disappear.
I feel like this is a monkey's paw wish. I've wanted to see QT and GTK replaced with something better for a long time.
We got Electron, and other browser based toolkits.
We got Electron, and other browser based toolkits.
SwiftUI is pretty good, if you don't care about Android/Linux/Windows.
For the GUI-parts (and more) there's always wxWidgets and Qt, at least.
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.
That's not my experience, at least.
I haven't had any major issues I wasn't able to solve with either.
Even if I were more comfortable with web tech when I first started experimenting with this stuff (some time around 2012-2015) I still found the end result much better.
Even if I were more comfortable with web tech when I first started experimenting with this stuff (some time around 2012-2015) I still found the end result much better.
If you don't go beyond standard interactions and look it's probably fine but let's say I want system chrome to look like the one in photoshop and some custom dropdowns for starters...
Why would your desktop users want your weird drop downs? UI consistency used to be a thing.
Some companies/people take branding too seriously.
... it'd be doable ? E.g. look at telegram which is a Qt app and even more foreign-looking than Photoshop: https://images.app.goo.gl/JVNR4Jetmh7frvwo6 . Or allegorithmic substance, also made in Qt: https://images.app.goo.gl/CbJaGhRvSswymAjQ7
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.
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.
Slack definitely does not look good when your definition of "looks good" is "integrated with the rest of the OS"
Is CSS really the major factor in the memory usage of an Electron app?
I wasn't responding to the memory usage portion of the GP's message, but rather to the alien feel.
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.
[deleted]
[deleted]
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.
The Electron alternative that possibly isn't one.
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.
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.
Isn't windows system webview now a chromium fork? This should make incompatibility on the major platforms now much less of an issue.
People act as if they haven’t dealt browser incompatibilities in the past. Just feature-detect/polyfill and move on.
Some people haven't dealt with browser incompatibilities in the past. Not every developer comes from a webapp background, and electron is a platform to develop desktop apps. desktop app developers don't want to deal with polyfills and feature-detection in their platform.
It's weird to want all the benefits of web development without it's unfortunate quirks in my opinion. If desktop developers don't want to deal with them, which I think is reasonable, they have loads of other tools they can use to build desktop apps (and give the users a better experience most likely).
It's not weird - every developer wants to 'just code' their features/business logic without having to deal with the pain points of the tech. They choose web tech for their app because the opportunity cost of learning a desktop-native language is the time that could be spent bootstrapping an electron app and getting the product out the door earlier.
It seems like it would be pretty easy to get rolling a feature request for automatic polyfills. I'm not sure if Tauri pre-compiles the js it's handed, but if it does it can very easily check for what needs to be polyfilled.
how (if) important is using as minimal resources on the user's system? (if) Everyone agrees electron is bloated, is it (still) fair to prioritize developer "comfort zone" over actual specs?
Every developer needs to have a certain understanding of the environment he tries to build something. Just like printing 3d models - you need to know the characteristics of the material and limitations of them and the machine you're using. Blaming one of these later on just because you didn't want to read the manual is unprofessional.
What browser incompatibilities do exist are case-by-case basis, not all at once, depending on business domain and solution design, and even if, like you point out, you can just carpet bomb the issue with a poly/ponyfill.
The infantilization in frontend is accelerated by its veneer of supporting Product's sole mission in life to ship products ASAP, and I fucking hate it, and I've been some frontend engineer somehwere unimportant for 5 years now.
I wager, generalizing from my quite limitde experience, that a concerning amount of frontend devs just know how to schlep bags of data around and eventually get a desirable outcome with a framework keeping things narrowly from getting out of control when they are obvious re-factors, massive simplifications, that would get just as much expressiveness with less code. You will have bossess who only understand technical discussion in the form of "what framework or library should we use for this new epic?", like, bro, let's model the problem and see what we need from there maybe before we start thinking about writing code? You can almost just ask a frontend dev, "How would you refactor this or that code? to find out if they're just a baggage handler trying to minimize any concerted thought on their part. It's like frontend is corporate's proving ground on how to flatten all thinking and passion out of software engineering
Sorry, end of rant. I came to frontend from academia naively thinking people wanted to think about problems and put effort into solutions
The infantilization in frontend is accelerated by its veneer of supporting Product's sole mission in life to ship products ASAP, and I fucking hate it, and I've been some frontend engineer somehwere unimportant for 5 years now.
I wager, generalizing from my quite limitde experience, that a concerning amount of frontend devs just know how to schlep bags of data around and eventually get a desirable outcome with a framework keeping things narrowly from getting out of control when they are obvious re-factors, massive simplifications, that would get just as much expressiveness with less code. You will have bossess who only understand technical discussion in the form of "what framework or library should we use for this new epic?", like, bro, let's model the problem and see what we need from there maybe before we start thinking about writing code? You can almost just ask a frontend dev, "How would you refactor this or that code? to find out if they're just a baggage handler trying to minimize any concerted thought on their part. It's like frontend is corporate's proving ground on how to flatten all thinking and passion out of software engineering
Sorry, end of rant. I came to frontend from academia naively thinking people wanted to think about problems and put effort into solutions
That works for many scripting capabilities, but there’s plenty you can’t polyfill. If you’re stuck with the old MSHTML-based web view (which you will be on all but very recent Windows 10 and even sometimes there), there are various CSS Grid features that you can’t polyfill, and you’ll have a number of weird and annoying SVG sizing and styling issues quite apart from any potential missing features, and a bunch of other things like that—even if you polyfill everything in reach (which, even where possible, may perform terribly).
That updated Webview is, still, not the default on Windows. You have to ship it yourself.
> 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.
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.
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.
I understand your point, however I still think it's unacceptable to have 1-1.5 GB of RAM consumed by simply two Electron applications running idle.
That's not the baseline though, the baseline RAM consumption for an Electron app is about 100MB. If you have garbage code as input it doesn't matter which stack executes it, you'll have garbage performance output.
Even 100MB is crazy. I know RAM is cheap but the absurdity of that amount is beyond me.
It's a lot for sure, but it's not quite that simple:
- First of all the amount of RAM consumed actually depends on how much free RAM you have, Electron thinking it's a browser boggles up some extra RAM "just in case", which is a tread-off that probably works better for actual browsers than the average Electron app.
- Secondly while displaying "hello world" costs you ~100MB of RAM the RAM required as the app scales in complexity doesn't scale quite that fast, you may very well work on your app for a year and still need about ~100MB or RAM for it, you'll have to write very inefficient code (or keep a lot of data in memory) for it to require 1GB for JS' heap or something crazy like that.
Still ~100MB is a lot for sure, I think a lot of it could be trimmed away if the developers really tried to lower memory usage significantly, like maybe a much more efficient "Electron Mini" could be made with some effort.
- First of all the amount of RAM consumed actually depends on how much free RAM you have, Electron thinking it's a browser boggles up some extra RAM "just in case", which is a tread-off that probably works better for actual browsers than the average Electron app.
- Secondly while displaying "hello world" costs you ~100MB of RAM the RAM required as the app scales in complexity doesn't scale quite that fast, you may very well work on your app for a year and still need about ~100MB or RAM for it, you'll have to write very inefficient code (or keep a lot of data in memory) for it to require 1GB for JS' heap or something crazy like that.
Still ~100MB is a lot for sure, I think a lot of it could be trimmed away if the developers really tried to lower memory usage significantly, like maybe a much more efficient "Electron Mini" could be made with some effort.
It’s not crazy - go run a blank Cocoa app in Xcode and see how much memory it takes.
People have unrealistic expectations on this.
People have unrealistic expectations on this.
How many Electron applications do you honestly have running on your computer at any given time such that 100MB each is so concerning?
Right now I'm running VS Code and PyCharm, each with an one open project and one open editor. PyCharm is eating 1.8 GB while VS Code is only eating 130 MB. Funny enough, I see people complain about VS Code being a resource-hungry Electron app all the time but I've never seen anyone gripe about the resource usage of JetBrainz IDEs.
This isn't an excuse to Electron all the things, but browser-based GUIs do have their place.
Right now I'm running VS Code and PyCharm, each with an one open project and one open editor. PyCharm is eating 1.8 GB while VS Code is only eating 130 MB. Funny enough, I see people complain about VS Code being a resource-hungry Electron app all the time but I've never seen anyone gripe about the resource usage of JetBrainz IDEs.
This isn't an excuse to Electron all the things, but browser-based GUIs do have their place.
Honestly I could try to ignore the memory consumption if at least it was snappy. The few electron apps I use have visible lag when I do something that forces a large redraw.
That's a problem that didn't have with GTK app running on a computer with one order of magnitude less computing power and RAM two decades ago. VS code on the first computer I used to program would probably be unusable (if it even launched), yet we had full fledged IDEs back then. I'm not talking about advanced language server plugins here, just basic usage.
The great side effect of this is that if you avoid all this wasteful crap and keep using old school technology, computers are snappier than ever. My terminal always pops up instantly, nvim fires up faster than I can press return, rg lets me search a huge codebase with barely noticeable latency. My IMAP mail client is faster, more configurable and more ergonomic than any webmail I've seen.
Life is good when you avoid the www.
That's a problem that didn't have with GTK app running on a computer with one order of magnitude less computing power and RAM two decades ago. VS code on the first computer I used to program would probably be unusable (if it even launched), yet we had full fledged IDEs back then. I'm not talking about advanced language server plugins here, just basic usage.
The great side effect of this is that if you avoid all this wasteful crap and keep using old school technology, computers are snappier than ever. My terminal always pops up instantly, nvim fires up faster than I can press return, rg lets me search a huge codebase with barely noticeable latency. My IMAP mail client is faster, more configurable and more ergonomic than any webmail I've seen.
Life is good when you avoid the www.
[deleted]
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.
We've had about 60 years and multiple huge attempts at it, and IMHO HTML & CSS _are_ the easy to use cross-platform GUI platform. Nothing else stuck--flash, java swing, qt, etc. were all super capable and promising but failed to gain mass usage. HTML & CSS is the way. Nothing in existence has as much capability, developer usage and talent pool, accessibility and internationalization features, etc. A good GUI system is much more than just getting boxes and text on the screen.
> were all super capable and promising but failed to gain mass usage
Depends where you look. Plenty of hardware devices use Qt as their UI. Modern Mercedes-Benz and Ford cars, LG TVs UI, stuff like the Remarkable tablet or th Telegram chat app... The nice thing being that you can test the UI on whatever OS you're running. Also, i18n on the web ? Come on. It's terrible when compared to Qt tooling
Depends where you look. Plenty of hardware devices use Qt as their UI. Modern Mercedes-Benz and Ford cars, LG TVs UI, stuff like the Remarkable tablet or th Telegram chat app... The nice thing being that you can test the UI on whatever OS you're running. Also, i18n on the web ? Come on. It's terrible when compared to Qt tooling
I don't think HTML+CSS is the way because of innate goodness of them, but because the web led to so many people being expert at it, and so many tools being built around it, including a cross platform browser or too that are top notch to render it all.
At the very least a proper gui library could precompile all of that stuff so you aren't literally parsing HTML and CSS to render things, and HTML And CSS parsers don't need to be part of your running code. Nor a Javascript JIT, and runtime, etc.
At the very least a proper gui library could precompile all of that stuff so you aren't literally parsing HTML and CSS to render things, and HTML And CSS parsers don't need to be part of your running code. Nor a Javascript JIT, and runtime, etc.
I don't disagree either to be honest, but the reality is we live in a world where almost every business is dependent on a presence that shows up in web browsers. This puts enormous pressure and real dollars spent on making web browsers and the HTML & CSS ecosystem super fast, accessible, etc. Thousands of developers are trained every day how to make basic HTML & CSS experiences. Any UI system that throws all that away and tries to build up a similar ecosystem from scratch is going to be churning and churning for years.
Don't forget browsers are pretty spectacular runtimes. V8 and its JIT compiler is arguably one of the best runtimes of any language in the world. Sure the very first view of a page is going to do some parsing, etc. but as it runs it gets faster and faster with core functions and components compiled on the fly into platform machine code. The sandbox and security and encryption support in browsers is top notch and supremely battle-tested and hardened. With WASM now pretty mainstream we're starting to see entirely new frontend UIs coded in languages like C++, Go, Rust, etc. that are incredibly fast too. If you squint hard enough the browser is really no different than the JVM or .NET CLR these days--it just has 20 more years or so and an order of magnitude more developers working on improving it.
Don't forget browsers are pretty spectacular runtimes. V8 and its JIT compiler is arguably one of the best runtimes of any language in the world. Sure the very first view of a page is going to do some parsing, etc. but as it runs it gets faster and faster with core functions and components compiled on the fly into platform machine code. The sandbox and security and encryption support in browsers is top notch and supremely battle-tested and hardened. With WASM now pretty mainstream we're starting to see entirely new frontend UIs coded in languages like C++, Go, Rust, etc. that are incredibly fast too. If you squint hard enough the browser is really no different than the JVM or .NET CLR these days--it just has 20 more years or so and an order of magnitude more developers working on improving it.
I think you're right, but I'm not sure about "easy to use". It's only easy to use because everybody uses it, so as you point out there's a massive talent pool and massive resources.
As somebody who only started developing for the web a few years ago after a long time working with Qt, winforms, GTK and other "old school" native toolkits, I really don't find the web superior in terms of simplicity outside maybe of a few niches. You end up having to resort to dozens of external libraries to emulate the base functionality of something like Qt. And unless you want to go the transpiler way (which, admittedly, is incredibly common these days) you have to do it all is Javascript which is easy to pick up but a pretty huge liability in the long run IMO. It's just not a very good language, even if you stick to "the good parts".
As somebody who only started developing for the web a few years ago after a long time working with Qt, winforms, GTK and other "old school" native toolkits, I really don't find the web superior in terms of simplicity outside maybe of a few niches. You end up having to resort to dozens of external libraries to emulate the base functionality of something like Qt. And unless you want to go the transpiler way (which, admittedly, is incredibly common these days) you have to do it all is Javascript which is easy to pick up but a pretty huge liability in the long run IMO. It's just not a very good language, even if you stick to "the good parts".
I suppose this depends on your point of view. QT has achieved broad acceptance as "the" cross platform solution among open source Linux-first applications, as well as much of the open source ecosystem more generally. (Open source being what it is means that there are many exceptions, obviously.)
For example, on my computer right now I have 55 applications that depend directly on qt5-base, not including libraries and parts of QT. This is also not including a ton of applications that depend indirectly on QT, including most every KDE desktop application, which depends through KDE's frameworks.
So while QT may not have caught on in commercial software development, I'd say calling it a failure depends very much on what software ecosystem you're in. You might argue that HTML has achieved "universal usage" for desktop apps in a way that QT has not, but I would have to disagree. I don't have a single HTML UI or Electron app on my computer, and I don't feel as though I've given anything up. In fact I simply haven't come across any of these apps that I felt like I needed.
So I might say that HTML has failed to gain mass usage on the platforms that matter to me. :-)
For example, on my computer right now I have 55 applications that depend directly on qt5-base, not including libraries and parts of QT. This is also not including a ton of applications that depend indirectly on QT, including most every KDE desktop application, which depends through KDE's frameworks.
So while QT may not have caught on in commercial software development, I'd say calling it a failure depends very much on what software ecosystem you're in. You might argue that HTML has achieved "universal usage" for desktop apps in a way that QT has not, but I would have to disagree. I don't have a single HTML UI or Electron app on my computer, and I don't feel as though I've given anything up. In fact I simply haven't come across any of these apps that I felt like I needed.
So I might say that HTML has failed to gain mass usage on the platforms that matter to me. :-)
I don't think this is entirely true.
Have you tried wxWidgets or even Qt?
In my experience, this is more about resources and economics ("reuse existing code" vs. having to learn something new).
In my experience, this is more about resources and economics ("reuse existing code" vs. having to learn something new).
I didn't say I was shipping GUI software ;)
> Meanwhile 16GB of memory
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.)
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.)
you can't buy an M1 mac with more than 16GB of memory so it seems like you have bigger problems
My Mac isn't an M1, but it does only have 16GB of RAM. Yes, it goes into swap when Safari grows like that. It's mostly ok even with several GB of swap used, but can slow down.
My solution is to restart Safari when it gets too bad, as it's obviously leaky.
For a long time I used Firefox, was annoyed at how slow it would get on a busy browsing day, and didn't realise the memory consumption of Safari (also open) was overloading the poor machine. One day I saw the stats and realised what was happening. Now I open only one browser at a time, and everything is much nicer.
If I decide to get another Mac (undecided), I'm holding out for an M1X or whatever with more RAM. 16GB isn't comfortable for my work any more. I'm not the kind of person who casually buys new expensive machines, so won't be getting the x86 32GB as an intermediate knowing I don't really need it, as I think it would be better to end up with both an x86 (which I already have) and an ARM going forward. I'm into code generation and portability, so that's better for me. And I like the idea of less fan noise!
My solution is to restart Safari when it gets too bad, as it's obviously leaky.
For a long time I used Firefox, was annoyed at how slow it would get on a busy browsing day, and didn't realise the memory consumption of Safari (also open) was overloading the poor machine. One day I saw the stats and realised what was happening. Now I open only one browser at a time, and everything is much nicer.
If I decide to get another Mac (undecided), I'm holding out for an M1X or whatever with more RAM. 16GB isn't comfortable for my work any more. I'm not the kind of person who casually buys new expensive machines, so won't be getting the x86 32GB as an intermediate knowing I don't really need it, as I think it would be better to end up with both an x86 (which I already have) and an ARM going forward. I'm into code generation and portability, so that's better for me. And I like the idea of less fan noise!
I was going to comment this elsewhere, but workstation class problems require workstation class solutions. If 16GB isn't sufficient for your work you should upgrade. Unfortunately Apple has stopped making competitive workstation laptops.
As an example, the new MacBooks are not very competitive (for performance) with the latest XPS series from Dell.
As an example, the new MacBooks are not very competitive (for performance) with the latest XPS series from Dell.
Unfortunately, The XPS would be useless for that part of my workstation class problems that target the Apple ecosystem.
Like almost everyone, I'm financially constrained as well as space constrained. so buying multiple expensive machines, or a high end Mac Pro or something is not on the table as an option.
So it's a compromise.
My compromise at the moment is to use a MBP for Apple things, do smaller Linux and Windows things in a VM on it, and do big Linux and Windows things on cost-optimised rented servers much more powerful than the XPS from Dell. That seems to be a better use of the resources I have for the workstation class problems I'm choosing to solve.
An additional target of my interests is the M1-class processor with it's ARM plus extensions architecture.
So I will wait and see what the next high end, ARM-based MBP from Apple is like. By all accounts the M1 is an excellent and powerful processor, competitive with other Intel-based laptops, so its successor may be a good match for my needs. It might not be, in which case I will need to revisit my strategy, but until it's announced we don't know, and it doesn't make sense to buy an XPS at the moment for what might be just a few months of only marginal discomfort. I have my servers after all.
Like almost everyone, I'm financially constrained as well as space constrained. so buying multiple expensive machines, or a high end Mac Pro or something is not on the table as an option.
So it's a compromise.
My compromise at the moment is to use a MBP for Apple things, do smaller Linux and Windows things in a VM on it, and do big Linux and Windows things on cost-optimised rented servers much more powerful than the XPS from Dell. That seems to be a better use of the resources I have for the workstation class problems I'm choosing to solve.
An additional target of my interests is the M1-class processor with it's ARM plus extensions architecture.
So I will wait and see what the next high end, ARM-based MBP from Apple is like. By all accounts the M1 is an excellent and powerful processor, competitive with other Intel-based laptops, so its successor may be a good match for my needs. It might not be, in which case I will need to revisit my strategy, but until it's announced we don't know, and it doesn't make sense to buy an XPS at the moment for what might be just a few months of only marginal discomfort. I have my servers after all.
Is the M1 really not competitive with the latest XPS?
16GBs of memory isn’t enough for me anymore.[1] Although that is mostly due to Intellij and the Web at large (my browser).
[1]https://news.ycombinator.com/item?id=26120743
[1]https://news.ycombinator.com/item?id=26120743
dylan604(2)
Why doesn't Electron debundle itself into the Runtime vs Application? Much like .Net Runtime. Electron can then be installed in a single spot in the system and all Electron apps pick it up from that spot. You can install bundle the Electron Runtime in the installer (200mb installer is no biggie for a desktop app) but you get all the benefits of consolidating RAM usage across.
Well, the .Net runtime isn't exactly the most successful story from an end user perspective, where you occasionally run into weird problems with mismatched runtimes or missing runtimes or similar.
Granted, it's not that often, but it feels like a lot of apps relying on it just ship their own copies of the runtime. Still saves resources if multiple apps use the same runtime version, but...
Granted, it's not that often, but it feels like a lot of apps relying on it just ship their own copies of the runtime. Still saves resources if multiple apps use the same runtime version, but...
If the installer could do this instead..
Check if the app is supported by an existing runtime, if not download it and make it available globally, otherwise use the current runtime and download only the app
Check if the app is supported by an existing runtime, if not download it and make it available globally, otherwise use the current runtime and download only the app
It already is. For example, on Arch Linux, Electron is packaged as a separate binary and the eg. VS Code binary is just a shell script that points electron to the right entrypoint
#!/bin/bash
ELECTRON_RUN_AS_NODE=1 exec electron9 /usr/lib/code/out/cli.js /usr/lib/code/code.js "$@"
It's a simpler experience to just dl the app and install it when it's bundled and less chance of something odd breaking your app for your users. Unbundled you wind up with either a Java situation where you have to get your users to install a particular runtime because you built with a particular one or a MS runtime where every app comes bundled with it's own copy to make sure you have the right one so there's not that big of a savings.
That's an interesting point, especially since V8 is already used for running multiple applications that need to be sandboxed from each other. It would probably be a big effort though, and to get any real benefit from it, applications would actually have to start switching to a different fork of electron. But I often have multiple electron applications running at once so this would be pretty nice.
Argument against debundling is that runtime update could break your app in some way.
Sure, there are apps that get updated regularly, but not of all of them are like that, for example some company could implement some internal tool that doesnt have to get updated for years and runtime updates would present a risk with no benefit.
Sure, there are apps that get updated regularly, but not of all of them are like that, for example some company could implement some internal tool that doesnt have to get updated for years and runtime updates would present a risk with no benefit.
I only have one question. Was the name inspired by Stargate?
That's what I was wondering. I've watched a decent amount of it but my GF is the biggest fan I've ever met (so, naturally, that's what stuck out when I saw the article).
It's actually inspired by the star system (https://en.wikipedia.org/wiki/T_Tauri_star).
It's either that or a reference to the Tauri civilization that dwindled some 3,000 years ago in the Crimean peninsula. I'm leaning toward the former.
This was my first thought as well.
I scrolled just for this.
On the go side, there is Wails (https://wails.app/) which is pretty popular
This project is cool, and it is cool to have alternatives to Electron for cases that call for something like Electron.
Something that is also cool is that Rust runs really well on the web (via WASM), which opens the door to building projects primarily with Rust and deploying them to the web with a web front-end. It will not suit every case, but in some cases it might save you from asking users to download a separate app that bundles a web browser engine.
Something that is also cool is that Rust runs really well on the web (via WASM), which opens the door to building projects primarily with Rust and deploying them to the web with a web front-end. It will not suit every case, but in some cases it might save you from asking users to download a separate app that bundles a web browser engine.
Question: Why do we need Electron alternatives? Why do we need to develop applications that need a bundled browser to run? Why can't we just use GTK/Qt?
Have you tried developing relatively complex UI with QT? You need to hire a team of engineers and spend man-years of effort to build custom UX that in the web / Electron can be replicated with an npm install fancy-library.
Yes, I hate Electron, but the alternative is not QT; it's something like Sciter.JS with real Web API compatibility (or perhaps a stripped down WebKit2 which is much less resource-heavy).
Yes, I hate Electron, but the alternative is not QT; it's something like Sciter.JS with real Web API compatibility (or perhaps a stripped down WebKit2 which is much less resource-heavy).
I worked in a job where people developed very similar Qt and Electron apps, in both cases it was a one person effort and the development took about the same time.
Would you be able to mention these apps? I would like to take a look.
Not really, they were apps made for museum exhibitions, not apps that you can download
I am convinced that the sort of Web API compatibility so many people demand is only a few native libraries away. I would like to start experimenting in this area but I can only get rust-sciter DLLs working with "vanilla" Sciter and not Sciter.js, and I don't want to use other languages.
There is a lot of effort currently being put into creating web applications. It would be nice if we could use the fruits of that labor on desktop and mobile applications.
That's how I understand it, anyway.
That's how I understand it, anyway.
It would also be nice if people understood and really appreciated the trade-offs of doing so – i.e. hogging resources, killing batteries, potentially wrecking the end users' experience and ability to multitask efficiently, etc.
The two main reasons I’ve always heard against QT in particular are
1. Non C++ devs don’t want to write C++/participate in the C++ ecosystem at all. While there are plenty of QT binding libraries for other languages, they seem to be of varying and unpredictable quality.
2. QT has potentially difficult licensing: https://www.qt.io/licensing/
Disclaimer: I’ve never used QT.
1. Non C++ devs don’t want to write C++/participate in the C++ ecosystem at all. While there are plenty of QT binding libraries for other languages, they seem to be of varying and unpredictable quality.
2. QT has potentially difficult licensing: https://www.qt.io/licensing/
Disclaimer: I’ve never used QT.
Their licensing is written horribly, to just FUD companies into buying their commercial license.
However, the library components offered under LGPL3 are all you need to ship a perfectly good desktop app. The GPL3 licensed stuff listed in the comparison chart on the page you linked are typically the utility applications like Qt Designer which you won't need to ship with your application anyway.
It's unfortunate how the company backing Qt is going about this. But it's a great framework overall.
(At my last firm, we shipped several apps via Qt and it's always been a joy to use.)
However, the library components offered under LGPL3 are all you need to ship a perfectly good desktop app. The GPL3 licensed stuff listed in the comparison chart on the page you linked are typically the utility applications like Qt Designer which you won't need to ship with your application anyway.
It's unfortunate how the company backing Qt is going about this. But it's a great framework overall.
(At my last firm, we shipped several apps via Qt and it's always been a joy to use.)
The "patterns" documentation seems like a good place to get oriented around the ways they suggest people use this Tauri:
https://tauri.studio/en/docs/usage/patterns/about-patterns
https://tauri.studio/en/docs/usage/patterns/about-patterns
Can we just stop using browsers as a framework for desktop applications? That's not what they are meant for. Electron and everything like it is the ultimate expression of developer laziness.
Can we stop attributing technology choices to laziness? Sounds like a _lazy_ evaluation and presumption of someone else's motivations.
More seriously, there are far more folks familiar with browser frontend technologies than the myriad of desktop frameworks, rife with their own challenges.
More seriously, there are far more folks familiar with browser frontend technologies than the myriad of desktop frameworks, rife with their own challenges.
There's a reason why no one wants to build a desktop app using Qt and it's not laziness.
Blazor can now also be used to write cross-platform desktop applications with C# similar to Electron:
https://visualstudiomagazine.com/articles/2021/02/17/net-6-p...
C# will then be compiled to WebAssembly.
https://visualstudiomagazine.com/articles/2021/02/17/net-6-p...
C# will then be compiled to WebAssembly.
Whenever I'm reminded of Electron, I'm thankful to have experienced WinAmp!
ironic, because Electron apps should be easily skinnable. just put new CSS and images, maybe some new html, especially if there's some way of exposing e.g. the UI components so you can alter the layout and such.
I used to use an Electron wrapper for Google Play Music (may it rest in peace) and the developer of that did this. The default colour scheme for that product was a harsh orange, but the Electron client allowed you to override the CSS to change that base color, as well as switch between light/dark mode.
previous discussion from 7 months ago: https://news.ycombinator.com/item?id=23769424
Looks like they're making good progress!
Looks like they're making good progress!
Hmm, there doesn't seem to be any real applications made with it yet. Though, the roadmap looks good.
Not sure why this is downvoted, this is a good point.
Before people are getting hyped around this, this is alpha software and not production ready.
Before people are getting hyped around this, this is alpha software and not production ready.
From the roadmap:
> Go, Nim, Python, C++ and other bindings are possible with the stable API.
I think something like this might actually have a lot of potential, specifically because it's much easier to create bindings for other languages with Rust than with JavaScript.
You're stuck with a NodeJS runtime to run an Electron app, even if you "compile" it. You could theoretically make bindings to another language, but you'd still be dependent on that NodeJS runtime. But this could theoretically be compiled to a relatively lightweight DLL and interfaced with using practically any language you want.
The page logic would still need to be JavaScript, of course, but that's just the nature of webviews for now.
> Go, Nim, Python, C++ and other bindings are possible with the stable API.
I think something like this might actually have a lot of potential, specifically because it's much easier to create bindings for other languages with Rust than with JavaScript.
You're stuck with a NodeJS runtime to run an Electron app, even if you "compile" it. You could theoretically make bindings to another language, but you'd still be dependent on that NodeJS runtime. But this could theoretically be compiled to a relatively lightweight DLL and interfaced with using practically any language you want.
The page logic would still need to be JavaScript, of course, but that's just the nature of webviews for now.
If someone paid me to do something similar, I would probably be building on top of this: https://github.com/Const-me/Vrmac
There’re two hard problems there.
One is how to render vector graphics and fonts. So far, only web browsers do that in a cross-platform way. Windows has it’s Direct2D and DirectWrite, while Linux has nothing comparable, unfortunately.
Another higher level one is how to build easy to use GUI library on top of that. Have not approached that one. I have a few ideas but did nothing so far to address them, lately I’m too busy with other projects.
There’re two hard problems there.
One is how to render vector graphics and fonts. So far, only web browsers do that in a cross-platform way. Windows has it’s Direct2D and DirectWrite, while Linux has nothing comparable, unfortunately.
Another higher level one is how to build easy to use GUI library on top of that. Have not approached that one. I have a few ideas but did nothing so far to address them, lately I’m too busy with other projects.
Why not just wrap/abstract the native platform APIs (like what wxWidgets does)?
These native platform APIs don’t use GPU much, or at all. That’s true even on Windows where GPU support is better than anywhere else. wxWidgets wraps Win32 stuff, it does not use WPF (backed by DirectX 9.0c) nor UWP (backed by Direct3D 11+, Direct2D, and DirectWrite).
Count of pixels in displays was improving way faster than RAM bandwidth or CPU performance. Currently, this does not matter much on desktops, matters somewhat on laptops, and critically important for many mobile and embedded platforms.
When you want to render anything at all at native display resolution and refresh rate, GPU stuff is the only option that works well enough.
Count of pixels in displays was improving way faster than RAM bandwidth or CPU performance. Currently, this does not matter much on desktops, matters somewhat on laptops, and critically important for many mobile and embedded platforms.
When you want to render anything at all at native display resolution and refresh rate, GPU stuff is the only option that works well enough.
I've been following this project for a while, it's super exciting. Unfortunately, progress seems to have slowed somewhat in the last 6 months.
Loading Node in the renderer is a broken pattern that is full of compatibility issues and security vulnerabilities. Electron have come to realise this too and seem to be pushing towards ContextIsolation and explicitly defined bridges between the "backend" node process and the renderer.
Loading Node in the renderer is a broken pattern that is full of compatibility issues and security vulnerabilities. Electron have come to realise this too and seem to be pushing towards ContextIsolation and explicitly defined bridges between the "backend" node process and the renderer.
Just a note to the marketing site developer I wasn’t familiar with the “Brownfield” term and that was the first one listed.
For others https://en.wikipedia.org/wiki/Brownfield_(software_developme...
Also the first comment by brunsolf might be worth considering as the first description.
For others https://en.wikipedia.org/wiki/Brownfield_(software_developme...
Also the first comment by brunsolf might be worth considering as the first description.
This is huge. I've been waiting for the equivalent of this to emerge in the crystal lang ecosystem for years (gotta get them to finish windows support first). I might dust off Rust again just because this exists.
Without wanting to attack Tauri's author work in any way, for me, the only sensible alternative to Electron are native webviews and daemons/services talking to the user's installed browsers.
Isn’t that what this is basically?
Is it? I couldn't find it.
https://tauri.studio/en/docs/getting-started/technical-detai...
"The first generation user interface in Tauri apps leverages Cocoa/WebKit on macOS, gtk-webkit2 on Linux and Webkit via EdgeHTML / Chakra on Windows. Tauri leverages the MIT licensed work known as webview that has been incorporated into the officiall webview_rust bindings."
"The first generation user interface in Tauri apps leverages Cocoa/WebKit on macOS, gtk-webkit2 on Linux and Webkit via EdgeHTML / Chakra on Windows. Tauri leverages the MIT licensed work known as webview that has been incorporated into the officiall webview_rust bindings."
Thanks, I stand corrected.
Definitely needs a better homepage, one better targeted at developers, which so many fail to do.
So if I install a Tauri app I can access it with Firefox?
I started to build some internal tools (that utilize Rust libraries to interface with hardware) using Tauri last year. That effort ended after trying to cross-compile to aarch64 and hitting a ton of roadblocks. It looks like it is still an open issue. So, Raspberry Pi, for example, is not supported.
https://github.com/tauri-apps/tauri/issues/941
https://github.com/tauri-apps/tauri/issues/941
I'd rather have development resumed on Carlo. You can re-use the existing Chrome install on a user's device without having to rely on a system-provided WebView.
I can't help to remind everyone to watch The Birth and Death of Javascript:
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Cousins of electrons and their RAM requirements are a steep reminder that the DOM is cancerous and will have to evolve and suffer from deprecation.
Or maybe introduce metrics and good performance practices?
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Cousins of electrons and their RAM requirements are a steep reminder that the DOM is cancerous and will have to evolve and suffer from deprecation.
Or maybe introduce metrics and good performance practices?
Huh, funny seeing this here, started using it just a week or so ago, really like it so far.
I'm writing my frontend in JavaScript with Svelte, and able to make impressively smooth RPCs to the Rust backend with Tauri's API. Really nice work.
Edit: actually that's something quite important to add perhaps that the headline doesn't make completely clear - it's not merely 'written in' Rust, but like Electron gives you Rust (resp. Node) to use.
I'm writing my frontend in JavaScript with Svelte, and able to make impressively smooth RPCs to the Rust backend with Tauri's API. Really nice work.
Edit: actually that's something quite important to add perhaps that the headline doesn't make completely clear - it's not merely 'written in' Rust, but like Electron gives you Rust (resp. Node) to use.
I just love that they have different "patterns", which truly makes this a flexible platform.
I'm personally a big fan of the "Lockdown" [0] pattern, which avoids spinning up a local server and has a far more conservative security model.
[0] https://tauri.studio/en/docs/usage/patterns/lockdown
I'm personally a big fan of the "Lockdown" [0] pattern, which avoids spinning up a local server and has a far more conservative security model.
[0] https://tauri.studio/en/docs/usage/patterns/lockdown
Will PWAs make Electron obsolete?
Electron gives you far, far more access to native libraries and hardware than PWAs will ever dream about. People are still arguing about how to expose USB devices, bluetooth, etc. in the browser for example. With an electron app you can just npm install a few native wrapper libs and go to town. It's great for moving clunky old native GUI apps (IDEs, etc.) to a more modern cross-platform codebase.
Unlikely, because Electron is very useful in exposing system and hardware APIs.
For most apps - wouldn't PWA's be sufficient as implemented today. Presumably, they'll expose more and more hardware APIs over time?
Even basic things like reading and writing files from the filesystem are obnoxiously difficult in a pure browser or PWA environment. Storing state in general is full of enormous pitfalls and eccentricities, like 50mb limits for some browsers or just completely random total deletion of all app state at the browser's whim.
Seems like they are making a lot of progress on that front: https://web.dev/file-system-access/
Fine, but these are proposals. We want something we can work with today, something that we have the power to hack on that will expose new systems we come up with to HTML/JS, and that is the niche that Electron-like systems fill really well.
Supported in Chrome and Edge today.
PWA is useless if you need to bypass CORS(i.e you can't develop a general rss reader for example). In practice PWAs are just a shortcut to a website.
On electron you get closer to native apps in terms of network and OS access so I believe the PWA are and Electron are quite different platforms.Do PWA's support notifications?
If not, then no.
If not, then no.
Web notifications do exist, they're horrible though
I shipped a Mac app to the App Store using native web views via macgap in 2013 :) Idea is not new but still better than electron up until today.
Will this at some point make Electron apps like Slack/VSCode less hungry and more resource efficient?
My cpu fans spin up everytime Slack is open.
My cpu fans spin up everytime Slack is open.
This never happens to me. I run slack in my browser as just another tab.
Reading all these comments about WebView compatibility issues makes me wonder why not just do Progressive Web Apps"? For the server the OS doesn't matter, and for the browser compatibility issues just deal with them like any web-app would.
What is wrong with separate client and server?
What is wrong with separate client and server?
Isn’t there a lot more work to do around local IO and permissions with PWAs?
Not sure but why would there be? A server is a server whether it runs in the same machine or somewhere else.
But for development purposes yes there is the complication of having to acquire and install a certificate to your server which your browser will trust without questions. So yes, that is (at least) one factor making PWA development more cumbersome than it should be.
But for development purposes yes there is the complication of having to acquire and install a certificate to your server which your browser will trust without questions. So yes, that is (at least) one factor making PWA development more cumbersome than it should be.
In what sense it is an alternative to ElectronJS?
If size than not that much as Tauri is based on Node.JS that is 56 Mb executable by itself.
Yet Node.JS is pure C/C++ code. It is not clear what does "written in Rust" mean at all and what benefits Rust provides in that setup.
For the comparison: my scapp.js.exe ( https://github.com/c-smile/sciter-js-sdk#demos ) that is Sciter.JS packaged as standalone exe without dependencies is of size 5.3mb - at least 10 times less than Node.JS, Tauri and ElectronJS.
That exe includes HTML/CSS, QuickJS (ES2020) engines and essential portions of Node.JS runtime: https://github.com/c-smile/sciter-js-sdk/blob/main/docs/md/m...
So is the question above, alternative in what sense?
If size than not that much as Tauri is based on Node.JS that is 56 Mb executable by itself.
Yet Node.JS is pure C/C++ code. It is not clear what does "written in Rust" mean at all and what benefits Rust provides in that setup.
For the comparison: my scapp.js.exe ( https://github.com/c-smile/sciter-js-sdk#demos ) that is Sciter.JS packaged as standalone exe without dependencies is of size 5.3mb - at least 10 times less than Node.JS, Tauri and ElectronJS.
That exe includes HTML/CSS, QuickJS (ES2020) engines and essential portions of Node.JS runtime: https://github.com/c-smile/sciter-js-sdk/blob/main/docs/md/m...
So is the question above, alternative in what sense?
If you look at the website you will see that it is not bundling Node.js, apps can be as small as less than 1mb. It is written in rust (because the backend is, also it will integrate with Deno in future which in Rust).
It is still in development, but if you look at the website you will see the features that it provides or will provide (such as system integration) and the value that it adds.
Tauri apps don't use the NodeJS runtime. You have to write your app's backend in Rust. Like you said, the NodeJS runtime is tens of MB; if you look at their demo app you'll see that it doesn't even break 3MB.
Why can't there be a docker-like Electron running a base version of Chromium with additional layers for other versions support for different apps on top of it? This would both save more resources and lower each app's bundle size significantly.
"The core is built with Rust and the CLI leverages Node.js"
Sublime to the gorblimy in one sentence!
Sublime to the gorblimy in one sentence!
Wouldn't a better solution to be use something like https://github.com/microsoft/react-native-macos ?
I appreciate the desire to move towards a lower memory footprint, but it seems they are still many months behind the Electron team and what they are doing.
I am a bit bias, I am the author of a security-focused Electron template.
I am a bit bias, I am the author of a security-focused Electron template.
Does this let me bundle signed snapshots so random miscreants can't tamper with my app? I couldn't find it, and it's the one thing I'm desperately looking for in this kind of platforms
i've also heard of this alternative
https://www.outrunlabs.com/revery/
I just tried and integrating with create-react-app was an breeze. I would consider that as an alternative for electron.
Does using the underlying platform's webview make things faster? What are the benefits to end users?
It'll make applications smaller by not having to bundle a full copy of Chromium for each application. It may make applications slightly faster if the webview is already loaded in memory, and it'll probably save some RAM because applications would share some memory.
Is it easier to test than electron? Cypress doesn’t support electron and that makes me sad
I love this feature roadmap!
On their web site I don't see a quick answer to the most obvious question: How's it better than Electron? Does it require less resources than Electron and if so how does it accomplish it?
Doesn't seem like a big improvement when they still use web tech.
I'm all for web tech, but that's what makes Electron no better than a browser.
Revery seems like a much better solution.
I'm all for web tech, but that's what makes Electron no better than a browser.
Revery seems like a much better solution.
What part does node.js play in this?
does it support the bluetooth web api?
[deleted]
Thaxll(1)
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?