20 ms·

Rust

321 points by cheeseblubber 3y ago

littlestymaar 3y ago
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.
paholg 3y ago
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 3y ago
  Thanks. We have mobile clients in the roadmap! There is a big refactor that we would need to do before getting there :)
  - paholg 3y ago
    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?
    - cheeseblubber 3y ago
      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
    - digging 3y ago
      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 3y ago
        Sorry forgot to update the FAQ. We shipped realtime Discord sync a few months ago Will update it now.
        vxNsr 3y ago
        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.
- jokowueu 3y ago
  Revolt is pretty great
paxys 3y ago
Discord alternative would be a better description, considering Slack isn't meant for communities but companies.
- paulddraper 3y ago
  I see it used for communities
  - palata 3y ago
    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
    - OJFord 3y ago
      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?)
      - palata 3y ago
        I don't think it's the same. Maybe "is meant for" is not the right wording, but the point is really that the model of Discord just works better for communities, because the server admin does not have to pay for the users (rather the users can contribute to the server).
      - paulddraper 3y ago
digging 3y ago
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 3y ago
  We do have private teams/communities. It is actually what we use internal for work. Mobile app is on the roadmap!
  - bravura 3y ago
    Mobile should be at the top of the roadmap, TBH. No mobile is a complete show-stopper. I think it's commendable to build a chat alternative that is snappy. But right now, it's basically going to be a sync-ed mirror with Slack for everyone. "It is actually kind of tricky to self host since there are quite a few services that needs set up and we could use quite a bit of work in our documentation." Uh... a second-degree showstopper for people looking for Slack alternatives. We have one-click deploys for rocket.chat and Zulip on digital ocean, vercel, render, etc. Where do you believe your adoption will come from? I ask this sincerely. What is the burning pain that will lead people to adopt linen right now? The whole "SEO" your community is such a red herring in my opinion. There are already many Discord, Slack, etc. bots that make public discussions readable and indexable. And LLM-integrated bots that automatically summarize discussions. Why not prioritize what's really needed in this space: a) Super easy self hosting. Make the devops/infra team happy. b) Super snappy chat clients on desktop AND mobile. Make the users much happier than the alternatives. c) API compatability with Slack, maybe also Zulip and rocket.chat. Make the devs happy and eat the lunch of your competitors by making it super easy to port apps to linen. (And, get SEO + autosummarization features for FREE)
sigg3 3y ago
> Building a slack alternative I've always thought slack was the alternative, to IRC.
- palata 3y ago
  Me too... Modern software piles up new stuff on top of new stuff. There is no time for the basics. /s
- awestroke 3y ago
  Isn't "alternative" commutative?
  - wakamoleguy 3y ago
    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 3y ago
      Amazon is also not necessarily an alternative to a local bookstore
- kachnuv_ocasek 3y ago
  IRC was originally an alternative to a BBS… You can keep piling this to no end.
  - nicce 3y ago
    Let’s not forget the Windows Live Messenger. I guess it was more like Discord alternative of that time.
sedatk 3y ago
> 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.
- awestroke 3y ago
  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
  - sedatk 3y ago
    That’s great to hear, thanks!
- bojo 3y ago
  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.
- mustache_kimono 3y ago
  > 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/ https://tauri.app/v1/references/benchmarks/
  - josephg 3y ago
    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.
palata 3y ago
> 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.
- cheeseblubber 3y ago
  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 3y ago
    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 3y ago
  Chromium or Tauri, you are still building platform specific binaries either way.
  - IshKebab 3y ago
    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).
renewiltord 3y ago
Just out of curiosity, is the server-side self-hostable? I want to just try it out.
- cheeseblubber 3y ago
  The code is here: https://github.com/linen-dev/linen.dev 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.
thewataccount 3y ago
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 3y ago
  The code is open source https://github.com/linen-dev/linen.dev https://github.com/linen-dev/linen.dev
