81–90 of 101 posts
Earlier quoted context omitted.
Sadly instead of having native apps we have "web" monstrosities... each sporting custom "fancy" UI instead of following the OS native style…
Because WinUI and QT are so glamorous and offer a super intuitive development experience. /s
Took a look at the homepage ( https://v2.tauri.app/ )... and basically have no idea what this is or why I would use it. Consider adding something more informative than 'Hardened foundation for your web apps', and maybe an 'About' page.
> Hardened foundation for your web apps
The honest description is : smaller faster electron for macos/win/linux/android/ios - written in rust using the OS provided web browser component for tiny binaries. The Tauri developer's focus on security in their marketing is genuine (they have paid for audits) but a little incongruous given what most of it's users want from it which is just a cross-platform UI and/or with a great rust experience.
I have really been enjoying v2 with Leptos with no problems. Ironically the only tricky bit has been setting up permissions for various types of system access (docs are not quite there) but it was simple and made sense once I saw how to do it. I expected a bad experience from the Linux OS web component but it's been excellent in terms of both performance and support on Ubuntu 22.04. The way Tauri can package your app as a .deb or .apk was crazy simple which I also did not expect.
Took a look at the homepage ( https://v2.tauri.app/ )... and basically have no idea what this is or why I would use it. Consider adding something more informative than 'Hardened foundation for your web apps', and maybe an 'About' page.
Electron replacement
Earlier quoted context omitted.
Yup this was also our first impression. Wait until you have users (no snark here, but its the reality). We do have around 1/3 of our users on Linux and WebKitGTK is plainly bad. Our application is complex I will give you that, but it isnt just that. Say you want to use WASM you have to check which macos versions you want to support and check the oldest possible webview (it doesn't get updated at the same time as safa…
This is just the reality of web development. You'd have the same issues if you were developing a PWA. Blaming Tauri for this doesn't seem fair. It sounds like Electron is a better fit for what you're trying to do.
Earlier quoted context omitted.
This is just the reality of web development. You'd have the same issues if you were developing a PWA. Blaming Tauri for this doesn't seem fair. It sounds like Electron is a better fit for what you're trying to do.
Not really PWA will use your browser of choice which is likely up to date. Tauri often is run on system with very old webviews like 6-7 years old.
Earlier quoted context omitted.
When it comes to a non-hosted web app most non-technical users would have no concept or ability to run a local web server whereas “install this app” is something they’re familiar with. I’m talking from a position of “I have an app that I want to distribute to a population of end users.” If that population happens to be technical your solution would likely work fine. As well if you’re not distributing apps to end user…
> When it comes to a non-hosted web app most non-technical users would have no concept or ability to run a local web server whereas “install this app” is something they’re familiar with. Clearly not true. Sonarr and Radarr for example installs like a normal app. Then sits in the system tray. If click the system tray, most options inside launch a web browser that brings you to the localhost webapp. https://sonarr.tv/…
Explicitly removing the browser capabilities/tools is a feature imo. i.e to hide the moving parts.
Within a browser, the average low tech users may:
- ...install extensions(ad blockers? dark reader?) that interfere with the app in some way.
- ...mess with the back/forward buttons ,corrupting the router/ui state, or just get very curious why the back button kicks them back to the last page instead of closing a fullscreen modal.
- ...bookmark SPA js-driven pages where the ui state is not fully saved in the address bar(via query params, hashes, etc) and surprisingly find them broken/not working as intended when accessing the bookmark again.
- ...try to copy and send the "localhost" link to their friends and complain.(Hold on to your papers - I've seen this behavior at my workplace!)
All of those will generate complains, useless bug reports and sometimes negative reviews. While some (if not most) of the problems can be solved with great software design and extra care, I think solving these problems comes at a cost that can be very well avoided by simply removing these capabilities.
Earlier quoted context omitted.
> When it comes to a non-hosted web app most non-technical users would have no concept or ability to run a local web server whereas “install this app” is something they’re familiar with. Clearly not true. Sonarr and Radarr for example installs like a normal app. Then sits in the system tray. If click the system tray, most options inside launch a web browser that brings you to the localhost webapp. https://sonarr.tv/…
> It seems so inferior to have the same thing but lose access to the browser's suite of tools/capabilities. Explicitly removing the browser capabilities/tools is a feature imo. i.e to hide the moving parts. Within a browser, the average low tech users may: - ...install extensions(ad blockers? dark reader?) that interfere with the app in some way. - ...mess with the back/forward buttons ,corrupting the router/ui state…
Earlier quoted context omitted.
Yup this was also our first impression. Wait until you have users (no snark here, but its the reality). We do have around 1/3 of our users on Linux and WebKitGTK is plainly bad. Our application is complex I will give you that, but it isnt just that. Say you want to use WASM you have to check which macos versions you want to support and check the oldest possible webview (it doesn't get updated at the same time as safa…
This is just the reality of web development. You'd have the same issues if you were developing a PWA. Blaming Tauri for this doesn't seem fair. It sounds like Electron is a better fit for what you're trying to do.
Personally I think the ideal scenario would be allowing developers a choice between: 1. Use the native OS renderer 2. Bundle a specific version of some renderer (most likely Chrome) 3. Use a shared library for the renderer (this gets a little trickier with sandbox-based security models, but allows Tauri to ship a renderer without ballooning the bundle size of each individual app)
As a user, I'd be happy with a combo of #1 and #2. Use the native OS renderer by default, but allow me to install a "known good" renderer if I run into problems. Since it sounds like MacOS and Windows both ship better native web renderers than Linux this would likely be an option mostly used by Linux users, who are on average more willing to poke around in the settings to enable a compatibility option.
Earlier quoted context omitted.
> Say you want to use WASM... Using WASM, unless you're doing it for some really good reasons, seems like overkill for essentially a front-end layer. I think of the WebView in a Electron/Tauri app as comparable to the Qt Framework. It's not supposed to do any heavy lifting, and trying to do heavy lifting in JS suggests a mis-architecting of the app.
Using wasm is becoming a very common and practical thing to do, especially with how you can cross compile so much into it. Unless you're just making blogs and content pages, it's just part of writing web apps now
It hardly adds anything in performance if there are too many DOM interactions, and if the performance need is due to compute, all modern computers have a GPU.
Earlier quoted context omitted.
Sadly instead of having native apps we have "web" monstrosities... each sporting custom "fancy" UI instead of following the OS native style…
Because WinUI and QT are so glamorous and offer a super intuitive development experience. /s
Not even portable Web code, they rather ship a copy of Chrome, and then complain Google has taken over the Web.