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?
Note that according to the FAQ, Discord syncs hourly. Real-time is a WIP. So the sync would not be great at facilitating live cross-platform discussion yet.
Hey, seems there are a few typos/grammatical errors in the faq, might be due to the recent changes, just thought you should take another look. I’m on my phone otherwise I’d take screenshots and share.
The parent said "meant for communities" and not "used for communities".
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
I don't think it's the same. Maybe "is meant for" is not the right wording, but the point is really that the model of Discord just works better for communities, because the server admin does not have to pay for the users (rather the users can contribute to the server).
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?
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)
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.
Commutative means that changing the order of the operands yields the same result. Ex: a+b = b+a. In that way, "alternative" is (mostly) commutative, but there are exceptions: Amazon is an alternative to a local bookstore, but a local bookstore is not necessary an alternative to Amazon.
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!
> 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.
> That might be slimmer than electron, but it’s still ridiculous given what it’s doing.
Then I think your beef is with the class of apps, not Tauri or Rust.
> Tauri still issues about 25000 syscalls at startup and needs about 300mb of ram for a “hello world” app
How many syscalls and how much memory does your web browser require on startup?
I'm not the biggest fan of JS apps, Electron, etc., but it's simply ridiculous to think this class of apps don't provide value.
It's become chic to yell about the good old days when it didn't take your editor a few seconds to startup, and I agree, but I think this lament actually requires an answer 1) in the form of code, 2) in a language everyone can learn 3) that runs on everything.
> it's simply ridiculous to think this class of apps don't provide value.
They absolutely provide value. I’m not questioning that. I’m just sad and frustrated by the lack of any better options for application developers.
We desperately need a good, lightweight, feature rich, cross platform application framework. Making something good will probably need an 8-figure budget at a minimum. Unfortunately nobody with that kind of money seems invested enough to make it happen. As a result, every computer on the planet is either slower or more expensive than it needs to be in order to run Teams / Slack / Discord / etc etc.
It feels like a coordination problem more than a technical problem, with users suffering the most.
> We desperately need a good, lightweight, feature rich, cross platform application framework.
Or those services should just expose a damn API and allow third party apps. I don't see what would be wrong technically with a lightweight Slack CLI app, a native macOS app, etc. Damn it's just about showing text on a screen... writing a third-party Slack client could even be a nice student project.
It just means that Slack needs to expose a proper API (unfortunately "proper" is not the norm in our industry), and probably there is a business reason to not allow it that I don't see right now (maybe just cargo cult or wrong assumptions, those are typical reasons behind business decisions).
> Then I think your beef is with the class of apps, not Tauri or Rust.
Are you saying that "WebGUI" is the primary category you'd place this app in?
For end-users, the category is "chat apps". I grant the point, though, that these days there may not be any difference between the two.
> It's become chic to yell about the good old days when it didn't take your editor a few seconds to startup, and I agree, but I think this lament actually requires an answer 1) in the form of code, 2) in a language everyone can learn 3) that runs on everything.
While I ordinarily agree with this sentiment, the big pitch about this particular product is performance.
From the landing page, this is literally the first bullet point listed:
> Linen is 1000x more lightweight than alternatives. This means that we load faster, use less bandwidth and are more responsive
In this respect, I think that using 500MB on the 3MB transfer benchmark
contradicts the 1000x more lightweight claim. I've never seen Slack or similar need even 10x as much RAM as the benchmark results.
Last I used Slack, it was using around 1GB of RAM in daily and active use.
At any rate, these are the things that get funded by VCs? It seems to me that the world is not crying out for a slightly more lightweight Slack alternative.
Some demand? Sure, for free tiers and low-cost tiers ... but how do they expect to monetise those free and low-cost users? The free tiers are usually subsidised by the enterprise tiers.
This response is kinda all over the map. My point was simply -- if you don't get it, or want to moan about it, then I think you need to at least discuss the alternatives. If you can't, then it might be an indication that these apps are solving a problem in a domain you perhaps don't fully understand.
Now -- does this particular app solve this particular problem better than Slack? That's a fair Q, but, again, far afield from my point.
I have a real problem with this abstract beefing with other peoples' products and tech choices, that takes place in land that without alternatives. Show me the code for cross platform GUI development that doesn't look something like this. Explain how it's better than this, and how we should all be using it, instead of this. Until then, these criticism ring hollow to me.
> Show me the code for cross platform GUI development that doesn't look something like this.
Well, there's Qt that's relatively popular. Also WxWidgets. Java applications have had much success for x-platform GUIs (Jetbrains products come to mind) but is hardly considered lightweight (although much lighter than Electron-types).
Personally, I lean towards Lazarus.
All of the above (and I'm missing quite a few here) are insanely lightweight and performant compared to Electron-type implementations.
> Explain how it's better than this, and how we should all be using it, instead of this.
I did not claim that "all of us" should be using the alternatives. I said that, while in general I agree with using the quickets x-platform dev stack, for this particular application which claims "performance" as it's main goal AND further goes on to claim actual performance as a delivered result, I disagree that it is in any way as performant as it could be.
I mean, a quick win here would have been to use one of those alternatives I listed, maybe Qt. C++ GUI (using Qt) with Rust application logic would have probably been faster to develop than Html/Js + Rust, and the result would run just as fast (if not faster) and use less memory.
I'm inclined to use some of my precious free time to write a bare-bones x-platform GUI chat application, inventing my own protocol (like Linen did) just so that I have something to point at when invariably the claims of "performant" in electron-type apps is made.
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.
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.
> 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.
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?
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.
JLink (JEP 282) does the first part and was released with Java9 (6 years ago), the native compilation stuff is a product of GraalVM. Binaries are reasonably small but it depends of course on what your app is doing. There is a whole ecosystem of web frameworks that's being built on that (quarkus.io, micronaut) and IIRC you can build a simple REST API that ships as a <20MB container.
JavaFX supports a WebKit based WebView widget, but it's optional. If you don't use it it's not bundled. If you do then you pay the cost of including the WebKit build which is ~80mb.
In practice the need for WebKit is going down over time. For basic rich text you can render Markdown to JavaFX nodes directly, for more advanced stuff you could transform [X]HTML to FXML, you don't need it for video or audio, there's a native rich text / word processor control these days, and if you can do 3D graphics with a high level scene graph (meshes, lights etc) then you don't need HTML for 3D either.
Still, it's often useful and bandwidth/disk space isn't the problem it once was.
Are you the Mike Hearn from the bitcoin and "history is a scam" fame? Cool to see you here :) I somehow am (positively!) surprised to see your name in relation to Java GUI frameworks. Hydraulic Conveyor looks interesting, is it planned to support GraalVM's native-image? Would it work with Scala/ScalaFX?
We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way. There's also someone in our Discord who has been trying it with Compose apps.
If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:
For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff. OTOH if you don't care about that, it'd be (imo) easier and more direct to not use HTML. Proper GUI toolkits give you a lot of stuff out of the box like virtualized list views which HTML still doesn't; useful for scrolling over huge datasets like chat logs.
I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.
Thanks for the reply, I'll definitely keep an eye on all that.
> For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff.
I'm not even sure it matters so much, for instance there is this XMPP client that uses (lib)WebRTC for audio/video calls and has all of its UI build with Gtk (no web): https://dino.im/
> Proper GUI toolkits give you a lot of stuff out of the box […] Also I learned GUI programming decades ago and find classical UI toolkit more intuitive than HTML.
yep, looks like we are on the same boat of angry old men yelling at clouds :)
OpenJDK doesn't do the AOT compilation part, you have to use GraalVM native-image for that and it's somewhat experimental for desktop apps. But otherwise it's pretty easy to bundle stuff up.
2. Run `conveyor generate {javafx,compose} my-test-project` (pick your preferred UI toolkit). You now have a JVM desktop project.
3. `./gradlew jar; conveyor make site`. You now have a directory with self-updating platform native packages for Windows, macOS (ARM/Intel) and Linux that you can upload to a web server of your choice. Or supply upload creds and it'll do that step for you. Provide certificates and it'll also take care of signing.
That's all it takes to get a self-updating JVM desktop app these days. The same tool can do Electron, Flutter and native apps too (i.e. C++/Rust), so you could also use it with Tauri, but the nice thing about the JVM support is that it'll both strip down and bundle the JVM for you whilst cross-building/packaging so you don't need CI to do releases. From the user's perspective it's a normal app, from the developer's perspective you just hack on your local dev laptop like you could for a web app.
Binary sizes depend on how much functionality you use and how much effort you put into minifying. With the default level of effort (i.e. none) a simple hello world JavaFX desktop app will be about 33mb and a simple compose app will be about 52mb for macOS (skia is a very large graphics library). However, the Mac versions are larger than those for other platforms, and these sizes are still quite wasteful. There's a lot of low hanging fruit. You could make it a fair bit smaller by using ProGuard and other more aggressive dead code elimination techniques, as well as more heavily compressing bytecode. There's also plenty of fat to trim on the native code side.
GraalVM native images are interesting because they have much faster startup time and low memory usage - competitive with C++ apps, even. They take more work to create though. You can see a robotics app that's natively compiled here:
At some point you need to ship the runtime, right? Even native (Go, Rust, C++, …), depending on how you do the linking. What would make it more acceptable in this case is that you would strip down the JVM and only ship the modules depended upon (whereas Chromium is a monolith) when using jlink, and on top of that, native-image does some PGO, inlining and dead-code elimination AFAICT.
TIL, I haven't been using Java-based software for a long time (and I still have vivid memories of having to install the correct version of the JDK before installing one).
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.
While Fleet is still a JVM app at it's core, it's true that it apparently no longer uses Swing for the UI components. Instead they seem to have reinvented that wheel with their own UI component library called Noria (also JVM) and render it to the screen with Skia (a native 2D graphics library - non JVM).
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.
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.
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.
Its never fun finding the correct java version to get ghidra going on a new machine. I don't use java often enough to remember versioning differences between the official and openjdk. I never install the right one on the first try, always requires a trip to the ghidra docs.
I must have gone through this 7 or 8 times in the last 5 years.
Its also really rare for a desktop app written in java to look good. I'm sure its possible, but man looking at ghidra is a real pain.
> Its also really rare for a desktop app written in java to look good.
Java/JVM as platform suffers from trying to be all encompassing "second OS". Want to do time, fonts, cacerts? JVM does its own thing. Want to do UIs? Hey, there are widgets from 90s, should be good.
Don't JetBrains just ship with their JRE and always ignore any "system" JRE? That feels like the correct solution, at least once your app gets to a certain size so the size of the JRE can be ignored. Also JetBrains' apps look good enough I'd say.
Another pretty one with a java frontend is BitWig. That's perhaps more impressive than any JetBrains app.
IntelliJ can have its own dependency hell, don't worry. Not so often but it happens.
Last time I upgraded an old install i wasn't using, it pulled its own JRE, then pulled a new gradle which promptly complained about the JRE Android Studio installed itself.
Had to do some googling and force it to use a JRE that both the IDE and gradle liked.
But as I said, that doesn't happen often. It's just funny when it does, in a masochistic sort of way.
> 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.
I've got Notion, Spotify, the app for my insta360, Slack, linear, Final Cut, and VS Code open right now. As best as I can tell, half are Electron and zero are JVM.
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.
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.
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.
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.
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.
No, I mean the latter: picking "not embedding a whole web browser" is worth it for the user-friendliness, even though it means having to deal with those browser differences, which have grown a lot less onerous than they used to be.
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.
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.
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...
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.)
The code is here: https://github.com/linen-dev/linen.dev 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.
Tell me you're going to support video/audio calls in Firefox, and that you're not going to randomly shuffle the list of contacts in the “Direct message” section, and you'll have a better UX than Slack already.
Anything that's not XMPP or based on it is inferior, IMO. And I'm not saying that for the troll (although it's easy to be dogmatic about such things). Facts are XMPP has awesome server implementations that scale to billions of users (as proven by WhatsApp/ejabberd), and developing new clients is made easy by the sheer number of libraries and platforms supported. XMPP is an established IETF standard that has a compact core and extensibility in mind (so you can remain compatible across a large spectrum of users and use cases while rolling out new and unique features). Because it's federated, it's resilient against most types of monopolistic abuses (as seen with slack and other venture capital endeavors). I would only consider P2P and other federated protocols to be worthy of my (peers) time, but I also haven't seen anything else out there that would make me want to leave the comfort of XMPP and my self hosted instance.
It's been a while, but I seem to recall group chats being a bit unwieldy in XMPP.
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).
Group chats work pretty well in my experience. The spec for MUC is rather large even though only a small portion of it is used in practice (the roles/ACL capabilities go way beyond that of other protocols, probably inheriting the requirements of large-scale government/corporate deployments). There were also some challenges early-on relating to mobile use-cases (e.g. how to notify/respond to a user who's not joined to the group chat because their client is offline), and XMPP has grown a set of extensions in that area (push notifications, stream resumption, …).
> Other issue with XMPP is how hard it is to find clients that don't suck
OK, but the alternative we are talking about here consists of developing the server, protocol and clients all at once and from scratch, and end-up with something that's merely a prototype heading into a decade worth of enhancement and scalability improvements, iteratively bumping into the exact same kind of problems. Wouldn't it be less effort to just make an XMPP client that doesn't suck and lead by example? (That's pretty much what the "Conversations" Android client did when it came out, and now it's used by the German government, among others).
> I think I've seen at least 3 different ways clients implemented emojis, for example
I'm not aware of anything like that. There are different ways to do certain things, like sending attachments (HTTP upload or client-to-client), but that's the good thing about XMPP: your client/server negotiate capabilities and sometimes even translate among them.
I won't pretend that everything is rosy, for sure, but it also isn't that bad.
Whatsapp succeeded with XMPP because they defined a superset and their only client implements 100% of it. This isn't applicable to XMPP at large at all.
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.
That's great. Probably too late to make an impact (And I say this as someone who uses XMPP regularly), but I would have killed for something like that 10 years ago. Weeding through clients was such a pain. 90% of the clients were either half-baked or well-baked, but super out-of-date, and without having certain XEP numbers memorized, finding the remaining 10% was super frustrating.
I don't think it makes sense to expect XMPP to "make an impact" ever, if by that you mean "to spontaneously become the next dominant network" (or it already is, under the guise of WhatsApp, bar the federated aspect). The forces in presence are too uneven and the modern internet is too consolidated to permit that to happen (even google cannot dislodge WhatsApp/Messenger).
IMO, what does matter for XMPP's future is that it remains appealing to a growing niche of users who want to be in control, for whom self/local-hosting is important (XMPP excels at that), who care about privacy (OMEMO is state of the art, and XMPP offers gentler alternatives where PFS isn't desired), and who understand the benefits of federation for resilience. This niche will grow naturally as more and more people get deceived by every monopolistic network being doomed to grow beyond a threshold of sustainability and implode as a result. By that time, it only matters that there are enough sufficiently well maintained and user-friendly clients on all platforms for those "super-users" to embark their peers (which is currently largely the case).
This is how I ended-up here, in fact. I refused to join WhatsApp because I was tired of previous forced migrations from protocols I thought were "too big to fail" (MSN, Skype, …), WhatsApp was already banned in some of the countries I was travelling to for work, and I so, after a failed errand with Matrix, I rediscovered XMPP 10 years after I had my first account on it. Today I have about a hundred contacts there, and the less tech-literate of my peers notice no practical difference in usability or features compared to something like WhatsApp: it just works.
By "make an impact" I was thinking maybe being more popular than either Matrix or IRC (both of which I use regularly, and both of which I would prefer XMPP to) not "spontaneously become the next dominant network"
Yeah I agree. People should be building their Slack alternatives in Elixir at the very least. It's the tried & true, no brainer, boring technology stack for highly scalable, performant, concurrent applications.
Figma was started in 2012, while definitely successful, it wasn't exactly built quickly. C++ on WASM is performant, but probably not super easy to bootstrap a new project on.
The challenge is more in the stack. Building GUIs is tricky, and the web stack offers a lot of useful tools which make it a very good default choice from a “get shipped” perspective. Qt is nice but it sure feels like a big step back in velocity for me
Sure, but that's off topic and has been covered to death on this site over the past few weeks, so could we keep this thread focused on Tauri and Linen?
The discord sync feature combined with it being google indexable does seem nice but is there a way to control what can be indexed? Some discord channels are somewhat private on purpose even if the entire server is public. So can you control which channels are indexable?
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.
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.
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.
Most electron apps are (mostly but not solely) a bundling of the web-app.
So the cost is less the cost of "switching" and more the cost of initially writing a native app.
In turn the actual question is how to reuse as much code as possible between the web-app and native apps without it introducing a lot of friction.
And one of the few reliable, nicely (developer) usable answers for this is currently electron.
For "business logic" there somewhat are already other answers, some languages run on most targets reliable and there is also wasm which often still needs a bit more tooling but has a lot of potential for such use cases (e.g. see Disney which AFIK does have their core business logic compiled to a wasm blob and then "only" provide UI/system glue to bundle it in on all platforms their streaming app runs on).
The problem is UI, you really don't want to reimplement UI and the mapping of non HTML/CSS producing UI to a mix of HTML/CSS on some platforms and native components on other often doesn't work grate so it's not surprising people decided to "just go with HTML/CSS everywhere". And if you are already there going with electron isn't "that" much more overhead.
This right here. Something monumental would have to happen for senior leadership to green light a rewrite, because that’s a massive project that will bring in no additional revenue.
Webviews are built on weakly, dynamically typed languages, which naturally have development speed advantage over statically typed languages in the happy path. On top of that you have multitude of frameworks even more optimized for the happy path. It is much faster to create an MVP of a GUI with web technologies.
Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch. Web, desktop, mobile. Almost one codebase can be used for all three.
Could you do the same with say, Java (and maybe soon with .NET)? Maybe. But web has a lower barrier for entry and faster speed of development cycle. Not to mention larger pool of developers available.
All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. And once you get going, it is really hard to pivot your technology stack to something else.
> Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch.
With an exception of web there are very solid GUI cross-platform (linux, windows, mac) frameworks out there. Qt is even pretty good at targeting native look.
> All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost.
Yes, web technologies let you build MVPs faster, that's literally in my original comment. However, in order to provide quick MVPs these technologies inherently sacrifice long term maintainability.
QT is just gonna be untenable for most people. Learning C++ is hard enough, but learning QT is basically a different dialect of C++, and I can't even say it's worth the investment.
The massive advantage of Electron is write once -- with some extra overhead, perhaps 40% effort -- and you can ship the same app to web, mac, windows, ios, android, and linux.
MS seems to be using electron in the worst possible way.
I mean it's basically running an outdated version of the web version bundled into a even more absurdly outdated version of electron.
Given how bad the decision is it really looks like it's just for ticking of some checkbox and avoiding claims that MS is intentionally hurting other desktop system... but honestly the way they did it makes it look even more like that.
Through there are technical reasons AFIK:
- it seems to be that they have some custom native "call/video/screen-capture" code, which doesn't seem to provide any sustainable benefits but is less reliable in my experience.
- (speculative) for some time in the not that distant past (Chrome <v110) on Wayland desktops for screen sharing Chrome did only support an older experimental version of the protocol, locked behind an experimental flag. Through most distros set up pipewire in a way where the old protocol was still supported (on the fly converted) and even through the chrome flag was experimental it did work very reliable. So re-implementing pipewire support by hand would have been quite of an bad decision I hope Teams didn't do.
Can't speak about other OSes but that is the case for me on linux.
And I hace seen quite a few people on windows who literally has to reboot because teams app was working erratically or was freezing and no amount of stopping/restarting the app would help.
Well, s/Electron/WebUI generally, the conclusion that I came to last year was beyond Qt there really isn't a decent cross platform UI toolkit out there that really handles all the nitty gritty details like accessibility, proper GPU acceleration, etc. And Qt comes with its own normative lifestyle assumptions. And there is this huge community of HTML/JS/TypeScript developers and a pile of UI frameworks for them.
So if you're looking to build a cross platform desktop application, you want to also be able to service it on web, and you want to be able to hire beyond the limited Qt/C++ talent pool, it just makes sense.
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.
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.
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.
Yes because electron comes with its own distinct instance of chrome (usually an outdated version) for each individual app, introducing massive overhead versus running on the OS provided browser engine.
It will still be a browser and a modern "app" done by people who think guis should refresh at 120 fps instead of just when something changed on screen...
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.
This stood out to me too. The article doesn't seem to touch on it, but I assume they have to ship more binaries to account for the vast variety of setups on Linux.
> If your app plays audio/video ... This will increase the size of the AppImage bundle to include additional gstreamer files needed for media playback.
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.
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
This is very much the same issue I have with the message input box on the Threads feature of Discord. It works on "normal" messages (those outside the forums feature) but if it's in those, the home key sends the cursor straight to the very start.
Unsolicited Advice: instead of building an alternative that is mostly similar from an end-user perspective, think more deeply about communication within organizations. Followers copy and extend. Innovators lead the way to a new vista.
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…
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.
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.
252 comments
[ 3.2 ms ] story [ 238 ms ] threadWe 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!
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
(And funnily enough, aren't they both pivots out of a company doing something else? Discord a game and Slack some other start-up?)
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 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 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've always thought slack was the alternative, to IRC.
Modern software piles up new stuff on top of new stuff. There is no time for the basics. /s
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!
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/
Then I think your beef is with the class of apps, not Tauri or Rust.
> Tauri still issues about 25000 syscalls at startup and needs about 300mb of ram for a “hello world” app
How many syscalls and how much memory does your web browser require on startup?
I'm not the biggest fan of JS apps, Electron, etc., but it's simply ridiculous to think this class of apps don't provide value.
It's become chic to yell about the good old days when it didn't take your editor a few seconds to startup, and I agree, but I think this lament actually requires an answer 1) in the form of code, 2) in a language everyone can learn 3) that runs on everything.
They absolutely provide value. I’m not questioning that. I’m just sad and frustrated by the lack of any better options for application developers.
We desperately need a good, lightweight, feature rich, cross platform application framework. Making something good will probably need an 8-figure budget at a minimum. Unfortunately nobody with that kind of money seems invested enough to make it happen. As a result, every computer on the planet is either slower or more expensive than it needs to be in order to run Teams / Slack / Discord / etc etc.
It feels like a coordination problem more than a technical problem, with users suffering the most.
Or those services should just expose a damn API and allow third party apps. I don't see what would be wrong technically with a lightweight Slack CLI app, a native macOS app, etc. Damn it's just about showing text on a screen... writing a third-party Slack client could even be a nice student project.
It just means that Slack needs to expose a proper API (unfortunately "proper" is not the norm in our industry), and probably there is a business reason to not allow it that I don't see right now (maybe just cargo cult or wrong assumptions, those are typical reasons behind business decisions).
The hello world for cross-platform Egui also written in Rust is a 19MB binary and uses 89MB of RAM.
Are you saying that "WebGUI" is the primary category you'd place this app in?
For end-users, the category is "chat apps". I grant the point, though, that these days there may not be any difference between the two.
> It's become chic to yell about the good old days when it didn't take your editor a few seconds to startup, and I agree, but I think this lament actually requires an answer 1) in the form of code, 2) in a language everyone can learn 3) that runs on everything.
While I ordinarily agree with this sentiment, the big pitch about this particular product is performance.
From the landing page, this is literally the first bullet point listed:
> Linen is 1000x more lightweight than alternatives. This means that we load faster, use less bandwidth and are more responsive
In this respect, I think that using 500MB on the 3MB transfer benchmark contradicts the 1000x more lightweight claim. I've never seen Slack or similar need even 10x as much RAM as the benchmark results.
Last I used Slack, it was using around 1GB of RAM in daily and active use.
At any rate, these are the things that get funded by VCs? It seems to me that the world is not crying out for a slightly more lightweight Slack alternative.
Some demand? Sure, for free tiers and low-cost tiers ... but how do they expect to monetise those free and low-cost users? The free tiers are usually subsidised by the enterprise tiers.
Now -- does this particular app solve this particular problem better than Slack? That's a fair Q, but, again, far afield from my point.
I have a real problem with this abstract beefing with other peoples' products and tech choices, that takes place in land that without alternatives. Show me the code for cross platform GUI development that doesn't look something like this. Explain how it's better than this, and how we should all be using it, instead of this. Until then, these criticism ring hollow to me.
Well, there's Qt that's relatively popular. Also WxWidgets. Java applications have had much success for x-platform GUIs (Jetbrains products come to mind) but is hardly considered lightweight (although much lighter than Electron-types).
Personally, I lean towards Lazarus.
All of the above (and I'm missing quite a few here) are insanely lightweight and performant compared to Electron-type implementations.
> Explain how it's better than this, and how we should all be using it, instead of this.
I did not claim that "all of us" should be using the alternatives. I said that, while in general I agree with using the quickets x-platform dev stack, for this particular application which claims "performance" as it's main goal AND further goes on to claim actual performance as a delivered result, I disagree that it is in any way as performant as it could be.
I mean, a quick win here would have been to use one of those alternatives I listed, maybe Qt. C++ GUI (using Qt) with Rust application logic would have probably been faster to develop than Html/Js + Rust, and the result would run just as fast (if not faster) and use less memory.
I'm inclined to use some of my precious free time to write a bare-bones x-platform GUI chat application, inventing my own protocol (like Linen did) just so that I have something to point at when invariably the claims of "performant" in electron-type apps is made.
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.
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.
Asking for a friend, of course.
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?
In practice the need for WebKit is going down over time. For basic rich text you can render Markdown to JavaFX nodes directly, for more advanced stuff you could transform [X]HTML to FXML, you don't need it for video or audio, there's a native rich text / word processor control these days, and if you can do 3D graphics with a high level scene graph (meshes, lights etc) then you don't need HTML for 3D either.
Still, it's often useful and bandwidth/disk space isn't the problem it once was.
Yes I think you can compile Scala and ScalaFX apps down to native binaries this way. Look at Gluon Substrate:
https://github.com/gluonhq/substrate
One of our customers is experimenting with shipping such apps with Conveyor. There's a discussion ongoing here:
https://github.com/hydraulic-software/conveyor/discussions/6...
We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way. There's also someone in our Discord who has been trying it with Compose apps.
If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:
https://hydraulic.dev/blog/13-deploying-apps-with-jcef.html
For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff. OTOH if you don't care about that, it'd be (imo) easier and more direct to not use HTML. Proper GUI toolkits give you a lot of stuff out of the box like virtualized list views which HTML still doesn't; useful for scrolling over huge datasets like chat logs.
I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.
> For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff.
I'm not even sure it matters so much, for instance there is this XMPP client that uses (lib)WebRTC for audio/video calls and has all of its UI build with Gtk (no web): https://dino.im/
> Proper GUI toolkits give you a lot of stuff out of the box […] Also I learned GUI programming decades ago and find classical UI toolkit more intuitive than HTML.
yep, looks like we are on the same boat of angry old men yelling at clouds :)
1. Go grab https://conveyor.hydraulic.dev/ (disclosure: my company makes that)
2. Run `conveyor generate {javafx,compose} my-test-project` (pick your preferred UI toolkit). You now have a JVM desktop project.
3. `./gradlew jar; conveyor make site`. You now have a directory with self-updating platform native packages for Windows, macOS (ARM/Intel) and Linux that you can upload to a web server of your choice. Or supply upload creds and it'll do that step for you. Provide certificates and it'll also take care of signing.
That's all it takes to get a self-updating JVM desktop app these days. The same tool can do Electron, Flutter and native apps too (i.e. C++/Rust), so you could also use it with Tauri, but the nice thing about the JVM support is that it'll both strip down and bundle the JVM for you whilst cross-building/packaging so you don't need CI to do releases. From the user's perspective it's a normal app, from the developer's perspective you just hack on your local dev laptop like you could for a web app.
Binary sizes depend on how much functionality you use and how much effort you put into minifying. With the default level of effort (i.e. none) a simple hello world JavaFX desktop app will be about 33mb and a simple compose app will be about 52mb for macOS (skia is a very large graphics library). However, the Mac versions are larger than those for other platforms, and these sizes are still quite wasteful. There's a lot of low hanging fruit. You could make it a fair bit smaller by using ProGuard and other more aggressive dead code elimination techniques, as well as more heavily compressing bytecode. There's also plenty of fat to trim on the native code side.
GraalVM native images are interesting because they have much faster startup time and low memory usage - competitive with C++ apps, even. They take more work to create though. You can see a robotics app that's natively compiled here:
https://www.youtube.com/watch?v=XxVoG1ft7w8
Aren't you just replacing one VM for another?
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.
Pretty fun stuff.
https://blog.jetbrains.com/fleet/2023/02/fleet-below-deck-pa...
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.
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.
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.
I must have gone through this 7 or 8 times in the last 5 years.
Its also really rare for a desktop app written in java to look good. I'm sure its possible, but man looking at ghidra is a real pain.
Java/JVM as platform suffers from trying to be all encompassing "second OS". Want to do time, fonts, cacerts? JVM does its own thing. Want to do UIs? Hey, there are widgets from 90s, should be good.
Another pretty one with a java frontend is BitWig. That's perhaps more impressive than any JetBrains app.
Last time I upgraded an old install i wasn't using, it pulled its own JRE, then pulled a new gradle which promptly complained about the JRE Android Studio installed itself.
Had to do some googling and force it to use a JRE that both the IDE and gradle liked.
But as I said, that doesn't happen often. It's just funny when it does, in a masochistic sort of way.
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.
You’re in a thread about some people that built a new piece of desktop software…
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.
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.
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.
Also the JetBrains IDEs are really good IMO.
"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
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...
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.)
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.
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).
> Other issue with XMPP is how hard it is to find clients that don't suck
OK, but the alternative we are talking about here consists of developing the server, protocol and clients all at once and from scratch, and end-up with something that's merely a prototype heading into a decade worth of enhancement and scalability improvements, iteratively bumping into the exact same kind of problems. Wouldn't it be less effort to just make an XMPP client that doesn't suck and lead by example? (That's pretty much what the "Conversations" Android client did when it came out, and now it's used by the German government, among others).
> I think I've seen at least 3 different ways clients implemented emojis, for example
I'm not aware of anything like that. There are different ways to do certain things, like sending attachments (HTTP upload or client-to-client), but that's the good thing about XMPP: your client/server negotiate capabilities and sometimes even translate among them.
I won't pretend that everything is rosy, for sure, but it also isn't that bad.
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.
IMO, what does matter for XMPP's future is that it remains appealing to a growing niche of users who want to be in control, for whom self/local-hosting is important (XMPP excels at that), who care about privacy (OMEMO is state of the art, and XMPP offers gentler alternatives where PFS isn't desired), and who understand the benefits of federation for resilience. This niche will grow naturally as more and more people get deceived by every monopolistic network being doomed to grow beyond a threshold of sustainability and implode as a result. By that time, it only matters that there are enough sufficiently well maintained and user-friendly clients on all platforms for those "super-users" to embark their peers (which is currently largely the case).
This is how I ended-up here, in fact. I refused to join WhatsApp because I was tired of previous forced migrations from protocols I thought were "too big to fail" (MSN, Skype, …), WhatsApp was already banned in some of the countries I was travelling to for work, and I so, after a failed errand with Matrix, I rediscovered XMPP 10 years after I had my first account on it. Today I have about a hundred contacts there, and the less tech-literate of my peers notice no practical difference in usability or features compared to something like WhatsApp: it just works.
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.
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.
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.
So the cost is less the cost of "switching" and more the cost of initially writing a native app.
In turn the actual question is how to reuse as much code as possible between the web-app and native apps without it introducing a lot of friction.
And one of the few reliable, nicely (developer) usable answers for this is currently electron.
For "business logic" there somewhat are already other answers, some languages run on most targets reliable and there is also wasm which often still needs a bit more tooling but has a lot of potential for such use cases (e.g. see Disney which AFIK does have their core business logic compiled to a wasm blob and then "only" provide UI/system glue to bundle it in on all platforms their streaming app runs on).
The problem is UI, you really don't want to reimplement UI and the mapping of non HTML/CSS producing UI to a mix of HTML/CSS on some platforms and native components on other often doesn't work grate so it's not surprising people decided to "just go with HTML/CSS everywhere". And if you are already there going with electron isn't "that" much more overhead.
Could you do the same with say, Java (and maybe soon with .NET)? Maybe. But web has a lower barrier for entry and faster speed of development cycle. Not to mention larger pool of developers available.
All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. And once you get going, it is really hard to pivot your technology stack to something else.
With an exception of web there are very solid GUI cross-platform (linux, windows, mac) frameworks out there. Qt is even pretty good at targeting native look.
> All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost.
Yes, web technologies let you build MVPs faster, that's literally in my original comment. However, in order to provide quick MVPs these technologies inherently sacrifice long term maintainability.
MS seems to be using electron in the worst possible way.
I mean it's basically running an outdated version of the web version bundled into a even more absurdly outdated version of electron.
Given how bad the decision is it really looks like it's just for ticking of some checkbox and avoiding claims that MS is intentionally hurting other desktop system... but honestly the way they did it makes it look even more like that.
Through there are technical reasons AFIK:
- it seems to be that they have some custom native "call/video/screen-capture" code, which doesn't seem to provide any sustainable benefits but is less reliable in my experience.
- (speculative) for some time in the not that distant past (Chrome <v110) on Wayland desktops for screen sharing Chrome did only support an older experimental version of the protocol, locked behind an experimental flag. Through most distros set up pipewire in a way where the old protocol was still supported (on the fly converted) and even through the chrome flag was experimental it did work very reliable. So re-implementing pipewire support by hand would have been quite of an bad decision I hope Teams didn't do.
And I hace seen quite a few people on windows who literally has to reboot because teams app was working erratically or was freezing and no amount of stopping/restarting the app would help.
So if you're looking to build a cross platform desktop application, you want to also be able to service it on web, and you want to be able to hire beyond the limited Qt/C++ talent pool, it just makes sense.
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?
https://github.com/tauri-apps/wry/issues/890#issuecomment-14...
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.
> 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.
https://tauri.app/v1/guides/building/linux/
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.
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
https://github.com/wee-slack/wee-slack
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 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.