Live data from Hacker News

Building a Slack/Discord alternative with Tauri/Rust

linen.dev

71–80 of 253 posts

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

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

If you offer developers the choice of either embedding a whole web browser and not dealing with platform differences, or not embedding a whole web browser and dealing with differences between the now-evergreen browser engines on each major platform, many may pick the latter to be more user-friendly. I certainly would.

But as long as you’re maintaining a webapp anyways, you still have to do all that browser support. Using tauri doesn’t make it worse than a webapp that only runs in a browser context.

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

#73
post #36

Earlier quoted context omitted.

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

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.

So your suggestion to avoid shipping chromium is to ship java instead?

Aren't you just replacing one VM for another?

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

#74
post #52
post #35

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.

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…

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

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

#75
post #52
post #35

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.

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…

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.

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

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

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.

You mean the former?

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

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

Yes we have 15k users

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

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

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

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

#79

With Figma being so incredibly performant and robust as a web assembly app, why don't more apps turn to this approach instead?

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.

True but doesn't Rust support WASM? Author is using Rust.

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

#80
post #75
post #52

Earlier quoted context omitted.

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…

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

Such a subset exists already: https://xmpp.org/about/compliance-suites/
Post reply on HN