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.
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?
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.
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.
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.
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.
I've always thought slack was the alternative, to IRC.
The transitive property implies that if a=b and b=c, then a=c. "Alternatives" are also (mostly) transitive. A counterexample would be that Slack is an alternative to IRC, and IRC is an alternative to Slack, but Slack is not an alternative to Slack!
Modern software piles up new stuff on top of new stuff. There is no time for the basics. /s
It seems to be the perfect platform for a communications service (and is also what Discord is built on).
And before that, WhatsApps was strictly Erlang.
I tried getting E2EE working. There are 3 standards. Some clients implement one or two of them. Some clients none. It's a nightmare to get them to talk together.
Then you have all the other 400 XEPs that may or may not be implemented by clients. Things like file transfer, typing indicator, video chat, avatars, group chats.
The only way XMPP becomes relevant again is if they choose a subset of REQUIRED features and clients must implement them all to be considered XMPP2-compatible.
Other issue with XMPP is how hard it is to find clients that don't suck (particularly if you want to interop; I think I've seen at least 3 different ways clients implemented emojis, for example).
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)
Slack's app broke the basic functionality of the main input box where the home and end keys jump to the start and end of the entire input rather than the current line. This turns simple text edits into a chore. I pointed this out to their support staff who responded that the issue wasn't important enough for them to fix. Very disappointing
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 understand wanting to produce an alternative, but I can't help but wonder why not produce an alternative that is substantially different?[1]
From the screenshots Linen is almost a clone of Slack, with (I think) the biggest difference being "google-indexable". There's literally, on the landing page, no compelling reason for using this product over Slack.
Looking at the landing page for Linen[2], I don't see anything about why one would choose Linen over Slack other than "google-indexable" and "advanced thread management"[3].
I think the biggest differentiator is pricing, but that is not an issue for companies using Slack, and unprofitable targeting anyone who finds Slack too expensive.
[1] The easy "substantially different" thing to do would be to rearrange the layout. The hard "substantially different" thing to do would be to actually have a performant chat program that starts in <10ms and consumes under 100MB in normal and active daily use.
[3] Managing conversation threads in IM is not a problem I've heard anyone complain about, TBH.
$10/month for up to 100 users compared to Slack's $7.25/user/month.
What it really comes down to is integrations. For a team to consider Linen, they'd have to get their Jira tickets in there, bitbucket/github hooks etc. as well as external integration with Okta/azure SSO etc. That will make or break Linen, more so than being indexable. Because if you want indexed content, you're likely working on an open source project or are open which means without revenues, and so you won't be willing to pay much.
I'm glad an alternative to Slack, cheaper, with open search is available.
> For a team to consider Linen, they'd have to get their Jira tickets in there, bitbucket/github hooks etc. as well as external integration with Okta/azure SSO etc.
Yeah, but those things cost money, usually per user, and with good reason.
Just comprehensive SSO alone is something that costs around $5/user/month. Sure, the Linen team could write it themselves, but it won't work anywhere nearly as nicely or as performant as signing up for an SSO service that works with everything a corporate uses for sign-ins.
So, yeah, it can be $1/user/month now, but it's unlikely to remain that way when they need to add in all the Slack functionality. It's also unlikely to remain performant when it matches Slack feature-for-feature.
> Windows - 4.13 MB
> Linux - 73.8 MB
One is not like the others.
> CAUTION
> If your app plays audio/video ... This will increase the size of the AppImage bundle to include additional gstreamer files needed for media playback.
The biggest difference I see is that Discord is "free" for communities, or at least the model is different: an individual user can apparently pay to contribute to the server and "unlock" features. Also I think Discord just comes with history for free, which is a killer feature in many communities.
Slack is more "meant for companies" in the sense that the "owner" of the server (i.e. the company) has to pay each month for each user. Many open source communities can't afford that, which is why they like the Discord model better.
Disclaimer: I hate both, because they don't have an open API and the Desktop apps use ElectronJS. So I'm not sure if I'm biased towards one or the other :D
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!
At the moment I hop into many of the chats and they aren't too active. Which is fine but makes discovery a bit boring.
Why not have the feed of the latest messages from your top 50 trusted Linen workspaces (should I call them sheets? duvets? covers? :-)). Then I can see active discussions that are happening and join in.
Also use Linen for your own day to day team activities. Assuming there is a private channel concept for stuff that is secret that'll create more activity and make it interesting to follow.
This coming from someone that has mostly done Web stuff in the last 20 years.
