I recently went the other way (started a project in Tauri, moved to Electron) because of frustration with rendering differences between the web views employed on different platforms. Have you run into any cross platform UI bugs since you switched?
It looks like your UI needs are pretty simple while computation is complex so the extra QA tradeoff would still be worth it for you. I'm just wondering if my experience was unusual or if rendering differences are as common as they felt to me.
Also, did you go Tauri 2.0 or 1.0? 2.0 released its first stable release while I was mid-stream on v1, and migration was a nightmare/documentation was woefully inadequate. Did they get the docs sorted out?
We are using system webviews for https://kreya.app (not Tauri, but a custom implementation) and the platform differences are seldom a problem...
Polyfills fix most of the things and we are running automated end to end test on Linux, which catches most of the issues.
IMO the most difficult thing is figuring out how far the users are behind with their webview version, mostly on Linux and macOS. Windows has done thinga right with their WebView2 implementation
On the contrary it is a big big issue if you have a complex web app like we do. It was a PITA to deal with user bugs in a specific macos version with a 8y out of date webview.
And the performances of webkitgtk are horrible on Linux.
That’s a big issue if you can’t set a minimum required version for some reason, same for web apps in general - I rarely find much problems with platform behavior but that’s probably because we just reject out of date browsers.
That's one of the main selling points of Electron: it ships a single browser instead of using the system webview.
The main drawback, of course, is that it ships a browser with every app.
Yeah for a small tertiary apps then Electron is a huge performance burden to put on your users. They might just choose it's not worth it and not use your app.
On the contrary if it's a large app that the user spends lots of time in, then the performance overhead might well be worth it for the user.
Imagine in the first case that it requires a base load of 10 units of energy to run and gives 2 units of output, while in the second it still costs 10 units of base load energy, but now it gives 100 units of output. The base load becomes relatively irrelevant.
Yeah I was wondering how you dealing with the inconsistency of the different webviews? Are you using jquery? Or data star? Or is your own custom made polyfill depending on your user base?
TBH, a lite weight polyfill for most system webview would be refreshing change to all the spa frameworks out there.
Wait - there's system webviews? On Mac, Windows, and Linux?
Edit: It looks like Tauri uses the following platform webview features.
https://github.com/tauri-apps/wry?tab=readme-ov-file#platfor...
This looks fantastic! Any deets on the stack?
The UI inside the webview is written in Angular, everything else in C#.
More on the stack and our initial issues can be read here: https://kreya.app/blog/how-we-built-kreya/#cross-platform-gu... (from 2021)
We actually haven't rolled out cross platform support yet with the Tauri version, so we will see how that goes. Our UI needs are simple, luckily. What kind of rendering differences were you seeing with Tauri? Was there one platform that worked the best/worst for your app? We'd love to support Windows next.
With the Electron version of the app, we had issues running our bundled binaries on Macs with Intel chip. That caused us so many headaches that we decided for the rebuild on Tauri that we wanted to focus on one platform first (Macs with Apple chip) before supporting other platforms.
We went with Tauri 1.4 and no issues so far. Will have to check out the docs for 2.0 migration and see what that looks like.
I worked with an open-source project that uses Tauri 1.x and their migration has been blocked with issues for months. It was a nightmare for the span I was involved in, and it looks like it hasn't moved forward since I stopped.
In particular, rendering and crashing issues specific to Linux have been blockers, but Tauri 1.x also has other rendering issues on Linux that 2.0 fixed. There's little to no guidance on what's causing the stability and new rendering problems or how to fix them.
The app I worked on was a launcher that installed and managed content for an app, and the launcher invoked the app through command-line flags. Those flags arbitrarily fail to be passed in Tauri 1.x but work as expected in Tauri 2.x, but nobody we asked about it knows why.
Also the multi repo nature of the Tauri project, and the changes to this structure between 1.x and 2.0, makes migration hard.
Tauri 2.0 migration can potentially give you some more performance benefits, because they've greatly enhanced the JS-Rust bridge especially when you're moving lots of data.
We picked egui instead of tauri because we had more rust skills than web skills. Other than rastered text, whoch I can't find any customers who actually care, are there good reasons to go tauri? It seems widely used, but also widely complained about.
I think the main good reason to go Tauri is getting access to the full JS ecosystem, especially if you already have experience with that. If you don’t not really any reason to complicate your life I think.
My app needs wysiwyg editors, and JS is full of them.
Who is 'we'? :)
Would you have any webpage or product info, possibly with screenshots?
We're building an in-house DCC with egui so I'm curious.
No, our customers use it internally. Not even sure if they will end up deploying it as a website or a windows application. Which is an advantage of egui i suppose. I just picked it because I don't know any html or javascript and it does all that stuff for you, so it is just a rust app you can browse to. My team didn't know much more JavaScript than I do and they seemed to like it fine, but not as well as something declarative, which it is not.
Nothing flat out broke, but I am developing and dogfooding on a Mac, so I get visual QA for free on that platform. When I tested my app on a Windows machine, I noticed several UI regressions that looked/felt really janky. I didn't get as far as testing a Linux build, but I assume I'd find more issues there.
I can't remember why I wanted to migrate to 2.0 now, but there was a nice-to-have that I couldn't do in 1.4. I ended up abandoning the 2.0 migration after a slew of cryptic errors, took a step back, and decided I'd be better off using Electron for my project. My app is at heart a rich UI text editor and none of the computation is that expensive. With all the value add coming from the interface, optimizing for consistency there feels right.
Interesting you ran into UI regressions on Windows. I'm looking forward for us to get to that point where we can test on a Windows and see what changes...hopefully it's smooth.
With Electron's UI powered by the same browser across platforms, you end up with a much more consistent experience. Makes sense to optimize for that.
> I recently went the other way (started a project in Tauri, moved to Electron) because of frustration with rendering differences between the web views employed on different platforms.
This is our #1 frustration with Tauri. The OS-provided system webviews are not stable, repeatable, consistent platforms to build upon.
Tauri decided that a key selling point of their platform was that Tauri builds won't bundle a browser runtime with your application. Instead, you wind up with whatever your operating system's browser runtime is. Each OS gets a different runtime.
Sounds nice on paper, but that has turned into a massive headache for us.
Safari and Edge have super finicky non-standard behavior, and it sucks. Different browser features break frequently. You're already operating in such a weird way between the tight system sandboxing and CORS behaviors (different between each browser), the subtle differences are death by a thousand cuts. And it never seems to stop stacking up. These aren't small CSS padding issues, but rather full-blown application behavior breakages. Even "caniuse.com" is wrong about the compatibility matrix with built-in web views.
To be fair, we're using advanced browser features. Animation, 2D contexts, trying to do things like pointer lock. But these are all examples of things that are extremely different between each web view.
All of this has doubled (quadrupled - with dev and prod builds behaving so differently! - but that's another story) the amount of physical testing we have to do. It takes so much time to manually test and ship. When we were building for the web, this wasn't an issue even if people used different browsers. The webviews have incredibly different behavior than web browsers.
Their rationale for using OS-provided system webviews instead of a bundled runtime baked into the installer at build time is that it would save space. But in reality all it has done is created developer frustration. And wasted so much freaking time. It's the single biggest time sink we have to deal with right now.
We were sold on Tauri because of Rust, but the system browser runtime is just such a bad decision. A self-imposed shotgun wound to the chest.
The Tauri folks have heard these complaints, and unfortunately their approach to solving it is to put Servo support on the roadmap. That's 1000% not the right fix. Servo is not even a production-ready platform. We just want Chrome.
Please just let us bundle a modern chrome with our apps. It's not saving anyone any headache with smaller programs and installer sizes. Games are already huge and people tolerate them. Lots of software is large. It's accepted, it's okay, it's normal. We have a lot of space, but we don't have a lot of time. That's the real trade off.
I want to use Rust. I want to use Chrome.
I hope the Tauri devs are reading this. It's not just from me. This is the general community consensus.
Built-in webviews are not the selling point for Tauri. Rust is.
Why even bother with a browser runtime? It sounds like you have intricate UI needs, so you need a proper UI library. Several options exist.
There are some intangible matters of practicality. The team is more familiar with React.
I tried to use Bevy (since we also use 3D) and that wasn't ready for prime time.
I thought about Iced and Imgui and several other Rust frameworks, but given our experience with Bevy we shied away from it.
We figured we'd be able to move faster and rely on a lot of existing tooling. That's been true for the most part.
> Please just let us bundle a modern chrome with our apps.
please, no.
I wish software companies had to pay the hardware they require for their users, then we would have devs using Rust instead of JS and optimizing using ASM just to save parts of cents per instance. And we wouldn't see companies like MS kill well designed and performed native apps for a electron app
[dead]
> I want to use Rust. I want to use Chrome.
So use Electron and FFI, it's not that hard
Haven't touched Tauri because of the cross platform issues. The major appeal with Electron to me is the exact control over the browser. I'm curious about Rust integration though. I'm guessing they're doing something that provides better DX over something like https://github.com/napi-rs/napi-rs?
> Haven't touched Tauri because of the cross platform issues.
You were wise. That's the biggest issue plaguing the project right now.
> curious about Rust integration though
Tauri is written in 100% native Rust, so you write Rust for the entire application backend. It's like a framework. You write eventing and handlers and whatever other logic you want in Rust and cross-talk to your JavaScript/TypeScript frontend.
It feels great working in Rust, but the webviews kill it. They're inferior browsers and super unlike one another.
If Tauri swapped OS webviews for Chromium, they'd have a proper Electron competitor on their hands.
Sounds easier/more reasonable the other way around. Aren't there already specific libs / bridges for Rust / Electron / Node for performance heavy computations ?
Don’t try to speak for me please. I’m perfectly happy with my app looking mildly different and not weighing 1GB. I’m inclined to believe most people using Tauri do not have your issue.
I don’t quite understand why you have that issue in the first place. The fact they use the system webview is front, left and center on their website. It’s like you decided to use a fork because of the decorations on the back, and now complain that it’s pointy and the developers should just make it a spoon instead.
Because Tauri people advertise it as a complete solution to everything Electron does. But then they act surprised when people have platform difference issues that they don't have with Electron. Tauri is being actively misrepresented and people have good reason to feel duped.
> I don’t quite understand why you have that issue in the first place.
My read on it is that they didn’t understand the implications of using system webviews.
And possibly they expected Tauri would insulate them from cross-system differences without a lot of exploration.
This. We wouldn't have signed up for this if we'd have known.
Tauri needs a big fat warning label.
Is it hard to ship a Rust library with Electron? At least then it's not all C++
I am a web developer and haven't used Tauri or Electron much yet.
I am wondering why rendering differences between different platforms are such an issue? When building web apps, you face the same challenges, so I would assume it wouldn't be much different.
The promise of Electron is the version of chrome you develop on is the version that ships with your app. If it looks right on your machine, it looks right on whoever is running it. This is much nicer than when doing web development and deciding which browsers/browser versions to test and support.
Tauri does not bundle chrome with your app. This makes the bundle size much smaller. But the tradeoff is you end up rendering in whatever the default web view browser is. On Mac this will be some version of Safari (depending on MacOS version), and on Windows it will be some recent-ish Edge thing. Tauri actually has a nice page breaking this down: https://v2.tauri.app/reference/webview-versions/
This also means that a new OS release can change how your app is rendering, so a user can conceivably have a UI bug appear without updating your app.
Does anyone actually choose to ship an Electron app instead of a web app in order to benefit from UI consistency? Most Electron apps I've seen either share a codebase with a web app that's also made available (so the codebase still has to be tested cross-browser), or else can't be web apps because they need full filesystem privileges or otherwise don't work with the browser's security model.
Yep, we use Electron specifically because it gives us a locked-down version of Chromium with a consistent WebGPU implementation. Without that, we're stuck dealing with whatever browser version the user happens to have, and that completely wrecks the stability of our GPU pipeline.
Okay, fair, none of the apps I had in mind make much use of WebGPU and it stands to reason that browser diversity might be a bigger problem with a very complicated and relatively less mature API like that one.
Yes, it is the biggest selling point. You almost never need to debug user/platform specific UI bugs -- if the app starts, it will render the same. There might be some GPU issues, but that's not due to the framework itself.
Electron apps often fully share codebase with the Web apps, so on the app backend you implement native functionality and communicate with your app via IPC.
I would expect most trouble to come from complicated features like the audio stack or canvas, as well as system integration, not aesthetics.
That does not answer the question.
The question is not if Electron feels better for developers because it renders consistently.
The question is if that matters. Is it a big issue? Does any user actually care?
I care, for sure. Electron apps have been better than tauri apps so far, from what I’ve used.
Web developers building web apps for web browsers typically do not test cross browser compatibility.
They build in Chrome and test with Chrome and then the test of the week they whine about Firefox and Safari.
Some of us still do, apparently the newer generation no longer does, putting to waste all our effort for Web freedom, it is ChromeOS now, Google suceeding where Microsoft failed.
If true then Chrome is truly the new IE because that's exactly what they used to do with IE.
Web apps pretty much by definition don't do the kinds of things that desktop apps want to do. In the rare cases where they are actually on par feature-wise, it's just as much headache to support all the browsers in use, it's just that the functionality bar is so much lower on average.
Just recently Tauri announced:
> This year we've got a lot of exciting innovations in store for you, like CEF and SERVO based webviews...
From their discord.
Blog post: https://v2.tauri.app/blog/tauri-verso-integration/
HN discussion: https://news.ycombinator.com/item?id=43518462
Looking forward to either being stable. I like the idea of Tauri, but I need it to work well on Linux too.
Dealing with the rendering differences isn't any more difficult with Tauri than it is when making a normal web app, is it?
With Electron, it will bundle chrome into the app so you only have to handle that single rendering engine. Tauri uses whatever is the default browser on the system the app is installed on
I know. I'm saying that Tauri doesn't make things more difficult than any normal web app development, it's not like making web apps which work across browsers is a new and scary thing
It's not a new or scary thing, but it's way more expensive (in time or money) than relying on "it looks good on my machine, so it looks good everywhere."
I've worked on large consumer-facing web-apps where we had a dedicated QA team (and/or contracting firm) that runs visual regression testing on multiple platforms and browser versions. As a solo developer, I have no interest in being that team for my hobby project. So the tradeoff with Tauri for me was "accept that I will ship obvious UI bugs" vs "accept that I will ship a bloated binary."
Reading anecdata on forums, it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them.
> "it looks good on my machine, so it looks good everywhere."
It bas always been a fallacy though, as with CSS the end result can depend on the DPI scaling and the size of the display (unless you make sure it doesn't, but then you need to test different setups to be sure).
Well, they're right to point out that it removes a lot of inconsistency though. For example, today I was working on an app which used some Unicode characters as icons in buttons, and they look perfectly centered in the button in Firefox but weirdly off-Center in Chrome.
I never managed to find a set of CSS properties which made it look good in Chrome tho. And if it was a more serious project I'd probably have used SVGs instead of Unicode characters.
Sure, the closer your config is from the actual user config the fewer issues you'll get, but I wanted to highlight that even with electron you ought to test on different configurations.
Oh, yeah, certainly. Even when I've made dinky little Electron apps I've had a Windows machine ready (I otherwise use Linux and macOS) just to make the Windows binary and do some rudimentary acceptance tests. You can't get away from testing on all your officially supported configurations.
It’s an unpopular take I’m sure, but I really have to question shipping binaries for platforms that I can’t or won’t personally test. Between platform intricacies I don’t understand, unaddressed papercuts, and limited ability to debug issues, the end result is very likely to be underwhelming and/or frustrating for users of that platform, and as such if the app is paid those users are disproportionately unlikely to convert and more likely to churn. The only real benefit I see is an extra platform icon lined up on the marketing page.
There's also the simple fact that shipping an identical UI on multiple operating systems is obviously wrong for a least some of those operating systems (and maybe all of them). You don't have to worry about "platform intricacies" because a web-based cross-platform UI toolkit is going to get really basic UI conventions wrong.
It’s not only UI design/conventions being covered, but also things like quirks with the system’s audio, compositor, window manager, etc depending on what your app does and which technologies it uses. If the dev doesn’t understand these things about a platform, they’re walking into a minefield by supporting it.
At this point people are more accustomed to chrome’s conventions than the native UI’s conventions in most cases
But there aren't really many "Chrome conventions" to speak of. Every web app (and Electron app) necessarily has to reinvent a lot of wheels that desktop apps get for free from the underlying OS. And sure, there are component libraries for that... way too many libraries, each of them doing everything slightly differently from others.
> Reading anecdata on forums, it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them
I think it's good to be wary of overly sensitive advice that regular users don't care about. But would a regular user realize they have 10 electron apps running and their ram is maxed out all the time?
The argument against Electron isn't just a single bloated binary, but everyone shipping an app that uses way more RAM than necessary.
That's a fair point. My app (and possibly the OP's) is built assuming it is the user's current focus and priority, and that you'll quit it once you're done with the task. I don't feel bad about asking for a chunk of RAM for a focal app like this, but I would feel differently if I was shipping a background tool or small utility or something.
Especially macOS is built on the assumption that you rarely "quit" apps. When you close all of an app's windows, it remains running. You actually have to hit cmd+q or right click and hit "Quit" in the Dock to really quit an app.
In other circumstances too though, it's not great UX to demand your users quit your app once they're done with it because it eats too many resources just being idle in the background. It's an issue I have with both Electron, where idle apps waste tonnes or RAM, and with many Rust UI frameworks, where an immediate-mode architecture means they'll be consuming CPU on the background.
Electron doesn't seem to support it (and even if it did, I suspect most electron developers wouldn't pay it any mind) but...
NSApplicationDelegate's -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender; method exists so an application can, uhh, automatically terminate after the last window closes.
https://developer.apple.com/documentation/appkit/nsapplicati...
It's not 100% consistent but if you look at Apple's applications based on single window (calculator, system preferences, etc), closing the window quits the app.
Electron doesn't automatically exit when the last window is closed, and the Electron getting started guide (https://www.electronjs.org/docs/latest/tutorial/tutorial-fir...) recommends this code:
Most Electron apps probably do exactly that. It would feel extremely out of place for a macOS app to quit just because you closed a window.The function has been available for a while, but auto-closing system apps is a relatively recent change.
I can’t find obvious reference or when Apple started changing this, but it seems related to background app killing that is done now as well. I’m still not sure how I feel about it, but historically that wasn’t common for Mac apps.
The ability for an app to keep running without a window was a godsend back in the days when we were all running on hard drives and large apps had splash screens to amuse you during their multi-second launch process. If you were done with a particular document but not done with the application as a whole, you could simply close the window and next time you needed to open a document in that app you wouldn't have to sit through the splash screen again. Unless it was an app with a cross-platform GUI that didn't support this model.
Nowadays, apps closing themselves or being closed by the OS automatically is reasonable in a lot of cases, but Electron apps tend to hit the cases where it still is valuable to operate with the classic NeXT/OS X document-based app paradigm.
Part of it is respecting your customers regardless of whether they are aware of your crappy electron app consuming all their RAM and draining their battery or not. If I went to a mechanic (car analogy incoming) that repaired pressurized lines with duct tape instead of hose clamps because I wouldn’t care as long as the car worked, I would be upset, regardless of whether or not it got the job done.
Take pride in your work and respect the people using it.
At one of my jobs we actually measured those differences and even 10s of MB in app size increase moved user download, use and update metrics (negatively).
I think the person you're responding to didn't actually measure if their claim is true.
> it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them
Tauri however, is.
Some of these apps then download huge models these days and the total space savings kinda vanishes.
Absolutely. HN is unnecessarily full of "electron always bad" mindset. It makes sense for so many use cases.
This is true in a "technically correct" way, but not in a meaningful way.
It's like developing sophisticated websites for IE6-era web, with ActiveX and Java applets and this new "ajax" thing on the horizon that sure sounds nice but it'll be a decade before you can actually use it for most of your users.
The very core basics are essentially the same because yea - it's just a web browser. An <h1> will be bigger than a <p>. But they are regularly multiple years out of date, have WILDLY different security and native-access models, version specific bugs, initialization and threading requirements, performance tradeoffs, styling quirks, and you might have hundreds or thousands of versions to test against which you cannot reasonably test against because they are frequently tied to specific operating system versions that you can no longer download and install, or require hardware you do not have.
So yea. IE6-era stuff. Not an exaggeration at all.
For simple stuff they work just fine, performance is generally more than good enough, and they start up faster, use fewer resources, and lead to a much smaller install. They're entirely reasonable choices. But once you push the edges of the envelope they're an absolute nightmare, and that is the entire reason Electron exists. That is what caused Electron to become the giga-powerhouse that it is now. It solved that problem, at relatively high cost, but it is incredibly obviously worth it to anyone who has dealt with native webviews in complicated ways.
Modern browsers are a completely different game, in comparison - far more consistent and up to date in aggregate. They're utterly incomparable.
Problem is that now we have a whole generation with "Works best on Chrome" attittude.
What a waste of time it was fighting for Web freedom.
Perhaps users have different standards for a desktop app they installed.. but it's just a possibility, I do not know.
Tauri does not do this in all cases, as WebkitGTK on Linux has performance issues and is often the ugly duckling of everything.
I also feel like I will have to, yet again, trot out the comment from a Slack dev that explains why they moved _from_ per-platform webviews to Chromium. This isn't new ground being charted, plenty of companies and teams have been down this path and Electron exists for a reason.
(I am not saying Electron is _good_, I am saying that Tauri isn't the holy grail people make it out to be)
According to https://slack.engineering/building-hybrid-applications-with-..., Slack never used multiple different per-platform webviews. The earliest version of their desktop app was Mac-only and used the OS-native WebView API, but they switched to Electron at the same time they started work on making the app cross-platform. At the time, not only did Tauri not exist, but neither did the WebView2 API that it uses under the hood on Windows; they would have had to use the WebBrowser ActiveX control, which uses Internet Explorer's Trident engine and was already deprecated. So it's not so much that they rejected per-platform webviews, as that per-platform webviews were not yet really available as an option on desktop.
Isn't Spotify using CEF (Chromium Embedded Framework) rather than Electron?
Regardless, your point stands: it's a bundled Chromium on all platforms
https://news.ycombinator.com/item?id=18763449
It took me 2 seconds to find in Google, and you're splitting hairs if you think it being macOS-only was the point of my comment. Their second bullet point is just as true today as it was back then.
Slack in web works fine in several platform browsers still though.
That's not what the comment was even remotely disputing.
No, WebkitGTK is notoriously an issue.
The Linux port of Orion (Kagi’s power user oriented web browser) is built with WebKitGTK, some hopefully the Orion team will be patching up some of the more glaring issues. At minimum the port will put it in front of pairs of eyeballs that hadn’t been looking at it before which should help bring attention to bugs.
It's awful. I'm cautiously optimistic (hopeful? naive?) that progress on servo will make it unnecessary!
Is WebKitGTK as used by Tauri worse than WebKitGTK used by a web app user's web browser?
No. But also, nobody(first order approximation) uses Gnome web. I would wager most javascript web apps don't work on that browser anyways due to webkitgtk. The most popular gnome distros all come with firefox installed so even the "just use the default" folks won't be using gnome web.
WebKitGTK benefits from sharing a codebase with WebKit for iOS, which web developers do care about supporting. There can still be bugs in the Linux-specific platform integration code, but that's not most of the codebase, so any given app is less likely to run across a bug in it. It's not as reliable as more mainstream browser-OS combinations, but saying that most apps don't work is an exaggeration.
Last I checked, WebkitGTK does not have parity with WebKit on iOS, and plenty of devs do test on that platform anyway - so I'm not sure what you're talking about? You're right to correct someone saying _most_ apps don't work, but it's also not cool to just sweep the WebkitGTK issue under the rug and pretend it's not an issue at all. It's bitten plenty of people who build on Tauri.
Additionally, the issues people find with WebkitGTK/Tauri aren't always web related, usually moreso Linux related (weird blank screens, issues with rendering certain stacked items, etc).
Gnome Web sucks, it has shitty defaults and a horrid performance. But luakit/vimb can be really fast. Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.
> Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.
I have one such device and Firefox and Chrome also run on it. They're slow but still usable.
But the thing is, if you're using Tauri, you control the web app. So you need to test it on WebkitGTK, I guess that's the extra burden?
Have you actually tried deploying to webkitgtk ever?
Good luck "testing" your video conferencing app on webkitgtk - it doesn't support webrtc! It is still useful to test your error page I suppose.
Note that this is one example among many of missing features, bugs and/or horrible performance.
Here's a preview: no notifications, no :has, no TLA.
(Not blaming the epiphany devs for the situation here to be clear)
The thing is, Firefox/Gecko isn't embeddable (probably the one of worst tech blunders ever). I wonder if Tauri could wrap around Blink, instead? Then your app could just ask for Chrome to be installed.
The modern Qt web view component, QtWebEngine, is actually Chromium-based. So you could imagine a Tauri which uses Qt instead of GTK and uses QtWebEngine as its renderer instead of WebKitGTK.
Ahem https://github.com/tauri-apps/tauri/discussions/8426
That's a significant amount of workaround for something that "just works" elsewhere (and if I'm reading correctly doesn't work under Wayland).
It proves what everyone knows: that there's no reason WebRTC can't work in Tauri/Linux environments.
It also proves the point here: there are legitimate issues with the system-provided webview approach that are not always apparent.
Gnome Web sucks, it's has shitty defaults and a horrid performance. But luakit/vimb can be really fast. Luakit even ran under a netbook. Single page bound, ok,, but not bad from an n270 with 1GB of RAM.
Chrome has by far the most consistent cross-platform rendering.
[dead]
I had the exact same experience and switched from Tauri 2.0 to Electron after a month.
No only were there UI inconsistencies, but Safari lags behind chrome with things like the Popover API and the build/codesign/CD ecosystem for Tauri is incredibly scattered.
When I was using it, IAPs were still not really an option for Tauri or at least I could not find any docs or resources about it.
Same here. We went with Electron mainly for consistency and stability. The larger bundle size wasn’t an issue for our particular project, so the decision was pretty straightforward.
> Have you run into any cross platform UI bugs
Of course not, it's only for Mac. If they were to support Windows and Linux, they probably would not have published this post.
Cross-platform UI is hard, even harder if you want to keep almost the exact same UI, same feature set across platforms, and potentially an online version. People moved from native applications to Qt to web stack for a reason.
Saying this as someone who works at a company that develops cross-platform desktop application that has millions of users. I can't imagine what my job would be like if we were using any other solution.
Not sure what you're saying; Tauri uses the native web view, it still ends up rendering a website. The differences in UI toolkits don't matter.
Just read other replies, if you use the web platform in any capacity, you end up with tons of hardly reproducible issues, and it seems on Linux performance is bad no matter what.
Chromium is superior to the native web view unless you have latest version of Windows or Mac.
I don't even need to refute the point myself -- plenty of comments under the parent thread have already pointed out problems with Tauri.
Do you mean the actual rendering of html/css when you say rendering differences? Or are you referring more to differences in JS support?
Pure html/css rendering. JS support could be addressed trivially in the build system by transpiling anything unsupported by the oldest likely target.
Not all JS APIs are fully pollyfillable, especially ones that are part of the Web platform rather than ECMAScript. I dunno if it's a bigger problem overall than HTML/CSS, probably not, but it's not consistently trivial.
I'm curious how Tauri causes different views on different platforms because Tauri frontends are websites and if websites function same way on platforms so should the apps. If websites use something to hide browser differences so should the app developer on Tauri.
[dead]
You’re post honeymoon.
“We moved from X to Y and were so in love.” posts are often postcards from the honeymoon.
We love it here. We're staying together forever
The documentation for Tauri V2 was straight up trash when I last used it about 6 months ago. The project is very promising, but it was a huge pain getting some things to work with nothing to reference.
I guess the Web would be all much better if ChromeOS Platform was everything that remained, who needs standards and multiple vendors.
It's much more convient for developers for there to be a dominant to open source browser engine. Open source reduced the need for these standards and multiple vendors. See what happened with how Linux largely replaced the slew of UNIXes. The ability for everyone to contribute to a single project paired with the ability to customize it where needed to suit the product you are building has shown to be a winning model.
Chromium may be open-source, even free software, but only in letter, not in spirit. Google has total control over it, and will force any changes it likes. Developer community can only abide.
>but only in letter, not in spirit. Google has total control over it
This applies to every open source project. The owners control what will be merged upstream and the direction the project will go in.
Ask BSD guys and girls how they feel about that.
Monocultures are great, as long they are the one we bet on.
Well due to it being open source their niche operating systems were able to run Linux software via a compatibility layer and Linux drivers making them better.
Microsoft was right all along after all, what a waste of money in lawsuits, monoculture for the win.
Likewise I guess there is no problem that game developers mainly care about Windows, Proton is open source, so no big deal, why bother.
>monoculture for the win
The browser is the actual product. An open source browser engine lowers the barrier of entry of creating new browsers.
>Likewise I guess there is no problem that game developers mainly care about Windows, Proton is open source, so no big deal
Which is why Valve recommends game developers to target Windows and use Proton for compatibility. Having one platform to target simplifies developers lives. Before developers were making bad ports to Linux because they did not have the resources to properly support another tech stacks. The value of developers being able to target a single platform can not be understated.
Though this is fundamentally a different situation as the leading implementation is closed source and is more capable.
There will be no browsers left, likewise the Year of Desktop Linux will never come, cursed forever to emulate/translate other platforms, ChromeOS and Windows, so that it can have any kind of applications, pretending to be "native".
What do you mean? Chrome, Edge, Opera, and Brave are all different browsers that share the same browser engine. The year of the Linux Desktop didn't come, but the year of the Linux phone did come with Android becoming the most popular operating system surpassing desktop operating systems.
>pretending to be "native".
The code is native. Just because something uses a library to call platform code it doesn't mean it isn't native. By that logic programs that use qt are not native because they use a cross platform api.
Effectively killing the Web freeddom, it is all about ChromeOS Computing platform.
The Linux kernel is an implementation detail on Android, there is nothing about Linux exposed as official userspace API.
Any use of Linuxisms on Android apps is done at user's own peril and possible kick out of PlayStore.
I don't see how it would kill web freedom. If anything the reduction of duplicate work means that the web can evolve faster to better compete against its competitors to stay relevant and attractive for developers to target and support.
>The Linux kernel is an implementation detail on Android
The kernel is such an important part of an operating system, you can't really ignore it as a developer even if technically it may be an implementation detail.
>Any use of Linuxisms on Android apps is done at user's own peril and possible kick out of PlayStore.
Sure, but Linux's ABI is stable and even in a world where things are moved to Zircom starnix was made to support that same ABI.