Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cross-Platform GUI Toolkit Trainwreck (2016)

blog.johnnovak.net

Post reply on HN
Print view View original

61–70 of 177 posts

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#61

Post by grawprog »

rapsey wrote: post #46
ausjke wrote: post #29

Earlier quoted context omitted.

exactly, unless he really has something super special, QT should fix all his jokes. I don't use QT, but I think QT rarely has competition as far as cross-platform desktop GUI is concerned. the only true "cross-platform" alternative is electron, which is a bit bloated and slow, but vscode is built on it, along with many others and worked fine. I personally prefer electron these days.

Qt and wxwidgets pretty much force you into using C++ and maybe python. If you have to deal with all that baggage, then you might as well go build the UI layer native.

Huh?

https://wiki.qt.io/Language_Bindings

5.1 Qt for Python (PyQt)

5.2 Qt for Ring (RingQt)

5.3 Qt for Rust (Rust-Qt)

5.4 Qt Quick for Rust (qml-rust)

5.5 Qt Quick for Rust (qmlrs)

5.6 Qt for Crystal (qt5.cr)

5.7 Qt for Go (qt)

5.8 Qt for C#/Mono/.Net (QtSharp)

5.9 Qt for C#/Mono/.Net (Qml.Net)

5.10 Qt for D (QtE5)

5.11 Qt for Haskell (qtHaskell)

5.12 Qtah

5.13 Qt for Julia (QML.jl)

5.14 Qt Quick for Haskell (HsQML)

5.15 Qt Quick for OCaml (lablqml)

5.16 Qt Quick for Node.js (Brig)

5.17 QML bindings for Nelson language

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#62

Post by lmm »

cfv wrote: post #60
lmm wrote: post #54

Earlier quoted context omitted.

Why? Is a medieval scribe hand-copying your GUI libraries? A bible costs maybe $15, which is about 60GB's worth of storage - that seems like a more relevant comparison.

You miss the point. And you are missing it because you're OK with jamming your code right inside 400 times more foreign code in order to display a cute window with two panes in it. Do please make a civil effort to understand there's people who are not ok with it. People like OP, who feels devoting 47 bibles of code to displaying a taskbar widget is not OK. Or like me, who actually likes to know exactly what is my cod…

It's a bit rich to be asking someone to be civil in the same post where you turn your non-point into a personal attack. If there's a point I'm missing then make that point. Don't just talk about "number of bibles" as though it means something.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#63

Post by lmm »

xfer wrote: post #58
lmm wrote: post #41

Earlier quoted context omitted.

Sure. However long it takes to read 120mb off a disk (most likely less, if the application is only using some of the GTK dlls). 120mb of RAM. 120mb more to read when restoring from suspend. 120mb extra data use over your home internet connection. (I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you). It's still all irrelevant . Put a monetary or hum…

All that multiplied by the number of customers. If you don't value your customers, then they are all "irrelevant". > Our programming culture's priorities are so far skewed from whats' actually important. Indeed, that's why there are so many electron based bloatware being developed.

All development effort is multiplied by number of customers though. Like, if you put that time and effort into developing a new useful feature, the value of that is multiplied by number of customers too.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#64

Post by megous »

lmm wrote: post #11

What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.

Well, just loading 120MB executable from an SD card to run it would take 6s in ideal case on the tablet that I use, before it even gets to execution. That's 10s+ startup times for Electron app. Meanwhile my 2MB static C app starts in fractions of a second right after boot.

Storage space is not the only consideration. Storage speed may also be limited.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#65

Post by cfv »

lmm wrote: post #62
cfv wrote: post #60

Earlier quoted context omitted.

You miss the point. And you are missing it because you're OK with jamming your code right inside 400 times more foreign code in order to display a cute window with two panes in it. Do please make a civil effort to understand there's people who are not ok with it. People like OP, who feels devoting 47 bibles of code to displaying a taskbar widget is not OK. Or like me, who actually likes to know exactly what is my cod…

It's a bit rich to be asking someone to be civil in the same post where you turn your non-point into a personal attack. If there's a point I'm missing then make that point . Don't just talk about "number of bibles" as though it means something.

Given you confuse statements of fact with personal attacks, this conversation no longer makes no sense. Bye.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#66

Post by bunderbunder »

glangdale wrote: post #55
bunderbunder wrote: post #51

Earlier quoted context omitted.

There was plenty of explanation for me when I first encountered this article (in the context of trying to solve the same problem): > what cross-platform libraries are available for Nim! Things might have changed over the past couple years, but, at least at the time, there weren't any (usable) Nim bindings for either.

Fair enough, but I think that the onus of proof is on the weird-language-user here. That is, a discussion of how cross-platform GUI toolkits are a 'trainwreck' takes on a different vibe if you're insisting on using Nim or Left-Handed Pure Phenomenological Haskell or the like.

I think you're maybe over-interpreting the article.

There is no (grammatical) article in its title. You seem to be assuming the article is implicitly "the", which would imply that it's intended for a more-or-less universal audience. It could just as easily be "a", which would then mean that it's more of a personal rant about the author's specific situation. I'd argue that the leading two sentences in the italicized portion of the article imply that it's the latter.

