[HN Gopher] Building a Slack alternative with Rust/Tauri
___________________________________________________________________
Building a Slack alternative with Rust/Tauri
Author : cheeseblubber
Score : 147 points
Date : 2023-06-20 18:45 UTC (4 hours ago)
(HTM) web link (www.linen.dev)
(TXT) w3m dump (www.linen.dev)
| Solvency wrote:
| With Figma being so incredibly performant and robust as a web
| assembly app, why don't more apps turn to this approach instead?
| nosequel wrote:
| 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.
| paholg wrote:
| 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!
| cheeseblubber wrote:
| Thanks. We have mobile clients in the roadmap! There is a big
| refactor that we would need to do before getting there :)
| paholg wrote:
| 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?
| digging wrote:
| 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.
| cheeseblubber wrote:
| Sorry forgot to update the FAQ. We shipped realtime
| Discord sync a few months ago Will update it now.
| vxNsr wrote:
| 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.
| cheeseblubber wrote:
| Yep if you just create an account linen.dev/s/linen you
| should be subscribed to updates. I only do email updates
| around once a quarter
| sigg3 wrote:
| > Building a slack alternative
|
| I've always thought slack was the alternative, to IRC.
| palata wrote:
| Me too...
|
| Modern software piles up new stuff on top of new stuff. There
| is no time for the basics. /s
| awestroke wrote:
| Isn't "alternative" commutative?
| wakamoleguy wrote:
| 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!
| awestroke wrote:
| Amazon is also not necessarily an alternative to a local
| bookstore
| kachnuv_ocasek wrote:
| IRC was originally an alternative to a BBS... You can keep
| piling this to no end.
| nicce wrote:
| Let's not forget the Windows Live Messenger. I guess it was
| more like Discord alternative of that time.
| orthecreedence wrote:
| I prefer Comic Chat.
| nicce wrote:
| How I have missed this... Oh I'm too young.
| thewataccount wrote:
| Do you plan on releasing the source code for the client at any
| point? I'd love to possibly use it as a reference for some of my
| stuff
| cheeseblubber wrote:
| The code is open source https://github.com/linen-dev/linen.dev
| palata wrote:
| > 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.
| bastawhiz wrote:
| > why not going for a JVM-based technology?
|
| 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.
| mike_hearn wrote:
| We have a surprising number of customers who ship JVM desktop
| apps, mostly in industrial control and robotics of various
| kinds.
| ezst wrote:
| 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.
| glowingly wrote:
| 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.
| MSFT_Edging wrote:
| 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.
| dijit wrote:
| exception to the rule, and should be popular on this site:
| IntelliJ IDEA (and derivatives) are JVM based.
| lopatin wrote:
| I use IntelliJ, which is a Java + Swing app I think.
| X6S1x6Okd1st wrote:
| Initial release was 2001
| lopatin wrote:
| Looks like Java is working pretty well for them then.
| [deleted]
| szundi wrote:
| Yes we have 15k users
| piperswe wrote:
| 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.
| wmf wrote:
| LibreOffice has very little Java code. https://www.reddit.c
| om/r/libreoffice/comments/6gxy82/is_libr...
| JoshTriplett wrote:
| 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.
| notatoad wrote:
| 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.
| giovannibonetti wrote:
| You mean the former?
| datadeft wrote:
| Because of Oracle?
| wilg wrote:
| 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.
| cheeseblubber wrote:
| 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.
| mike_hearn wrote:
| 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?
|
| Asking for a friend, of course.
| bojo wrote:
| Chromium or Tauri, you are still building platform specific
| binaries either way.
| IshKebab wrote:
| 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).
| littlestymaar wrote:
| > why not going for a JVM-based technology? That's cross-
| platform, and it doesn't require a web browser / webview to
| show text.
|
| Because then you require the user to install a JVM?
| ezst wrote:
| 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.
| tredre3 wrote:
| So your suggestion to avoid shipping chromium is to ship
| java instead?
|
| Aren't you just replacing one VM for another?
| silisili wrote:
| It's been years since I've messed with Java. OpenJDK can do
| all that? How big are the binaries?
| ipsi wrote:
| They're pretty big. I've got a fairly basic JavaFX app
| that's compiled with Graal, and it weighs in at 98MB, or
| 32MB when zipped.
| mike_hearn wrote:
| 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.
|
| 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
| ezst wrote:
| 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.
| virtue3 wrote:
| 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.
|
| [1] https://softwareengineering.stackexchange.com/a/20024
| [deleted]
| sreejithr wrote:
| A good Reddit alternative would be useful right about now
| lolinder wrote:
| 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?
| littlestymaar wrote:
| 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.
| renewiltord wrote:
| Just out of curiosity, is the server-side self-hostable? I want
| to just try it out.
| cheeseblubber wrote:
| 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.
| alberth wrote:
| Too bad Elixir/Rust wasn't used.
|
| 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.
| ezst wrote:
| 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.
| aidenn0 wrote:
| 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).
| tredre3 wrote:
| 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.
| paxys wrote:
| Discord alternative would be a better description, considering
| Slack isn't meant for communities but companies.
| paulddraper wrote:
| I see it used for communities
| palata wrote:
| 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
| [deleted]
| sedatk wrote:
| > 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.
| bojo wrote:
| 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.
| awestroke wrote:
| 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
| mustache_kimono wrote:
| > Does Rust have a meaningful contribution to the performance
| and the safety of the codebase here?
|
| It apparently has a tremendous benefits:
| https://tauri.app/v1/references/benchmarks/
| josephg wrote:
| 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.
| mustache_kimono wrote:
| > 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.
| VWWHFSfQ wrote:
| 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.)
| digging wrote:
| 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?
| cheeseblubber wrote:
| We do have private teams/communities. It is actually what we
| use internal for work. Mobile app is on the roadmap!
| dijit wrote:
| 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.
| Shared404 wrote:
| > 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.
| dijit wrote:
| I'm trying to get it to replace our Teams usage, but having
| Teams be the default when you create meeting invites is
| just too strong.
___________________________________________________________________
(page generated 2023-06-20 23:00 UTC)