> Did I miss something important that should be covered?<p>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.<p>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.
I think the article is conflating people's acceptance of web apps with people's appreciation of web apps. Web apps (or electron apps) are always worse than a well-written native counterpart in every verifiable UX metric. Let's not kid ourselves: web apps and electron apps are developer-experience focused, not user centered.
From "Why not web":<p>> I think the fundamental problem of the web is that its APIs are too high‑level.<p>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.<p>It looks like he's using Skia for rendering so the WebGL/WebAssembly Skia port that Flutter uses might be a particularly good fit.<p>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.<p>[1] <a href="https://flutter.dev/docs/development/tools/web-renderers" rel="nofollow">https://flutter.dev/docs/development/tools/web-renderers</a><p>[2] <a href="https://skia.org/docs/user/modules/canvaskit/" rel="nofollow">https://skia.org/docs/user/modules/canvaskit/</a><p>[3] <a href="https://gioui.org/" rel="nofollow">https://gioui.org/</a><p>[4] <a href="https://clojurescript.org/about/differences" rel="nofollow">https://clojurescript.org/about/differences</a>
This is a great writeup and good to see I'm not the only one looking at JVM for cross platform desktop apps.<p>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.<p>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.<p>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.<p>I'm not affiliated with TornadoFX or JavaFX, just a happy user that has rediscovered joy in building desktop apps again.
I have been enjoying working on a cljfx project recently. Extremely fast to get a prototype together, proper multi core support for number crunching, whole JVM ecosystem to reach out for functionality. Probably not for the faint hearted but it has the advantage that it exists today.
"The web started to get more suitable for apps probably since Gmail in 2004. It’s very convenient, yet still very limited and has shortcomings."<p>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.
Compose is still data-oriented! It's not only possible to pass a Button around, it's encouraged. The representation you should pass is a higher-order function, or lambda:<p><pre><code> val button: @Composable () -> Unit = { Button(...) }
List(button) // definitely possible
</code></pre>
The advantage is encapsulation: Button as a lambda exposes no external state, so you don't create tangled graphs of data dependencies in your UI.<p>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).
> <i>[Electron] can’t […] render smooth 144Hz animations</i><p>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.<p>To be sure, you’ll have to be a tad more careful at higher frame rates, but my point is that it <i>can</i> render smooth 144Hz animations.<p>—<p>¹ When run under Wayland; XWayland is apparently still locked to 60Hz.
As someone who believes Electron is genuinely the best existing option for cross-platform desktop apps (and possibly desktop apps in general), I'm excited to see someone trying to make something better by <i>incorporating</i> that context and that progress instead of ignoring it. The goals and the ideas here sound well-thought-out, and not tone-deaf, and I really hope this goes somewhere.
This is really cool. It's great to see someone pushing for good desktop applications. I'm not an electron hater, but I don't love it either, and I'm happy to see new alternatives emerge, in a fun language like clojure no less.
Clojure ecosystem really need something similar. The ability to not have to deal with Clojuscript and to pack-ship an app with desktop UI easily.<p>With the work you did on Skija we have high hope! Good luck and keep us updated
While I appreciate the time invested in researching all this, I feel this is "reinventing the wheel". Native GUIs almost always offer superior performance and already offer everything that the developer(s) of a new framework would have to reinvent. Thus, a wrapper around native GUIs makes the most sense. (GUI frameworks on Linux though does need an improvement or a complete revamp. )
> CSS in JS as a good idea (we won’t start from CSS separated from layout, but it’s good to not to repeat HTML’s mistake).<p>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.
Interesting that yesterday's submission of this got buried. Let me repeat and elaborate because it's somewhat close to my heart.<p>> I plan to focus on the high‑quality desktop instead of finding a mediocre middle ground between desktop and mobile.<p>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.<p>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 <i>not being available</i> on it.<p>Stop it, please. Smartphones are computers. They're used for the same things and <i>increasingly so</i>. Stop pretending they're fundamentally different. They're not.<p>Guess why the Web is eating everything. It's WORA. And there's close to no competition.
I read somewhere when someone was criticizing Rust for GUI stuff, that lack of OO and inheritance can be a real problem. Is that also true for Clojure?
GUIs are one of the domains where object orientation shines. The ability to express in code a set of physically bounded widgets with visual a representation that matches their state is probably a biggest win for OOP. FP, I guess its not that intuitive.
You criticize Electron and then proceed to make pretty much the same mistake by using ... JVM. I don't think this is going to fly as a better alternative to JavaScript. It's just one evil exchanged for another.<p>And I'll be extremely surprised if you manage to do smooth animations at 144Hz in Clojure without killing battery life.
Why use the language with the most horrible startup time for a GUI framework though? The core might be C/C++, but users will write their app in Clojure. GraalVM also still has big limitations.