6 ms·
Because nobody is investing in native UI development. Electron is proof that if there were a simple to use GUI stack that companies would adopt it.
by giancarlostoro 6mo ago
Because nobody is investing in native UI development. Electron is proof that if there were a simple to use GUI stack that companies would adopt it.
- bbkane 6mo agoContrary to what the article says ("but Google gave up on the project before a real product was launched"), I think Flutter work continues and adoption is increasing
- deleted 6mo ago[deleted]
- airstrike 6mo agoI don't really want Dart tbh
- danpalmer 6mo agoI dislike Dart, but it does work really well for Flutter. I think if you treat it as a Flutter DSL it's easier to put up with.
- serial_dev 6mo agoThe article (as I read it) says that Google gave up on the new operating system (where Flutter would have been the default UI toolkit). I’m not sure if Google actually already gave up on Fuchsia, I’d be surprised if the work actually stopped, but it’s clear now that it will not be a panacea and if it will ever get released and gets some traction, it’s still like a decade away from becoming a major OS.
- mghackerlady 6mo agoThey laid off most of the people on the Fuchsia team so it isn't getting as much work, but Fuchsia is used on their nest stuff iirc
- giancarlostoro 6mo agoOne of my former coworkers / dev friend is primarly a Flutter dev, and he's about to give up on it because finding Flutter jobs has become a pain.
- tootie 6mo agoZed did. I know it has it's fans, but it doesn't seem to be generating a stampede of adoption despite what looks like a monumental effort to build a GUI system from the ground up.
- jbvlkt 6mo agoWhat I do not like on Zed or electron GUIs is lack of customization. Older IDEs using sdks like Swing, JWT, QT, GTK etc. allowed user to design its user interface using drag and drop. ie compare older IDEs like eclipse or idea and try to create layout which fills screen with information important for you. And then try to do the same with vscode or zed. I like functionality and speed of zed but UI customization is too limited for me. It might be design choice or sdk limit I am not sure.
- landr0id 6mo agoTheir GUI system (GPUI) is not very mature for use outside of Zed. GPUI is basically a UI framework in the truest sense: a framework for building UI... frameworks/components. It has core functionality for async execution, an ECS for grabbing shared resources, and a div. It's basically like building a website with div and basic CSS. gpui-component exists: https://github.com/longbridge/gpui-component https://github.com/longbridge/gpui-component Up until sometime late 2025 GPUI wasn't even on crates.io, and it seems like the GPUI-component ecosystem still promotes using git deps. It was also in "read the code for docs" state for a very long time It's been a while since I've used it, but there were weird things missing too like the Scollbar was located in Zed's UI component crates instead of core GPUI. Arbitrary text selection also is not possible, which is something I really value about egui.
- thayne 6mo agoI don't think it is lack of investment necessarily, so much as not building the right thing. What we need is a framework that is easy to use, cross platform, open source, and ideally can be used from your programming language of choice.
- victorio 6mo agoYou are not going to believe this... (joking)
- einpoklum 6mo agoAre the available FOSS cross-platform frameworks really not that good? There's at least Qt, GTK, umm, and, I guess Juce and wxWindows, right? Oh, I see there are more: https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries https://en.wikipedia.org/wiki/List_of_platform-independent_G... Can you explain what's deficient about the first two I mentioned?
- MrDOS 6mo ago> Qt Arcane build system. I mean, I guess it technically supports CMake these days, but I have never been able to get anyone else's Qt project to build without much gnashing of teeth. Emulated native widgets try for pixel-perfect, but tend to feel wrong somehow. > Gtk Outside of a Linux/Gtk native environment, Gtk applications are awful. Take GIMP on macOS, for example: it's had window focus issues (export dialog getting lost behind the main application window) literally ever since Gtk on macOS dropped the XQuartz dependence. And that's the flagship application for the toolkit.
- Pay08 6mo agoCMake support in Qt is perfectly fine nowadays. There are some (optional) custom commands you can use, but generally it's just plain CMake.
- deleted 6mo ago[deleted]
- 6mo ago
- AlienRobot 6mo agoTo me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amount of time you spend dealing with packaging, distribution, etc., is small and you don't care about file sizes. But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install necessary. The same thing on Linux? Impossible. There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained you need to ship the entire OS. Now your file size is huge. I can't use Python, because now Windows users need to have Python or I have to ship an interpreter. The only plausible alternative is something like Java. Now you have a single .jar file that runs on any system. But then Oracle changed the license, and JavaFX is no longer part of Java (Swing still is). Honestly, I just want to display a menubar with keyboard shortcuts. Why can't there be a menubar VM or something that gives me access to a menubar on all OS's without having to deal with all of this. We are already shipping the entire browser with Electron. That is stupid. The way it should work is users install a something like Flash but for desktop apps and every app just uses that platform. It's probably easier to ship a DOS game than a desktop app because everyone who wants to run a DOS game will just have a DOS emulator installed.
- polski-g 6mo agoI want to say you could statically link a GUI application, but I'm pretty sure libpthread doesn't cooperate on static linking.
- badc0ffee 6mo agolibpthread is fine with static linking. Where you run into issues is libraries like libresolv that use configuration files in a specific path.
- einpoklum 6mo ago> There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained So don't be self-contained. I mean, you depend on an X server or Wayland, right? So why not depend on GTK or Qt being available? (Of course, it _is_ tricky to be able to depend on any of several versions of these, but still.)
- gray_-_wolf 6mo agoI mean, both wxWidgets and Qt are fine, no? GTK 2 and 3 as well (4+ is... meh). There are plenty applications using one of these (often via python bindings). I think it is more of a staffing problem. Plenty of people know web development, so you want to use those people for desktop as well. Having desktop be JS (electron) helps a lot with that.
- dpe82 6mo agoA year ago I would have agreed with you, but now anyone can build a perfectly reasonable native app.
- maccard 6mo agoWhat is native on Linux?
- Gigachad 6mo agoWhat is native on Windows too. These days the term native app is so confused it's hard to come up with a definition that doesn't include electron.
- maccard 6mo agoThere’s a few options on windows all of which are native. WPF, Winforms and WinUI are all “native”. > These days the term native app is so confused it's hard to come up with a definition that doesn't include electron. Electron is _not_ native.
- dpe82 6mo agoTUIs, apparently. :)
- mghackerlady 6mo agoathena[0], take it or leave it [0]https://en.wikipedia.org/wiki/X_Athena_Widgets https://en.wikipedia.org/wiki/X_Athena_Widgets