Honestly, I think you all should consider changing that policy. Not only because I've seen it broken before, but because major version changes imply things can be broken at upgrade time, and features are settled for a long time. Good to let people know about major releases...
FWIW this post specifically links to the v1.0 release announcement in the form of "Tauri in 100 seconds" video that is now linked from the homepage; this is essentially their launch blog post.
The linked URL nor the video has not been posted before.
I'm just pointing this out as many projects seem to post their 1.3.2 Beta 1 blog posts and that seems to be ok -- or at least I see them pretty often.
In my curious search for lighter Electron alternatives to implement Zoho Writer's (https://writer.zoho.com) desktop app: I found Sciter[1]
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.
I agree that Sciter is pretty exciting. It's tiny and very resource friendly, and the language extensions are quite nice. It also is much better at behaving like a desktop application than Electron. Oh, and did I mention there are Rust bindings?
The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs. Most sufficiently large libraries that do more than pure compute will use an API that isn't supported, so you can't just import a random chart library. Of course fixing that is a sisyphean task for a single-developer project like Sciter.
I still really like it, but if you use it be prepared to either modify the libraries you use or write your own code.
The problem is, you can forget about the entire web and node ecosystems of libraries, because it's just not compatible with any of the standard stuff. You'll probably end up having to write almost everything from scratch.
Also, whatever you write won't then be usable in normal browsers. So it's essentially just another cross-platform UI library, with a DSL for the UI parts - of course that's still good enough for many people.
That sounds like the worst of both worlds, actually. A web-LIKE language that only supports some, not all, of real browser features? Sounds like Internet Explorer all over again.
If you can't reuse the same code between web and the desktop, you might as well use a better desktop framework. This just creates a false positive lookalike that is surface-level compatible but really not reusable and maintainable, and trying to figure out which APIs are shared and which aren't would be more work than just working in a different language & environment altogether.
Sciter isn't exactly a custom browser engine, because it lacks many, many APIs that browsers would use. It just happens to also use HTML & CSS, but it's not Servo-lite or Chromium-lite with V8 slapped on.
sciter looks good, but just don't think about the recent modern web feature, current web feature is impossible to make it right/full by a small team, even ms can not catch up, so they just choose the chromium.
sciter is good if you are looking for make an app based biz which not depends too much on web spec.
- 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.
This is what I thought at first until I dove in more. AFAIK, Tauri makes it possible to write your ENTIRE app in Rust _EXCEPT_ the view. This means you can take events and send them directly to Rust for processing and vice versa. While porting an existing web app might not use any Rust, someone using this to specifically create a Rust GUI app can use the HTML/CSS/JS portion as just a view for their Rust app for the most part.
> 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?
You're assuming the 'heavylifting' part of the application is in the UI itself. Imagine some data processing app where the heavylifting part would benefit from a backend running in Rust. Say, an image enhancer of some kind.
> Without this requirement, it was also trivial before Electron showed up to write a small native wrapper application around the system-provided webview widget.
Electron also made the packaging of such an app dramatically easier when building on macos/linux/windows.
It's an application framework, with UI being only one part of it. It has a native Rust API for writing non-UI parts of the apps in Rust. Plus there's a lot of Tauri's own code for window management, clipboard, networking, auto update, bundling, etc.
Another difference is that it doesn't need to bundle a Node.js or another language runtime.
I think it depends on your use case. Yes, a huge selling point Electron is being able to control the Chromium version. But, I can imagine a lot of less complicated apps don't need this.
Also, the Chromium renderer is only half of an Electron app. There is also a background thread running in node, which can pass messages to the renderer.
So, I can imagine that for apps that are more background thread heavy, swapping out node for rust could work quite well.
> 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?
That is true. It's basically exposing a Rust API and using FFI to the Desktop APIs. Nothing special going on apart from hype and marketing and possible over-promising on features.
> Isn't the whole point of Electron to have version/feature stability for the browser APIs by bundling a specific Chromium runtime?
Yes. The selling point here is that there are no fundamental rewrites needed for using Electron but only small Javascript / Typescript tweaks to get it up and running. This is why unfortunately Electron is used all the time despite the giant negatives. As with Tauri, it is basically a wrapper around the system Webview and using Rust FFI to the Desktop APIs.
I'd rather bet on Flutter Desktop as a possible long term Electron competitor.
Tauri is such a breath of fresh air for a web developer like me! I picked up Rust because of it, and was easier than I thought (I've read lots of "Rust is hard" articles).
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.
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.
This looks fantastic, and Electron needs some competition.
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.
> 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.
Isn't this the same as you have for web, but with a much smaller set of browsers to support? Ie if you're doing a web app anyway, you need to solve that problem.
This seems a very interesting addition to the Rust ecosystem. I wonder how much traction it will get, though.
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)
This is a known downside: rust forces you to write correct code, and will refuse to compile until you prove to it that you don’t have data races, all errors are handled, etc.
If it’s a one time script, I still whip out the trusty Perl one-liner, because correctness doesn’t matter.
I would argue, however, that the vast majority of software would benefit from the rust compiler. The type system is very powerful and modelling your problem in it lets you think about the problem explicitly and guarantees safety around its usage. You can refactor without worrying about the entire codebase breaking, and the doc and testing system is some of the best I’ve seen.
Rust lends itself naturally to writing large maintainable codebases, and I think that this is a much more important aspect that how quickly can you get the initial build out the door. Reliability is not just for the kernel and rendering engine.
You can use tauri without concerning yourself with rust at all. You can use typescript or JavaScript. Optionally if you want too you can write backend stuff that needs to go fast in safe or unsafe rust. It's kinda dreamy if you need to access drivers, or other things that are very uncomfortable to do in js.
When you get comfortable with rust it's just like any other language you might use. Yea it has safety benefits but it's just a nice language.
People talk about rust like it's impossible to learn, or not worth it, I think it's a language every programmer should learn at some point to fact check their understanding of memory management. It does take a few weeks to figure out for some people, but writing basic/easy/sane rust isn't a challenge at all.
For electron based apps, most part of the codebase runs on the chrominum front-end - written in JavaScript / HTML. Usually only some critical code runs on the node backend.
As such then, the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem, while the critical parts can be offloaded to Rust. Even the filesystem access is possible in JavaScript side itself.
Tauri is "just" a system webview wrapper. It's an interesting alternative to Electron for some applications because the installer is much smaller, but it also has downsides compared to Electron (the system web view will be updated independently and may unexpectedly break the application).
As far as I understand, applications are not written in Rust but in HTML/CSS/JS.
For anyone not on board because of how the WebViews work, or that it uses WebViews at all, the roadmap has other renderers to be explored. I believe the majority of the Tauri framework is decoupled from "web" and it's merely supported first - likely through popularity.
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.
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.
For anyone coming from the rust side and just looking for a cross-platform rust frontend framework: although not covered in any details by the docs, you can cut out all the web stuff and run everything from cargo.
Here is another one https://github.com/wailsapp/wails powered by Golang, but both of tauri and wails do not support BrowserView like feature in Electron, which means you can not build a brave browser on top of them.
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
Been using tauri since it was in alpha for hobby project. Experience overall is pretty good. You really can call backend rust from js, in a lightweight browser window.
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.
Tauri is very well designed, from an app model to its component parts (wry, tao). In short, it’s a platform that allows writing Rust as the backend and use of the OS webview. So light and fast.
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.
I've always felt Tauri was too early to be a viable electron competitor, but now that I've seen it used in a huge project (Spacedrive), I think I might reconsider.
Whatever their opinions on this project. I'm pretty much like it when start to create a small project, it's very light in terms of memory usage, also the size of the compiled binary is way smaller than electron.
That 100 second video was really very well done and convincing. I shouldn't have watched it on break because now I want to do go home and do something with Tauri :)
[+] [-] dang|3 years ago|reply
(The cutoff for dupes is a year or so: https://news.ycombinator.com/newsfaq.html)
[+] [-] password4321|3 years ago|reply
[+] [-] crabbygrabby|3 years ago|reply
[+] [-] Uninen|3 years ago|reply
The linked URL nor the video has not been posted before.
I'm just pointing this out as many projects seem to post their 1.3.2 Beta 1 blog posts and that seems to be ok -- or at least I see them pretty often.
[+] [-] f4ncyp4ntz|3 years ago|reply
[deleted]
[+] [-] lewisjoe|3 years ago|reply
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.
[1] https://sciter.com
[+] [-] wongarsu|3 years ago|reply
The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs. Most sufficiently large libraries that do more than pure compute will use an API that isn't supported, so you can't just import a random chart library. Of course fixing that is a sisyphean task for a single-developer project like Sciter.
I still really like it, but if you use it be prepared to either modify the libraries you use or write your own code.
[+] [-] realharo|3 years ago|reply
Also, whatever you write won't then be usable in normal browsers. So it's essentially just another cross-platform UI library, with a DSL for the UI parts - of course that's still good enough for many people.
[+] [-] solardev|3 years ago|reply
If you can't reuse the same code between web and the desktop, you might as well use a better desktop framework. This just creates a false positive lookalike that is surface-level compatible but really not reusable and maintainable, and trying to figure out which APIs are shared and which aren't would be more work than just working in a different language & environment altogether.
[+] [-] ohgodplsno|3 years ago|reply
Sciter isn't exactly a custom browser engine, because it lacks many, many APIs that browsers would use. It just happens to also use HTML & CSS, but it's not Servo-lite or Chromium-lite with V8 slapped on.
[+] [-] wener|3 years ago|reply
sciter is good if you are looking for make an app based biz which not depends too much on web spec.
EDIT: small app -> app biz
[+] [-] leeoniya|3 years ago|reply
(he also hangs out on HN)
[+] [-] flohofwoe|3 years ago|reply
- 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.
[+] [-] nu11ptr|3 years ago|reply
[+] [-] iffycan|3 years ago|reply
- Cross-platform auto-updating
- Desktop tray features
- System notifications
- Menu stuff
These are some of the "extra" things that also made Electron nice.
You have a point about browser API compatibility, though. That's the big downside to using the system-provided webview widget.
[+] [-] Octoth0rpe|3 years ago|reply
You're assuming the 'heavylifting' part of the application is in the UI itself. Imagine some data processing app where the heavylifting part would benefit from a backend running in Rust. Say, an image enhancer of some kind.
> Without this requirement, it was also trivial before Electron showed up to write a small native wrapper application around the system-provided webview widget.
Electron also made the packaging of such an app dramatically easier when building on macos/linux/windows.
[+] [-] pornel|3 years ago|reply
Another difference is that it doesn't need to bundle a Node.js or another language runtime.
[+] [-] Humphrey|3 years ago|reply
Also, the Chromium renderer is only half of an Electron app. There is also a background thread running in node, which can pass messages to the renderer.
So, I can imagine that for apps that are more background thread heavy, swapping out node for rust could work quite well.
[+] [-] rvz|3 years ago|reply
That is true. It's basically exposing a Rust API and using FFI to the Desktop APIs. Nothing special going on apart from hype and marketing and possible over-promising on features.
> Isn't the whole point of Electron to have version/feature stability for the browser APIs by bundling a specific Chromium runtime?
Yes. The selling point here is that there are no fundamental rewrites needed for using Electron but only small Javascript / Typescript tweaks to get it up and running. This is why unfortunately Electron is used all the time despite the giant negatives. As with Tauri, it is basically a wrapper around the system Webview and using Rust FFI to the Desktop APIs.
I'd rather bet on Flutter Desktop as a possible long term Electron competitor.
[+] [-] stjohnswarts|3 years ago|reply
[+] [-] jeremychone|3 years ago|reply
[+] [-] waplot|3 years ago|reply
marketing
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Vaslo|3 years ago|reply
[deleted]
[+] [-] Uninen|3 years ago|reply
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... )
[+] [-] capableweb|3 years ago|reply
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.
[+] [-] rathboma|3 years ago|reply
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.
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.
[+] [-] klabb3|3 years ago|reply
Isn't this the same as you have for web, but with a much smaller set of browsers to support? Ie if you're doing a web app anyway, you need to solve that problem.
[+] [-] j1elo|3 years ago|reply
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)
[+] [-] e63f67dd-065b|3 years ago|reply
I would argue, however, that the vast majority of software would benefit from the rust compiler. The type system is very powerful and modelling your problem in it lets you think about the problem explicitly and guarantees safety around its usage. You can refactor without worrying about the entire codebase breaking, and the doc and testing system is some of the best I’ve seen.
Rust lends itself naturally to writing large maintainable codebases, and I think that this is a much more important aspect that how quickly can you get the initial build out the door. Reliability is not just for the kernel and rendering engine.
[+] [-] crabbygrabby|3 years ago|reply
When you get comfortable with rust it's just like any other language you might use. Yea it has safety benefits but it's just a nice language.
People talk about rust like it's impossible to learn, or not worth it, I think it's a language every programmer should learn at some point to fact check their understanding of memory management. It does take a few weeks to figure out for some people, but writing basic/easy/sane rust isn't a challenge at all.
[+] [-] anoopelias|3 years ago|reply
As such then, the proposal from tauri is to run majority of the application in JavaScript / HTML ecosystem, while the critical parts can be offloaded to Rust. Even the filesystem access is possible in JavaScript side itself.
From that sense I feel this is a good tradeoff.
[+] [-] flohofwoe|3 years ago|reply
As far as I understand, applications are not written in Rust but in HTML/CSS/JS.
[+] [-] BiteCode_dev|3 years ago|reply
[+] [-] lucasyvas|3 years ago|reply
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.
[+] [-] galaxyLogic|3 years ago|reply
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.
[+] [-] __ryan__|3 years ago|reply
[+] [-] japanuspus|3 years ago|reply
I have a small `hello-world` example of a rust-only Tauri application at https://github.com/Japanuspus/tauri-from-rust
[+] [-] wener|3 years ago|reply
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
[+] [-] remram|3 years ago|reply
[+] [-] crabbygrabby|3 years ago|reply
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.
[+] [-] petercooper|3 years ago|reply
[+] [-] jeremychone|3 years ago|reply
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!
[+] [-] AndrianV|3 years ago|reply
[+] [-] hdjjhhvvhga|3 years ago|reply
https://neutralino.js.org/
[+] [-] zeandcode|3 years ago|reply
[+] [-] lynndotpy|3 years ago|reply
[+] [-] akmarinov|3 years ago|reply
[+] [-] linkdd|3 years ago|reply
[+] [-] sourabhv|3 years ago|reply