
GUI development is broken - adamnemecek
http://www.charlesetc.com/gui-development-is-broken/
======
panzagl
The outlined problem in the article has all of the requirements of a full GUI
toolkit, yet the only GUI toolkit looked at is discarded as being too much.
The proposed alternative is to recreate XUL in JSON. I weep for our industry.

~~~
prlin
What are other suggestions? (I haven't done any searching but it sounds like
you had some in mind.)

~~~
panzagl
Not an OCaml dev- it looks like wxwidgets has bindings, which is what I'd use
for 'minimal'. But a text editor with the type of features he wants is not
minimal.

------
jancsika
> I wanted something reasonably fast, with a simple way of producing graphics.

Use the text widget in tcl/tk. It can display graphics and is powerful enough
to build an old HTML 4.01 editor.

> I wanted to draw a horizontal line between the name of the file and its
> contents.

Use the text widget in tcl/tk. You can hard-code a base64 encoded gif/jpeg of
a horizontal line, store it in memory, and display it wherever you need a
horizontal line.

> I wanted to be able to open new instances/windows of this text editor
> quickly to fit into my workflow.

Use the text widget in tcl/tk. Tk's design is the old-school multiple-
toplevel-window paradigm which is perfect for this use case.

> And I wanted low-level control of how the text was rendered (fonts, syntax
> highlighting, and the ability to add vim keybindings.)

Use the text widget in tcl/tk. It allows you to tag particular parts of the
text which you can later manipulate. But it is _way_ more lightweight than the
DOM.

> I wanted this to be easy.

Then use the text widget in tcl/tk.

~~~
monetus
...tcl/tk is always being worked on, too. If only the ttk widgets were easier
to style and more consistent between the platforms.

------
flohofwoe
Everyone complaining about the state of UI development should give Dear Imgui
(and similar immediate mode UIs) a whirl. It may not yet be the right solution
for all types of UIs, but it makes creating UIs fun again and the productivity
is astonishing.

