Comment by kodablah | Hacker News Reader

Comment by kodablah | Hacker News Reader

Parent Full thread

Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it.

Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming.

And no, I would rather not have an interpreted (or dynamic) language if I can help it.

Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.

There is a void because OS vendors are actively hostile to top-notch cross platform UI toolkits. They learned their lesson from software companies of the 80's and 90's: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

Making a super high quality cross platform UI toolkit is very hard, both in regards to core implementation and maintenance. Open Source did its best, but it apparently wasn't enough. Commercial vendors can't really get adoption cause everyone expects free and even Open Source solutions.

I feel that there's a catch-22 somewhere here :)

But isn't web browser currently is a de-facto cross platform UI toolkit for displaying web pages it is just that we managed to make web pages look and behave more like apps.

So it is definitely possible to make a framework/toolkit although if you look at development history of browsers how many years it took them to get where they are and Opera throwing in the towel and switching to Blink.

Only question is, if they do such a toolkit what is there remaining for OS vendors to do? Kernels? Users will just choose faster one.

The browser is a cross platform UI, yes.

But is it on-par with native offerings? Where are the standardized components? How many years did it take to get a simple grid layout present in Tk back in 1991? Where's the fool-proof GUI editor? How long did it take for it to have a date input?

The web had to fight its way to where it is now. And that's why it has so many scars (besides the self-inflicted DOM and Javascript before strict mode and ECMAScript 5).

Regarding the OS vendors, well, yes, kernels, tools, basic apps. Also not all applications are graphical.

Native offerings kinda suck too I don't know any standardized one. Swing, QT, GTK all look different depending on the OS.

Before web stack there was Flash it had hardware access but it was insecure, now web tech going the same way with web assembly and webgl.

"Swing, QT, GTK all look different depending on the OS."

They're supposed to. They're fitting in with the OS's native look and feel. And that's a GOOD THING.

Exactly, and building a UI framework as powerful as the web tech is very hard.

It took decades of development and an immense amount of resources - the current web engine we all use is the work of dozens of developers from KDE, Apple and Google. If we could've got those all to collaborate on a native UI toolkit you could probably have got something equally good, but such a joint Apple-Google project would probably have been politically impossible at both companies.

Sorry if I go OT, but I wouldn't know where else to ask this since the question comes from the article you linked.

So, by the logic of making your complements a commodity, what is FogCreek trying to make a commodity of with Glitch? Are they trying to make "building apps" (and thus "getting into programming") a commodity so they get more users to StackOverflow?

Also, does anyone have any good material to suggest on this topic? I'd like to learn more about it and learn how to be able to recognize the things for what they are: complements or products.

Well, as I think Joel says in the article, you want some sort of Econ 101 textbook. Regarding FogCreek, you need to be aware of the whole picture: when Joel's talking about strategy, especially at that level, he's talking about big companies. Fog Creek doesn't have the kind of pull necessary to really care about complements or substitutes. Their strategy is probably: "fill whichever niche we deem free" :)

Oh yeah, I was thinking of something more specific, but I'll look into that too.

Well but then there's a big missed opportunity there, isn't it? I mean, it sounds like a principle like that would apply to most scenarios, unless you are too small to even think of making an impact on your complements markets with your financial power. In that case, sure.

It's interesting that you mention that GTK is not native enough, but do not mention that for Electron. It looks like (and I feel this way) GTK hits the uncanny valley, whereas Electron is different enough (and applications written in it are used to spending effort on looks) to not run into that problem.

otoh, I think that with Electron, people are sufficiently acclimatized to web apps for them to feel at home with it. GTK feels like a java app.

Yup. The default interface for almost every normal users these days is a web interface. Yes, there are mobile apps, but even on mobiles, users will need to use websites, despite the best efforts of vendors at lock-in into their walled app gardens.

