151–160 of 253 posts
Earlier quoted context omitted.
What exactly makes Electron better for speed than say popular cross-platform GUI library X?
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.
Earlier quoted context omitted.
Anything that's not XMPP or based on it is inferior, IMO. And I'm not saying that for the troll (although it's easy to be dogmatic about such things). Facts are XMPP has awesome server implementations that scale to billions of users (as proven by WhatsApp/ejabberd), and developing new clients is made easy by the sheer number of libraries and platforms supported. XMPP is an established IETF standard that has a compact…
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).
> 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.
Earlier quoted context omitted.
You've been able to package your java apps so to not require that from your users for a very long time, and in the more recent years, with the compartmentalization of the JDK, you've been able to ship a very striped down version of it, and even more recently, an AOT compiled/PGO optimized binary, so nowadays you can ship your instant starting/low footprint/well performing java code without Java/a JVM.
So your suggestion to avoid shipping chromium is to ship java instead? Aren't you just replacing one VM for another?
Earlier quoted context omitted.
It's been years since I've messed with Java. OpenJDK can do all that? How big are the binaries?
They're pretty big. I've got a fairly basic JavaFX app that's compiled with Graal, and it weighs in at 98MB, or 32MB when zipped.
Earlier quoted context omitted.
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.
LibreOffice has very little Java code. https://www.reddit.com/r/libreoffice/comments/6gxy82/is_libr...
Earlier quoted context omitted.
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 recent…
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…
Another pretty one with a java frontend is BitWig. That's perhaps more impressive than any JetBrains app.
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 te…
Thanks for sharing the experience. From time to time, I go to 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).
By all means use it on desktop platforms, but it won’t get you an acceptable web version.
Earlier quoted context omitted.
They're pretty big. I've got a fairly basic JavaFX app that's compiled with Graal, and it weighs in at 98MB, or 32MB when zipped.
Not too surprised, but aren't you incidentally also bundling chrome/WebKit on top of that by depending on WebView?
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.
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.
> One of the main core differences with Tauri is that it uses a Webview instead of using chromium like in Electron. This means that every desktop application doesn’t have to ship with chromium and can rely on the native browser’s webviews. The downside here is that because it is using Webview you have to deal with different quirks of different operating systems. ElectronJS is a cross-platform framework. It is bloated…
> why not going for a JVM-based technology? Not to pick on the JVM, but does anyone actually build new desktop software for the JVM that's meant to be downloaded and installed by mainstream consumers? Qt and other frameworks work pretty well (with their own flaws) but I'd simply never even consider the JVM as a viable option for desktop software. The last JVM app I installed was probably Minecraft in 2012.
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.