Ask HN: What's the state of the art in multi-platform client GUI development? | Hacker News Reader

Ask HN: What's the state of the art in multi-platform client GUI development?

4 pointsmarcosscriven4 comments

It seems to me that there's plenty of good options for writing everything but the GUI of client apps in a cross-platform manner. Just for example, one could write the meat of an app in C++, and it could be compiled to OS X, Linux, Windows, iOS and Android. With Emscripten one can even run it in a browser surprisingly well.

However, the GUI side of things seems to be split into three (let me know if I've missed a category):

1) Native to the OS (That's to say, using OS-provided widgets and idiomatic HIG) 2) HTML/CSS based (E.g. React in a Chromium environment) 3) Some kind of cross-platform widgets (E.g Java Swing/AWT, QT, even OpenGL)

I think the first option seems to be the most favoured, but option 2 still seems attractive to me (as a dev), given how well Spotify and Atom seem to work. Option 3, while practical for some applications, seems to be generally derided to the point of contempt.

I do wonder how much of how well option 2 performs is down to implementation, rather than a fundamental limitation of its approach. For instance, before Atom moved to using React, it was dreadfully slow to scroll.

Another way to phrase it is, what multi-platform apps do you admire, and what tech stack do they use? I'm particularly interested in excellent examples of cross-platform GUIs (Be they HTML/CSS or otherwise)

The problem is way deeper than the UI itself. You think a socket, a thread and a file somehow magically become multi-platform because of c++ ? Chromium embed is 100Mb for a reason just like Java and Qt. The dependencies define the app and not hipster culture. Mocking UI is a sport for people who do not understand the underlying problem. Huge industrial sewer pipeline is too ugly for my living room, etc.

Apple, Microsoft and Google made three different phone UI API´s for the same problem just to lock people in. Apple and Google then beat Microsoft at their own game because they themselves defined the marked. Legal bullshit and patents is the main driving force behind all this non-standard API idiocy. Everyone claims to be unique and non-obvious.

Native apps on many platforms are easy when most of the work is server side. So native is now big because of servers, multi-touch dependencies and code signing complexity. Hybrid is big when the client does all the work. HTML/CSS works when you are showing a document, a list or a form.

wxWidgets does a pretty darn good job and it really isn't THAT big. I'm totally still willing to cry bloat.

1) Native is probably the best... obviously. As you said, you get to follow each specific HIG, so that's good.

2) This I think is a bit of a fad. It's just so bloated and honestly just a way to let people with javascript/web development experience make something the way they understand. I imagine that some parts of the workflow that make this approach popular will end up in the platform-abstracting toolkits. Things like reactive programming and more intuitive approaches to layout (XAML for instance)

3) Qt and Swing here seem to be what people are converging on. WX seems to be losing steam (I think? Can't tell.), and GTK just sucks completely. Lazarus seems to be stuck using Carbon on OS X, but a cocoa port is underway. The biggest endorsement of this approach IMO is Maya, which uses QT. Who wants to maintain THAT UI on different platforms?!

I'm currently developing a small card game in Python that is completely cross-platform. Basically, if the OS has Python 3, my game will run without any issue. It has been tested with Windows and Linux so far. The GUI uses the Python Tkinter library, which is an interface to Tcl/Tk and is included in Python's standard library. The widgets actually blend in well with the rest of the OS in the more recent versions if the library.

So that's one way to do it, though I wouldn't recommend it for a larger app. Developing a GUI with Tkinter takes a fair bit of work. Also, I decided to learn the library by starting that project, so that probably made it a bit more tedious for me than it would have been to someone more familiar with the tools. It's a solid option for a small app, though.

An option I've considered for a future project is Kivy [0]. It's a cross-platform Python library which is supposed to allow for quick cross-platform UI development.

[0] http://kivy.org/#home

Reply on news.ycombinator.com