10 ms·

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 o

by yojo 1y ago

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?

deleted 1y ago
[deleted]
logankeenan 1y ago
Do you mean the actual rendering of html/css when you say rendering differences? Or are you referring more to differences in JS support?
- yojo 1y ago
  Pure html/css rendering. JS support could be addressed trivially in the build system by transpiling anything unsupported by the oldest likely target.
  - ameliaquining 1y ago
    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.
krisknez 1y ago
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.
- yojo 1y ago
  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/ 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.
  - ameliaquining 1y ago
    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.
    - CreepGin 1y ago
      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.
      - ameliaquining 1y ago
        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.
katrinarodri 1y ago
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.
- starkparker 1y ago
  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.
  - jacobgorm 1y ago
    Also the multi repo nature of the Tauri project, and the changes to this structure between 1.x and 2.0, makes migration hard.
- yojo 1y ago
  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.
mort96 1y ago
Dealing with the rendering differences isn't any more difficult with Tauri than it is when making a normal web app, is it?
- Klonoar 1y ago
  No, WebkitGTK is notoriously an issue.
  - mort96 1y ago
    Is WebKitGTK as used by Tauri worse than WebKitGTK used by a web app user's web browser?
    - porridgeraisin 1y ago
      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.
      - oblio 1y ago
        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?
        porridgeraisin 1y ago
        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)
CommonGuy 1y ago
We are using system webviews for https://kreya.app 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
- Sytten 1y ago
  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.
  - presentation 1y ago
    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.
    - zdragnar 1y ago
      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.
      - Sammi 1y ago
        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.
cvburgess 1y ago
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.
- CreepGin 1y ago
  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.
andrewstuart 1y ago
You’re post honeymoon. “We moved from X to Y and were so in love.” posts are often postcards from the honeymoon.
- correa_brian 1y ago
  We love it here. We're staying together forever
no1youknowz 1y ago
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.
- ryanseys 1y ago
  Blog post: https://v2.tauri.app/blog/tauri-verso-integration/ https://v2.tauri.app/blog/tauri-verso-integration/ HN discussion: https://news.ycombinator.com/item?id=43518462 https://news.ycombinator.com/item?id=43518462
- pikdum 1y ago
  Looking forward to either being stable. I like the idea of Tauri, but I need it to work well on Linux too.
deleted 1y ago
[deleted]
- deleted 1y ago
  [deleted]
NoelJacob 1y ago
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.
- sieabahlpark 1y ago
  [dead]
pjmlp 1y ago
I guess the Web would be all much better if ChromeOS Platform was everything that remained, who needs standards and multiple vendors.
- charcircuit 1y ago
  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.
  - pjmlp 1y ago
    Ask BSD guys and girls how they feel about that. Monocultures are great, as long they are the one we bet on.
    - charcircuit 1y ago
      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.
      - pjmlp 1y ago
        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.
        charcircuit 1y ago
        >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.
rs186 1y ago
> 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.
- lionkor 1y ago
  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.
  - rs186 1y ago
    I don't even need to refute the point myself -- plenty of comments under the parent thread have already pointed out problems with Tauri.
  - bloomca 1y ago
    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.
platevoltage 1y ago
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.

by yojo 1y ago

deleted 1y ago

[deleted]

logankeenan 1y ago

Do you mean the actual rendering of html/css when you say rendering differences? Or are you referring more to differences in JS support?

yojo 1y ago
Pure html/css rendering. JS support could be addressed trivially in the build system by transpiling anything unsupported by the oldest likely target.
- ameliaquining 1y ago
  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.

krisknez 1y ago

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.

yojo 1y ago
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/ 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.
- ameliaquining 1y ago
  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.
  - CreepGin 1y ago
    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.
    - ameliaquining 1y ago
      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.

katrinarodri 1y ago

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.

starkparker 1y ago
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.
- jacobgorm 1y ago
  Also the multi repo nature of the Tauri project, and the changes to this structure between 1.x and 2.0, makes migration hard.
yojo 1y ago
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.

mort96 1y ago

Dealing with the rendering differences isn't any more difficult with Tauri than it is when making a normal web app, is it?

Klonoar 1y ago
No, WebkitGTK is notoriously an issue.
- mort96 1y ago
  Is WebKitGTK as used by Tauri worse than WebKitGTK used by a web app user's web browser?
  - porridgeraisin 1y ago
    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.
    - oblio 1y ago
      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?
      - porridgeraisin 1y ago
        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)

CommonGuy 1y ago

We are using system webviews for https://kreya.app 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

Sytten 1y ago
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.
- presentation 1y ago
  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.
  - zdragnar 1y ago
    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.
    - Sammi 1y ago
      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.

cvburgess 1y ago

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.

CreepGin 1y ago
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.

andrewstuart 1y ago

You’re post honeymoon. “We moved from X to Y and were so in love.” posts are often postcards from the honeymoon.

correa_brian 1y ago
We love it here. We're staying together forever

no1youknowz 1y ago

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.

ryanseys 1y ago
Blog post: https://v2.tauri.app/blog/tauri-verso-integration/ https://v2.tauri.app/blog/tauri-verso-integration/ HN discussion: https://news.ycombinator.com/item?id=43518462 https://news.ycombinator.com/item?id=43518462
pikdum 1y ago
Looking forward to either being stable. I like the idea of Tauri, but I need it to work well on Linux too.

deleted 1y ago

[deleted]

deleted 1y ago
[deleted]

NoelJacob 1y ago

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.

sieabahlpark 1y ago
[dead]

pjmlp 1y ago

I guess the Web would be all much better if ChromeOS Platform was everything that remained, who needs standards and multiple vendors.

charcircuit 1y ago
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.
- pjmlp 1y ago
  Ask BSD guys and girls how they feel about that. Monocultures are great, as long they are the one we bet on.
  - charcircuit 1y ago
    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.
    - pjmlp 1y ago
      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.
      - charcircuit 1y ago
        >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.

rs186 1y ago

> 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.

lionkor 1y ago
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.
- rs186 1y ago
  I don't even need to refute the point myself -- plenty of comments under the parent thread have already pointed out problems with Tauri.
- bloomca 1y ago
  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.

platevoltage 1y ago

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.