So you want to write a GUI framework

www.cmyr.net Permalink

There are a handful of technical blog posts in my bookmarks that made me go oh, I never thought of it that way when I first read them.

I'm talking about posts like Parse, don't validate, Text Editing Hates You Too, Choose Boring Technology, or Making illegal states unrepresentable. I consider these required reading for any working programmer.

To me, Colin Rofls' So you want to write a GUI framework falls into the same category.

Before reading this post, I'd never considered how much work goes into building a GUI framework. There's a reason even trillion-dollar megacorporations use web technologies to build their apps, ship buggy frameworks year after year, or drop support for platforms with no concern for their users.

Building a brand-new GUI framework in 2026 is a long slog, and you don't get to reap the fruits of your labor until you've solved every single problem on Colin's list.

Colin writes:

Regardless of the specifics, there is one major dividing line to recognize, and this is whether or not a framework is expected to integrate closely into an existing platform or environment.

On one side of this line, then, are tools for building games, embedded applications, and (to a lesser degree) web apps. In this world, you are responsible for providing almost everything your applications will need, and you will be interacting closely with the underlying hardware: accepting raw input events, and outputting your UI to some sort of buffer or surface. (The web is different; here the browser vendors have done that integration work for you.)

On the other side of this line are tools for building traditional desktop applications. In this world, you must integrate tightly into a large number of existing platform APIs, design patterns, and conventions, and it is this integration that is the source of most of your design complexity.

And later:

In general, a game or an embedded application is a self-contained world; there is a single ‘window’, and the application is responsible for drawing everything in it. The application doesn’t need to worry about menus or sub-windows; it doesn’t need to worry about the compositor, or integrating with the platform’s IME system. Although they maybe should, they often don’t support complex scripts. They can ignore rich text editing. They likely don’t need to support font enumeration or fallback. They often ignore accessibility.

He goes on to enumerate all the integration points a GUI framework has with its host platform, including windowing, menus, 2D graphics, text rendering, accessibility, user input, and a bunch more. Each of these problems is hard on its own, but to build a GUI framework that people will want to use, you must solve all of these problems simultaneously.

A few surprising things that stood out to me from the post:

  • Dropdowns and select menus are actually tiny windows. If they weren't, they would be constrained to live inside your app's main window. You can see this in action when a web application cobbles together a custom select box using a bunch of <div>s. Those custom selects can never overflow the boundaries of your browser.
  • Building an abstraction that supports all the different 2D drawing APIs across platforms (CoreGraphics on Mac, Direct2D on Windows, Cairo on Linux, etc.) is difficult. To get around this, many cross-platform apps bundle Skia, which adds ~17MB to the application's binary. The article is from 2021, so that footprint is probably larger now.
  • GPUs are built to render 3D scenes, which makes them worse at rendering 2D scenes. Rendering 2D scenes on GPUs is an area of active research.
  • If you only ever write English, you've probably never thought about IMEs. I write Hindustani and Punjabi, and broken support for the macOS IMEs for those languages immediately tells me that an app is built using a non-native GUI framework.
  • Replicating the native behavior and conventions of a platform is difficult but possible. Replicating the native appearance of a platform—down to the animation curves, gradients, border radii—is a fool's errand. In my opinion, if you're building a cross-platform app, it's better to have it look completely alien than trying to mimic the platform's native widgets. But not respecting the platform's conventions for things like drag and drop, scroll acceleration, etc. is nonnegotiable.

We don't have too many viable cross-platform GUI frameworks today, especially if you want to target desktop computers. It takes too much time, money, and specialized expertise to build one.

If I was starting a desktop app business today, there are only two frameworks I'd feel comfortable relying on: Electron and Qt. Nothing else is mature enough.