- 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.
- 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.
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.
Another difference is that it doesn't need to bundle a Node.js or another language runtime.
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.
Also, more complicated apps don't need this, the ones that want to control every aspect of the render, with SVG or Canvas.
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.
marketing
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.
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.
Even bigger drawback is that it ain't Free, honestly. Sure, the licence allows you to use it if the users install the sciter runtime separately, but that ain't really am option beyond development imo.
Every new feature also adds complexity and size, so it goes exactly against one of the main advantages of the project
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.
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 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
Not every feature needs to be supported, which feature are you referring to? Also, given the use case: what is required in your opinion? How does the shift in microsofts scope translate to the efforts to sciter? What did the shift imply?
> sciter is good if you looking for make a small app which not depends too much on web spec.
Since when is it a feature to comply to "web spec"? Why should anyone continue to comply with all new requirements? And why do you feel it is required for portable desktop applications? Why not settle on some proven essentials? And why I am talking about browser now?
Hopefully you elaborate your thoughts: I am sincerly curious about your opinion.
(he also hangs out on HN)
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)
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.
And to that extent, due to the lack of GC, you need to provide it (and keep in your head) with lots of extra information that wouldn't be needed with other languages.
I find that Rust is too strict because it assumes concurrent multithreaded code by default. Which wouldn't be needed for most desktop apps. Why no circular refs or having a mut ref and a ref at the same time, in my simple single-threaded To-Do list Tauri app?
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.
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.
That's a decision the developer has to take, but I'd rather see it as the opposite: the sensible approach is to run just the UI related things in Javascript, and run almost all of your business logic in Rust.
On a tangent, I've been forced to learn and use Swift the last couple weeks, and to my surprise it has been a delight! If it had a more cross-platform spirit, I think I might have found a new favorite of mine for general application development.
As far as I understand, applications are not written in Rust but in HTML/CSS/JS.
Frontend UI yes. But enables you to use rust for your background worker (Electron apps use node for the background worker)
(The cutoff for dupes is a year or so: https://news.ycombinator.com/newsfaq.html)
I wrote a longer explanation about this if anyone wants more: https://news.ycombinator.com/item?id=23071428
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
The problem with changing that policy is that the front page would see a massive influx of "Foo 1.2.3 release" stories. This would not be a step in the direction of the global optimum (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...).
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.
That is, it's not primarily about the diff between announcement N and announcement N+1. It's about the diff between HN thread N and thread N+1. Comments in these threads are almost invariably generically about the project as a whole. You can see that with e.g. https://news.ycombinator.com/item?id=31764384 in the current thread - which is a fine comment in its own right. There's nothing wrong with these threads! The only problem is that we have to regulate how much repetition of them there is.
But on a more serious note, what could they possibly stand to gain to use Deno instead of NodeJS at this point? The languages are mostly the same, the tooling slightly different. Sounds like it'd add a lot of changes just for the sake of changing things. Not to mention newer stuff usually are less tested and higher chance of not working.
Speaking about newer, has Deno received any sort of security audits? Tauri is pretty focused on security, so one could assume that'd be a requirement before even considering Deno.
My guess is that there's only so much change you can foist on people at once. If the point of Tauri is that JavaScript devs can leverage their existing knowledge and skills then meeting them where they (or most of them) are seems like a reasonable strategy.
With neutralino you're using the system main process, so you're only spawning a new browser thread.
i think thats where claim comes from.
edit: embedded lib-chromium thing
Tauri seems like a step in the right direction so will be giving it a go.
I get the impression that it’s a human who doesn’t know how to speak or edit particularly well but normally gets away with it not being too bad (as I say, other videos seem to be better, though they still suffer from the aggressive cut style), but compromised harshly on quality in this case in order to squish more into the hundred seconds… and still ended up 50% over time.
I very strongly dislike the general style.
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.
If not, can you try using it and let us know whether it improves your compile times or not?
Here's the instructions for using it with Rust: https://github.com/rui314/mold#how-to-use=
- Debug build from scratch: ~1m 20s
- Incremental debug build: ~3s
- Release build from scratch: ~3m 40s
So, seems that helped quite a bit, thanks for the tip :)
As someone who is generally unaware of things as I'm new to Rust, is there any drawbacks to using a non-default linker? Everything seems to work fine as far as I can tell, but no drawbacks mentioned in the repository of Meld makes me slightly skeptical.
Out of curiosity: fresh builds or also incremental builds? If the latter, how much of it is linking?
My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies and changing one line in main.rs takes about ~20 seconds for the debug compile to finish (on a 5950X CPU). Fresh build takes about 1m30s but that only happens on CI, so not really a problem day-to-day for me. Full CI build on Codeberg/Woodpecker takes around 5 minutes from push to release created, but that's including other things too.
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
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.
Windows 10/11 both ship with Edge by default, so however big of a problem that is _now_ (probably depends a lot on your target market), it certainly will progressively be a smaller problem over time. Windows 10 was released almost 7 years ago, so while there are undoubtably some corps stuck with windows 8 as their standard, most of the world should've moved on at this point I'd think.
But don't blame Electron. Blame OS vendors and their refusal to standardize anything when it comes to app distribution.
Not just styling buttons with CSS, but actual components like e.g. tab-strips?
Some link to share
- MacOS & Windows https://github.com/gabrielbull/react-desktop - Ubuntu https://github.com/vivek9patel/vivek9patel.github.io - XP https://botoxparty.github.io/XP.css/
There is no such thing like desktop native components, you have to choose the desktop first, every desktop is different, but there are always someone simulate the ui.
I have been unable to find any "desktop-like" components.
There are many many things that just use some CSS styling on native radio buttons or whatever, but very few that offer higher-level functionality like tab-strips where I can pull of a tab and reorder it etc. I.e. more than just styling some divs.
This makes GTK and QT look lightweight in comparison, not to mention FLTK, a 3D enabled, platform independent toolkit, which fits in a statically linkable 300kB library.
Of course, these require C++, and the point of those frameworks is to enable web developers to become application developers. One can't expect resource efficiency when everything has to run on top of a web browser.
- The desktop application I build end up being 16M which seems small enough to me.
- The performance is generally good enough, even though I haven't spent any time optimizing things (here is loading 1000 comments from a HN thread https://ditzes.com/item/31742590, even faster if you use the local version [obviously])
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.
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.
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.
For folks turning web apps into desktop apps, sure it doesn't matter as much, but a real desktop app is way more integrated and feature-full.
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.
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!
Tauri offers a very elegant, secure, and effective way for the WebView JS environment to communicate with the Rust backend. It's not a trivial task to do this effectively and securely, let alone with something ergonomically pleasing.
Anyway, what "native messaging API" are you referring to? Perhaps they missed something obvious, but I found that unlikely.
Jokes aside, it was still a good video!
It would be good to see what it actually looks like before investing in time to build something.
woah! this looks awesome, thanks for mentioning it.
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... )
I have a small `hello-world` example of a rust-only Tauri application at https://github.com/Japanuspus/tauri-from-rust
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.
This rocks, especially with some IPC between the "native" things like filesystem + TCP sockets -> JavaScript "bridge".
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.
Have things matured meaningfully since then?
One issue from 2019: "Tracking : accessibility (a11y)" https://github.com/tauri-apps/tauri/issues/207