[https://github.com/ocornut/imgui](https://github.com/ocornut/imgui)

Checkout the screenshot threads
[https://github.com/ocornut/imgui/issues/1607](https://github.com/ocornut/imgui/issues/1607)

Especially desktop apps like this look interesting:
[https://github.com/ocornut/imgui/issues/1607#issuecomment-37...](https://github.com/ocornut/imgui/issues/1607#issuecomment-372018336)

And it's small enough to work well with WebAssembly:
[https://floooh.github.io/sokol-html5/wasm/imgui-
emsc.html](https://floooh.github.io/sokol-html5/wasm/imgui-emsc.html)

~~~
defanor
Unfortunately usual system-wide settings and accessibility features seem to
suffer (be ignored) if those are used, just as with cairo (or SDL). The other
methods mentioned in the article seem to be better in those aspects, unless
they are explicitly made to be less so.

------
dylan-m
It's silly to discard GTK as overcomplicated because it is designed for more
than "a few buttons and some text". Surely the author's JSON idea would end up
in the same place. After all, it's a GUI toolkit that is going to be serving
the needs of many different applications; just in the flavour of the month,
instead of a shared library. (And as far as GUI toolkits are concerned, GTK
generally strikes me as quite modest. It has a lot of widgets, but they aren't
terribly redundant, and it doesn't have stuff like an analog clock widget for
that one developer who wanted an analog clock. And the odd ones that are
there, like the different kinds of buttons, are pretty transparent quality-of-
life helpers where it's clear how to make your own if you want).

With that said, nobody cares about GObject Introspection in OCaml. So unless
you want to maintain that, you're stuck with an ancient wrapper library for
GTK2, which is pretty sad. I definitely would avoid it.

If we're going to discard GTK for a reason that isn't "I probably picked the
wrong language", I'd add that it's challenging to target non-"Linux" platforms
with it, but then your best option for that is Qt, and if you pick Qt you
probably aren't using OCaml…

So I can see where he's coming from, at least for OCaml, but, uh, JSON?

~~~
JasonFruit
It's not obvious to me: why wouldn't someone using OCaml use QT? I see some
bindings; is there something that makes QT less appropriate than GTK, e.g. C++
vs. C?

~~~
dylan-m
Actually, looking back at it: I've been living under a rock and oblivious to
how successful Qt Quick has been :b Before I lost the plot, Qt relied on a lot
of C++ particulars (and they used to recommend their own precompiler for some
features), so it was trickier to work with it from other languages. Some of
that has been improved over the years, and it has a simpler surface nowadays
with Qt Quick, so, yes, use Qt!

------
madrox
I got excited about the headline, because I whole-heartedly agree with the
statement, but then the author’s answer was to reinvent HTML with doodads.

I was hoping this would be a call for a higher order of expression which could
be interpreted by lower order frameworks, but alas. I think the author is
confusing the technology with the tools. The tools for building interfaces
haven’t changed a whole lot in the last decade.

------
kodablah
Why are you open to all manners of options except language option? I don't
think you can call GUI development broken when you set your own broken
parameters. Consider broadening your options. Now having said that, GUI
development is broken, but that Qt isn't even mentioned makes this blog post
broken. At least prepend "Cross-Language" or append "in My Language" to the
title.

------
asdsa5325
>And I wanted to do it in OCaml

He glances over that part...

Also, not sure why he is fixed on JSON. There are plenty of GUI libraries that
use XML, why doesn't he use one of those (and therefore not use OCaml).

Misleading, clickbait title and low quality, narrow content. It's a shame.

------
stepvhen
>This afternoon I sat down to write a mini text editor.

i understand reinventing wheels is both fun and educational and grants a
deeper understanding of wheels in general, but the way that statement reads
is... over confident. the idea that any nontrival standard tool for software
developers can be written in an afternoon, presumably from sratch, starting
cold, not even done with preliminary researche (as evidenced by the rest of
the article), is just silly.

>I wanted this to be easy.

has the author ever programmed anything at all these things are never "easy"
just "easier than once thought", which is rare, and "inexplicably more
difficult and obtuse, and motivation enough that time is better spent on other
projects" or somewhere in between.

------
petepete
Was there ever a more productive GUI programming experience than Delphi? It's
been more than twelve years since I used it (or developed on Windows for that
matter), but it was so powerful and fast.

~~~
jdswain
I thought Delphi was mostly dead. I saw a job listing recently and thought it
would be kind of cool to go back to it. But when I checked the Tiobe index
it's still quite popular at number 11, notably it's above Swift and
Objective-C, so apparently it's far from dead.

~~~
robocat
It isn't dead, but it should be: I sometimes support legacy Delphi code.

We use the XE7 version of the IDE, which is excruciatingly slow on a laptop
with an i7 7700HQ processor, fast nVME SSD, and 32GB RAM. Oh, the IDE is 32
bit so it runs out of memory. The IDE also crashes a lot (I have never heard
of a stable release of any version of Delphi). Our codebase still compiles on
Delphi 7 (from 2002) because it is a _better_ developer experience than thier
modern versions...

Trying to find good components was easy in 2002, but it can be impossible now.
All the good component developers moved on to more profitable targets. You
can't find good open source components because no developer can afford the
annual costs to get new versions of the compiler and compile components.

------
pipio21
I believe it is JSON what is broken.

I do not understand the article at all. We created our own GUI development
using Dear IMGUI. It is probably the simplest GUI in the world. For text we
use our own rasterizer library.

But it comes at a price: It just continuously draws the screen, 60 times per
second, which makes the battery of laptops last very little.

Now our software uses a fork of Dear Imgui that does not update the screen but
just when necessary.

Before Dear Imgui, we tried Qt, GTK, Web, Win32. Making your own widgets with
hardware accelerated fonts that you control is extremely complicated in those
GUIs.

~~~
s73v3r_
Can I ask how your approach deals with accessibility?

~~~
blattimwind
It doesn't

------
0n34n7
VSCode isn’t clunky. So is Atom clunky because webkit or because
implementation?

I think you missed the target on dismissing the first option... i.e there’s a
reason html/css/js is the most popular - as in popularity is a good objective
median.

To get to the point, use electron with jsonSchema and a form builder of choice
(I suggest Vue) but React and Angular could suffice depending on how much
functionality your text editor needs.

Point is, your “answer” is pretty much reinventing jsonSchema in Python.

~~~
meesterdude
> a form builder of choice (I suggest Vue)

Any particular reasoning for this?

~~~
0n34n7
OP appears to be a polyglot with a foundation lower in the stack (e.g
frameBuffer, X, etc) ... thus (as has been admitted) React et al are too
abstracted from what is considered “familiar” web dev.

Vue gives you the binding, flow and components - whilst maintaining a closer
relevance to what can be considered “familiar”... and subsequently a good
introduction for someone who rejects web at first, yet introduces how a Text
Editor can actually he built in a day using the principles shared by all
modern web frameworks.

Or something like that... :)

------
dexwiz
So replace HTML with the JSON?

out({command: "new_text_box", border: "grey", content: "hi there!"})

looks a lot like

<div style="background: grey">hi there!<div>

The browser is complicated, because its an abstraction that runs in almost
every modern environment. Once WASM gets document bindings, writing web code
will become language agnostics.

Also how are you going to bind interactions with the UI? I see a global event
listener, but that would become unmanageable.

~~~
nixpulvis
The real problem with the "browser" is how bad they are at being the same as
each other.

~~~
lallysingh
He didn't say he needed it to work further than on localhost. Especially for
the 'simple' use case, the browsers will work close enough to the same.

------
mumphster
Sounds like QML, which even looks slightly like JSON if you squint at it
right. Bonus (depending on your views) points: you can even use javascript in
it.

~~~
CarVac
QML is amazing.

Every time I make a change in my QML based photo editor I marvel at how easy
the toolkit has made it.

~~~
polkadotted
Every QML application I've tried was comparable to Electron in my eyes so far:
slow and full of little usability bugs.

This started to be really noticeable for me in the linux world, where QT is
already common, but more and more UIs are converted to QML from QtWidgets.

The difference is staggering for me. QML GUIs are also often styled by the
authors, which very often break or replace the system theme, something I hate.

~~~
CarVac
I'll admit to completely ignoring the system theme, but that's absolutely
standard practice among photo editing software like RawTherapee, darktable,
and proprietary ones like Lightroom and Capture One.

As far as slow, no way. Instant startup, instant everything, no memory leaks.
I've left my editor running for multiple weeks straight with no issues.

Usability bugs? Yes, there's basically one: scrolling. I've hacked together my
own momentum scrolling system but I'm not happy with it. At least it's better
than scrolling in KDE Plasma native applications, though.

~~~
polkadotted
RawTherapee has the option to use the system theme, and I'm quite grateful for
that.

darktable on the other hand has basically one dark theme only which _also_
shows stupid UI mistakes as black-overscroll-on-black-background in all lists
and fixed font size. If there is ONE setting you have to keep, is the FONT
SIZE in the system theme!

You're excluding many more issues from here. Click on a scollbar and drag
outside: very often the scrollbar doesn't release when the mouse button is
depressed, though styling and custom events play a role. QML is not immune to
a _lot_ of quirks in highdpi, most of which are completely absent in
QtWidgets. In detail, font rendering (hinting) in QML in GL contextes is
basically broken.

The whole UI is perceptibly laggier as a whole. I'm a programmer myself. As a
programmer I feel ambivalent, but as an user, I hate it.

------
johnchristopher
I remember dabbling with Visual Basic 5.0 as a teenager. It was pure godsend
and bliss compared to turbo basic (executables !). I never found glade, xul
and other tech stack as easy to use and get into (flash mx 2004 was cool as
well but not as much because the web).

------
jasim
You mean this:

    
    
        do while .t.
                   @ 22,  1 clear to 22, 78
                   @ 22, 26 say 'Ready to Print ? <Y/N> ' get cPType pict '!' ;       
                           valid ( cPType = 'Y' .or. cPType = 'N' .or. cPType= 'H')
                   read
                   if cPType = 'N'
                      exit
                   elseif cPType = 'H'
                      jAlert( ';Help on Print Formats - Press :                     ;;' + ;
                              '     Y for normal bill without leaving no blank lines;' + ;
                              '     N for aborting bill print                       ;' + ;
                              ';' + ;
                              '     L for Large bill covering an A4 size paper' 
                              )
                      loop
                   endif
                   invoice_print( cPType )
                   exit
        enddo
    
    

This piece of code executes linearly, there are no events to listen for and so
no callbacks. There are only keyboard events that occur at specific times in
the program's execution. No mouse events that'd have generated events that
you'll need an asynchronous model of the program to deal with. And this screen
is fixed size - 24 lines and 80 columns; it has 16 colors: red, green, blue,
yellow, and the rest. The window doesn't resize nor the screen size ever
change.

Modern GUI however has events and has to work on devices with all sorts of
resolutions, and they support mouse and asynchronous execution. The program
model is vastly more complex, and although the good old days were really
really nice, they would probably never be back.

~~~
pjc50
Is that ... Fortran?

~~~
jasim
It is CA-Clipper (formerly Nantucket Clipper). It falls in the xBase family of
4GL languages.
[https://en.wikipedia.org/wiki/XBase](https://en.wikipedia.org/wiki/XBase)

------
pjc50
The "procedural JSON to screen" sounds like a reinvention of either Display
PostScript, or more closely Tcl/Tk.

[https://stackoverflow.com/questions/166231/tcl-tk-
examples](https://stackoverflow.com/questions/166231/tcl-tk-examples)

(also, the author hasn't reviewed any of the Windows approaches to this;
drawing up a quick GUI in Visual Studio and C# is pretty easy)

------
Sir_Cmpwn
It's not a lot to look at and I'm deliberately working on it slowly, but if
anyone finds my goals compelling and wants to jump in my email is in my
profile:

[https://github.com/sircmpwn/chopsui](https://github.com/sircmpwn/chopsui)

I plan on finishing up the boring parts in the next few weeks, then the
exciting stuff begins.

------
phlakaton
It amuses me that, for all its "brokenness," OP lists 5 workable solutions and
proposes 1 non-solution. The comments here propose at least one other workable
solution (Dear ImGui) that's new to me and looks very nice!

I am more enthusiastic about the future of GUI development than ever before.
;-)

~~~
rainieri
Everyone should use whatever GlassWire uses. Can't remember now what it was.
The creator answered that question here on HN.

------
Groxx
I mean, sure, if all you want is a couple UI elements and zero control over
how they look or their layout, most existing GUI toolkits are _incredibly_
over-complicated.

But you only want those basics for, like, a minute or two. Or to show a couple
buttons and nothing else. Then you realize how incredibly restricting that is,
and how impossible it is to make something _nice_ and not just _functional_ ,
and you discover the problem is bigger than you thought it was.

Shoes gets pretty close perhaps? [http://shoesrb.com/](http://shoesrb.com/)
But even a tiny glance will show it's _vastly_ more complicated than the
proposed API here, because the proposed API is so inadequate you can't even
say "put X near Y".

------
blattimwind
GUI development is broken [for ocaml]

A rather disingenuous omission by the author.

~~~
moosingin3space
Why should horrible low-level or platform-specific languages be our only
options for building GUIs?

~~~
pseudalopex
What do you call Python, JavaScript, Java, or C#?

~~~
moosingin3space
Python isn't first-class in any GUI framework IIRC (although Qt for Python may
change this). JavaScript and C#, with regards to GUI, are single-platform
languages (I've never seen a UI built with Node and no browser, and I don't
see a good way to build a Linux GUI in C# that is actively maintained). That
leaves Java, which I will concede, even though Java isn't first-class on any
platform except Android.

~~~
megaman22
Mono? Xamarin?

------
nixpulvis
> I wanted this to be easy.

Famous last words :P

~~~
berdon
Yeah, this is just simple naivete. I do agree with the author's premise that
"GUI development is broken" but certainly not because I can't rip out a "text
editor" in a couple hours. Things that seem simple tend to have the worst
problems.

------
defanor
> What, I’ve just got to link to C libraries and write the bindings myself?
> This seems a bit ridiculous.

I think it's a good scenario: it seems that in most cases available libraries
don't expose a C API at all.

I had thoughts similar to the article's conclusion, and even a prototype of a
similar GUI (stdin/stdout, s-expressions), but then decided that a subset of
HTML (or XUL, as mentioned in another comment, though not sure how reusable
libxul is, and it seems pretty close to a full web browser with its scripts
and events) would be fine, though didn't get to trying it out. Currently GTK
seems usable to me, even if imperfect.

------
bitwize
You know that GUI programming is fucked -- at least on Linux -- when it's 2018
and the fastest route from zero to working UI is _still_ Tcl/Tk.

~~~
flukus
20 lines of C looks pretty simple to me:
[http://www.levien.com/gimp/hello.html](http://www.levien.com/gimp/hello.html)

If C is too hard maybe you want c#: [http://www.mono-
project.com/docs/gui/gtksharp/hello-world/](http://www.mono-
project.com/docs/gui/gtksharp/hello-world/)

~~~
bitwize
That's not bad. Fair cop: Gtk is pretty okay for a C API.

Here it is in Tcl:

    
    
        pack [button .b -text "Hello world" -command {echo "Hello, world!"; exit}]
    

Now you know what I mean when I said Tcl/Tk was "the fastest" way to get a GUI
up. Especially when you consider that wish also functions as a REPL at which
you can test your ideas right away with no compile step.

------
dvfjsdhgfv
> By far the most widely used graphics toolkit in history is HTML and CSS. ...
> And it’s definitely the easiest option. It’s the first thing I learned as a
> programmer

And this is where we are. A huge number of today developers, maybe even
majority, are so accustomed to web programming that it's the first thing that
comes to their minds.

~~~
ropeadopepope
Because there aren't any alternatives that are as easy to use and understand.
QML could be if it was available for any language other than C++. Ditto with
Lazarus and Pascal. I hear XAML WPF isn't bad, but it strikes me as having the
same limitations Adobe Flex had (performance). People here love to suggest
GTK, but I've never used a GTK app that didn't look like a Java swing app
straight out of the 90s.

Nuklear looks promising if you don't care about "native look and feel". In
this age of "web swallowing the world", I don't think I care about native look
and feel. Then again, maybe the native look and feel on windows and linux just
sucks. All of the gorgeous, yet still fast apps are for the Mac and iOS
ecosystems and it isn't because their tooling or native GUI APIs are so much
better than everybody else's.

------
theknarf
I love when people try to reinvent stuff like html, but with JSON! Like html
somehow would be better with JSON? If he didn't want to use GTK, nor HTML,
then he could have just gone with Qt Quick. Qt Quick offers a declarative GUI,
it even looks almost like JSON. What a waste of an article.

------
amirouche
What about termbox, it's a good enough abstraction for coding application for
the terminal.

~~~
masukomi
the author specifically excluded cli editors for what seamed to be reasonable
reasons.

~~~
ksherlock
I must have missed the reasonable reasons. All I saw was:

1\. Terminal emulators have too many LOC (how many LOC does cairo, Xlib,
Chrome, or GTK have?)

2\. Oh noes, you have to check for control codes in your text. (do you want to
use a text editor that doesn't?)

~~~
amirouche
2\. is fixed by termbox

------
dvfjsdhgfv
> And I wanted to do it in OCaml.

That's interesting. If you decided to use Lazarus instead, you'd have the
project finished sooner that you wrote the blog post.

The clickbait title is plain wrong: GUI development can be easy and fun,
depending on what toolset you choose.

~~~
ropeadopepope
Care to share same examples?

------
dschep
Sounds like he wants something like Jasonette[0].

[0] [https://jasonette.com/](https://jasonette.com/)

------
jbob2000
GUI development isn't broken, you're just trying to build a skyscraper with
sand.

------
badsectoracula
If you remove the OCaml requirement, everything described can be done with
Lazarus [1] which even comes with a very powerful code editing control/widget.
In fact i made a simple IDE [2] for my LIL scripting language [3] using
Lazarus in a couple of days (which also supported remote execution for LIL
code so i can run and update code while my game engine is running, inspired by
an article about how Naughty Dog used Lisp for Jax and Daxter - except i use
LIL, which is closer to Tcl, instead of Lisp).

Lazarus doesn't have a simple small framework, if anything it is much bigger
than Gtk, but it is very simple to start with and you can ignore most of it.
If you want to see how it is to use it, recently i recorded a video making a
simple game with it under Linux [4] (there are a few comments in a text editor
in the first 6-7 minutes but after that i do not have any sort of comments).
If you want something with more GUI controls (the game really uses just a
painting control), i also have an older video making a tilemap editor [5].

Now to make a disclaimer: IMO both Lazarus and Free Pascal (the language used
by Lazarus) are a bit messy and i'm not presenting them as examples of the
perfect development environment. _However_ Lazarus is both very powerful and
very simple to use, to the point that i consider it by far the best and
easiest way to create GUI desktop applications (the only closest alternative
is old versions of Delphi before it became a bloated mess - but even if the
new versions weren't bloated, i'd still not recommend them because of their
ridiculous price, the fact that VCL only supports Windows and above all the
DRM they have - i remember reading complaints from users that they had to use
cracks so that they can use their highly expensive software in their own
laptop, which is absurd IMO). It has warts but they are well worth it.

My biggest issue with Lazarus is that it seems that the Gtk3 backend is going
to become the default one on Linux in the future and as a user i dislike
everything about Gtk3 (and Qt5 but to a lesser extent).

[1] [http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)

[2] [https://i.imgur.com/tCd64Wh.png](https://i.imgur.com/tCd64Wh.png)

[3] [http://runtimeterror.com/rep/lil](http://runtimeterror.com/rep/lil)

[4]
[https://www.youtube.com/watch?v=s_01Xhd2EJM](https://www.youtube.com/watch?v=s_01Xhd2EJM)

[5]
[https://www.youtube.com/watch?v=_3JgeIUo1X0](https://www.youtube.com/watch?v=_3JgeIUo1X0)

------
mratzloff
Apple has a pretty good approach.

