Building a Slack/Discord alternative with Tauri/Rust
linen.dev
linen.dev
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.
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:
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.
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.)
I mean VS Code, Discord, Slack and Obsidian are all in very widespread use and work perfectly fine for me.
Are there alternatives to Electron that require less resources? Tauri seems to be proof that there are.
But I think there is real value in large communities and backing. Electron seems to work perfectly fine to me for everyday use as is evident by the applications mentioned above. I would personally choose Electron over Tauri even for greenfield projects, simply because Electron seems to power applications that are in much more widespread use.
Exact opposite, to me Electron is the living proof that software companies correctly care a lot about building a product people want, and correctly realize that the large majority of people correctly do not care that one of their top productivity app uses $1 worth of RAM, but want the app to have the features and UX they need instead.
The irrational obsession of part of the Hacker News crowd for the RAM usage of web apps is borderline psychotic. Man, take a chill pill, go get more RAM for a couple bucks once every 3 years, and let the engineers focus on UX and features ok? I don't want my productivity app to be a codegolf exercise
Users pay 2% more to get more RAM, Slack developers have 200% productivity thanks to not having to deal with low-level optimization crap, and can focus on building features and UX.
That's how the world works. But some angry HNers can't wrap their heads around it
Additionally at the end of the day some people do interact with non developers and realize they tend to have less beefy devices. Being the tech support in the family can be interesting because of that front. For example when I'm asked what's causing my fathers or grandparents relatively new laptop to be so laggy despite how much better it is than the predecessor and finding out there's no happy answer for that. There's no explaining that some software regressed on this front and they should just accept more electronic waste.
This whole "this is how the world works" bullshit is post-hoc rationalisation done by wealthy idiots trying to justify their purchase by saying "it's just 5 cents a day if you consider it'll last ten years". This is bullshit and only applies if the purchase you're making is insignificant to you. So, congrats, $200 is insignificant to you. It's not, for most of the world, but you'd see that if you pulled your head out your ass.
This isn't even "not having to deal with low level optimization". Using a normal toolkit is not low level optimization, it's the bare minimum.
Putain, elle est belle la French Tech avec des gens comme ça.
Clearly, companies and developers are behaving in a way you don't like. You seem to believe that billion dollar companies are just stupid, that all developers are idiots.
I'm explaining to you the correct way to explain this behavior, an explanation that does not assume that a majority of successful companies and people are stupid, but that instead relies on rational arguments.
Of course I'd love it if there was a perfect way to develop software once without micromanaging memory, run it on web, desktop, mobile and have it be super performant at the same time. It just does not exist as of today, companies and people take rational decisions based on this. It is how it is, stop raging, accept it or build something better.
No, you're stating an opinion and trying to pass it off as facts.
>You seem to believe that billion dollar companies are just stupid, that all developers are idiots.
If you work with developers, you know we're all idiots at heart. And lol absolutely yes billion dollar companies are stupid. You think that scale prevents stupidity ? No, if anything it scales it up even harder. A company that was doing stupid things as a self funded startup with 5k in the bank and a multinational megacorporation with 50 billion in the bank both have equal opportunities to be stupid. The billion dollar corporation even gets to use it's sheer scale to walk over their stupidity and not die from it.
> stop raging,
The day I'll stop complaining will be a miserable one. Stopping the rage is what lead to absolutely dreadful state of software development today.
>an explanation that does not assume that a majority of successful companies and people are stupid, but that instead relies on rational arguments.
One does not preclude the other, the rational argument is still a moronic one.
>Of course I'd love it if there was a perfect way to develop software once without micromanaging memory, run it on web, desktop, mobile and have it be super performant at the same time.
Have you _never_ looked at any UI toolkit in existence, ever ? Even Flutter is a better option than Electron if all you want is a multiplatform app, and this is coming from someone not necessarily holding Flutter in his heart. The bare minimum to do if you're going to make your life easier is to not pick the absolute worst option that is Electron. There's a scale to multiplatform toolkits, and Electron is at the bottom end of this, being neither a good technical choice, a good product choice, a good choice for your users. Electron benefits a single group: developers, but mostly company management, happy to crap out software.
Funny that you say that, I actually did my PhD on this topic! You can find a state of the art of UI toolkits, from page 28 to page 96 of my PhD manuscript. https://hal.science/tel-01455466 I wrote it in 2015, so it's dated for sure. But short answer is: Yes I have been looking at A LOT of UI Toolkits, and one thing I am sure of is that you clearly are blissfully unaware of the socio-technical aspects of Toolkit adoption.
As an industry we trade runtime efficiency for lowering the bar on developers; we've been doing that for 40 years now. The industry has been growing so hard that that is a unavoidable and at a macro level probably a net positive.
The large majority of people care about programs that run fast and feel snappy, programs that don't look like some high school dropout's modern art project, programs that don't demand a pocket supercomputer to bankrupt you, programs that just get shit done because computers are just a god damn appliance comparable to a toaster from Walmart.
Today's software runs worse on modern hardware than yesterday's does, because you "let the engineers focus on UX and features" without teaching them to care for a single moment about _actual_ user experience instead of whatever bullshit their product owner put out.
Talk to any real engineer and not the US bullcrap of "oh sure everyone out of a code camp is an engineer" and ask them if quadrupling the weight of a bridge and multiplying resource consumption by ten is an option. You are making our profession look like fucking clowns.
People don't care about 600MB. They care about how using their PC feels, and Electron is a massive contributor to it feeling like shit.
There’s a difference between not caring that your computer is sluggish because of its programs, and not being able to tell the difference and demand less sluggish alternatives.
Normies put up with poor user experiences to the exact degree that software engineers deliver them.
That my UI should be significantly slower than my screen’s framerate is a false premise.
Just like people learn to completely ignore popups (and are often not even aware that a popup appears, even an important one), they learn to accept bugs, overall bad apps, and the fact that they need a new smartphone every two years to keep up.
Doesn't mean at all they wouldn't enjoy better technology. They just do not have a choice.
Can we at least agree on the fact that it would not be that difficult (and costly) for Slack to actually expose an API allowing for third-party clients? That way I could have a lightweight CLI client and I would be fine with most users staying on their crappy Electron client.
I guess they don't do it for a reason, which is probably not user experience. Maybe having only official apps is (or seems, again) better for lock-in?
1-An external API is a product, you have to maintain it, keep it backward compatible even when you change your internal models, monitor it, protect it against attacks, etc. So no, I do not agree that it would be easy for Slack to expose an external API for 3rd party clients. It would be at least millions worth of investment.
2-A lightweight CLI client for Slack? Let me tell you, this would have a very very tiny user base. Probably just you, and even you would be bored of it after 1week. Would it be worth it for Slack to invest millions in an external API just so a couple hundred geeks can make their own crappy client?
3-Analytics. Slack runs analytics on usage of their app, in order to know what users use and want. Can't do that if you don't own the frontend.
4-Brand. If one of your main competitive advantages is a good UX (And believe me, it is the case for Slack), would you want to grant people the right to create crappy apps that ruins the UX and turn people off your product? This is what is killing Android brand value for example. Sure it's open, but it means there are a lot of Crappy UIs that turn people off.
The beauty of liberal capitalism is that ultimately, at least to some extent, what is good for users is good for the company, so incentives are aligned to some extent, and very unlikely to be completely opposed as you seem to suggest. So yes, I believe that companies are taking strategic decisions (such as not shipping an external API and 5 different native clients) in large part because it does indeed benefit the majority of their users.
2- Don't assume too much. I use IRC from a CLI. But anyway you are just repeating your previous point, which is that you think it would cost millions.
3- Well, they would know what the third-party apps use in the API. They could also provide integrations for most popular languages, and those would send telemetry (what do you think the Google Play Services do?). For my crappy app, probably they don't need to know what I do, I am just a useless geek as you said.
4- Counter example: I was always able to connect my crappy app to my GMail account, and it did not prevent GMail from essentially taking over e-mail. But the couple hundred geeks who don't like the web frontend can use their crappy e-mail app, and everyone is happy.
> The beauty of liberal capitalism is that ultimately, at least to some extent, what is good for users is good for the company.
Respectfully, that is the most naive comment I have read today. I don't even know where to start answering that, so I'll just pass :-).
You forgot about the times when two or more of the electron applications you run because you have no other option decide to take 20% CPU each or more.
Even if you make it a point of pride to run a computer that eats power measurable in kilowatts per hour, that's bad when on battery at least.
And from the article:
> One of the main core differences with Tauri is that it uses a Webview instead of using chromium like in Electron.
What's the difference? It will still end up eating all that ram and needlessly refreshing the cat gifs someone posted a day and a half ago.
The code of the web engine can be shared among several apps, instead of each of them having its own copy in RAM, making it less of an issue when having several of them.
If each of them don't abuse RAM usage of course.
Which is a big if of course.
I'm not familiar with internal browser architecture, but do they make at least a token effort to not render/run attached javascript for elements that are not currently in view?
I haven't measured, but my gut feeling is Electron apps go extremely crappy when you have like 30 memes in a row in a chat channel and make the mistake of switching to it.
Edit: hey, what happens when you open a 500 M log file in vscode?
And VSCode has to be contrasted with Atom, which is the same but in so much worse: It takes a lot of effort to make Electron work well.
That being said, if a "drop-in" alternative would be available I would probably try to switch at one point. But the alternative would have to be on par with the ecosystem (including packaging, binaries signing, etc.), the community, the ease of use... I don't think there is such a thing yet.
The app, if you are interested: https://mockoon.com
Also electron comes with its own advantages which many on HN seem to forget.
code-server for instance was very easy todo, because vscode was build using electron. It runs virtually anywhere. Uses fewer resources then most WMs on a headless device if you need a full blown IDE.
Having a latency on local clicks and transitions is not my idea of fun.
VSCode is an outlier here. And it's getting slower and slower with age, while sublime text is getting faster.
For what it is, Obsidian is very impressive.
To be clear, your opinion is absolutely valid I just don't think they apply equally to everyone.
The 20 last years, the web, the animations and the badly coded apps lead people to be used to slow software.
However, when you have used software for decades on much less powerful hardware, the sluggishness of all of it is kinda jarring.
On Android, I stumbled upon a file explorer, called Little File Explorer, that feels like this. It's 170 KiB, and generally opens directories without a feeling of transition. Instead of feeling like it's laboriously building a view, it feels almost like the view's already built. Alas, it doesn't yet remember scroll position when paging back.
Modern things can make stuff that would be slow, fast; but they also usually make stuff that can be fast, slow. I believe this normalisation of slowness is a "Normalisation of Deviance".
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'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.
As I said, businesses are probably not the main target customers for Linen so it's completely understandable, I would've loved it though. Great work!
We migrated our small, private slack group to discord when slack changed their retention policy, though it's become less active since then.
I think a lot of the members use slack already, but are not inclined to deal with discord. Maybe a different app would be better, or maybe it's "slack or nothing" for some of those folks.
What I really want is slack to just have a reasonable pricing plan for small, low activity groups, like Linen has. So props for that!
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.
I understand wanting to produce an alternative, but I can't help but wonder why not produce an alternative that is substantially different?[1]
From the screenshots Linen is almost a clone of Slack, with (I think) the biggest difference being "google-indexable". There's literally, on the landing page, no compelling reason for using this product over Slack.
Looking at the landing page for Linen[2], I don't see anything about why one would choose Linen over Slack other than "google-indexable" and "advanced thread management"[3].
I think the biggest differentiator is pricing, but that is not an issue for companies using Slack, and unprofitable targeting anyone who finds Slack too expensive.
[1] The easy "substantially different" thing to do would be to rearrange the layout. The hard "substantially different" thing to do would be to actually have a performant chat program that starts in <10ms and consumes under 100MB in normal and active daily use.
[3] Managing conversation threads in IM is not a problem I've heard anyone complain about, TBH.
$10/month for up to 100 users compared to Slack's $7.25/user/month.
What it really comes down to is integrations. For a team to consider Linen, they'd have to get their Jira tickets in there, bitbucket/github hooks etc. as well as external integration with Okta/azure SSO etc. That will make or break Linen, more so than being indexable. Because if you want indexed content, you're likely working on an open source project or are open which means without revenues, and so you won't be willing to pay much.
I'm glad an alternative to Slack, cheaper, with open search is available.
> For a team to consider Linen, they'd have to get their Jira tickets in there, bitbucket/github hooks etc. as well as external integration with Okta/azure SSO etc.
Yeah, but those things cost money, usually per user, and with good reason.
Just comprehensive SSO alone is something that costs around $5/user/month. Sure, the Linen team could write it themselves, but it won't work anywhere nearly as nicely or as performant as signing up for an SSO service that works with everything a corporate uses for sign-ins.
So, yeah, it can be $1/user/month now, but it's unlikely to remain that way when they need to add in all the Slack functionality. It's also unlikely to remain performant when it matches Slack feature-for-feature.
> Windows - 4.13 MB
> Linux - 73.8 MB
One is not like the others.
> CAUTION
> If your app plays audio/video ... This will increase the size of the AppImage bundle to include additional gstreamer files needed for media playback.
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
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?)
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!
At the moment I hop into many of the chats and they aren't too active. Which is fine but makes discovery a bit boring.
Why not have the feed of the latest messages from your top 50 trusted Linen workspaces (should I call them sheets? duvets? covers? :-)). Then I can see active discussions that are happening and join in.
Also use Linen for your own day to day team activities. Assuming there is a private channel concept for stuff that is secret that'll create more activity and make it interesting to follow.
This coming from someone that has mostly done Web stuff in the last 20 years.
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.