I build and ship a production application using tauri and linux support is the most painful experience I had in a long time.
They use WebKit GTK which is really not a good fondation IMO, its hard to test for all versions, its much slower than other browser, it has weird bugs.
In general the idea of not shipping a browser bundle is nice, in practice it doesn't really work for a startup. It's just too much unrelated testing and debugging work you need to do to support old outdated systems.
We were very excited to use tauri since we are a rust shop, but we are strongly considering moving to electron unless we get a way to bundle a renderer.
I have used Tauri (or more accurately, WRY) for Windows and macOS and it worked very great in my opinion. It still needed some tweaks to suit my needs, which was the main reason I didn't use Tauri proper, but I guess your issues are more related to the lack of well-known system web view in linux. It might make sense for Tauri to bundle the browser engine only for linux if this is a big concern.
But do note (given the context of this discussion) that Iced is completely unsuitable for the web. Early on it had an actual web renderer (iced_web), but they stopped maintaining it and it doesn’t work any more, so what you get if you use Iced on the web is the pure-canvas approach, which is fundamentally and irredeemably unsuitable for general-purpose web content and apps. (I’ve written about this a number of times here on HN; https://news.ycombinator.com/item?id=33861831 is one.)
By all means use it on desktop platforms, but it won’t get you an acceptable web version.
WebKit is five loosely related browser engines in a trench coat. A lot of the code is "platform" specific, and most of the optimization happens in that layer. Apple's Cocoa webkit is a lot more polished than WebkitGTK could ever hope to be with its meagre dev resources.
I think you might be confusing an OS web view - which is what Tauri uses - with WebKit, which is the web view on Apple operating systems. It’s the way to get Safari inside your app if you are on an Apple device. On Linux, there is no WebKit, the web view will be your system browser. That might not be very fast.
Most of the Electron junk can be easily done as pure Web application, of course authors don't want to pay for hosting and ship a browser and server with the application.
There are a very tiny percentage of such startup ideas that really need features not available on a standard Web browser.
Now that at least Windows, Chrome OS, and soon macOS properly support PWAs it will finally get feasible to add web apps to your desktop environment. I know I’ll upgrade to the new macOS ASAP just to get rid of slack.
I tried this same approach (embedded webview instead of e.g. electron -- https://github.com/rdaum/vstwebview) for something last year and I agree the biggest problem is Linux support, specifically WebKit GTK.
On Windows, and to a lesser degree on the Mac, this approach actually went pretty smoothly. But WebKit GTK introduces all sorts of problems -- having to tie into GTK's event loop even though you don't want it, dealing with distribution variances, event binding issues, etc.
I suspect the answer here for Tauri is that someone needs to expend the effort to come up with a good Rust crate bundling of Chromium or Gecko or etc that isn't tied into GTK. Yes, it would defeat the "just use the platform's webview instead of bundling" line, but really it would only be a concern for Linux.
> One of the main core differences with Tauri is that it uses a Webview instead of using chromium like in Electron. This means that every desktop application doesn’t have to ship with chromium and can rely on the native browser’s webviews. The downside here is that because it is using Webview you have to deal with different quirks of different operating systems.
ElectronJS is a cross-platform framework. It is bloated because it ships a full cross-platform browser (Chromium) in order... well in order to be cross-platform.
Tauri wants to be less bloated, and therefore removes Chromium. Which makes it... not so cross-platform, apparently.
Genuine question: why not going for a JVM-based technology? That's cross-platform, and it doesn't require a web browser / webview to show text.
Not to pick on the JVM, but does anyone actually build new desktop software for the JVM that's meant to be downloaded and installed by mainstream consumers? Qt and other frameworks work pretty well (with their own flaws) but I'd simply never even consider the JVM as a viable option for desktop software. The last JVM app I installed was probably Minecraft in 2012.
I will say that my dev cycle builds (full clean and rebuild) take about 20s, which is nice. That nets me a “runnable fat jar”. Running the packager for the platform installers takes longer on top of that, but that’s not part of my dev cycle.
I dev on macOS, I have “tested” on Ubuntu and Windows, and the app works. My buttons button, cut and paste works, drag and drop (I can drag one of my generated images and drop it into, say, Word) works, I can generate PDFs via the “print to PDF” features of the platforms, including my custom fonts. I also have, like, 10 lines of code that uses JavaFX 3D — and that works.
It all works, and so far, knock on wood, the “cross platform” parts are doing what they’re supposed to do.
All that said, germane to the overall topic, there’s this funny little tidbit. In my app, all my bundled documentation is simply in HTML using bundled pages. And I show that in a JavaFX WebView. And WebView is built on WebKit. So in the end, if you need any HTML in your app, you bundle WebKit anyway.
Of course, if you don’t, WebView is in its own module that you don’t have to ship if you don’t need it.
For me it's probably Ghidra or Jetbrains IDEA in 2023. Both are desktop, thought I could see the debate on whether or not developers are considered mainstream consumers. I use them on Linux and Windows, so I definitely get value out of their cross platform capabilities.
I use Eclipse-based tools at work (again, I can see the debate). It seems like Samsung's Smarthings (IoT platform) used to use Groovy, but has recently migrated away.
I also know you said desktop, but a weak argument could be made in favor of the (also weak) JVM connections of Android. I'd put forth that some Android usecases are basically former desktop usecases.
A lot of modern consumer and business oriented GUI apps run on JVMs and they look very platform native too. In finance, I’ve come across many of them. You can take a look at the upstream demo apps for Swing with FlatLaf and for JavaFX (rebranded to OpenFX). They perform nicely. I’ve been struggling with the JetBrains tools’ performance on large JVM projects but given the complexity and reindexing it’s justified, Visual Studio would simply hang indefinitely on such code bases, VS Code just doesn’t do this much.
Then there’s also Kotlin Multiplatform and Jetpack Compose, and now Compose Multiplatform (desktop, mobile, web including JS and WASM). Their DSL is really amazing, truly compositional and resembling the way you do React. To me that’s the path cross-platform GUI will be taking now.
On the .NET side, there’s Avalonia UI and Uno Platform as cross-platform alternatives, with Avalonia UI v11 (pending release) even doing mobile on almost the same code base.
> Not to pick on the JVM, but does anyone actually build new desktop software for the JVM that's meant to be downloaded and installed by mainstream consumers?
Does anyone actually build new desktop software for mainstream consumers these days?
JVM UI is "good enough", I've seen it used for businessey tools where the point is the functionality rather than the polish (including hobby tools). Honestly it may well be the best non-electron option once you think about the whole stack; with Qt you have to either write C++ and deal with that, or use the Python bindings and deal with that.
JavaFX/OpenFX is surprisingly decent these days, but it got suckerpunched by Oracle licensing for a long time and had a bunch of compatibility issues between releases that made upgrading painful.
I probably would consider it now for a new project, but not 5-10 years ago, when dev cycles for now-popular apps would've started realistically.
There are more than a few decent Java GUI apps out there, some built with swing, some with JavaFX, some with SWT, maybe we will soon see some using jetbrains compose. I would say that the developer experience isn't bad at all, but if you want to make a very complex or unique application, you will want to surround yourself with someone who knows those stacks very well (just like any other tech), the problem being that it's a dying breed.
If you want to make a small to mid-scale GUI, I'd argue that you'll be better off with a java toolkit than anything web based (tooling is awesome, there are RAD tools to prototype and iterate quickly, ...). The alternative I see in this space is PyQt/Qt for Python, but it's easy to shoot yourself in the foot with it and everyone knows how terrible packaging and shipping python is.
LibreOffice is still built on Java, that's probably the main consumer app that still is. Of course, there are developer tools like the Jetbrains IDEs still running on the JVM, but those aren't for mainstream consumers.
Nowadays it can be hard to tell if something uses Java, since it's recommended to just bundle a JRE with your app so a user doesn't have to know/care about Java.
I, for one, am looking forward to the evolution of stuff like Compose for Desktop. Kotlin + Compose on Android is just amazing, I wish it worked as well on Desktop.
IMO native widgets are dead. Users have become accustomed to the graphical gimmicks that are easy with a full-blown browser rendering engine.
Even a resizable background image is really hard to do with pure native widgets.
This means cross-platform libraries that wrap native widgets are dead as well. Now you need to ship your own rendering engine, and suddenly an entire browser looks reasonable. E.g. JavaFX isn't a featherweight either...
The web browser is a feature, it allows developers to not have to code a second UI for their app, when they often have already built a web version. And it neatly end runs around having to make a cross platform UI toolkit that doesn’t look like hot garbage on every platform.
I guess we aren't aware of any Electron alternatives built with JVM. We started out as a web app so we need something that would bundle web based technology. Besides electron Tauri seemed like it was the next best bet.
I'm curious if you would have considered it if there was a Tauri-like thing with a JVM backend (maybe natively compiled AOT)? That is, if you could write "backend" code in a high level GCd language whilst using HTML/CSS as the UI layer, would that have been preferable to Rust?
The JVM being truly cross-platform was a bit of a lie depending on what you do.[1]
"Java is write once, test and debug everywhere."
Also the ui toolkits for JVM ecosystems are just not as nice to develop with. But I was pretty hardcore C#/.net back in those days so take what I say there with a grain of salt.
Or why not use Flutter? You can integrate with Rust as FFI via flutter_rust_bridge. That's what I do as Flutter is pretty cross platform yet much leaner than even using a browser engine.
A good idea. I think Flutter loses quite badly to React for web apps. But if you want to build a cross-platform app it works well. Dart is similar to Javascript and not difficult to pick up.
> Tauri wants to be less bloated, and therefore removes Chromium. Which makes it... not so cross-platform, apparently.
It's certainly cross-platform. Name a current OS that doesn't have one WebKit-forked webview or another available at all times. If you don't like Apple's insistence on only baseline WebKit out of the box, there's Microsoft's WebView2 which ships a known Chromium to every major desktop OS.
But really, if you are a web developer complaining about the differences between WebKit and Chromium, you may be spoiled. If you are a web developer complaining that you can't package a specific Chromium version (which is the real Electron benefit, not just that it packages its own Chromium but that every Electron app can pick and choose down to the exact Chromium version they want to ship), you've gone beyond spoiled to basically distrusting how the web platform is supposed to work.
(That's before you get to the other monoculture assumptions that no modern OS is instead shipping something like Firefox as the system default webview in 2023. It's all one tiny family tree with WebKit as the trunk.)
If you offer developers the choice of either embedding a whole web browser and not dealing with platform differences, or not embedding a whole web browser and dealing with differences between the now-evergreen browser engines on each major platform, many may pick the latter to be more user-friendly. I certainly would.
But as long as you’re maintaining a webapp anyways, you still have to do all that browser support. Using tauri doesn’t make it worse than a webapp that only runs in a browser context.
Sure but with Electron you don't have to worry about browser differences. And you can use experimental web stuff.
If your app is primarily a website and you want to wrap it as an app then I guess Tauri makes some sense. E.g. something like Slack or Gmail.
If you're just using it as a way to make a desktop app then it makes more sense to use Electron unless your UI is very simple and download size is very important (e.g. something like the Raspberry Pi Imager app; though that uses QtQuick).
You've been able to package your java apps so to not require that from your users for a very long time, and in the more recent years, with the compartmentalization of the JDK, you've been able to ship a very striped down version of it, and even more recently, an AOT compiled/PGO optimized binary, so nowadays you can ship your instant starting/low footprint/well performing java code without Java/a JVM.
Is it just me or do others find the Electron bashing a little over the top as well?
I mean VS Code, Discord, Slack and Obsidian are all in very widespread use and work perfectly fine for me.
Are there alternatives to Electron that require less resources? Tauri seems to be proof that there are.
But I think there is real value in large communities and backing. Electron seems to work perfectly fine to me for everyday use as is evident by the applications mentioned above. I would personally choose Electron over Tauri even for greenfield projects, simply because Electron seems to power applications that are in much more widespread use.
While I appreciate VSCode, I think Discord, Slack and Obsidian are not selling the platform at all. They feel sluggish and have poor ergonomics. Now the second one may or may not be attributed to Electron depending of if you buy the cultural thinggy, but the first one clearly is. Mumble is super reactive in comparison to them, and most note softwares dance around Obsidian.
Having a latency on local clicks and transitions is not my idea of fun.
VSCode is an outlier here. And it's getting slower and slower with age, while sublime text is getting faster.
These things are all very subjective. Not everyone is affected the same way by latency. I hear people complaining about it all the time on thw internet, but in practice I never notice it and I don't know anyone that does either. Ergonomics is the same, I think discord is really nice to use and all the alternatives I've used have been worse.
To be clear, your opinion is absolutely valid I just don't think they apply equally to everyone.
Discord is not working "perfectly fine" on desktop for many people. Usually, the browser version is faster, needs less resources, has fewer platform integration problems (mic/camera access etc.), and crashes less often. And has less critical security vulnerabilities, as a browser gets patched much faster than Electron in general, and Discord in particular (who tend to be on an older branch, due to some native C++ libraries, that as far as I can tell have no user-visible impact).
And VSCode has to be contrasted with Atom, which is the same but in so much worse: It takes a lot of effort to make Electron work well.
I maintain an open-source app built with Electron. It serves tens of thousands of users every months and nobody complained in 5 years that it is being built with Electron. Not saying that Electron is perfect, and that it couldn't be a bit more performant, but as a solo maintainer (and entrepreneur) it helps me ship something that save people time. The burden of maintaining an application is already huge. Having to juggle with multiple environments would be a hassle and I definitely wouldn't do it.
That being said, if a "drop-in" alternative would be available I would probably try to switch at one point. But the alternative would have to be on par with the ecosystem (including packaging, binaries signing, etc.), the community, the ease of use... I don't think there is such a thing yet.
Slack is currently eating 600MB of my RAM, for something I check maybe once an hour. You know what I'd like to use my RAM for instead ? Gradle. kotlinc. intellij. Things that I actually use to do my work, and not a bad IRC that wants to make me pay for the privilege of seeing old messages. Electron is a demonstration of laziness and a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time.
> a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time.
Exact opposite, to me Electron is the living proof that software companies correctly care a lot about building a product people want, and correctly realize that the large majority of people correctly do not care that one of their top productivity app uses $1 worth of RAM, but want the app to have the features and UX they need instead.
The irrational obsession of part of the Hacker News crowd for the RAM usage of web apps is borderline psychotic. Man, take a chill pill, go get more RAM for a couple bucks once every 3 years, and let the engineers focus on UX and features ok? I don't want my productivity app to be a codegolf exercise
Idk. I have electron programs running which take up much less residual memory. I do have slack running in my browser thou and the whole browser running slack and outlock360 and a bunch of other tabs uses 600MB of residual memory of which ... 324MB is used by slack ... so I would say it's more of an slack then a electron problem. AFIK the overhead of electron is around 100MB per-program this is still bad, sure, but far less worse then what you describe.
I feel so too. There are currently no valid alternatives I know to electron. It is sad, but this is the current state of UI frameworks, if you are targeting cross-platform with identical look and feel.
Also electron comes with its own advantages which many on HN seem to forget.
code-server for instance was very easy todo, because vscode was build using electron. It runs virtually anywhere. Uses fewer resources then most WMs on a headless device if you need a full blown IDE.
I remember reading about the performance-first development of Linen here on HN a few weeks ago. In that thread I also heard about Zulip for the first time.
Both look good. I am not sure which to proselytize to my groups. Most groups I'm in just use Discord because of its momentum, but I really don't like Discord that much - it feels chaotic (I've learned it does have threading and maybe even forum mode now, but nobody seems to use those...), and it's not open-source.
Indexability is an interesting feature, of obvious use for public or semi-public groups, but certainly not something I'm interested in for private groups. Can it be disabled?
I also really like that Linen has two-way sync. This would massively reduce friction in switching. However, the lack of mobile apps could be a bigger source of friction. How is Linen as a PWA?
I feel obligated to extoll enormous praise on Zulip.
I was the person who forced us to try it for a week (so, take a pinch of salt), and people were apprehensive, but I floated the idea of going back to slack recently and was met with open hostility due to how nice Zulip is to use.
It even exceeded my expectations, having only used it briefly with the rust community prior to the trial; basing the trial solely on others on hackernews extolling similar praise to me now.
The thread first model is really great for finding information, the search works decently and integrating with random things is much nicer than with Slack.
its not all sunlit uplands, the UX feels a bit weird sometimes (there is a strong keyboard shortcut system for power users but you can be in the wrong context to use the common hotkeys with no visual indicator) and the mobile app is mediocre at best.
Additionally; a few business people have referred to it as a “nerd tool” and do not put any effort at all into getting over the relatively minor learning curve, but I also believe that they wouldn't truly engage with slack either.
But holistically: its a fantastic system and is a much better use of inefficiencies of electron based messenger clients.
Jitsi is also extremely nice by the way and the pair of Jitsi and Zulip is extremely nice.
Mobile should be at the top of the roadmap, TBH. No mobile is a complete show-stopper.
I think it's commendable to build a chat alternative that is snappy. But right now, it's basically going to be a sync-ed mirror with Slack for everyone.
"It is actually kind of tricky to self host since there are quite a few services that needs set up and we could use quite a bit of work in our documentation." Uh... a second-degree showstopper for people looking for Slack alternatives. We have one-click deploys for rocket.chat and Zulip on digital ocean, vercel, render, etc.
Where do you believe your adoption will come from? I ask this sincerely. What is the burning pain that will lead people to adopt linen right now?
The whole "SEO" your community is such a red herring in my opinion. There are already many Discord, Slack, etc. bots that make public discussions readable and indexable. And LLM-integrated bots that automatically summarize discussions.
Why not prioritize what's really needed in this space:
a) Super easy self hosting. Make the devops/infra team happy.
b) Super snappy chat clients on desktop AND mobile. Make the users much happier than the alternatives.
c) API compatability with Slack, maybe also Zulip and rocket.chat. Make the devs happy and eat the lunch of your competitors by making it super easy to port apps to linen. (And, get SEO + autosummarization features for FREE)
> Tauri is an open-source electron alternative that is built in Rust.
I'm not familiar with Electron development, but isn't the code mostly JavaScript in that case? Does Rust have a meaningful contribution to the performance and the safety of the codebase here? I feel like Rust part would be "spin up the WebView". There is no code in the repository, so I couldn't check that out myself.
I'm building an app using tauri. More than 70% of the code is rust. The tauri codebase itself consists of a lot of Rust code, and it's based on two substantial rust libraries for cross platform window management and cross platform webview management
I'm not sure about this project specifically, but Tauri let's you farm all of your business logic out to the Rust side with straightforward function calls and keep the web view a presentation layer.
According to those benchmarks Tauri still issues about 25000 syscalls at startup and needs about 300mb of ram for a “hello world” app. That might be slimmer than electron, but it’s still ridiculous given what it’s doing.
In Electron you run a node 'server' and browser JS client (packaged up into one app). Tauri uses rust for the backend instead.
So yes, in Electron 'the code is mostly JavaScript', but Tauri's offering 'let's do a piece of that in rust instead'. (And I suppose you could do the frontend in rust via wasm, but probably true of Electron too.)
It's not just Tauri itself as a development tool that's written in rust.
My understanding is that Tauri allows building the presentation layer with standard web tech (HTML, CSS, JS) while using the system web view to render it. This has the major benefit over Electron that you don't have to ship all of Chrome in your binary. The downside is that now you have to support the peculiarities of the system web view (Safari, Chrome, Firefox, etc.)
There is another benefit+downside: Web view can get security updates without you updating your software. But, that means your app might break at some point even if you haven't released any updates.
I understand this is more tailored at communities and such (being the Business plan the last in the tier), but for Linen to be a Slack alternative we'd need App integrations (Google Calendar, Jira, etc) as well as other features such as to send scheduled messages, snooze/bookmark incoming messages for later, a strong channel administration/management, and a few other features that increase productivity and we can't live without.
As I said, businesses are probably not the main target customers for Linen so it's completely understandable, I would've loved it though. Great work!
Looks interesting, though I would definitely need Android/iOS clients before considering it.
We migrated our small, private slack group to discord when slack changed their retention policy, though it's become less active since then.
I think a lot of the members use slack already, but are not inclined to deal with discord. Maybe a different app would be better, or maybe it's "slack or nothing" for some of those folks.
What I really want is slack to just have a reasonable pricing plan for small, low activity groups, like Linen has. So props for that!
I just noticed you advertise a real-time sync with slack/discord, so that just may handle my use-case. Is there a mailing list I could join to be notified when there's mobile clients?
Unrelated question. Anyone know if it would be difficult to write a SwiftUI “compiler” to non-Mac architectures, including wasm? (I’m not a ui developer). I mean, I realize it is probably non-trivial, like most cross-platform ui, but I have been imagining that Apple would do this since they released it, so that their webapps could be written in SwiftUI instead of whatever they are doing now…
Hard, but doable. I don’t see Apple doing it anytime soon because it doesn’t really gain them anything but here’s a third party demo: https://github.com/swiftwebui/SwiftWebUI
One of the rumors for Apple's increased visible attempts to, among other things, rewrite Foundation libraries themselves in Swift is to better unify their own internal cross-platform efforts (because they get to maintain Apple TV and Music apps on nearly every platform, if no other reason).
I don't know how much Apple is incentivized to make any steps they take towards SwiftUI cross-platform support available to third party developers, but it is an interesting rumor to watch.
Yes, it would be difficult. Certainly not impossible, but difficult.
Microsoft has their MAUI project (Multi-platform App UI). It lets you write programs in C# and compile for Windows, macOS, Android, and iOS. AvaloniaUI and Uno Platform are other C# options. Flutter exists for Dart. Compose Multiplatform exists for Kotlin. React Native exists.
All that said, they all have drawbacks/issues. Flutter means ignoring the platform and just drawing things using Skia so Flutter apps feel like Flutter apps, not platform specific apps. Compose Multiplatform is only an alpha for iOS and it's also just drawing on a canvas (though you can break out of that and program specific stuff in iOS's UIKit). Avalonia is Skia and from what I've heard the iOS/Android support is poor compared to desktop OSs. Uno is mostly Skia with some platform-specific widgets, but their desktop support is poor compared to their mobile and WASM support.
MAUI is the only one that's really targeting native widgets on macOS, Windows, iOS, and Android. It seems like it's been a bit of a hard journey for Microsoft there, but it seems to be getting pretty decent in the latest betas (especially if you're using things like the CommunityToolkit MVVM and Markup extensions).
So, it's hard. It's taken many great companies many years to create ok cross platform toolkits. None are really amazing.
I think another thing holding stuff back is WASM. WASM will be getting a lot better, but it's not amazing for UI stuff right now because it means overhead communicating between WASM and JS (and a lot of copying). WASM also isn't great for garbage collected languages at the moment since the language has to ship its garbage collector. This will be changing in the future as WASM gets GC support. Swift's reference counts don't require the same overhead so it might not have that pitfall, but WASM is still usually for things that require lots of calculation compared to the UI work at the moment.
I don't know how much code reuse there would be between SwiftUI and the web if they did create such a compiler. Maybe there's value in using SwiftUI instead of React or whatever on the web. I don't really know.
I think Apple is unlikely to be the company that really pursues a cross-platform toolkit. They want people in their ecosystem and they know that a lot of developers target iOS first.
I guess it really depends on the value Apple would get out of it. Companies have spent a lot of time trying to make cross-platform UI kits over decades and there have been a lot of failures (or successes that don't really seem like successes given a lack of popular adoption). PhoneGap was an early iOS/Android one. RubyMotion has been around since 2012. Java was probably the original "write once, run anywhere with a GUI" language. Tcl/Tk has been around for ages. Qt has been around for a long time. It seems like an area where companies pour money and don't get amazing results. I'm not arguing that the results aren't worth it sometimes to have a single codebase. However, I haven't seen one of these toolkits take over the world despite the clear benefits of writing code once. That doesn't mean that the perfect thing can't be done, but it does make it seem like the difficulty is up there to make something really great.
For Apple, it's probably just not worth it. Most of their web stuff is different enough to what they'd be running on devices that they might not get a ton of value out of it for the difficulty involved. Plus, Apple isn't really looking to support Android, Windows, or Linux.
Readit News
They use WebKit GTK which is really not a good fondation IMO, its hard to test for all versions, its much slower than other browser, it has weird bugs.
In general the idea of not shipping a browser bundle is nice, in practice it doesn't really work for a startup. It's just too much unrelated testing and debugging work you need to do to support old outdated systems.
We were very excited to use tauri since we are a rust shop, but we are strongly considering moving to electron unless we get a way to bundle a renderer.
It's much less acceptable if you are Slack and still ship a slow bloated Electron app 10 years in.
This is not specific to Electron, it's a similar effect with every core technology, all the way to COBOL.
From time to time, I go to https://www.areweguiyet.com/ to check out how rust GUI is doing.
I've heard good things about Iced framework (the one that System76 is building their DE on).
By all means use it on desktop platforms, but it won’t get you an acceptable web version.
I could really feel the lag and the lack of snappiness when interacting with that UI.
Its webkit, safari also uses webkit? Why is it so slow?
Most of the Electron junk can be easily done as pure Web application, of course authors don't want to pay for hosting and ship a browser and server with the application.
There are a very tiny percentage of such startup ideas that really need features not available on a standard Web browser.
(I don’t know about Linux).
On Windows, and to a lesser degree on the Mac, this approach actually went pretty smoothly. But WebKit GTK introduces all sorts of problems -- having to tie into GTK's event loop even though you don't want it, dealing with distribution variances, event binding issues, etc.
I suspect the answer here for Tauri is that someone needs to expend the effort to come up with a good Rust crate bundling of Chromium or Gecko or etc that isn't tied into GTK. Yes, it would defeat the "just use the platform's webview instead of bundling" line, but really it would only be a concern for Linux.
ElectronJS is a cross-platform framework. It is bloated because it ships a full cross-platform browser (Chromium) in order... well in order to be cross-platform.
Tauri wants to be less bloated, and therefore removes Chromium. Which makes it... not so cross-platform, apparently.
Genuine question: why not going for a JVM-based technology? That's cross-platform, and it doesn't require a web browser / webview to show text.
Not to pick on the JVM, but does anyone actually build new desktop software for the JVM that's meant to be downloaded and installed by mainstream consumers? Qt and other frameworks work pretty well (with their own flaws) but I'd simply never even consider the JVM as a viable option for desktop software. The last JVM app I installed was probably Minecraft in 2012.
I will say that my dev cycle builds (full clean and rebuild) take about 20s, which is nice. That nets me a “runnable fat jar”. Running the packager for the platform installers takes longer on top of that, but that’s not part of my dev cycle.
I dev on macOS, I have “tested” on Ubuntu and Windows, and the app works. My buttons button, cut and paste works, drag and drop (I can drag one of my generated images and drop it into, say, Word) works, I can generate PDFs via the “print to PDF” features of the platforms, including my custom fonts. I also have, like, 10 lines of code that uses JavaFX 3D — and that works.
It all works, and so far, knock on wood, the “cross platform” parts are doing what they’re supposed to do.
All that said, germane to the overall topic, there’s this funny little tidbit. In my app, all my bundled documentation is simply in HTML using bundled pages. And I show that in a JavaFX WebView. And WebView is built on WebKit. So in the end, if you need any HTML in your app, you bundle WebKit anyway.
Of course, if you don’t, WebView is in its own module that you don’t have to ship if you don’t need it.
I use Eclipse-based tools at work (again, I can see the debate). It seems like Samsung's Smarthings (IoT platform) used to use Groovy, but has recently migrated away.
I also know you said desktop, but a weak argument could be made in favor of the (also weak) JVM connections of Android. I'd put forth that some Android usecases are basically former desktop usecases.
Then there’s also Kotlin Multiplatform and Jetpack Compose, and now Compose Multiplatform (desktop, mobile, web including JS and WASM). Their DSL is really amazing, truly compositional and resembling the way you do React. To me that’s the path cross-platform GUI will be taking now.
On the .NET side, there’s Avalonia UI and Uno Platform as cross-platform alternatives, with Avalonia UI v11 (pending release) even doing mobile on almost the same code base.
Does anyone actually build new desktop software for mainstream consumers these days?
JVM UI is "good enough", I've seen it used for businessey tools where the point is the functionality rather than the polish (including hobby tools). Honestly it may well be the best non-electron option once you think about the whole stack; with Qt you have to either write C++ and deal with that, or use the Python bindings and deal with that.
I probably would consider it now for a new project, but not 5-10 years ago, when dev cycles for now-popular apps would've started realistically.
If you want to make a small to mid-scale GUI, I'd argue that you'll be better off with a java toolkit than anything web based (tooling is awesome, there are RAD tools to prototype and iterate quickly, ...). The alternative I see in this space is PyQt/Qt for Python, but it's easy to shoot yourself in the foot with it and everyone knows how terrible packaging and shipping python is.
Nowadays it can be hard to tell if something uses Java, since it's recommended to just bundle a JRE with your app so a user doesn't have to know/care about Java.
Also the JetBrains IDEs are really good IMO.
Even a resizable background image is really hard to do with pure native widgets.
This means cross-platform libraries that wrap native widgets are dead as well. Now you need to ship your own rendering engine, and suddenly an entire browser looks reasonable. E.g. JavaFX isn't a featherweight either...
Asking for a friend, of course.
"Java is write once, test and debug everywhere."
Also the ui toolkits for JVM ecosystems are just not as nice to develop with. But I was pretty hardcore C#/.net back in those days so take what I say there with a grain of salt.
[1] https://softwareengineering.stackexchange.com/a/20024
It's certainly cross-platform. Name a current OS that doesn't have one WebKit-forked webview or another available at all times. If you don't like Apple's insistence on only baseline WebKit out of the box, there's Microsoft's WebView2 which ships a known Chromium to every major desktop OS.
But really, if you are a web developer complaining about the differences between WebKit and Chromium, you may be spoiled. If you are a web developer complaining that you can't package a specific Chromium version (which is the real Electron benefit, not just that it packages its own Chromium but that every Electron app can pick and choose down to the exact Chromium version they want to ship), you've gone beyond spoiled to basically distrusting how the web platform is supposed to work.
(That's before you get to the other monoculture assumptions that no modern OS is instead shipping something like Firefox as the system default webview in 2023. It's all one tiny family tree with WebKit as the trunk.)
If your app is primarily a website and you want to wrap it as an app then I guess Tauri makes some sense. E.g. something like Slack or Gmail.
If you're just using it as a way to make a desktop app then it makes more sense to use Electron unless your UI is very simple and download size is very important (e.g. something like the Raspberry Pi Imager app; though that uses QtQuick).
Because then you require the user to install a JVM?
Deleted Comment
I mean VS Code, Discord, Slack and Obsidian are all in very widespread use and work perfectly fine for me.
Are there alternatives to Electron that require less resources? Tauri seems to be proof that there are.
But I think there is real value in large communities and backing. Electron seems to work perfectly fine to me for everyday use as is evident by the applications mentioned above. I would personally choose Electron over Tauri even for greenfield projects, simply because Electron seems to power applications that are in much more widespread use.
Having a latency on local clicks and transitions is not my idea of fun.
VSCode is an outlier here. And it's getting slower and slower with age, while sublime text is getting faster.
To be clear, your opinion is absolutely valid I just don't think they apply equally to everyone.
And VSCode has to be contrasted with Atom, which is the same but in so much worse: It takes a lot of effort to make Electron work well.
That being said, if a "drop-in" alternative would be available I would probably try to switch at one point. But the alternative would have to be on par with the ecosystem (including packaging, binaries signing, etc.), the community, the ease of use... I don't think there is such a thing yet.
The app, if you are interested: https://mockoon.com
Exact opposite, to me Electron is the living proof that software companies correctly care a lot about building a product people want, and correctly realize that the large majority of people correctly do not care that one of their top productivity app uses $1 worth of RAM, but want the app to have the features and UX they need instead.
The irrational obsession of part of the Hacker News crowd for the RAM usage of web apps is borderline psychotic. Man, take a chill pill, go get more RAM for a couple bucks once every 3 years, and let the engineers focus on UX and features ok? I don't want my productivity app to be a codegolf exercise
You forgot about the times when two or more of the electron applications you run because you have no other option decide to take 20% CPU each or more.
Even if you make it a point of pride to run a computer that eats power measurable in kilowatts per hour, that's bad when on battery at least.
And from the article:
> One of the main core differences with Tauri is that it uses a Webview instead of using chromium like in Electron.
What's the difference? It will still end up eating all that ram and needlessly refreshing the cat gifs someone posted a day and a half ago.
Also electron comes with its own advantages which many on HN seem to forget.
code-server for instance was very easy todo, because vscode was build using electron. It runs virtually anywhere. Uses fewer resources then most WMs on a headless device if you need a full blown IDE.
Both look good. I am not sure which to proselytize to my groups. Most groups I'm in just use Discord because of its momentum, but I really don't like Discord that much - it feels chaotic (I've learned it does have threading and maybe even forum mode now, but nobody seems to use those...), and it's not open-source.
Indexability is an interesting feature, of obvious use for public or semi-public groups, but certainly not something I'm interested in for private groups. Can it be disabled?
I also really like that Linen has two-way sync. This would massively reduce friction in switching. However, the lack of mobile apps could be a bigger source of friction. How is Linen as a PWA?
I was the person who forced us to try it for a week (so, take a pinch of salt), and people were apprehensive, but I floated the idea of going back to slack recently and was met with open hostility due to how nice Zulip is to use.
It even exceeded my expectations, having only used it briefly with the rust community prior to the trial; basing the trial solely on others on hackernews extolling similar praise to me now.
The thread first model is really great for finding information, the search works decently and integrating with random things is much nicer than with Slack.
its not all sunlit uplands, the UX feels a bit weird sometimes (there is a strong keyboard shortcut system for power users but you can be in the wrong context to use the common hotkeys with no visual indicator) and the mobile app is mediocre at best.
Additionally; a few business people have referred to it as a “nerd tool” and do not put any effort at all into getting over the relatively minor learning curve, but I also believe that they wouldn't truly engage with slack either.
But holistically: its a fantastic system and is a much better use of inefficiencies of electron based messenger clients.
Jitsi is also extremely nice by the way and the pair of Jitsi and Zulip is extremely nice.
I'm a big fan of Jitsi. Haven't used it in any business settings, but do 5 person calls every so often for my TTRPG group and it works great.
I think it's commendable to build a chat alternative that is snappy. But right now, it's basically going to be a sync-ed mirror with Slack for everyone.
"It is actually kind of tricky to self host since there are quite a few services that needs set up and we could use quite a bit of work in our documentation." Uh... a second-degree showstopper for people looking for Slack alternatives. We have one-click deploys for rocket.chat and Zulip on digital ocean, vercel, render, etc.
Where do you believe your adoption will come from? I ask this sincerely. What is the burning pain that will lead people to adopt linen right now?
The whole "SEO" your community is such a red herring in my opinion. There are already many Discord, Slack, etc. bots that make public discussions readable and indexable. And LLM-integrated bots that automatically summarize discussions.
Why not prioritize what's really needed in this space: a) Super easy self hosting. Make the devops/infra team happy. b) Super snappy chat clients on desktop AND mobile. Make the users much happier than the alternatives. c) API compatability with Slack, maybe also Zulip and rocket.chat. Make the devs happy and eat the lunch of your competitors by making it super easy to port apps to linen. (And, get SEO + autosummarization features for FREE)
I'm not familiar with Electron development, but isn't the code mostly JavaScript in that case? Does Rust have a meaningful contribution to the performance and the safety of the codebase here? I feel like Rust part would be "spin up the WebView". There is no code in the repository, so I couldn't check that out myself.
It apparently has a tremendous benefits: https://tauri.app/v1/references/benchmarks/
So yes, in Electron 'the code is mostly JavaScript', but Tauri's offering 'let's do a piece of that in rust instead'. (And I suppose you could do the frontend in rust via wasm, but probably true of Electron too.)
It's not just Tauri itself as a development tool that's written in rust.
As I said, businesses are probably not the main target customers for Linen so it's completely understandable, I would've loved it though. Great work!
We migrated our small, private slack group to discord when slack changed their retention policy, though it's become less active since then.
I think a lot of the members use slack already, but are not inclined to deal with discord. Maybe a different app would be better, or maybe it's "slack or nothing" for some of those folks.
What I really want is slack to just have a reasonable pricing plan for small, low activity groups, like Linen has. So props for that!
I don't know how much Apple is incentivized to make any steps they take towards SwiftUI cross-platform support available to third party developers, but it is an interesting rumor to watch.
Microsoft has their MAUI project (Multi-platform App UI). It lets you write programs in C# and compile for Windows, macOS, Android, and iOS. AvaloniaUI and Uno Platform are other C# options. Flutter exists for Dart. Compose Multiplatform exists for Kotlin. React Native exists.
All that said, they all have drawbacks/issues. Flutter means ignoring the platform and just drawing things using Skia so Flutter apps feel like Flutter apps, not platform specific apps. Compose Multiplatform is only an alpha for iOS and it's also just drawing on a canvas (though you can break out of that and program specific stuff in iOS's UIKit). Avalonia is Skia and from what I've heard the iOS/Android support is poor compared to desktop OSs. Uno is mostly Skia with some platform-specific widgets, but their desktop support is poor compared to their mobile and WASM support.
MAUI is the only one that's really targeting native widgets on macOS, Windows, iOS, and Android. It seems like it's been a bit of a hard journey for Microsoft there, but it seems to be getting pretty decent in the latest betas (especially if you're using things like the CommunityToolkit MVVM and Markup extensions).
So, it's hard. It's taken many great companies many years to create ok cross platform toolkits. None are really amazing.
I think another thing holding stuff back is WASM. WASM will be getting a lot better, but it's not amazing for UI stuff right now because it means overhead communicating between WASM and JS (and a lot of copying). WASM also isn't great for garbage collected languages at the moment since the language has to ship its garbage collector. This will be changing in the future as WASM gets GC support. Swift's reference counts don't require the same overhead so it might not have that pitfall, but WASM is still usually for things that require lots of calculation compared to the UI work at the moment.
I don't know how much code reuse there would be between SwiftUI and the web if they did create such a compiler. Maybe there's value in using SwiftUI instead of React or whatever on the web. I don't really know.
I think Apple is unlikely to be the company that really pursues a cross-platform toolkit. They want people in their ecosystem and they know that a lot of developers target iOS first.
I guess it really depends on the value Apple would get out of it. Companies have spent a lot of time trying to make cross-platform UI kits over decades and there have been a lot of failures (or successes that don't really seem like successes given a lack of popular adoption). PhoneGap was an early iOS/Android one. RubyMotion has been around since 2012. Java was probably the original "write once, run anywhere with a GUI" language. Tcl/Tk has been around for ages. Qt has been around for a long time. It seems like an area where companies pour money and don't get amazing results. I'm not arguing that the results aren't worth it sometimes to have a single codebase. However, I haven't seen one of these toolkits take over the world despite the clear benefits of writing code once. That doesn't mean that the perfect thing can't be done, but it does make it seem like the difficulty is up there to make something really great.
For Apple, it's probably just not worth it. Most of their web stuff is different enough to what they'd be running on devices that they might not get a ton of value out of it for the difficulty involved. Plus, Apple isn't really looking to support Android, Windows, or Linux.