Heck, even on desktops, sometimes the UIs feel quaint and antiquated: no back button/undo by default, many times scrolling failures at different resolutions (the settings screen doesn't fit at a certain resolution and the button is out-of-screen somewhere), text can't be selected and copy-paste by default...

I find this inconsistency interesting as well. It's like if you used a "flat" GTK theme and avoided traditional UI elements like MDIs, menus, and toolbars, you'd be divorced enough from native to leave that criticism behind (granted there are others). I think this is what makes QML, JavaFX, and HTML+CSS more popular recently...desktop-like expectations are out the window (per se) before you start.

With Java 9 jigsaw and jlink you can now build fairly light JavaFX apps. The entire jre no longer has to be bundled. Only the pieces you're using.

I recently started experimenting with JavaFX. I was pleasantly surprised how nice it is, and how easy it is to package application bundles.

Looks like that's about 45 MB [1]. For comparison, Electron is about 80 MB. Qt starts at 50 MB depending on what you need, but a few years ago I got it down to 16 MB with UPX and a customized ICU. Gtk starts at ~20 MB and compresses to about half that with UPX. You could probably get those a bit smaller if your license permits static linking, but then you have to write C++.

[1] https://steveperkins.com/using-java-9-modularization-to-ship...

Unfortunately JavaFX still does not support Wayland, just like most Java GUI things (except for SWT which seems to have some support https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841)

Given the progress of Wayland's adoption, I don't see it as a major issue.

Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.

In many times bindings are:

* incomplete

* immature

* not up to date

and definitely out-of-tree, aka not maintained by the folks that make the original toolkit.

Would you bet your company on those bindings?

Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.

Yes, but some of them are of very high quality, such as wxPython or PyQt.

And to be honest, modern C++11/14/17 is quite a different language, more friendly to beginners compared to 90s C++ people remember.

Writing C++ with wxWidgets or Qt really feels like Java or C# with their batteries.

There are bindings and there are bindings. I'd bet my company on PyQt - if anything I'd say bugs get fixed there quicker than in Electron. But part of the reason for that is that PyQt is a commercial (dual license) project with a dedicated company behind it.

>Also, in case AOT compiler comes to Java

What? AOT is available in Java even on Debian, the next step is Java-on-Java stack. HotSpot is about to be deprecated in 4 weeks once Graal becomes default for all platforms in Java10.

> java --list-modules | grep aot

> jdk.aot@9-Debian

I'm not in Java world, but I remember there were talks about future AOT awhile ago - is this a thing now? i.e. you don't have to ship the whole JVM, and no more bytecode, just a native executable?

If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).

Because of the crowd that doesn't want to pay for AOT compilers.

The majority of commercial JDKs always supported AOT to native code, only Sun did not, as they were religiously against AOT.

Oracle thankfully thinks otherwise, has kept sponsoring MaximeVM research, which became Graal and SubstrateVM, and now they are in the process of even re-writing the C++ parts into Java (Project Metropolis).

>I remember there were talks about future AOT awhile ago - is this a thing now?

Yes, AoT is now supported in Java out of box. Java after Jigsaw projects is modularized and you can build an executable file, like .exe or .bin which contains minimal JVM in it with JVM modules and your own modules and it's dependencies. You can read more about it here https://steveperkins.com/using-java-9-modularization-to-ship...

>If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).

Probably because a lot of developers still think Java is slow, many peoples opinion on Java is from 10 years ago. AoT was officially released in OpenJDK a few weeks ago, so as you can see, a lot of people don't know about it yet.

I think part of the UI problem is more fundamental than UI.

The only common ABI among all programming languages is C. For a UI lib to work with all languages, we end up with wrappers for C libraries. If not we end up with language specific libs like Swing. We need a common ABI that's better than C.

> JVM AOT...we're waiting, we know it's coming.

https://www.excelsiorjet.com/

It might as well not exist in this day and age: https://www.excelsiorjet.com/#pricing

Yes, you can argue: "that's not fair", "for a professional programmer that's worth only a few weeks of work's for massive productivity improvements", etc., but things don't work that way.

Most developers have been conditioned to not use commercial products, if they can. With an extra downside for the commercial product being closed source.

That was only one example, and I explicitly mentioned Excelsior instead of other alternatives, because it is free for open source projects.

Fun aside, I once wrote a JVM AOT [0]. Instead of compiling to low level code and building my own GC and runtime, I just transpiled to Go. And it worked, but the Go compiler couldn't handle it well[1] so I started trimming identifier names and shortcutting JRE libs to use Go versions. It became tedious so I gave up. I should revisit that project one day, heh.

0 - https://github.com/cretz/goahead 1 - https://github.com/golang/go/issues/18602

Reply on news.ycombinator.com