Hacker News new | ask | show | jobs
by frozenport 3376 days ago
But C++ GUI toolkits are disaster. While any kid can put together a reasonable looking JS app, the default options in toolkits like Qt are junk. Common features like centering a QComboBox aren't there. Quickly, you're going to have to custom build every widget. Then you need to hire engineers to manually press all the buttons. These engineers won't be too good at art stuff, so guess what, now you need to hire graphic designers - many of whom aren't familiar with Qt. You're best bet is to pay a consulting company tons of money to make a GUI, which you will struggle to keep updated. Even with unlimited cash, the lead time for this is unjustifiable.

Do customers really want to trade performance for actual money? Are people still browsing the fatweb?

3 comments

From what I remember centering in Qt is possible and easy. Why would you need designers to know, Qt, they will show you a picture and you implement that. hopefully they don't want elliptic windows with elliptic buttons with animated shiny/metalic colors and animated shadows, you can get that but you may need to create custom widgets. Don't even compare a GUI Listbox or similar widget that can handle 10000 items because it smart to create and paint only visible stuff and the html DOM UL/OL that can't handle so many items, and you have to implement the smart list yourself. Same with DataGrids , for html you probably need to buy some code that has part of the functionality present in normal GUI toolkits.
> Common features like centering a QComboBox aren't there

Well, browsers didn't have proper vertical centering for UI elements for ages, too. Not to mention it's between a PITA and impossible to do "simple" things like styling a file upload button (only works via pseudo CSS on Chrome) or cross-browser styling of a scrollbar (usually people tend to handroll JS stuff, which is expectedly slow and unintuitive).

> You're best bet is to pay a consulting company tons of money to make a GUI, which you will struggle to keep updated.

It's the same in the Web sphere, with the added difference of clients not simply accepting "you cannot style a file upload button/input element cross-browser-like", they will usually answer you something along "it's the Web and HTML5 after all!!!". You will always need specialized engineers, designers and UX designers for a well-working app, no matter if native or web.

(But yes I agree with you that C++ GUI toolkits are a desaster, especially when cross-platform! And especially the build tooling coughs at autotools)

What saddens me is that instead of improving the web software development process with tried and tested methodologies, the inverse happened, and the web and its terrible software ecosystems and perpetrators are somehow seen as the "cool kids" of software development. When observer pattern is seen as the holy grail of modern web development, you know we are in trouble.
The observer pattern isn't sold to everyone... The thing is, Web browsers have been nearly as diverse as OSes both historically and recently... But, you get a mostly compatible UI and runtime engine that's installed on pretty much every personal computing device out there. There's a lot to be said for that.

As to the "cool kids", they exist in every corner of things that get done by people. I think WebASM will open up to higher-level tools once it's widely available, and signalling between the UI layer and WebASM code becomes easier to deal with.

> But, you get a mostly compatible UI and runtime engine that's installed on pretty much every personal computing device out there. There's a lot to be said for that.

Only "lowest common denominator" comes to mind.

But to the point of this thread, what bothers me is the transcendence of web tech outside of browsers, where a technology known historically for terrible practices with a very low barrier to entry is now considered the "assembly" of all these platforms, such as mobile and desktop, and the developers, that until yesterday could only make a web page that loads 20MB of dependencies to show a few paragraphs of text, now call themselves "mobile developers" or "full-stack developers".

Well, I take a bit of offense to the last statement... in only that JavaScript is just as, or more valid as a server-side language for development as any other scripting language is. The engines themselves tend to be more optimized than alternatives, and combined with NPM/CJS modules a much nicer experience than many of the alternatives.

As to being able to target mobile/desktop, why not? I mean with Cordova and Electron you can target 4+ platforms with minimal code variance. And in most cases the performance is good enough, until you need more. And React-Native can go even further towards native/compiled language performance, with slightly more variance.

Yes, there is more memory and cpu use than alternatives, but there's also a real cost in developer time, and time to launch. In many cases it's the difference between having platform X, or not... the alternative is nothing, not something better in most cases.

"Tried and tested" cannot be sold for money (as it's already known).

So in order to create demand for consultants the ecosystem repeats history and willfully messes up... and we all know where the consultantocracy finally ended up goes looking at Enterprise FizzBuzz

Assuming this is Qt Widgets we're talking about, this issue can be sidestepped entirely by just going with native style controls with tastefully placed brand accents. The need for each app to have a unique UI theme unto itself is questionable at best.