
Ask HN: What's the state of the art in multi-platform client GUI development? - marcosscriven
It seems to me that there&#x27;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.<p>However, the GUI side of things seems to be split into three (let me know if I&#x27;ve missed a category):<p>1) Native to the OS (That&#x27;s to say, using OS-provided widgets and idiomatic HIG)
2) HTML&#x2F;CSS based (E.g. React in a Chromium environment)
3) Some kind of cross-platform widgets (E.g Java Swing&#x2F;AWT, QT, even OpenGL)<p>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.<p>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.<p>Another way to phrase it is, what multi-platform apps do you admire, and what tech stack do they use? I&#x27;m particularly interested in excellent examples of cross-platform GUIs (Be they HTML&#x2F;CSS or otherwise)
======
jp
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.

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

------
gaze
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?!

------
ferrari8608
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](http://kivy.org/#home)

