by Uninen on 6/16/22, 9:24 AM with 238 comments
by dang on 6/16/22, 4:44 PM
(The cutoff for dupes is a year or so: https://news.ycombinator.com/newsfaq.html)
by lewisjoe on 6/16/22, 11:47 AM
It supports multiplatform app development with HTML/JS/CSS and the entire engine's runtime is just about 5MB which is unbelievably small!
I further analysed how this was possible, what I found was beyond fascinating.
1. The author has wrote a compiler that supports JS with useful extensions like classes and fancy stuff, even before ES6 came into existence.
2. He had built his own layouting engine that understands HTML and CSS 3.0
Basically he's built a custom browser engine, but custom tailored for writing multi-platform apps. So it's super-fast without as much memory taxes. It's not backed by a BigCo or a huge community (I guess) and I'm not sure whether I'll pick it for a business critical app. But the way it's architected seems far superior than the shortcut approaches that Electron or most other alternatives take.
The project is not even new. It's more than a decade old which itself is amazing.
by flohofwoe on 6/16/22, 11:15 AM
- What's the point of mentioning Rust when the heavylifting is done by the system's webview widget, and applications are written in HTML/CSS/JS, just as in Electron?
- Isn't the whole point of Electron to have version/feature stability for the browser APIs by bundling a specific Chromium runtime? Without this requirement, it was also trivial before Electron showed up to write a small native wrapper application around the system-provided webview widget.
by Uninen on 6/16/22, 12:17 PM
The project encouraged me to better my own workflows too, as even the awesome-tauri repo requires signed commits in the PR template :) ( https://github.com/tauri-apps/awesome-tauri/blob/dev/.github... )
by capableweb on 6/16/22, 10:26 AM
The application I wrote is a Hacker News client with focus on offline reading and listing comments in threads sorted by time and flat, instead of trees sorted by score (which incidentally, also works as a web application which is deployed here: https://ditzes.com/).
I found it helpful when I'm traveling but still want to read discussions, useful for following along threads that are actively being discussed (this submission can be seen at https://ditzes.com/item/31764015 for example) and also useful when using HN comments as reference to something I'm building. Guess I'm also pretty proud that the client is VERY fast, loading 1000 comments in something like 1s (because of the caching). Like this thread for the Coinbase layoffs: https://ditzes.com/item/31742590 (1001 comments)
The Tauri application currently works with 99% of the features of Ditzes, but the mouse "back" button doesn't actually navigate the internal browser back in history with Tauri yet, so I haven't done a "Show HN" yet as I consider that a essential feature of Ditzes (for following along threads via the "View" link) before "launching" it.
The Tauri-part of the source can be found here: https://codeberg.org/ditzes/ditzes/src/branch/master/src-tau...
Overall, besides the extremely long compile times, Tauri has a been a pleasure to develop with, and I'd definitively use it over Electron in the future. Really looking forward to mobile support as well, as then I'll finally have a comfortable and offline-capable HN client for my cellphone.
by rathboma on 6/16/22, 2:14 PM
That said, here's my set of hesitations as an Electron app developer (Beekeeper Studio - beekeeperstudio.io).
1. With Electron it's nice to be able to lock the browser implementation across OSs. I'd have some pause about having to support arbitrary Webview implementations. It makes testing so much harder.
2. It's really really nice to be able to code-share between UI code and app backend code. In Electron everything is JS, so you can use the same codebase for both components. With Tauri it requires two languages and two sets of packages.
- One example of this is an ORM for a SQLite database. I need to load some settings before the UI renders, in Electron this is the same ORM code.
3. The only Linux build is a DEB.4. Smaller community - desktop apps are a total PITA to debug, it helps that Electron builds have been tested at length by companies like Microsoft.
by j1elo on 6/16/22, 11:18 AM
Some days ago there was an HN thread about Rust, conversing about the steep learning curve of Rust. The conclusion frequently is that maybe Rust is great for financial systems, kernels, rendering engines, media processors, etc... but just not necessarily the best tool for the job when there is no pressing need to avoid GC, and/or to squeeze the maximum performance while at the same time maintaining memory correctness. Which, on the other hand, tends to be the immense majority of application development out there...
So Tauri seems to me has a similar issue than the Qt Framework (built on and for C++): its adoption as an Electron alternative might not be as much as it deserves, because of the difficult to learn programming language that is behind it.
Thoughts?
EDIT: I know Tauri is just a WebView component, but programming in Rust still seems to be an important part of developing apps with it (it is even prominently featured in the 100 seconds video of the entry)
by lucasyvas on 6/16/22, 2:00 PM
When WebView2 goes multiplatform, you might even be able to use it on every platform (if you like web, but want a consistent browser engine on each platform)
I'm more interested in where Tauri will go next in terms of support - not where it is on day 1.
by galaxyLogic on 6/16/22, 3:19 PM
You write a server in Node.js, compile it to an exe with Vercel Pkg and users run the exe on their local machine and use it with their browser.
Instead of running an app "in the cloud" they run it on the server on their machine. But the server could easily also be moved to the cloud as well.
Using a browser to connect to an app running on your local machine has the nice feature that you can open any number of browser-views on it, looking at the app and your data and tools from multiple viewpoints. Since it is local they are the only user and don't need to login or "keep a session" and can thus interact with the app in multiple ways in parallel.
I don't need to design in a feature that allows users to "open a new window". That is handled by the browser. Open a new tab to the same or different (bookmarked) url.
Plus there is a benefit to coding both the server and the client in the same language.
by japanuspus on 6/16/22, 1:36 PM
I have a small `hello-world` example of a rust-only Tauri application at https://github.com/Japanuspus/tauri-from-rust
by wener on 6/16/22, 11:35 AM
Depends on your skill set, wails maybe better, think building a UI based tailscale app, just make the embed web part display directly instead behind a http.Server with extra 3-5 MB
by crabbygrabby on 6/16/22, 11:12 AM
It is probably the most approachable technology for me for making desktop apps these days. Much leaner than electron, like it says on the tin.
by petercooper on 6/16/22, 11:08 AM
by jeremychone on 6/16/22, 1:50 PM
I think and hope that many new desktop apps, even from the new big player, will be done in Tauri. I plan to use it for some of our future apps.
I know mobile is a whole other beast, but I hope Tauri can also crack this one up. That would be amazing.
Tauri rocks!
by AndrianV on 6/16/22, 1:57 PM
by hdjjhhvvhga on 6/16/22, 11:08 AM
by zeandcode on 6/16/22, 3:40 PM
by lynndotpy on 6/16/22, 2:57 PM
by akmarinov on 6/16/22, 10:13 AM
by sourabhv on 6/16/22, 11:31 AM
by MuffinFlavored on 6/16/22, 3:22 PM
This rocks, especially with some IPC between the "native" things like filesystem + TCP sockets -> JavaScript "bridge".
by smdyc1 on 6/16/22, 12:37 PM
by vegai_ on 6/16/22, 12:00 PM
by tensor on 6/16/22, 2:35 PM
by encryptluks2 on 6/16/22, 1:53 PM
I'd rather see a unified solution which pretty much exists then to have a bunch of alternatives that provide no greater benefits overall from what I can tell.
by api on 6/16/22, 11:15 AM
The usual problem is that you have to either use an antiquated IE based webview on Windows or install the Microsoft Edge runtime. The latter is painful to bundle and some people don't like it, especially enterprisey IT departments who consider it "another thing" they have to approve instead of just a part of the app since it's a separate OS component.
by sva_ on 6/16/22, 10:17 AM
by IceHegel on 6/16/22, 3:22 PM
Have things matured meaningfully since then?
by mattlondon on 6/16/22, 11:45 AM
Not just styling buttons with CSS, but actual components like e.g. tab-strips?
by password4321 on 6/16/22, 4:46 PM
One issue from 2019: "Tracking : accessibility (a11y)" https://github.com/tauri-apps/tauri/issues/207
by synergy20 on 6/16/22, 4:42 PM
by CMCDragonkai on 6/16/22, 3:43 PM
by aitchnyu on 6/16/22, 11:31 AM
by bennyp101 on 6/16/22, 10:37 AM
by knowsuchagency on 6/16/22, 7:56 PM
by k__ on 6/16/22, 11:04 AM
by productceo on 6/16/22, 10:52 AM
by showmeademo on 6/16/22, 12:13 PM
It would be good to see what it actually looks like before investing in time to build something.
by SeasonalEnnui on 6/16/22, 10:13 AM
Tauri seems like a step in the right direction so will be giving it a go.
by billfruit on 6/16/22, 3:32 PM
by nachtigall on 6/16/22, 10:39 AM
by newbieuser on 6/16/22, 11:26 AM
by UmbertoNoEco on 6/16/22, 3:23 PM
by jbverschoor on 6/16/22, 2:58 PM
by torginus on 6/16/22, 2:12 PM