alberth 3y ago
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 3y ago
  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 3y ago
    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).
    - ezst 3y ago
      Group chats work pretty well in my experience. The spec for MUC is rather large even though only a small portion of it is used in practice (the roles/ACL capabilities go way beyond that of other protocols, probably inheriting the requirements of large-scale government/corporate deployments). There were also some challenges early-on relating to mobile use-cases (e.g. how to notify/respond to a user who's not joined to the group chat because their client is offline), and XMPP has grown a set of extensions in that area (push notifications, stream resumption, …). > Other issue with XMPP is how hard it is to find clients that don't suck OK, but the alternative we are talking about here consists of developing the server, protocol and clients all at once and from scratch, and end-up with something that's merely a prototype heading into a decade worth of enhancement and scalability improvements, iteratively bumping into the exact same kind of problems. Wouldn't it be less effort to just make an XMPP client that doesn't suck and lead by example? (That's pretty much what the "Conversations" Android client did when it came out, and now it's used by the German government, among others). > I think I've seen at least 3 different ways clients implemented emojis, for example I'm not aware of anything like that. There are different ways to do certain things, like sending attachments (HTTP upload or client-to-client), but that's the good thing about XMPP: your client/server negotiate capabilities and sometimes even translate among them. I won't pretend that everything is rosy, for sure, but it also isn't that bad.
Solvency 3y ago
With Figma being so incredibly performant and robust as a web assembly app, why don't more apps turn to this approach instead?
- nosequel 3y ago
  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.
  - Solvency 3y ago
    True but doesn't Rust support WASM? Author is using Rust.
    - rtpg 3y ago
      The challenge is more in the stack. Building GUIs is tricky, and the web stack offers a lot of useful tools which make it a very good default choice from a “get shipped” perspective. Qt is nice but it sure feels like a big step back in velocity for me
- crabmusket 3y ago
  It's no silver bullet: https://zaplib.com/docs/blog_post_mortem.html https://zaplib.com/docs/blog_post_mortem.html
sreejithr 3y ago
[flagged]
- lolinder 3y ago
  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?
IceSentry 3y ago
The discord sync feature combined with it being google indexable does seem nice but is there a way to control what can be indexed? Some discord channels are somewhat private on purpose even if the entire server is public. So can you control which channels are indexable?
Sytten 3y ago
I build and ship a production application using tauri and linux support is the most painful experience I had in a long time. They use WebKit GTK which is really not a good fondation IMO, its hard to test for all versions, its much slower than other browser, it has weird bugs. In general the idea of not shipping a browser bundle is nice, in practice it doesn't really work for a startup. It's just too much unrelated testing and debugging work you need to do to support old outdated systems. We were very excited to use tauri since we are a rust shop, but we are strongly considering moving to electron unless we get a way to bundle a renderer.
- rickstanley 3y ago
  Thanks for sharing the experience. From time to time, I go to https://www.areweguiyet.com/ 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).
  - chrismorgan 3y ago
    But do note (given the context of this discussion) that Iced is completely unsuitable for the web. Early on it had an actual web renderer (iced_web), but they stopped maintaining it and it doesn’t work any more, so what you get if you use Iced on the web is the pure-canvas approach, which is fundamentally and irredeemably unsuitable for general-purpose web content and apps. (I’ve written about this a number of times here on HN; https://news.ycombinator.com/item?id=33861831 https://news.ycombinator.com/item?id=33861831 is one.) By all means use it on desktop platforms, but it won’t get you an acceptable web version.
- lifthrasiir 3y ago
  I have used Tauri (or more accurately, WRY) for Windows and macOS and it worked very great in my opinion. It still needed some tweaks to suit my needs, which was the main reason I didn't use Tauri proper, but I guess your issues are more related to the lack of well-known system web view in linux. It might make sense for Tauri to bundle the browser engine only for linux if this is a big concern.
the__alchemist 3y ago
I wish they'd used EGUI etc instead of another web UI. It's Rust; might as well leverage the performance.
- aguynamedben 3y ago
  YEEEESSSS I'm an Electron user for 6 years and Rust fanboy, but this is The Way™
raydiatian 3y ago
Core tenets, not tenants
Nellyz 3y ago
[dead]
Narishma 3y ago
> Mac - 4.17 MB > Windows - 4.13 MB > Linux - 73.8 MB One is not like the others.
- chrysoprace 3y ago
  This stood out to me too. The article doesn't seem to touch on it, but I assume they have to ship more binaries to account for the vast variety of setups on Linux.
- c-hendricks 3y ago
  Maybe this: > CAUTION > If your app plays audio/video ... This will increase the size of the AppImage bundle to include additional gstreamer files needed for media playback. https://tauri.app/v1/guides/building/linux/ https://tauri.app/v1/guides/building/linux/
quickthrower2 3y ago
My tip for the main product Linen: 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.
ChicagoDave 3y ago
Mattermost?
Minor49er 3y ago
Good. I've been looking for a Slack alternative 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
- manfre 3y ago
  That is my largest source of frustration with slack. It's an almost daily occurrence that results in me drafting longer messages in vscode.
- e12e 3y ago
  Fwiw, last time I looked, wee-slack was a decent improvement for slack text chat. These days maybe a matrix bridge? https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack
  - Minor49er 3y ago
    This looks great. I will check this out. Thank you!
- LuisAPI 3y ago
  This is very much the same issue I have with the message input box on the Threads feature of Discord. It works on "normal" messages (those outside the forums feature) but if it's in those, the home key sends the cursor straight to the very start.
shanghaikid 3y ago
Regarding the development & deployment speed, electron is still the king. it is just a little bit bigger.
andsoitis 3y ago
Unsolicited Advice: instead of building an alternative that is mostly similar from an end-user perspective, think more deeply about communication within organizations. Followers copy and extend. Innovators lead the way to a new vista.
meling 3y ago
Unrelated question. Anyone know if it would be difficult to write a SwiftUI “compiler” to non-Mac architectures, including wasm? (I’m not a ui developer). I mean, I realize it is probably non-trivial, like most cross-platform ui, but I have been imagining that Apple would do this since they released it, so that their webapps could be written in SwiftUI instead of whatever they are doing now…
- mdasen 3y ago
  Yes, it would be difficult. Certainly not impossible, but difficult. Microsoft has their MAUI project (Multi-platform App UI). It lets you write programs in C# and compile for Windows, macOS, Android, and iOS. AvaloniaUI and Uno Platform are other C# options. Flutter exists for Dart. Compose Multiplatform exists for Kotlin. React Native exists. All that said, they all have drawbacks/issues. Flutter means ignoring the platform and just drawing things using Skia so Flutter apps feel like Flutter apps, not platform specific apps. Compose Multiplatform is only an alpha for iOS and it's also just drawing on a canvas (though you can break out of that and program specific stuff in iOS's UIKit). Avalonia is Skia and from what I've heard the iOS/Android support is poor compared to desktop OSs. Uno is mostly Skia with some platform-specific widgets, but their desktop support is poor compared to their mobile and WASM support. MAUI is the only one that's really targeting native widgets on macOS, Windows, iOS, and Android. It seems like it's been a bit of a hard journey for Microsoft there, but it seems to be getting pretty decent in the latest betas (especially if you're using things like the CommunityToolkit MVVM and Markup extensions). So, it's hard. It's taken many great companies many years to create ok cross platform toolkits. None are really amazing. I think another thing holding stuff back is WASM. WASM will be getting a lot better, but it's not amazing for UI stuff right now because it means overhead communicating between WASM and JS (and a lot of copying). WASM also isn't great for garbage collected languages at the moment since the language has to ship its garbage collector. This will be changing in the future as WASM gets GC support. Swift's reference counts don't require the same overhead so it might not have that pitfall, but WASM is still usually for things that require lots of calculation compared to the UI work at the moment. I don't know how much code reuse there would be between SwiftUI and the web if they did create such a compiler. Maybe there's value in using SwiftUI instead of React or whatever on the web. I don't really know. I think Apple is unlikely to be the company that really pursues a cross-platform toolkit. They want people in their ecosystem and they know that a lot of developers target iOS first. I guess it really depends on the value Apple would get out of it. Companies have spent a lot of time trying to make cross-platform UI kits over decades and there have been a lot of failures (or successes that don't really seem like successes given a lack of popular adoption). PhoneGap was an early iOS/Android one. RubyMotion has been around since 2012. Java was probably the original "write once, run anywhere with a GUI" language. Tcl/Tk has been around for ages. Qt has been around for a long time. It seems like an area where companies pour money and don't get amazing results. I'm not arguing that the results aren't worth it sometimes to have a single codebase. However, I haven't seen one of these toolkits take over the world despite the clear benefits of writing code once. That doesn't mean that the perfect thing can't be done, but it does make it seem like the difficulty is up there to make something really great. For Apple, it's probably just not worth it. Most of their web stuff is different enough to what they'd be running on devices that they might not get a ton of value out of it for the difficulty involved. Plus, Apple isn't really looking to support Android, Windows, or Linux.
Brenda900 3y ago
[dead]
lelanthran 3y ago
I see all these "Alternative to $FOO" type projects that differ in the implementation but not in the result; IOW to the end-user the product looks and behaves practically the same as $FOO. 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. [2] https://www.linen.dev/ https://www.linen.dev/ [3] Managing conversation threads in IM is not a problem I've heard anyone complain about, TBH.
- keyle 3y ago
  Linen is significantly cheaper than Slack $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.
  - lelanthran 3y ago
    > $10/month for up to 100 users compared to Slack's $7.25/user/month. > 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.
pjmlp 3y ago
Really, if it uses Web techonology, target the browser(s) I already have installed. This coming from someone that has mostly done Web stuff in the last 20 years.
luckyshot 3y ago
I understand this is more tailored at communities and such (being the Business plan the last in the tier), but for Linen to be a Slack alternative we'd need App integrations (Google Calendar, Jira, etc) as well as other features such as to send scheduled messages, snooze/bookmark incoming messages for later, a strong channel administration/management, and a few other features that increase productivity and we can't live without. 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!
max_streese 3y ago
Is it just me or do others find the Electron bashing a little over the top as well? 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.
- ohgodplsno 3y ago
  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 and just want to push more crap, for cheaper, all the time.
  - crubier 3y ago
    > 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, 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
    - palata 3y ago
      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?
deleted 3y ago
[deleted]
petabytes 3y ago
Main thing that bothers me with electron is RAM usage (300mb I think?). And when I tested a WebView/tauri demo, RAM usage ended up being about the same since it had to load webkit.

321 points by cheeseblubber 3y ago

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.

paholg 3y ago

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 3y ago
Thanks. We have mobile clients in the roadmap! There is a big refactor that we would need to do before getting there :)
- paholg 3y ago
  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?
  - cheeseblubber 3y ago
    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
  - digging 3y ago
    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 3y ago
      Sorry forgot to update the FAQ. We shipped realtime Discord sync a few months ago Will update it now.
      - vxNsr 3y ago
        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.
jokowueu 3y ago
Revolt is pretty great

paxys 3y ago

Discord alternative would be a better description, considering Slack isn't meant for communities but companies.

paulddraper 3y ago
I see it used for communities
- palata 3y ago
  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
  - OJFord 3y ago
    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?)
    - palata 3y ago
      I don't think it's the same. Maybe "is meant for" is not the right wording, but the point is really that the model of Discord just works better for communities, because the server admin does not have to pay for the users (rather the users can contribute to the server).
    - paulddraper 3y ago