For the sake of throwing my own $0.02 in, I also have a historical habit of blithely ignoring wxWidgets and QT for my hobby projects. Their being written in C++ bit is a bit of a deal-breaker for me. The quagmire of interacting with C++ code from a language that isn't itself C++ in a cross-platform way results in me shaving my fill of yaks during working hours; I have little taste for doing even more of it during time that's supposed to be reserved for fun.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#67

Post by rapsey »

grawprog wrote: post #61
rapsey wrote: post #46

Earlier quoted context omitted.

Qt and wxwidgets pretty much force you into using C++ and maybe python. If you have to deal with all that baggage, then you might as well go build the UI layer native.

Huh? https://wiki.qt.io/Language_Bindings 5.1 Qt for Python (PyQt) 5.2 Qt for Ring (RingQt) 5.3 Qt for Rust (Rust-Qt) 5.4 Qt Quick for Rust (qml-rust) 5.5 Qt Quick for Rust (qmlrs) 5.6 Qt for Crystal (qt5.cr) 5.7 Qt for Go (qt) 5.8 Qt for C#/Mono/.Net (QtSharp) 5.9 Qt for C#/Mono/.Net (Qml.Net) 5.10 Qt for D (QtE5) 5.11 Qt for Haskell (qtHaskell) 5.12 Qtah 5.13 Qt for Julia (QML.jl) 5.14 Qt Quick for Haskell (HsQML)…

Most of these are limited to the point of uselesness.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#68

Post by panemic »

edraferi wrote: post #8
panemic wrote: post #6

Earlier quoted context omitted.

By personal experience, wxWindows is "OK", but it's not a panacea. There are a ton of little quirks that will burn you when doing cross-platform development simply because native controls do not behave in the same way. HiDpi is a major pain with wxWindows (but then again, the way HiDpi is managed is a pain irrespective of the toolkit). But if you do some forms and basic UI controls, wxWindows does the job egregiously…

> But if you do some forms and basic UI controls, wxWindows does the job egregiously. Looks the way it should be on all platforms. Word choice? "Egregiously" means "Conspicuously bad or offensive." [0] The context suggests you intended to say "adequate for the purpose," for which "competently" is the correct term.[1] [0] https://www.thefreedictionary.com/egregiously [1] https://www.thefreedictionary.com/competently

Thanks, I had a completely different meaning for this word in mind!

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#69

Post by alxlaz »

lmm wrote: post #41
alxlaz wrote: post #28

Earlier quoted context omitted.

It's not ridiculous. We write off executable size as something that's irrelevant in an age where you can get a 4 TB drive for (what most of the HN audience would consider) peanuts, but it's not just disk space budget that's affected. Larger executables also mean: - Longer start-up times (ridiculous things in 2019: a) SSD prices, b) the fact that it takes longer for an Electron todo app to load off a high-speed SSD th…

Sure. However long it takes to read 120mb off a disk (most likely less, if the application is only using some of the GTK dlls). 120mb of RAM. 120mb more to read when restoring from suspend. 120mb extra data use over your home internet connection. (I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you). It's still all irrelevant . Put a monetary or hum…

> I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you

If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away. And it's not something that you should ascribe to customers being irrational, either. If malware compromises your users' data and it turns out you're not running antivirus software on your computers you're gonna pay way more than you'll ever save by using a big fancy framework.

Sure, it's a bad idea (in strictly technical terms) but you can't just go to your customers with a straight face and ask them to stop running antivirus software because it's 2019.

> Put a monetary or human-time value on it and compare to the cost of the application, or the development time, or a single crashing bug

You say it as if these were independent, but they're not. Debugging performance issues (the critical kind, that make customers yell at you and utter words like "money" and "back") in Electron applications is a mini-project in and of itself. Complex frameworks (I'm not picking on Electron in particular) are cool to quickly develop against, but not cool to troubleshoot, and once you start going off the beaten path, it's not as fun.

Of course, sometimes it's a justified choice, I'm not in the "Real Programmers don't use Electron" camp. But the non-technical aspect of this engineering choice is slippery, as non-technical aspects always are. Sometimes it's the right choice in terms of organization expertise and whatnot, but sometimes it just appeases executive impatience, at the expense of customer experience.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#70

Post by lmm »

alxlaz wrote: post #69
lmm wrote: post #41

Earlier quoted context omitted.

Sure. However long it takes to read 120mb off a disk (most likely less, if the application is only using some of the GTK dlls). 120mb of RAM. 120mb more to read when restoring from suspend. 120mb extra data use over your home internet connection. (I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you). It's still all irrelevant . Put a monetary or hum…

> I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away. And it's not something that you should ascribe to customers being irrational, either. If malware compromises your users'…

> Debugging performance issues (the critical kind, that make customers yell at you and utter words like "money" and "back") in Electron applications is a mini-project in and of itself. Complex frameworks (I'm not picking on Electron in particular) are cool to quickly develop against, but not cool to troubleshoot, and once you start going off the beaten path, it's not as fun.

You can do a lot of debugging and performance tuning in the amount of time it takes to write a custom non-framework GUI. But you're right that it's much less fun for the programmer, which I suspect is the real motivation here.

Post reply on HN