Thoughts on Clojure UI framework
tonsky.me
tonsky.me
Accessibility. Outside of that everything seems reasonable. But I don't know much about cross-platforms GUI. I expect someone will come and explain that Delphi or something like that already does everything the author wants except for the integration with Clojure.
I would add that I'm not sure which value Clojure provides here. Does the REPL adds anything to the live-reload environment? If not, the choice of Clojure seems to be arbitrary.
Yes, altering state in a running application is vastly more productive than save/compile/reload, even if the latter happens automatically.
That being said even in that environment having a REPL is nice (although not as much of a quantum leap so much as an incremental improvement) because you can use code to directly poke at your application but is not actually used by your application instead of only being able to write code that your application actually uses.
With hot reloading, you can change the appearance or behavior of a button and see it reflected immediately. With a Clojure REPL, you can do that but also load in different data, trigger actions, etc.
> a live integrated inside an application REPL that lets you evaluate and hot-swap every single line of code at will and on-demand all at runtime without ever needing to restart the application, while also being able to inspect the runtime state at will
Just what instantly comes to mind. No recommendations.
Would love a better word or phrase to differentiate from e.g. the way people experience a python or haskell REPL.
The primary difference in experience is the unit of change that you can make with these systems, which is typically based on the unit of compilation of the language you're using.
For example if you're using a language whose unit of compilation is a file, IME you must reload every change in the file at once. This has upstream effects to how hot reloading is accomplished, because if you're reloading an entire file where you've only _actually_ changed one function, then your hot reloading system has two options:
1. It reloads everything in the file, meaning you're potentially losing state that could have been preserved across the change. This typically leads developers to spread definitions across many files in order to be able to make more fine grained changes to their running system.
2. It uses some heuristic to detect whether state should be preserved or not, typically via some static analysis. This can be opaque to developers working on applications, and adds a lot of complexity to the hot reloading system, but is probably the best one can do if your unit of compilation is a file.
Lisps, on the other hand, typically make the unit of compilation a "form", i.e. a well-formed syntax tree like (foo (bar baz)). This, combined with some editor tooling, means that I can make extremely fine grained changes to the system by selectively evaluating forms within a file, preserving its state except for the form that was evaluated.
The way this works in practice is: I have my editor open and connected to my running application using an extension. I place my cursor on a form I have changed and use a hot key to compile and send that form to the running application. I can view the return value of that form in my editor, and if there were any side effects (e.g. re-defining a variable or function), my application will now exhibit that new behavior.
Side note: the benefits of being able to evaluate forms and see their output in my editor is hard to state. It turns your editor from a one-way communication tool (I make changes, hit save, and those changes get made to the application) to a bidirectional tool, where I can both change and inspect the running system. I wish more languages had robust tooling for this.
The other difference that you tend to see between languages (even between languages with just hot reloading) is late vs. early binding. Lisps are typically very late bound, so you don't need to recompile and/or restart your entire application on every change.
Other languages who bind earlier have to deal with stale bindings. Even JS hot reloading has to deal with this problem in complex ways because most bundlers use closures as modules and bind their inter-module dependencies on instantiation, which means that even though you in theory don't need to recompile or reload anything except the one JS function you just changed, in practice you have to reload the file and any files that depend on it, which puts us back in the position of needing to use some sort of static analysis to detect what has actually changed in order to precisely invalidate application state.
I hope this mountain of text helps highlight the subtle differences between hot reloading and a lisp REPL. It's not just the tooling but the specific semantics of the language that make a difference when trying to make changes to a running system.
Source: my experience working with and developing tools for hot reloading and REPL development in JS, ClojureScript and Clojure
So it seems as though the decision to use Clojure was not made for technical reasons, but it's not exactly arbitrary.
REPL is the secret sauce for writing any time of program, not only UI. It lets you explore, play, test, inspect and break things very quickly and without losing context before you find the final shape of your code.
I can’t live without it, but it’s hard to explain the benefits to the people who have never experienced it. You have to try it to really be convinced
Here is a tiny demo of how I usually use it to build a program https://tonsky.me/blog/interactive-development/
That is true.
> Let's not kid ourselves: web apps and electron apps are developer-experience focused, not user centered.
That isn't true. I spend most of my days on Linux. Before web and electron apps, the alternatives were not well-written native apps. The alternatives were "Use another program". As a user, I'm really glad many things are web-centric these days.
If there were a larger market share, there would be more well-written native apps. If devs focused on users, the easily-ported mediocre electron app wouldn't exist.
Developer problems turn into cost and schedule problems. Users very much care about cost and availability.
Seems like you have the data to back up this statement so if you do, please share :) I'm especially curious about the notion of "every verifiable UX metric" as UX tends to be very subjective. Could you please share what metrics these are that can independently confirm that a native app is always better than a web app?
> I think the fundamental problem of the web is that its APIs are too high‑level.
Frameworks like Flutter (at least one backend) [1] [2] and Gio [3] use low-level APIs like WebGL and WebAssembly. That might not be the right choice for a web-first framework but seems reasonable for apps that would otherwise be desktop-only and need low-level access to be compatible with the native version.
It looks like he's using Skia for rendering so the WebGL/WebAssembly Skia port that Flutter uses might be a particularly good fit.
I assume a Clojure project would use Clojurescript if it had a web target, but I'm not familiar enough to know if the Clojure/Clojurescript differences [4] pose a big obstacle for this sort of UI framework or not.
[1] https://flutter.dev/docs/development/tools/web-renderers
Recently I've been experimenting with TornadoFX and it is very nice to work with. It's a Kotlin wrapper for JavaFX providing a "declarative builder DSL" to compose views. It uses a MVVM approach where the View components are bound to the ViewModel using observables. JavaFX supports CSS for styling components including variables without the clunky web css variable syntax. And with Kotlin coroutines/suspend functions it's trivial to add async IO for network and disk access.
Combine all that with modern JVM and Gradle tooling for native packaging (deb/rpm/msi/dmg) and access to the huge ecosystem of JVM libraries.
Of course there are drawbacks. JVM startup time isn't great but even with Spring Dependency Injection my project starts up in under a second which is fine for a long-running desktop app imho. It will never be as fast or consume as little memory as a native toolkit does but to me it's the pragmatic sweet spot in between native toolkits and packaging a full webbrowser like Electron.
I'm not affiliated with TornadoFX or JavaFX, just a happy user that has rediscovered joy in building desktop apps again.
Any advantages over Qt or Electron?
But if I were starting from a completely blank slate or building a startup around something (especially consumer based) I’d probably make different choices.
Yes. I worked for over a decade to make web apps behave more like native apps. I finally realized it was a fruitless endeavor. The browser and the web are amazing but, trying to make them behave like native apps just doesn't offer the same experience and, in most cases, offers a worse experience. All one need as proof are all the Electron apps or the Apple Music desktop app.
I think the other commenters are right that Music.app is written as a native macOS app, but it definitely leans heavily on web views for content, especially in the streaming parts of the app.
And VSCode performance (especially launch) degrades significantly once you have several workspaces open at once. I’ve learned to dread upgrade launches because the release notes tab amplifies that degraded performance even more (which is baffling because that’s just one more web thing in the same web context right?!).
Don’t get me wrong, I love VSCode, and it’s worlds better than most other Electron apps I have to use. I even went back to it from Nova because it better supports my workflow. But it is definitely slower than it could be if it were native.
val button: @Composable () -> Unit = { Button(...) }
List(button) // definitely possible
You should definitely take another look at Compose, because this concept maps extremely well onto Lisps in general (code is data) and Clojure in particular (tight composition of immutable state).
Hmm? I’m on a 165Hz screen, Arch Linux/Sway, and Firefox and Chromium both do 165Hz just fine¹, both with CSS animations and with JavaScript requestAnimationFrame. I would expect Electron to behave the same way.
To be sure, you’ll have to be a tad more careful at higher frame rates, but my point is that it can render smooth 144Hz animations.
—
¹ When run under Wayland; XWayland is apparently still locked to 60Hz.
It can't, generally. There's a specific subset of animations that browsers can offload to the GPU: anything that doesn't touch the layout. So, transform/translate. That's it.
Beyond that, though, you’re underestimating what browsers are capable of. You’ll certainly hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank), but it’s not hard to drive layout-affecting animations at 144Hz provided you careful about isolating the affected areas. The “don’t touch layout, animate transformations” narrative that got pushed hard some years back was much more about mobile than desktop—desktop can be more efficient with transformations, but even layout-based animations will generally be smooth on desktop platforms. (In the past, Firefox struggled more than Chrome on those sorts of things, but WebRender has helped to completely reverse that.)
As an absolutely toy pathological example, on my admittedly powerful laptop (Ryzen 5800HS, using integrated GPU) in Chromium (since we’re talking Electron and not WebRender), moving a series of ten inline-block 80px emojis by setting their margin-left to random layout-dependent values every frame (so that’s ten forced relayouts per frame, and quadratic layout behaviour) tends in profiling to take around 3–4ms, occasionally spiking briefly just above the 6ms budget my 165Hz display gives and causing jank (… not that I can tell visually with the emoji flickering all over the place anyway, but the profiler tells me!). For comparison, just one emoji (dodging the quadratic stuff) tends to take around 1ms, showing that a lot of the costs here are constant. URL for the code:
data:text/html;charset=utf-8,<style>body{overflow:hidden}div{display:inline-block;left:0;position:relative;font-size:5em}</style><div>%F0%9F%99%82</div><div>%F0%9F%99%81</div><div>%F0%9F%A4%A8</div><div>%F0%9F%98%AE</div><div>%F0%9F%98%9B</div><div>%F0%9F%98%80</div><div>%F0%9F%98%86</div><div>%F0%9F%98%A2</div><div>%F0%9F%98%95</div><div>%F0%9F%98%92</div><script>function f(){document.querySelectorAll('div').forEach(e=>e.style.marginLeft=Math.random()*(innerWidth-e.offsetWidth-e.offsetLeft*0.1)+'px');requestAnimationFrame(f)}requestAnimationFrame(f)</script>And you've literally written how hard it is: "hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank)" and then you couldn't reliably animate 10 emojis. Ten. Ten. And you call animating ten emojis a pathological case.
Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case) or forced recalculations (as you should be doing) and you’re back down to mostly just over 1ms. A hundred elements is then normally 2.5–3ms, with occasional brief spikes of 6–7ms (the spikes at this point are larger proportionally to the baseline than in the pathological ten case). And to remind you, this is for animating a comparatively large number of decent-sized independent elements in the most expensive way possible. It’s significantly more complex than a realistic UI animation test, though certainly a far cry from what is possible in something designed for the purpose, or even Firefox thanks to WebRender: it’s still comfortably hitting over 100fps at a thousand of these emoji, including all this layout recalculation—change a non-layout property instead and it can go way further. (Meanwhile, I try pasting my thousand-element 23KB data: URI into Chromium, and it completely locks up, and killing the process is my only recourse.)
It's only pathological because the web makes it pathological. Phones routinely do complex layout animations that are unimaginable on the web. And yet, "we're doing layout calculations on ten emojis, it's pathological" is the norm on the web.
> t’s decidedly rare to want to animate more than one or perhaps two such element at a time
Yes. It's rare on the web. Because the web is unbelievably inefficient and slow when it comes to any animations beyond a very limited subset.
> And alternatives to the web are normally not actually going to be better—the web has had an insane amount of effort put into making something not particularly amenable to good performance
I have no idea where this verifiably false mindset comes from. Anyone you ask is "yes, the web is very performant, you can't do better, the alternatives can't be better". And yet you use apps, and frameworks, and approaches that are magnitudes faster, more performant, and create significantly more complex interactions and layouts than the web could ever hope to achieve.
Yes. I'm talking about your phone. I'm talking about your desktop. Right now my iPhone screen with two notifications displays more animations, at a smoother framerate than your "pathological example".
The supercomputers in our pockets and on our desks can output this: https://www.youtube.com/watch?v=EFyWEMe27Dw And yet, "it's rare to animate more than two things, other cases are pathological, I doubt anything else can perform better". You're talking about performance available to 1984 Macintosh https://www.youtube.com/watch?v=2B-XwPjn9YY
> Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case)
Ah yes. The usual case. That's why it's still impossible to animate height: auto, or an item being removed from a list without complex hacks because on the web everything simple is hard beyond all reasoning, and everything hard is impossible.
Like you, I am excited to see this approach. There may be a lot of negative opionions about Electron, but you can't deny the inroads it has made.
With that said: I got the sense the author is mainly interested in targeting high-complexity desktop apps, which tend to have less need to be available in both forms
1) Packaging/general polish. With the server solution the user doesn't get a desktop icon, or a single .app/.exe, etc. Their window manager doesn't work with the app the normal way. Etc.
2) Certain other native integrations. An electron app can populate the Mac menu bar, it can use native right-click menus, it can do rich notifications that aren't constrained to the browser's notifications API, it can show a red dot in the system dock, etc.
3) Stability of pinning to a specific Chromium version.
This can work for some things- mostly developer tools where users may not care as much about polish and may care more about reducing install size. But it's not really a replacement.
> Recent versions of Qt use the native style APIs of the different platforms, on platforms that have a native widget set, to query metrics and draw most controls, and do not suffer from such issues as often
Other 30+ cross-platform GUI toolkits / frameworks: https://www.slant.co/topics/983/~best-cross-platform-gui-too...
With the work you did on Skija we have high hope! Good luck and keep us updated
Rendering everything yourself is actually as performant or potentially more performant than a 'native' set because what everyone is doing in the end, including native frameworks, is rendering on a rectangle using opengl, vulkan or metal.
It's not the rendering that's the issue - it's the work involved in making them conformant to the different OS guidelines, and dealing with the intricacies and quirks of each OS. It's more practical to extend and enhance what is lacking, rather than rebuild the whole thing again in 4 (Windows, macOS, Linux, FreeBSD) different ways.
Most of it is automatically handled by the native interface of the OS when it renders the UI. Some cases have to be dealt by the wrapper library developer, and some of it has to be done by the developer creating the app using the wrapper library.
For example, a Window usually has the default UI elements of a Title Bar, the title text, Max-minimize buttons, window resize handlers etc. In Windows, this is rendered with the max-minimise buttons on the top-right corner, and the title left aligned in the title bar (if I remember right). On macOS, the same Window will be rendered with the max-minimise button on the top-left corner and the title centered in the title bar.
When you create a window on MS Windows OS using the Win32 API for it - http://www.winprog.org/tutorial/simple_window.html - the rendered window will be, by default, according to Microsoft UI / UX guidelines. Similarly, when you create a window using the cocoa framework on macOS, the window will be rendered, by default, according to the UI / UX guidelines of Apple - https://github.com/lukakerr/NSWindowStyles .
This highlights how some UI / UX guidelines are baked into the native frameworks.
But if the wrapper library developer wants to offer some multi-platform custom UI component not available natively, they will have to ensure that the component is compliant with UI / UX guidelines of the OS they are rendered in.
(If you want to see this in action with an actual wrapper library, check out Lazarus IDE - https://www.lazarus-ide.org/index.php ... create a window on it on MS Windows, Linux or macOS with its GUI designer and compile the code to the see the native window it generates, on each OS.)
Most of the other things described in the article are also already available in the native GUI frameworks. It would make more sense to extend and enhance what is lacking, rather than re-inventing the whole thing again (which, as you noticed, can be a pain if you have to conform to different OS guidelines).
Reusing native stuff is fine - it provides rendering, text, accessibility, window management, and other hard stuff for you. But it's not equivalent to a native app, because you'll never conform to each platform's UI guidelines without significant work per app.
The HTML and CSS separation is great for accessibility. It is also great for machine processing. On the web "content is the king" which might not be true on native apps, but I tend to feel that separation of content and its _visual_ appealing is a good thing in general, only if CSS would have substantially less quirks.
> I plan to focus on the high‑quality desktop instead of finding a mediocre middle ground between desktop and mobile.
Oh god damn it. This space is severely under-served. It's only filled by Xamarin Forms, React Native (kinda), Flutter and web. They all kind of suck for desktop apps.
It doesn't even have to do both well. It just has to be a great experience on one platform and an okay one on others. Phone apps can be good desktop apps with minimal modification (as Apple realizes 5 years after Microsoft almost did) and not many things are worse than happening to use one platform and your data/functionality just not being available on it.
Stop it, please. Smartphones are computers. They're used for the same things and increasingly so. Stop pretending they're fundamentally different. They're not.
Guess why the Web is eating everything. It's WORA. And there's close to no competition.
I don't really agree here. Phones and desktops are very different, and have very different UI needs.
> Stop it, please. Smartphones are computers. They're used for the same things, even increasingly so. Stop pretending they're that fundamentally different.
Navigating with a mouse and keyboard is not the same thing at all ad navigating with your fingers on a touchscreen.
Sure. Keyboard shortcuts for text. Right click instead of long press. More precision. Hoveing. Swiping back on the trackpad instead of the screen. There are differences - but they're really not that fundamental. Minimal differences.
We can certainly argue about whether mobile first allows an app to use the full potential of the desktop. Maybe not. But I honestly don't care that much if the alternative is no app.
I feel the same, however I still find that mobile first app are not a great experience on desktop.
As evidenced by all the professional apps that require little to no modifications.
Oh wait...
It sounds like you’re imagining Photoshop in a mobile form factor, which is way besides the point.
Small primitive apps with little functionality and barely anything beyond text. Or really limited in their functionality. Or have to hide the absolute vast majority of their interface behind multiple clicks.
Also. Telegram isn't "smartphone-style". It's a native app.
> It sounds like you’re imagining Photoshop in a mobile form factor
Yes, I am. Because here's the list of apps I actually use daily:
- IntelliJ IDEA
- Figma/Sketch
- GitUp
- Terminal/iTerm
Oh, look. All of them cannot be "it's just mobile apps, just blow them up, they will work with little to no midification"
> Telegram isn't "smartphone-style". It's a native app.
With 95-100% (depending on usage) smartphone UX. If the iOS apps on M1 macs situation wasn’t such a fiasco I’d like to compare the two. My prediction: Loss of keyboard features, drag & drop, not much else (GAIN of image editing).
> Or have to hide the absolute vast majority of their interface behind multiple clicks.
It’s arguable whether this is a good thing or not, but that’s exactly where desktop software is going, likely to reduce clutter. It’s not a necessity for a convergent approach to work, however. Of course you can expand menus and such depending on your platform (one might say in a “responsive” fashion).
Seems like the web of 2012 all over again.
I'm talking about the expectations of a desktop app.
> The former is hard, the latter is easy.
It definitely isn't easy.
There's no easy way to transform an app optimised for imprecise touch on small screens into an app requiring precision inputs on a large screen.
There's no easy way to transform an app optimised to display information on a small screen into an app optimised to display information on a large screen.
> With 95-100% (depending on usage) smartphone UX.
It doesn't matter how much usage it gets on the phone. Telegram app on Mac OS is a native app (it's a native app on Windows, too).
> If the iOS apps on M1 macs situation wasn’t such a fiasco
You can't even comprehend why it's a fiasco.
> It’s arguable whether this is a good thing or not, but that’s exactly where desktop software is going, likely to reduce clutter.
It's not "reducing clutter". It's people who spend most of their lives on the phone not understanding how desktop software works and its requirements. You are a prime example of one such person.
> Of course you can expand menus and such depending on your platform
There's no easy way to "just expand the menus". Then you either get a bad experience on the small screen or a bad experience on the big screen, because requirements are completely different.
I wonder how many computer users are actually using a mouse in 2021. I reckon most people use laptops now, which means that people are navigating by touch, either with a trackpad or a touchscreen (I think lots of window laptops have touch screens?)
There’s no way to get actual numbers on this…. is there?
This might prove the OPs point, that trying to target both creates a mediocre middle ground? And could explain why you're unsatisfied with approaches that chose to do that.
Apple has the advantage of having visually converged for a large part, making differences less noticeable, and of course they control their platform.
I tend to think a desktop toolkit would have the best chance at providing a toolkit for both platforms. It’ll have to support touch input and other smartphone-isms either way, as Windows runs on tablets, Mac users expect flawless touchpad interactions and Linux runs on tablets and phones.
You're losing the OO mental model, but gain very loose coupling (data coupling) and code that is easier to reason about. (The trade-off here is not for everyone though.)
On top of that, Clojure is an extremely flexible, interactive language, which is fantastic especially for GUI programming (as mentioned in the article).
And I'll be extremely surprised if you manage to do smooth animations at 144Hz in Clojure without killing battery life.
I even have a few git-style CLI tools that bootstrap a JVM on each invocation without using optimized graalvm/native images.
> As it turns out, Clojure start time is a complicated and multi-dimensional topic. Clojure projects are slow to start not only because of JVM — JVM itself starts in ~50 ms — but because of JVM specifics the classes are loaded slowly. Clojure projects are slow to start not only because of Clojure — Clojure itself starts in ~1 second — but because of Clojure specifics, the namespaces, especially not AOT-compiled one, are loaded slowly. And so on.
http://clojure-goes-fast.com/blog/clojures-slow-start/
A more recent comparison of Clojure, Java and some other Clojure-inspired languages:
https://stuartsierra.com/2019/12/21/clojure-start-time-in-20...
1) Author wants to use Clojure and is funded by a Clojure organization.
2) Author wants write-once/run-anywhere, which the JVM provides.
3) Author wants live interactive development which Clojure can provide.
4) Author wants multi-core support, and fast runtime, which JVM provides.
5) Author wants a declarative data oriented approach, which Clojure is good at.
Finally, the author acknowledges they are concerned about startup time, but believe their is hope either with GraalVM native compilation support, or a custom Clojure runtime.
- lack of threads
- stuck using JavaScript
- can't do your own layout
- can't render 144Hz animation
- adds 150mb to app bundle
- memory hog
And the JVM has multiple of the best GCs out of any runtime, with a specific low latency one which promises <1 ms stops, at which point the OS’s scheduler will have more latency. Also, it’s not like JS is not a GCd language..