digging 3y ago

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 3y ago
We do have private teams/communities. It is actually what we use internal for work. Mobile app is on the roadmap!
- bravura 3y ago
  Mobile should be at the top of the roadmap, TBH. No mobile is a complete show-stopper. I think it's commendable to build a chat alternative that is snappy. But right now, it's basically going to be a sync-ed mirror with Slack for everyone. "It is actually kind of tricky to self host since there are quite a few services that needs set up and we could use quite a bit of work in our documentation." Uh... a second-degree showstopper for people looking for Slack alternatives. We have one-click deploys for rocket.chat and Zulip on digital ocean, vercel, render, etc. Where do you believe your adoption will come from? I ask this sincerely. What is the burning pain that will lead people to adopt linen right now? The whole "SEO" your community is such a red herring in my opinion. There are already many Discord, Slack, etc. bots that make public discussions readable and indexable. And LLM-integrated bots that automatically summarize discussions. Why not prioritize what's really needed in this space: a) Super easy self hosting. Make the devops/infra team happy. b) Super snappy chat clients on desktop AND mobile. Make the users much happier than the alternatives. c) API compatability with Slack, maybe also Zulip and rocket.chat. Make the devs happy and eat the lunch of your competitors by making it super easy to port apps to linen. (And, get SEO + autosummarization features for FREE)

