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.
Most electron apps are (mostly but not solely) a bundling of the web-app.
So the cost is less the cost of "switching" and more the cost of initially writing a native app.
In turn the actual question is how to reuse as much code as possible between the web-app and native apps without it introducing a lot of friction.
And one of the few reliable, nicely (developer) usable answers for this is currently electron.
For "business logic" there somewhat are already other answers, some languages run on most targets reliable and there is also wasm which often still needs a bit more tooling but has a lot of potential for such use cases (e.g. see Disney which AFIK does have their core business logic compiled to a wasm blob and then "only" provide UI/system glue to bundle it in on all platforms their streaming app runs on).
The problem is UI, you really don't want to reimplement UI and the mapping of non HTML/CSS producing UI to a mix of HTML/CSS on some platforms and native components on other often doesn't work grate so it's not surprising people decided to "just go with HTML/CSS everywhere". And if you are already there going with electron isn't "that" much more overhead.
This right here. Something monumental would have to happen for senior leadership to green light a rewrite, because that’s a massive project that will bring in no additional revenue.
The massive advantage of Electron is write once -- with some extra overhead, perhaps 40% effort -- and you can ship the same app to web, mac, windows, ios, android, and linux.
MS seems to be using electron in the worst possible way.
I mean it's basically running an outdated version of the web version bundled into a even more absurdly outdated version of electron.
Given how bad the decision is it really looks like it's just for ticking of some checkbox and avoiding claims that MS is intentionally hurting other desktop system... but honestly the way they did it makes it look even more like that.
Through there are technical reasons AFIK:
- it seems to be that they have some custom native "call/video/screen-capture" code, which doesn't seem to provide any sustainable benefits but is less reliable in my experience.
- (speculative) for some time in the not that distant past (Chrome <v110) on Wayland desktops for screen sharing Chrome did only support an older experimental version of the protocol, locked behind an experimental flag. Through most distros set up pipewire in a way where the old protocol was still supported (on the fly converted) and even through the chrome flag was experimental it did work very reliable. So re-implementing pipewire support by hand would have been quite of an bad decision I hope Teams didn't do.
Can't speak about other OSes but that is the case for me on linux.
And I hace seen quite a few people on windows who literally has to reboot because teams app was working erratically or was freezing and no amount of stopping/restarting the app would help.
Webviews are built on weakly, dynamically typed languages, which naturally have development speed advantage over statically typed languages in the happy path. On top of that you have multitude of frameworks even more optimized for the happy path. It is much faster to create an MVP of a GUI with web technologies.
Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch. Web, desktop, mobile. Almost one codebase can be used for all three.
Could you do the same with say, Java (and maybe soon with .NET)? Maybe. But web has a lower barrier for entry and faster speed of development cycle. Not to mention larger pool of developers available.
All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. And once you get going, it is really hard to pivot your technology stack to something else.
> Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch.
With an exception of web there are very solid GUI cross-platform (linux, windows, mac) frameworks out there. Qt is even pretty good at targeting native look.
> All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost.
Yes, web technologies let you build MVPs faster, that's literally in my original comment. However, in order to provide quick MVPs these technologies inherently sacrifice long term maintainability.
QT is just gonna be untenable for most people. Learning C++ is hard enough, but learning QT is basically a different dialect of C++, and I can't even say it's worth the investment.
Well, s/Electron/WebUI generally, the conclusion that I came to last year was beyond Qt there really isn't a decent cross platform UI toolkit out there that really handles all the nitty gritty details like accessibility, proper GPU acceleration, etc. And Qt comes with its own normative lifestyle assumptions. And there is this huge community of HTML/JS/TypeScript developers and a pile of UI frameworks for them.
So if you're looking to build a cross platform desktop application, you want to also be able to service it on web, and you want to be able to hire beyond the limited Qt/C++ talent pool, it just makes sense.
I 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.
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 is one.)
By all means use it on desktop platforms, but it won’t get you an acceptable web version.
WebKit is five loosely related browser engines in a trench coat. A lot of the code is "platform" specific, and most of the optimization happens in that layer. Apple's Cocoa webkit is a lot more polished than WebkitGTK could ever hope to be with its meagre dev resources.
I think you might be confusing an OS web view - which is what Tauri uses - with WebKit, which is the web view on Apple operating systems. It’s the way to get Safari inside your app if you are on an Apple device. On Linux, there is no WebKit, the web view will be your system browser. That might not be very fast.
Most of the Electron junk can be easily done as pure Web application, of course authors don't want to pay for hosting and ship a browser and server with the application.
There are a very tiny percentage of such startup ideas that really need features not available on a standard Web browser.
Now that at least Windows, Chrome OS, and soon macOS properly support PWAs it will finally get feasible to add web apps to your desktop environment. I know I’ll upgrade to the new macOS ASAP just to get rid of slack.
Yes because electron comes with its own distinct instance of chrome (usually an outdated version) for each individual app, introducing massive overhead versus running on the OS provided browser engine.
It will still be a browser and a modern "app" done by people who think guis should refresh at 120 fps instead of just when something changed on screen...
I tried this same approach (embedded webview instead of e.g. electron -- https://github.com/rdaum/vstwebview) for something last year and I agree the biggest problem is Linux support, specifically WebKit GTK.
On Windows, and to a lesser degree on the Mac, this approach actually went pretty smoothly. But WebKit GTK introduces all sorts of problems -- having to tie into GTK's event loop even though you don't want it, dealing with distribution variances, event binding issues, etc.
I suspect the answer here for Tauri is that someone needs to expend the effort to come up with a good Rust crate bundling of Chromium or Gecko or etc that isn't tied into GTK. Yes, it would defeat the "just use the platform's webview instead of bundling" line, but really it would only be a concern for Linux.
> 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.
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 will say that my dev cycle builds (full clean and rebuild) take about 20s, which is nice. That nets me a “runnable fat jar”. Running the packager for the platform installers takes longer on top of that, but that’s not part of my dev cycle.
I dev on macOS, I have “tested” on Ubuntu and Windows, and the app works. My buttons button, cut and paste works, drag and drop (I can drag one of my generated images and drop it into, say, Word) works, I can generate PDFs via the “print to PDF” features of the platforms, including my custom fonts. I also have, like, 10 lines of code that uses JavaFX 3D — and that works.
It all works, and so far, knock on wood, the “cross platform” parts are doing what they’re supposed to do.
All that said, germane to the overall topic, there’s this funny little tidbit. In my app, all my bundled documentation is simply in HTML using bundled pages. And I show that in a JavaFX WebView. And WebView is built on WebKit. So in the end, if you need any HTML in your app, you bundle WebKit anyway.
Of course, if you don’t, WebView is in its own module that you don’t have to ship if you don’t need it.
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.
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.
Don't JetBrains just ship with their JRE and always ignore any "system" JRE? That feels like the correct solution, at least once your app gets to a certain size so the size of the JRE can be ignored. Also JetBrains' apps look good enough I'd say.
Another pretty one with a java frontend is BitWig. That's perhaps more impressive than any JetBrains app.
IntelliJ can have its own dependency hell, don't worry. Not so often but it happens.
Last time I upgraded an old install i wasn't using, it pulled its own JRE, then pulled a new gradle which promptly complained about the JRE Android Studio installed itself.
Had to do some googling and force it to use a JRE that both the IDE and gradle liked.
But as I said, that doesn't happen often. It's just funny when it does, in a masochistic sort of way.
> Its also really rare for a desktop app written in java to look good.
Java/JVM as platform suffers from trying to be all encompassing "second OS". Want to do time, fonts, cacerts? JVM does its own thing. Want to do UIs? Hey, there are widgets from 90s, should be good.
A lot of modern consumer and business oriented GUI apps run on JVMs and they look very platform native too. In finance, I’ve come across many of them. You can take a look at the upstream demo apps for Swing with FlatLaf and for JavaFX (rebranded to OpenFX). They perform nicely. I’ve been struggling with the JetBrains tools’ performance on large JVM projects but given the complexity and reindexing it’s justified, Visual Studio would simply hang indefinitely on such code bases, VS Code just doesn’t do this much.
Then there’s also Kotlin Multiplatform and Jetpack Compose, and now Compose Multiplatform (desktop, mobile, web including JS and WASM). Their DSL is really amazing, truly compositional and resembling the way you do React. To me that’s the path cross-platform GUI will be taking now.
On the .NET side, there’s Avalonia UI and Uno Platform as cross-platform alternatives, with Avalonia UI v11 (pending release) even doing mobile on almost the same code base.
> 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?
Does anyone actually build new desktop software for mainstream consumers these days?
JVM UI is "good enough", I've seen it used for businessey tools where the point is the functionality rather than the polish (including hobby tools). Honestly it may well be the best non-electron option once you think about the whole stack; with Qt you have to either write C++ and deal with that, or use the Python bindings and deal with that.
I've got Notion, Spotify, the app for my insta360, Slack, linear, Final Cut, and VS Code open right now. As best as I can tell, half are Electron and zero are JVM.
While Fleet is still a JVM app at it's core, it's true that it apparently no longer uses Swing for the UI components. Instead they seem to have reinvented that wheel with their own UI component library called Noria (also JVM) and render it to the screen with Skia (a native 2D graphics library - non JVM).
JavaFX/OpenFX is surprisingly decent these days, but it got suckerpunched by Oracle licensing for a long time and had a bunch of compatibility issues between releases that made upgrading painful.
I probably would consider it now for a new project, but not 5-10 years ago, when dev cycles for now-popular apps would've started realistically.
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.
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.
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.
IMO native widgets are dead. Users have become accustomed to the graphical gimmicks that are easy with a full-blown browser rendering engine.
Even a resizable background image is really hard to do with pure native widgets.
This means cross-platform libraries that wrap native widgets are dead as well. Now you need to ship your own rendering engine, and suddenly an entire browser looks reasonable. E.g. JavaFX isn't a featherweight either...
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.
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.
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?
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.
Or why not use Flutter? You can integrate with Rust as FFI via flutter_rust_bridge. That's what I do as Flutter is pretty cross platform yet much leaner than even using a browser engine.
A good idea. I think Flutter loses quite badly to React for web apps. But if you want to build a cross-platform app it works well. Dart is similar to Javascript and not difficult to pick up.
> Tauri wants to be less bloated, and therefore removes Chromium. Which makes it... not so cross-platform, apparently.
It's certainly cross-platform. Name a current OS that doesn't have one WebKit-forked webview or another available at all times. If you don't like Apple's insistence on only baseline WebKit out of the box, there's Microsoft's WebView2 which ships a known Chromium to every major desktop OS.
But really, if you are a web developer complaining about the differences between WebKit and Chromium, you may be spoiled. If you are a web developer complaining that you can't package a specific Chromium version (which is the real Electron benefit, not just that it packages its own Chromium but that every Electron app can pick and choose down to the exact Chromium version they want to ship), you've gone beyond spoiled to basically distrusting how the web platform is supposed to work.
(That's before you get to the other monoculture assumptions that no modern OS is instead shipping something like Firefox as the system default webview in 2023. It's all one tiny family tree with WebKit as the trunk.)
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.
No, I mean the latter: picking "not embedding a whole web browser" is worth it for the user-friendliness, even though it means having to deal with those browser differences, which have grown a lot less onerous than they used to be.
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).
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.
At some point you need to ship the runtime, right? Even native (Go, Rust, C++, …), depending on how you do the linking. What would make it more acceptable in this case is that you would strip down the JVM and only ship the modules depended upon (whereas Chromium is a monolith) when using jlink, and on top of that, native-image does some PGO, inlining and dead-code elimination AFAICT.
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.
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:
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.
JavaFX supports a WebKit based WebView widget, but it's optional. If you don't use it it's not bundled. If you do then you pay the cost of including the WebKit build which is ~80mb.
In practice the need for WebKit is going down over time. For basic rich text you can render Markdown to JavaFX nodes directly, for more advanced stuff you could transform [X]HTML to FXML, you don't need it for video or audio, there's a native rich text / word processor control these days, and if you can do 3D graphics with a high level scene graph (meshes, lights etc) then you don't need HTML for 3D either.
Still, it's often useful and bandwidth/disk space isn't the problem it once was.
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?
We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way. There's also someone in our Discord who has been trying it with Compose apps.
If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:
For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff. OTOH if you don't care about that, it'd be (imo) easier and more direct to not use HTML. Proper GUI toolkits give you a lot of stuff out of the box like virtualized list views which HTML still doesn't; useful for scrolling over huge datasets like chat logs.
I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.
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 :)
TIL, I haven't been using Java-based software for a long time (and I still have vivid memories of having to install the correct version of the JDK before installing one).
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.
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 transitions is not my idea of fun.
VSCode is an outlier here. And it's getting slower and slower with age, while sublime text is getting faster.
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 equally to everyone.
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".
Discord is not working "perfectly fine" on desktop for many people. Usually, the browser version is faster, needs less resources, has fewer platform integration problems (mic/camera access etc.), and crashes less often. And has less critical security vulnerabilities, as a browser gets patched much faster than Electron in general, and Discord in particular (who tend to be on an older branch, due to some native C++ libraries, that as far as I can tell have no user-visible impact).
And VSCode has to be contrasted with Atom, which is the same but in so much worse: It takes a lot of effort to make Electron work well.
I maintain an open-source app built with Electron. It serves tens of thousands of users every months and nobody complained in 5 years that it is being built with Electron. Not saying that Electron is perfect, and that it couldn't be a bit more performant, but as a solo maintainer (and entrepreneur) it helps me ship something that save people time. The burden of maintaining an application is already huge. Having to juggle with multiple environments would be a hassle and I definitely wouldn't do it.
That being said, if a "drop-in" alternative would be available I would probably try to switch at one point. But the alternative would have to be on par with the ecosystem (including packaging, binaries signing, etc.), the community, the ease of use... I don't think there is such a thing yet.
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.
> 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
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 day).
Today's software runs worse on modern hardware than yesterday's does, because you "let the engineers focus on UX and features" without teaching them to care for a single moment about _actual_ user experience instead of whatever bullshit their product owner put out.
Talk to any real engineer and not the US bullcrap of "oh sure everyone out of a code camp is an engineer" and ask them if quadrupling the weight of a bridge and multiplying resource consumption by ten is an option. You are making our profession look like fucking clowns.
> most people really don't care about 600 MB of RAM
There’s a difference between not caring that your computer is sluggish because of its programs, and not being able to tell the difference and demand less sluggish alternatives.
Normies put up with poor user experiences to the exact degree that software engineers deliver them.
That my UI should be significantly slower than my screen’s framerate is a false premise.
Go ask your parents if they're not pissed off that the laptop they bought for cheap is now struggling to run Peggle Deluxe and they don't understand why, while there's 7 Electron apps running in the background eating all that memory.
People don't care about 600MB. They care about how using their PC feels, and Electron is a massive contributor to it feeling like shit.
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.
>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 large majority of people care about programs that run fast and feel snappy, programs that don't look like some high school dropout's modern art project, programs that don't demand a pocket supercomputer to bankrupt you, programs that just get shit done because computers are just a god damn appliance comparable to a toaster from Walmart.
Apple charges $200 for 8GB additional RAM. So the cost of 600MB of Apple RAM in $15. That's the cost of 1 month of a subscription to Slack. You're likely to use your laptop for ~4years = 50months, so the RAM cost of Slack is around 2% of overall Slack cost, even on Apple hardware.
Users pay 2% more to get more RAM, Slack developers have 200% productivity thanks to not having to deal with low-level optimization crap, and can focus on building features and UX.
That's how the world works. But some angry HNers can't wrap their heads around it
The thing is that slack developers are not the only ones that think that way.
So now people lose some percentage to their mail client, their chat client, their ide,...
A bit more ram for developer comfort, a bit more processing power, a bit more to download,...
Additionally at the end of the day some people do interact with non developers and realize they tend to have less beefy devices.
Being the tech support in the family can be interesting because of that front. For example when I'm asked what's causing my fathers or grandparents relatively new laptop to be so laggy despite how much better it is than the predecessor and finding out there's no happy answer for that. There's no explaining that some software regressed on this front and they should just accept more electronic waste.
No, the cost of 600MB of RAM is $200. You just end up having bonus to waste on more electron apps.
This whole "this is how the world works" bullshit is post-hoc rationalisation done by wealthy idiots trying to justify their purchase by saying "it's just 5 cents a day if you consider it'll last ten years". This is bullshit and only applies if the purchase you're making is insignificant to you. So, congrats, $200 is insignificant to you. It's not, for most of the world, but you'd see that if you pulled your head out your ass.
This isn't even "not having to deal with low level optimization". Using a normal toolkit is not low level optimization, it's the bare minimum.
Putain, elle est belle la French Tech avec des gens comme ça.
Look, I'm not even stating an opinion here, I'm just stating facts.
Clearly, companies and developers are behaving in a way you don't like. You seem to believe that billion dollar companies are just stupid, that all developers are idiots.
I'm explaining to you the correct way to explain this behavior, an explanation that does not assume that a majority of successful companies and people are stupid, but that instead relies on rational arguments.
Of course I'd love it if there was a perfect way to develop software once without micromanaging memory, run it on web, desktop, mobile and have it be super performant at the same time. It just does not exist as of today, companies and people take rational decisions based on this. It is how it is, stop raging, accept it or build something better.
>Look, I'm not even stating an opinion here, I'm just stating facts.
No, you're stating an opinion and trying to pass it off as facts.
>You seem to believe that billion dollar companies are just stupid, that all developers are idiots.
If you work with developers, you know we're all idiots at heart. And lol absolutely yes billion dollar companies are stupid. You think that scale prevents stupidity ? No, if anything it scales it up even harder. A company that was doing stupid things as a self funded startup with 5k in the bank and a multinational megacorporation with 50 billion in the bank both have equal opportunities to be stupid. The billion dollar corporation even gets to use it's sheer scale to walk over their stupidity and not die from it.
> stop raging,
The day I'll stop complaining will be a miserable one. Stopping the rage is what lead to absolutely dreadful state of software development today.
>an explanation that does not assume that a majority of successful companies and people are stupid, but that instead relies on rational arguments.
One does not preclude the other, the rational argument is still a moronic one.
>Of course I'd love it if there was a perfect way to develop software once without micromanaging memory, run it on web, desktop, mobile and have it be super performant at the same time.
Have you _never_ looked at any UI toolkit in existence, ever ? Even Flutter is a better option than Electron if all you want is a multiplatform app, and this is coming from someone not necessarily holding Flutter in his heart. The bare minimum to do if you're going to make your life easier is to not pick the absolute worst option that is Electron. There's a scale to multiplatform toolkits, and Electron is at the bottom end of this, being neither a good technical choice, a good product choice, a good choice for your users. Electron benefits a single group: developers, but mostly company management, happy to crap out software.
> Have you _never_ looked at any UI toolkit in existence, ever ?
Funny that you say that, I actually did my PhD on this topic! You can find a state of the art of UI toolkits, from page 28 to page 96 of my PhD manuscript. https://hal.science/tel-01455466 I wrote it in 2015, so it's dated for sure. But short answer is: Yes I have been looking at A LOT of UI Toolkits, and one thing I am sure of is that you clearly are blissfully unaware of the socio-technical aspects of Toolkit adoption.
Even if Flutter existed, it would absolutely not have been an obviously smart move by Slack to DOUBLE their engineering workload by picking it instead of Electron while still having to develop a web based version. For what result? The app would most likely not be noticeably faster, if anything, just because the engineering effort that went into optimizing Slack performance would have been dilapidated in re-implementing and maintaining Slack in another toolkit.
As an industry we trade runtime efficiency for lowering the bar on developers; we've been doing that for 40 years now. The industry has been growing so hard that that is a unavoidable and at a macro level probably a net positive.
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?
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.
1- I would hope that they already maintain and protect their private API against attacks (it has to be exposed to the internet, right?), and that they keep backward compatibility for the ElectronJS (and isn't the Android app native?) that are not updated out there. You forgot to mention something like "they would have to invent access control", to which I would answer that they already need that. They would literally just have to open their API to third parties. I doubt this would cost millions.
2- Don't assume too much. I use IRC from a CLI. But anyway you are just repeating your previous point, which is that you think it would cost millions.
3- Well, they would know what the third-party apps use in the API. They could also provide integrations for most popular languages, and those would send telemetry (what do you think the Google Play Services do?). For my crappy app, probably they don't need to know what I do, I am just a useless geek as you said.
4- Counter example: I was always able to connect my crappy app to my GMail account, and it did not prevent GMail from essentially taking over e-mail. But the couple hundred geeks who don't like the web frontend can use their crappy e-mail app, and everyone is happy.
> The beauty of liberal capitalism is that ultimately, at least to some extent, what is good for users is good for the company.
Respectfully, that is the most naive comment I have read today. I don't even know where to start answering that, so I'll just pass :-).
The code of the web engine can be shared among several apps, instead of each of them having its own copy in RAM, making it less of an issue when having several of them.
Only if they make use of the same version of electron. Also apps tend to statically link their libs nowadays to reduce the amount of runtime dependencies from what I've seen. And I'm pretty sure apps distributed through flatpak and the like come with their own copy of the corresponding .so and won't share anything either - unless I'm wrong and electron does get shipped in a shared runtime.
The .so is shared. All those uncompressed cat gifs, no.
I'm not familiar with internal browser architecture, but do they make at least a token effort to not render/run attached javascript for elements that are not currently in view?
I haven't measured, but my gut feeling is Electron apps go extremely crappy when you have like 30 memes in a row in a chat channel and make the mistake of switching to it.
Edit: hey, what happens when you open a 500 M log file in vscode?
Idk. I have electron programs running which take up much less residual memory. I do have slack running in my browser thou and the whole browser running slack and outlock360 and a bunch of other tabs uses 600MB of residual memory of which ... 324MB is used by slack ... so I would say it's more of an slack then a electron problem. AFIK the overhead of electron is around 100MB per-program this is still bad, sure, but far less worse then what you describe.
I feel so too. There are currently no valid alternatives I know to electron. It is sad, but this is the current state of UI frameworks, if you are targeting cross-platform with identical look and feel.
Also electron comes with its own advantages which many on HN seem to forget.
code-server for instance was very easy todo, because vscode was build using electron. It runs virtually anywhere. Uses fewer resources then most WMs on a headless device if you need a full blown IDE.
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?
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.
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)
> 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.
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
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.
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.
> 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.
> 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 this lament actually requires an answer 1) in the form of code, 2) in a language everyone can learn 3) that runs on everything.
While I ordinarily agree with this sentiment, the big pitch about this particular product is performance.
From the landing page, this is literally the first bullet point listed:
> Linen is 1000x more lightweight than alternatives. This means that we load faster, use less bandwidth and are more responsive
In this respect, I think that using 500MB on the 3MB transfer benchmark
contradicts the 1000x more lightweight claim. I've never seen Slack or similar need even 10x as much RAM as the benchmark results.
Last I used Slack, it was using around 1GB of RAM in daily and active use.
At any rate, these are the things that get funded by VCs? It seems to me that the world is not crying out for a slightly more lightweight Slack alternative.
Some demand? Sure, for free tiers and low-cost tiers ... but how do they expect to monetise those free and low-cost users? The free tiers are usually subsidised by the enterprise tiers.
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 afield from my point.
I have a real problem with this abstract beefing with other peoples' products and tech choices, that takes place in land that without alternatives. Show me the code for cross platform GUI development that doesn't look something like this. Explain how it's better than this, and how we should all be using it, instead of this. Until then, these criticism ring hollow to me.
> 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.
> 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 kind of money seems invested enough to make it happen. As a result, every computer on the planet is either slower or more expensive than it needs to be in order to run Teams / Slack / Discord / etc etc.
It feels like a coordination problem more than a technical problem, with users suffering the most.
> 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).
In Electron you run a node 'server' and browser JS client (packaged up into one app). Tauri uses rust for the backend instead.
So yes, in Electron 'the code is mostly JavaScript', but Tauri's offering 'let's do a piece of that in rust instead'. (And I suppose you could do the frontend in rust via wasm, but probably true of Electron too.)
It's not just Tauri itself as a development tool that's written in rust.
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.)
There is another benefit+downside: Web view can get security updates without you updating your software. But, that means your app might break at some point even if you haven't released any updates.
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!
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!
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?
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.
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.
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…
Hard, but doable. I don’t see Apple doing it anytime soon because it doesn’t really gain them anything but here’s a third party demo: https://github.com/swiftwebui/SwiftWebUI
One of the rumors for Apple's increased visible attempts to, among other things, rewrite Foundation libraries themselves in Swift is to better unify their own internal cross-platform efforts (because they get to maintain Apple TV and Music apps on nearly every platform, if no other reason).
I don't know how much Apple is incentivized to make any steps they take towards SwiftUI cross-platform support available to third party developers, but it is an interesting rumor to watch.
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.
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.
$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.
> $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.
> If your app plays audio/video ... This will increase the size of the AppImage bundle to include additional gstreamer files needed for media playback.
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.
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
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.
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
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).
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!
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.
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.
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?
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.
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.
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.
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
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.
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?
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.
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.
That's great. Probably too late to make an impact (And I say this as someone who uses XMPP regularly), but I would have killed for something like that 10 years ago. Weeding through clients was such a pain. 90% of the clients were either half-baked or well-baked, but super out-of-date, and without having certain XEP numbers memorized, finding the remaining 10% was super frustrating.
I don't think it makes sense to expect XMPP to "make an impact" ever, if by that you mean "to spontaneously become the next dominant network" (or it already is, under the guise of WhatsApp, bar the federated aspect). The forces in presence are too uneven and the modern internet is too consolidated to permit that to happen (even google cannot dislodge WhatsApp/Messenger).
IMO, what does matter for XMPP's future is that it remains appealing to a growing niche of users who want to be in control, for whom self/local-hosting is important (XMPP excels at that), who care about privacy (OMEMO is state of the art, and XMPP offers gentler alternatives where PFS isn't desired), and who understand the benefits of federation for resilience. This niche will grow naturally as more and more people get deceived by every monopolistic network being doomed to grow beyond a threshold of sustainability and implode as a result. By that time, it only matters that there are enough sufficiently well maintained and user-friendly clients on all platforms for those "super-users" to embark their peers (which is currently largely the case).
This is how I ended-up here, in fact. I refused to join WhatsApp because I was tired of previous forced migrations from protocols I thought were "too big to fail" (MSN, Skype, …), WhatsApp was already banned in some of the countries I was travelling to for work, and I so, after a failed errand with Matrix, I rediscovered XMPP 10 years after I had my first account on it. Today I have about a hundred contacts there, and the less tech-literate of my peers notice no practical difference in usability or features compared to something like WhatsApp: it just works.
By "make an impact" I was thinking maybe being more popular than either Matrix or IRC (both of which I use regularly, and both of which I would prefer XMPP to) not "spontaneously become the next dominant network"
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).
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.
Yeah I agree. People should be building their Slack alternatives in Elixir at the very least. It's the tried & true, no brainer, boring technology stack for highly scalable, performant, concurrent applications.
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.