3 ms·
That still doesn't address the root of the problem, which is that TUIs and Electron apps are write-once, run-anywhere, while native GUI dev is insanely fragment
by dlivingston 5mo ago
That still doesn't address the root of the problem, which is that TUIs and Electron apps are write-once, run-anywhere, while native GUI dev is insanely fragmented.
I mean, I guess that's more or less just a summary of the blog post, but it's true. And it will remain true until the fragmentation ends, and the fragmentation won't end until Microsoft gets its act together and ships their version of SwiftUI so that some sort of abstraction layer over SwiftUI/GTK/MsftUI can be created. And since Microsoft will almost certainly never get its act together, the problem will remain.
In other words, not a blip. The UIs of the present and future will all be Electron apps and TUIs.
- Ekaros 5mo agoWhy not instead have Linux just run Win32 applications?
- dlivingston 5mo agoThat's really not a solution. You're not targeting the host OS for that, which instantly kills that approach for everything other than "we need this to run on Linux and don't care how." You're shipping all of WINE with it. You're sticking out like a sore thumb with Win32 widgets next to the rest of your GTK apps. Etc etc etc.
- PunchyHamster 5mo agohow's that any different than electron, it's also sticking out with all of its widgets being different than native
- dlivingston 5mo agoMaterially, it's not. Which is what I'm arguing.
- d3Xt3r 5mo ago- You don't have to ship Wine with it, you can just make it a runtime/package dependency. Most distros have Wine in their repos anyways, so there's no need to bundle it. I don't see this conceptually being any different than shipping a Python app for instance. - You can make Wine apps inherit the system theme, well, at least the colors. Although it will still look out of place, but it's not much different to the issues with running a Qt app in GNOME, or a GTK app in KDE. Wine in this case can be considered as just another UI toolkit that has the same problem that all UI toolkits have in Linux. - Finally, the resource overhead of Wine is far, far lesser compared to Electron, which is a basically packing in a full-fledged browser.
- tptacek 5mo agoWhat does it matter how fragmented the platforms are? I feel like this isn't sinking in with people. I was chatting with a friend last night about a SwiftUI app that I'd built and he'd pitched in on. He then reimplemented --- didn't port it, reimplemented it, for WinUI, that night, with just a couple prompts. I am, in a proverbial sense, buying puts on Electron.
- nzoschke 5mo agoI agree, the LLM porting things is a game changer. Does it also follow that we can have pretty much any shape for valuable apps? API, CLI, TUI, Web, SwiftUI, WinUI...
- tptacek 5mo agoYes. Developers are conditioned to expect the only convenient answer is a TUI (actually, a CLI; TUIs are show-off projects most of the time) and, if you really want to go all out, Electron. That's not the case anymore.
- colesantiago 5mo ago[flagged]
- tptacek 5mo agoEvery time I read a comment like this, I flash to the episode of the Office where Michael steals one of Dwight's clients while Dwight is on the phone with him in the car. He pitches the client, and Dwight screams into his phone "ARE YOU SAYING YOU INVENTED PAPER?!" No, friend-o, I'm not saying htop and emacs are show-off projects --- though everyone I know who uses Emacs (myself included) uses graphical emacs. My point is that most developer tooling is CLI, not TUI; most developer tools are shop jigs, not packaged tools. Though most of the packaged tools: also CLIs! All of them can very quickly be made into native UIs, though. You'll get further on HN not calling people "very dishonest".