sigg3 3y ago

> Building a slack alternative I've always thought slack was the alternative, to IRC.

palata 3y ago
Me too... Modern software piles up new stuff on top of new stuff. There is no time for the basics. /s
awestroke 3y ago
Isn't "alternative" commutative?
- wakamoleguy 3y ago
  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 3y ago
    Amazon is also not necessarily an alternative to a local bookstore
kachnuv_ocasek 3y ago
IRC was originally an alternative to a BBS… You can keep piling this to no end.
- nicce 3y ago
  Let’s not forget the Windows Live Messenger. I guess it was more like Discord alternative of that time.

sedatk 3y ago

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

awestroke 3y ago
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
- sedatk 3y ago
  That’s great to hear, thanks!
bojo 3y ago
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.
mustache_kimono 3y ago
> 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/ https://tauri.app/v1/references/benchmarks/
- josephg 3y ago
  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.

palata 3y ago

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

cheeseblubber 3y ago
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 3y ago
  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 3y ago
Chromium or Tauri, you are still building platform specific binaries either way.
- IshKebab 3y ago
  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).

renewiltord 3y ago

Just out of curiosity, is the server-side self-hostable? I want to just try it out.

cheeseblubber 3y ago
The code is here: https://github.com/linen-dev/linen.dev 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.

