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.
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.
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.
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.
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.
You're not misremembering. There was an enormous setback in the usability of GUI programming when the web was invented. The first reason is that the whole platform is built on the jagged rubble of the 90s/2000s platform war. But the second is just that, with so many different languages and systems in play, tool and library support just can't keep up. What made Delphi great was that there was one integrated framework that knew about everything from your visual design to your databases - you could integrate them all, get autocomplete, etc.
These days, we write Python that generates SQL in order to generate HTML, then write Javascript to talk HTTP to the Python and then generate HTML that gets interpreted into the screen by CSS...and there is no way a tool can present the result of that in a coherent manner (let alone autocomplete it!).
(I get an up-close view of this because I cofounded Anvil - https://anvil.works - which does the complete opposite of this at every level. All in Python, one framework, all autocompleted - basically a modern Delphi for the web.)
My first response to the article was Ctrl+F Delphi in the comments.
Because everything the author was complaining about was solved in Delphi in mid-nineties.
Heck, if he were to write for Windows, he could still use Delphi and get what they want!
For that matter, VS.NET platform would be a pretty good tool for that job too (no surprise given that the head of the project was heading the development of Delphi before jumping ship to MS).
Yes, Delphi was great. I'm talking about earlier versions, but current versions are good too. [Disclaimer: Only used them lightly.] The two cons I see are:
1) the trend towards greater and greater complexity and more features as time goes by and as version numbers increase.
2) the cost, of course.
Edit: Also, as others point out in this thread, some versions of it were reportedly moderately to quite buggy.
And as someone else said in this thread, Lazarus is an option.
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.
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.
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.
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.
It seems like any consensus on ignoring/utilizing system themes is transient. I know I'm glad when they are mostly ignored on mac, while glad when they are utilized on linux.
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.
Yes, I too read the article, and it came across to me as dismissing many GUI development options for one single reason or another, maybe without checking to see if there were any solutions or workarounds to the issues of each of them. Might be a perfectionist point of view.
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.
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.
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.
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.
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.
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.
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.
pipio21: could you clarify "our software uses a fork of Dear Imgui that does not update the screen but just when necessary.", why and how did you have to fork the library? Could you share your work? Normally this decision is left to the application, as it is trivial to decide to not call any of the dear imgui function and stay idle, this is what desktop-ey applications using dear imgui that do not animate would normally do.
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.
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?
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?
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!
> I see some bindings; is there something that makes QT less appropriate than GTK
Qt has a long history of bindings coming and going to the point where I wouldn't trust any of them to last unless they come from the qt team themselves. Couple this with c++ making binary compatibility much harder (https://community.kde.org/Policies/Binary_Compatibility_Issu...) and you've got a recipe for frustration.
> 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.
> 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.
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).
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.
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.
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.
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:
>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.
80 comments
[ 7.2 ms ] story [ 124 ms ] threadFamous last words :P
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.
It's kind of funny, because one of the first things I wrote with Delphi when I first got my hands on it was a text editor. :-)
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.
These days, we write Python that generates SQL in order to generate HTML, then write Javascript to talk HTTP to the Python and then generate HTML that gets interpreted into the screen by CSS...and there is no way a tool can present the result of that in a coherent manner (let alone autocomplete it!).
(I get an up-close view of this because I cofounded Anvil - https://anvil.works - which does the complete opposite of this at every level. All in Python, one framework, all autocompleted - basically a modern Delphi for the web.)
Because everything the author was complaining about was solved in Delphi in mid-nineties.
Heck, if he were to write for Windows, he could still use Delphi and get what they want!
For that matter, VS.NET platform would be a pretty good tool for that job too (no surprise given that the head of the project was heading the development of Delphi before jumping ship to MS).
He he, I did the same.
>Because everything the author was complaining about was solved in Delphi in mid-nineties.
Related:
Delphi – why won't it die? (2013) (stevepeacocke.blogspot.com)
https://news.ycombinator.com/item?id=7613543
I had commented a few times in that thread.
1) the trend towards greater and greater complexity and more features as time goes by and as version numbers increase.
2) the cost, of course.
Edit: Also, as others point out in this thread, some versions of it were reportedly moderately to quite buggy.
And as someone else said in this thread, Lazarus is an option.
Beating a dead horse and outing myself to anyone that knows me!
Every time I make a change in my QML based photo editor I marvel at how easy the toolkit has made it.
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.
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.
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.
https://github.com/ocornut/imgui
Checkout the screenshot threads https://github.com/ocornut/imgui/issues/1607
Especially desktop apps like this look interesting: https://github.com/ocornut/imgui/issues/1607#issuecomment-37...
And it's small enough to work well with WebAssembly: https://floooh.github.io/sokol-html5/wasm/imgui-emsc.html
A rather disingenuous omission by the author.
Javascript isn't either.
Both of them have a glut of good cross-platform gui options.
With mono, C# and winforms work pretty well cross-platform too.
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.
Any particular reasoning for this?
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... :)
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.
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?)
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?
Qt has a long history of bindings coming and going to the point where I wouldn't trust any of them to last unless they come from the qt team themselves. Couple this with c++ making binary compatibility much harder (https://community.kde.org/Policies/Binary_Compatibility_Issu...) and you've got a recipe for frustration.
[0] https://jasonette.com/
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)
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.
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.
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.
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.
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.
https://github.com/sircmpwn/chopsui
I plan on finishing up the boring parts in the next few weeks, then the exciting stuff begins.
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.