Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Slack/Discord alternative with Tauri/Rust

linen.dev

Post reply on HN
Print view View original

241–250 of 253 posts

Re: Building a Slack/Discord alternative with Tauri/Rust

#241

Post by palata »

bastawhiz wrote: post #27
palata wrote: post #20

> 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…

> 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.

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.

Also the JetBrains IDEs are really good IMO.

Re: Building a Slack/Discord alternative with Tauri/Rust

#242

Post by paulddraper »

OJFord wrote: post #85
palata wrote: post #15

Earlier quoted context omitted.

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…

But that's like saying 'Discord isn't meant for communities, it's meant for gaming communities'. They both caught on beyond their original market. (And funnily enough, aren't they both pivots out of a company doing something else? Discord a game and Slack some other start-up?)

Slack also a game, funnily enough

Re: Building a Slack/Discord alternative with Tauri/Rust

#243

Post by BiteCode_dev »

Capricorn2481 wrote: post #225
BiteCode_dev wrote: post #200

Earlier quoted context omitted.

While I appreciate VSCode, I think Discord, Slack and Obsidian are not selling the platform at all. They feel sluggish and have poor ergonomics. Now the second one may or may not be attributed to Electron depending of if you buy the cultural thinggy, but the first one clearly is. Mumble is super reactive in comparison to them, and most note softwares dance around Obsidian. Having a latency on local clicks and transit…

I can't imagine anyone calling Obsidian sluggish. Do you perhaps have a lot of plugins?

Open sublime text side by side, and it will be obvious.

Re: Building a Slack/Discord alternative with Tauri/Rust

#244

Post by IIsi50MHz »

BiteCode_dev wrote: post #231
IceSentry wrote: post #229

Earlier quoted context omitted.

These things are all very subjective. Not everyone is affected the same way by latency. I hear people complaining about it all the time on thw internet, but in practice I never notice it and I don't know anyone that does either. Ergonomics is the same, I think discord is really nice to use and all the alternatives I've used have been worse. To be clear, your opinion is absolutely valid I just don't think they apply e…

It's probably a generational thing. 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.

This is true for me, as well. Whenever I start a 50 MHz computer and something is instantaneous instead of displaying a "Please wait…", or I start a modern computer with the Haiku operating system instead of Windows or Linux, I'm reminded just how responsive things can be.

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".

Re: Building a Slack/Discord alternative with Tauri/Rust

#245

Post by lelanthran »

mustache_kimono wrote: post #215
lelanthran wrote: post #147

Earlier quoted context omitted.

> 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 t…

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 afie…

> 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.

Re: Building a Slack/Discord alternative with Tauri/Rust

#246

Post by ezst »

mike_hearn wrote: post #204
ezst wrote: post #195

Earlier quoted context omitted.

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?

Haha, it's amusing that the history essays are one of the things you remember :) 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…

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 :)

Re: Building a Slack/Discord alternative with Tauri/Rust

#247

Post by palata »

crubier wrote: post #167
ohgodplsno wrote: post #163

Earlier quoted context omitted.

Slack is currently eating 600MB of my RAM, for something I check maybe once an hour. You know what I'd like to use my RAM for instead ? Gradle. kotlinc. intellij. Things that I actually use to do my work, and not a bad IRC that wants to make me pay for the privilege of seeing old messages. Electron is a demonstration of laziness and a living proof that software companies do not give a single shit about their users an…

> a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time. Exact opposite, to me Electron is the living proof that software companies correctly care a lot about building a product people want, and correctly realize that the large majority of people correctly do not care that one of their top productivity app uses $1 worth of RAM, bu…

You seem to believe that companies do what's best for their users. Not sure in which world you live: companies do what seems most profitable for them (and pray that it is).

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?

Re: Building a Slack/Discord alternative with Tauri/Rust

#248

Post by palata »

cinntaile wrote: post #181
ohgodplsno wrote: post #180

Earlier quoted context omitted.

Overprivileged HN-commenter believes that upgrading RAM is something that every user can afford, wants to afford (oh, I'm sorry, let me blow 50 bucks for your pretty eyes because you couldn't be arsed to not blast a whole javascript runtime on your app that you're forcing me to use to upgrade my drivers or launch a game), ignores physical limitations (unupgradable laptops, already maxed out configs from back in the d…

He's right though, most people really don't care about 600 MB of RAM or whatever.

Our whole industry is a big joke technically. On the business side, though, we managed to get people used to downloading huge apps, that run slow, and are full of bugs. That's admittedly a big business achievement, but not the kind of world I want to live in.

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.

Re: Building a Slack/Discord alternative with Tauri/Rust

#249

Post by palata »

josephg wrote: post #108
mustache_kimono wrote: post #69

Earlier quoted context omitted.

> 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 ridiculou…

> 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 k…

> 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).

Re: Building a Slack/Discord alternative with Tauri/Rust

#250

Post by crubier »

palata wrote: post #247
crubier wrote: post #167

Earlier quoted context omitted.

> a living proof that software companies do not give a single shit about their users and just want to push more crap, for cheaper, all the time. Exact opposite, to me Electron is the living proof that software companies correctly care a lot about building a product people want, and correctly realize that the large majority of people correctly do not care that one of their top productivity app uses $1 worth of RAM, bu…

You seem to believe that companies do what's best for their users. Not sure in which world you live: companies do what seems most profitable for them (and pray that it is). 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…

Couple reasons:

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.

Post reply on HN