thewataccount 3y ago

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 3y ago
The code is open source https://github.com/linen-dev/linen.dev https://github.com/linen-dev/linen.dev

alberth 3y ago

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 3y ago
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 3y ago
  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).
  - ezst 3y ago
    Group chats work pretty well in my experience. The spec for MUC is rather large even though only a small portion of it is used in practice (the roles/ACL capabilities go way beyond that of other protocols, probably inheriting the requirements of large-scale government/corporate deployments). There were also some challenges early-on relating to mobile use-cases (e.g. how to notify/respond to a user who's not joined to the group chat because their client is offline), and XMPP has grown a set of extensions in that area (push notifications, stream resumption, …). > Other issue with XMPP is how hard it is to find clients that don't suck OK, but the alternative we are talking about here consists of developing the server, protocol and clients all at once and from scratch, and end-up with something that's merely a prototype heading into a decade worth of enhancement and scalability improvements, iteratively bumping into the exact same kind of problems. Wouldn't it be less effort to just make an XMPP client that doesn't suck and lead by example? (That's pretty much what the "Conversations" Android client did when it came out, and now it's used by the German government, among others). > I think I've seen at least 3 different ways clients implemented emojis, for example I'm not aware of anything like that. There are different ways to do certain things, like sending attachments (HTTP upload or client-to-client), but that's the good thing about XMPP: your client/server negotiate capabilities and sometimes even translate among them. I won't pretend that everything is rosy, for sure, but it also isn't that bad.

Solvency 3y ago

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

nosequel 3y ago
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.
- Solvency 3y ago
  True but doesn't Rust support WASM? Author is using Rust.
  - rtpg 3y ago
    The challenge is more in the stack. Building GUIs is tricky, and the web stack offers a lot of useful tools which make it a very good default choice from a “get shipped” perspective. Qt is nice but it sure feels like a big step back in velocity for me
crabmusket 3y ago
It's no silver bullet: https://zaplib.com/docs/blog_post_mortem.html https://zaplib.com/docs/blog_post_mortem.html

sreejithr 3y ago

[flagged]

lolinder 3y ago
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?

IceSentry 3y ago

The discord sync feature combined with it being google indexable does seem nice but is there a way to control what can be indexed? Some discord channels are somewhat private on purpose even if the entire server is public. So can you control which channels are indexable?

Sytten 3y ago

I build and ship a production application using tauri and linux support is the most painful experience I had in a long time. They use WebKit GTK which is really not a good fondation IMO, its hard to test for all versions, its much slower than other browser, it has weird bugs. In general the idea of not shipping a browser bundle is nice, in practice it doesn't really work for a startup. It's just too much unrelated testing and debugging work you need to do to support old outdated systems. We were very excited to use tauri since we are a rust shop, but we are strongly considering moving to electron unless we get a way to bundle a renderer.

rickstanley 3y ago
Thanks for sharing the experience. From time to time, I go to https://www.areweguiyet.com/ 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).
- chrismorgan 3y ago
  But do note (given the context of this discussion) that Iced is completely unsuitable for the web. Early on it had an actual web renderer (iced_web), but they stopped maintaining it and it doesn’t work any more, so what you get if you use Iced on the web is the pure-canvas approach, which is fundamentally and irredeemably unsuitable for general-purpose web content and apps. (I’ve written about this a number of times here on HN; https://news.ycombinator.com/item?id=33861831 https://news.ycombinator.com/item?id=33861831 is one.) By all means use it on desktop platforms, but it won’t get you an acceptable web version.
lifthrasiir 3y ago
I have used Tauri (or more accurately, WRY) for Windows and macOS and it worked very great in my opinion. It still needed some tweaks to suit my needs, which was the main reason I didn't use Tauri proper, but I guess your issues are more related to the lack of well-known system web view in linux. It might make sense for Tauri to bundle the browser engine only for linux if this is a big concern.

the__alchemist 3y ago

I wish they'd used EGUI etc instead of another web UI. It's Rust; might as well leverage the performance.

aguynamedben 3y ago
YEEEESSSS I'm an Electron user for 6 years and Rust fanboy, but this is The Way™

raydiatian 3y ago

Core tenets, not tenants

Nellyz 3y ago

[dead]

Narishma 3y ago

> Mac - 4.17 MB > Windows - 4.13 MB > Linux - 73.8 MB One is not like the others.

chrysoprace 3y ago
This stood out to me too. The article doesn't seem to touch on it, but I assume they have to ship more binaries to account for the vast variety of setups on Linux.
c-hendricks 3y ago
Maybe this: > CAUTION > If your app plays audio/video ... This will increase the size of the AppImage bundle to include additional gstreamer files needed for media playback. https://tauri.app/v1/guides/building/linux/ https://tauri.app/v1/guides/building/linux/

quickthrower2 3y ago

My tip for the main product Linen: 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.

ChicagoDave 3y ago

Mattermost?

Minor49er 3y ago

Good. I've been looking for a Slack alternative 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

manfre 3y ago
That is my largest source of frustration with slack. It's an almost daily occurrence that results in me drafting longer messages in vscode.
e12e 3y ago
Fwiw, last time I looked, wee-slack was a decent improvement for slack text chat. These days maybe a matrix bridge? https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack
- Minor49er 3y ago
  This looks great. I will check this out. Thank you!
LuisAPI 3y ago
This is very much the same issue I have with the message input box on the Threads feature of Discord. It works on "normal" messages (those outside the forums feature) but if it's in those, the home key sends the cursor straight to the very start.

shanghaikid 3y ago

Regarding the development & deployment speed, electron is still the king. it is just a little bit bigger.

andsoitis 3y ago

Unsolicited Advice: instead of building an alternative that is mostly similar from an end-user perspective, think more deeply about communication within organizations. Followers copy and extend. Innovators lead the way to a new vista.

meling 3y ago

Unrelated question. Anyone know if it would be difficult to write a SwiftUI “compiler” to non-Mac architectures, including wasm? (I’m not a ui developer). I mean, I realize it is probably non-trivial, like most cross-platform ui, but I have been imagining that Apple would do this since they released it, so that their webapps could be written in SwiftUI instead of whatever they are doing now…

mdasen 3y ago
Yes, it would be difficult. Certainly not impossible, but difficult. Microsoft has their MAUI project (Multi-platform App UI). It lets you write programs in C# and compile for Windows, macOS, Android, and iOS. AvaloniaUI and Uno Platform are other C# options. Flutter exists for Dart. Compose Multiplatform exists for Kotlin. React Native exists. All that said, they all have drawbacks/issues. Flutter means ignoring the platform and just drawing things using Skia so Flutter apps feel like Flutter apps, not platform specific apps. Compose Multiplatform is only an alpha for iOS and it's also just drawing on a canvas (though you can break out of that and program specific stuff in iOS's UIKit). Avalonia is Skia and from what I've heard the iOS/Android support is poor compared to desktop OSs. Uno is mostly Skia with some platform-specific widgets, but their desktop support is poor compared to their mobile and WASM support. MAUI is the only one that's really targeting native widgets on macOS, Windows, iOS, and Android. It seems like it's been a bit of a hard journey for Microsoft there, but it seems to be getting pretty decent in the latest betas (especially if you're using things like the CommunityToolkit MVVM and Markup extensions). So, it's hard. It's taken many great companies many years to create ok cross platform toolkits. None are really amazing. I think another thing holding stuff back is WASM. WASM will be getting a lot better, but it's not amazing for UI stuff right now because it means overhead communicating between WASM and JS (and a lot of copying). WASM also isn't great for garbage collected languages at the moment since the language has to ship its garbage collector. This will be changing in the future as WASM gets GC support. Swift's reference counts don't require the same overhead so it might not have that pitfall, but WASM is still usually for things that require lots of calculation compared to the UI work at the moment. I don't know how much code reuse there would be between SwiftUI and the web if they did create such a compiler. Maybe there's value in using SwiftUI instead of React or whatever on the web. I don't really know. I think Apple is unlikely to be the company that really pursues a cross-platform toolkit. They want people in their ecosystem and they know that a lot of developers target iOS first. I guess it really depends on the value Apple would get out of it. Companies have spent a lot of time trying to make cross-platform UI kits over decades and there have been a lot of failures (or successes that don't really seem like successes given a lack of popular adoption). PhoneGap was an early iOS/Android one. RubyMotion has been around since 2012. Java was probably the original "write once, run anywhere with a GUI" language. Tcl/Tk has been around for ages. Qt has been around for a long time. It seems like an area where companies pour money and don't get amazing results. I'm not arguing that the results aren't worth it sometimes to have a single codebase. However, I haven't seen one of these toolkits take over the world despite the clear benefits of writing code once. That doesn't mean that the perfect thing can't be done, but it does make it seem like the difficulty is up there to make something really great. For Apple, it's probably just not worth it. Most of their web stuff is different enough to what they'd be running on devices that they might not get a ton of value out of it for the difficulty involved. Plus, Apple isn't really looking to support Android, Windows, or Linux.

Brenda900 3y ago

[dead]

lelanthran 3y ago

I see all these "Alternative to $FOO" type projects that differ in the implementation but not in the result; IOW to the end-user the product looks and behaves practically the same as $FOO. 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. [2] https://www.linen.dev/ https://www.linen.dev/ [3] Managing conversation threads in IM is not a problem I've heard anyone complain about, TBH.

keyle 3y ago
Linen is significantly cheaper than Slack $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.
- lelanthran 3y ago
  > $10/month for up to 100 users compared to Slack's $7.25/user/month. > 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.

pjmlp 3y ago

Really, if it uses Web techonology, target the browser(s) I already have installed. This coming from someone that has mostly done Web stuff in the last 20 years.

luckyshot 3y ago

I understand this is more tailored at communities and such (being the Business plan the last in the tier), but for Linen to be a Slack alternative we'd need App integrations (Google Calendar, Jira, etc) as well as other features such as to send scheduled messages, snooze/bookmark incoming messages for later, a strong channel administration/management, and a few other features that increase productivity and we can't live without. 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!

max_streese 3y ago

Is it just me or do others find the Electron bashing a little over the top as well? 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.

ohgodplsno 3y ago
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 and just want to push more crap, for cheaper, all the time.
- crubier 3y ago
  > 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, 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
  - palata 3y ago
    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?

deleted 3y ago

[deleted]

petabytes 3y ago

Main thing that bothers me with electron is RAM usage (300mb I think?). And when I tested a WebView/tauri demo, RAM usage ended up being about the same since it had to load webkit.