17 ms·

Clojure Desktop UI Framework

277 points by ducktective 2y ago

webprofusion 2y ago
Lol, checking out the readme. Dunking on stuff isn't what makes you an opinionated framework.
- bena 2y ago
  I’ve gone over the readme, what part would you say is them dunking? Like, honest question, I do agree with most of their points and don’t think they’re presenting them in a too harsh way
roenxi 2y ago
Really could use a link to the API docs in the README.md, it is a bit hard to judge when the "documentation" such as they have so far is sparse. But it is nice to see a newish UI project. I will say I've found Clojure to be a success story for doing GUI work. Projects like Dave Ray's seesaw (https://github.com/clj-commons/seesaw https://github.com/clj-commons/seesaw) are an amazing demo of how one man can rearchitect an API like Swing into something that is deceptively fun to use. High hopes that this project goes somewhere that is similarly enjoyable.
- vips7L 2y ago
  There's a lot of languages that just work better for doing declarative ui than Java. Booth Groovy and Scala have wrappers that just make it that much easier. http://groovy-lang.org/dsls.html#swingbuilder http://groovy-lang.org/dsls.html#swingbuilder https://github.com/scala/scala-swing https://github.com/scala/scala-swing
- nick__m 2y ago
  the Readme says this about the doc: Work in progress. No docs, and everything changes every day.
sieabahlpark 2y ago
[dead]
zombiwoof 2y ago
I love this. Clojure will be perfect for this. Per the other comment, might do less dunking
hyperhello 2y ago
Question about native integration. Does the framework support documents on a native level? Can I define a file type that opens the app when double clicked, maintaining the windows and data, etc?
- tonsky 2y ago
  Not yet, but in theory, sure
kpw94 2y ago
I'm sure Clojure is a great language for some tasks... But, looking at the examples (picked the Wordle one since I know that game): https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/wordle.clj https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/... I find it extremely hard to read. Even small snippets, say line 56 to 74 which define this "color", "merge-colors" and "colors"... then the "field" one lines 76 to 117 is even harder. is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?) I wonder what the same Wordle example would look like in, say pure Flutter. Also wonder how would that code look with external dependencies (say hitting a server to get the word of the day), and navigation (with maintaining state in between those pages)
- trentonstrong 2y ago
  "is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?)" As just one person who has written a great deal of functional code, it reads well to me. I think because I am used to reading it "inside out"? Reading lisp-likes is probably helpful. Take 'color' for example. It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the latter at all, yellow. Otherwise we're grey. That took me a few seconds to grok. Just one anecdote for you. Don't think you're broken but reading/writing this kind of code even a little bit will change the way you see code IMO.
  - exitb 2y ago
    This is the function that confused the person you respond to, ported to Python: def color(word, letter, idx): if word[idx] == letter: return GREEN elif letter in word: return YELLOW else: return GREY I know which one I'd prefer to grok at 2AM with alerts going off.
    - miroljub 2y ago
      > I know which one I'd prefer to grok at 2AM with alerts going off. At that time I'd just opt for sleep. Or sex. Or drink. Reading code doesn't belong to things one should do at 2AM.
michaelsbradley 2y ago
Cljfx is also worth a look! https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
Dansvidania 2y ago
Does anyone close to the project know when/if it will no longer be in "No docs, and everything changes every day" release status?
- tonsky 2y ago
  We have workshop planned for the middle of September, after that, I hope things will start to stabilize a bit. I already started documenting some stuff in examples app, sort of self-documenting integration tests. Will have normal docs too, of course https://s.tonsky.me/share/Screenshot%202024-08-27%20at%2017.31.23.png https://s.tonsky.me/share/Screenshot%202024-08-27%20at%2017....
rlkf 2y ago
I found this dimension of the analysis: > People prefer native apps to web apps > Java has “UI curse”: Looked bad to be at odds with this aspect of the design: > No goal to look native > Leverage Skia
- socksy 2y ago
  "People prefer native apps to web apps" is talking about literally using an app on your desktop, in the dock, with keyboard shortcuts, rather than having a website in your browser. This is sort of shown by the amount of Electron apps people use — you could use slack, spotify, or vscode in the browser, but most people prefer to use the app. "Java has UI curse" is referring to how when Java tries to imitate native UI (note the difference to "native app", which is in contrast to a web app), it fails and hits the uncanny valley. No-one likes it. Given that, it's not a contradiction to have a native app, that does not try to use the native GUI toolkit of the host platform, using Skia directly to draw UI elements.
  - wry_discontent 2y ago
    I used a few electron apps in a browser because the Linux experience wasn't working well for me, and it was a dramatically better experience.
- truculent 2y ago
  I suppose it’s just to clarify that those choices are deliberate, with the trade-offs in mind. The README also suggests that the reason why people prefer native apps isn’t just the UI’s aesthetics, but: > Normal shortcuts, icon, its own window, file system access, notifications, OS integrations
dzonga 2y ago
where did the myth that people prefer apps that look native to the platform come from? There are two types of apps: 1. the ones that professionals use and 2. the ones that consumers use. for 1. they don't care if it looks native, as long as it works and is performant e.g. DAWs, Video Editing tools, Trading, etc. 2. likewise I don't think it matters that much. my guess is the myth came from OS makers.
- layer8 2y ago
  Native look&feel makes for a consistent UX across apps. Users learn one set of conventions and UI controls that uniformly applies to all applications. In addition, all applications benefit from enhancements made to the native UI toolkit and integration with the OS (input methods, file dialogs, keyboard navigation, automations, …). Moreover, web UIs tend to be less sophisticated and less power user friendly, due to HTML/CSS and browser API limitations. This unfortunately often carries over even to non-browser-based applications that however use a web-like UI.
  - regularfry 2y ago
    There's a slightly deeper part to this which is that if I see a native UI toolkit in use, I can be at least relatively confident that the accessibility affordances I expect to be there haven't been half-arsed in some custom widget set implementation. That's part of the "one set of conventions" expectation you mention, but it's an important one. There's a lot of embedded knowledge in native widgets.
  - novagameco 2y ago
    I don't personally believe it's ever been true that users want the same UI styling across apps. When given the option to customize the colors or layout of an app, users will do that. People want their applications to follow common UI patterns, but applications should have some kind of personality to them, otherwise they just look like Microsoft or Apple products
    - troupo 2y ago
layer8 2y ago
The readme says it is aiming for a “web look”, with no intention to make it look — and, presumably, behave — native. As a user, that’s not what I expect and hope for from a desktop application.
- giancarlostoro 2y ago
  Isn't this the case with a lot of desktop GUIs that are cross platform?
  - layer8 2y ago
    Cross-platform desktop UI toolkits generally try to replicate a native look&feel as much as possible.
    - giancarlostoro 2y ago
      Do they? I can usually tell... Most cross-platform GUI stacks I've looked at, the app maybe tweaks the style slightly, but the behavior and look is mostly whatever its own interpretation is, or whatever the developer bothered to do.
- user432678 2y ago
  Following the author for some time and his main point is that “electron” won already, even despite the fact that the author himself doesn’t like it. And he’s not wrong. Majority of desktop users probably don’t care already if it’s native look or not (don’t cite me on that). The goal of the project to provide a way creating quite performant desktop apps with a DX of Clojure. And it’s a nice goal.
  - pelagicAustral 2y ago
    I can relate (I think). I mean, I don't care what the general look of the app is, even if gimmicky of what native desktop looks, as long as the design, general aesthetic, and cohesion are kept well defined, structured and organized. I do not like Electron, I hate to have "little chromes" just so I can do X and Y. I crave true native apps, even if they still look kind of web'ish.
BaculumMeumEst 2y ago
If only Clojure wasn't tied to the fucking JVM
- askonomm 2y ago
  Doesn't have to be: see https://jank-lang.org/ https://jank-lang.org/, https://babashka.org/ https://babashka.org/
- Dansvidania 2y ago
  may I ask what this sentiment comes from? I sincerely want to know what I am missing, because the fact that Clojure is hosted on the JVM (mainly) seems like a plus to me. I don't much like the build tools in the jvm environment such as maven or gradle, and the error messages could be better for sure. Is there more ugliness that I should look into?
  - BaculumMeumEst 2y ago
    What you said, plus applications use a ton of RAM and are a pain in the ass to distribute.
- iLemming 2y ago
  Well, first of all, JVM, even though it still gets a lot of bad rap (mainly due to Java) turns out to be really nice piece of tech, especially if the aim is to scale CPU-intensive tasks. Besides - Clojure is not JVM-only, Clojure is a hosted language, it can work a top of different platforms: JS engine - Clojurescript; Flutter - ClojureDart; Native Code scripting - Babashka; NodeJS - nbb; .Net - Clojure CLR; Fennel even though technically is not a Clojure, is a lovely little language very similar to it and it works on Lua. There's also jank-lang, currently in development that works on top of LLVM. There are a bunch of other Clojure dialects - for Rust, Go, Python, Erlang, etc.
dig1 2y ago
Clojure and Flatlaf [1] tick all the boxes for me. If I want declarative-ish UI, I can always throw in Seesaw [2]. Everything else I find cumbersome, pulls tons of unnecessary dependencies and (usually) ends up abandoned in a year or two. With Swing, I know it is well-documented and will work for the next 30 years. But YMMV and I'm hoping that HumbleUI could be an exception. [1] https://www.formdev.com/flatlaf/ https://www.formdev.com/flatlaf/ [2] https://github.com/clj-commons/seesaw https://github.com/clj-commons/seesaw
- swarthy_avenger 2y ago
  FlatLaf is incredible and breathes new life into the Swing UI framework.
- iamcalledrob 2y ago
  Having worked with Swing recently, I worry that it will not work well on the near-distant future, because it feels frozen in time at about 2005. There are a lot of assumptions baked in that aren't holding up today. For example, high density and multi monitor aren't well supported. There's a bunch of stuff hard-coded in the JDK that no longer makes sense and you have to hack around.
  - vips7L 2y ago
    I haven't worked with FX or Swing lately but I could have sworn they delivered hidpi support. Maybe in this JEP? https://openjdk.org/jeps/263 https://openjdk.org/jeps/263
  - lemming 2y ago
    I recommend using the JetBrains JRE, they have fixed lots of these sorts of issues, as well as greatly improved hot class reloading for development.
cess11 2y ago
What does it bring that https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx does not?

277 points by ducktective 2y ago

webprofusion 2y ago

Lol, checking out the readme. Dunking on stuff isn't what makes you an opinionated framework.

bena 2y ago
I’ve gone over the readme, what part would you say is them dunking? Like, honest question, I do agree with most of their points and don’t think they’re presenting them in a too harsh way

roenxi 2y ago

Really could use a link to the API docs in the README.md, it is a bit hard to judge when the "documentation" such as they have so far is sparse. But it is nice to see a newish UI project. I will say I've found Clojure to be a success story for doing GUI work. Projects like Dave Ray's seesaw (https://github.com/clj-commons/seesaw https://github.com/clj-commons/seesaw) are an amazing demo of how one man can rearchitect an API like Swing into something that is deceptively fun to use. High hopes that this project goes somewhere that is similarly enjoyable.

vips7L 2y ago
There's a lot of languages that just work better for doing declarative ui than Java. Booth Groovy and Scala have wrappers that just make it that much easier. http://groovy-lang.org/dsls.html#swingbuilder http://groovy-lang.org/dsls.html#swingbuilder https://github.com/scala/scala-swing https://github.com/scala/scala-swing
nick__m 2y ago
the Readme says this about the doc: Work in progress. No docs, and everything changes every day.

sieabahlpark 2y ago

[dead]

zombiwoof 2y ago

I love this. Clojure will be perfect for this. Per the other comment, might do less dunking

hyperhello 2y ago

Question about native integration. Does the framework support documents on a native level? Can I define a file type that opens the app when double clicked, maintaining the windows and data, etc?

tonsky 2y ago
Not yet, but in theory, sure

kpw94 2y ago

I'm sure Clojure is a great language for some tasks... But, looking at the examples (picked the Wordle one since I know that game): https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/wordle.clj https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/... I find it extremely hard to read. Even small snippets, say line 56 to 74 which define this "color", "merge-colors" and "colors"... then the "field" one lines 76 to 117 is even harder. is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?) I wonder what the same Wordle example would look like in, say pure Flutter. Also wonder how would that code look with external dependencies (say hitting a server to get the word of the day), and navigation (with maintaining state in between those pages)

trentonstrong 2y ago
"is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?)" As just one person who has written a great deal of functional code, it reads well to me. I think because I am used to reading it "inside out"? Reading lisp-likes is probably helpful. Take 'color' for example. It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the latter at all, yellow. Otherwise we're grey. That took me a few seconds to grok. Just one anecdote for you. Don't think you're broken but reading/writing this kind of code even a little bit will change the way you see code IMO.
- exitb 2y ago
  This is the function that confused the person you respond to, ported to Python: def color(word, letter, idx): if word[idx] == letter: return GREEN elif letter in word: return YELLOW else: return GREY I know which one I'd prefer to grok at 2AM with alerts going off.
  - miroljub 2y ago
    > I know which one I'd prefer to grok at 2AM with alerts going off. At that time I'd just opt for sleep. Or sex. Or drink. Reading code doesn't belong to things one should do at 2AM.

michaelsbradley 2y ago

Cljfx is also worth a look! https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx

Dansvidania 2y ago

Does anyone close to the project know when/if it will no longer be in "No docs, and everything changes every day" release status?

tonsky 2y ago
We have workshop planned for the middle of September, after that, I hope things will start to stabilize a bit. I already started documenting some stuff in examples app, sort of self-documenting integration tests. Will have normal docs too, of course https://s.tonsky.me/share/Screenshot%202024-08-27%20at%2017.31.23.png https://s.tonsky.me/share/Screenshot%202024-08-27%20at%2017....

rlkf 2y ago

I found this dimension of the analysis: > People prefer native apps to web apps > Java has “UI curse”: Looked bad to be at odds with this aspect of the design: > No goal to look native > Leverage Skia

socksy 2y ago
"People prefer native apps to web apps" is talking about literally using an app on your desktop, in the dock, with keyboard shortcuts, rather than having a website in your browser. This is sort of shown by the amount of Electron apps people use — you could use slack, spotify, or vscode in the browser, but most people prefer to use the app. "Java has UI curse" is referring to how when Java tries to imitate native UI (note the difference to "native app", which is in contrast to a web app), it fails and hits the uncanny valley. No-one likes it. Given that, it's not a contradiction to have a native app, that does not try to use the native GUI toolkit of the host platform, using Skia directly to draw UI elements.
- wry_discontent 2y ago
  I used a few electron apps in a browser because the Linux experience wasn't working well for me, and it was a dramatically better experience.
truculent 2y ago
I suppose it’s just to clarify that those choices are deliberate, with the trade-offs in mind. The README also suggests that the reason why people prefer native apps isn’t just the UI’s aesthetics, but: > Normal shortcuts, icon, its own window, file system access, notifications, OS integrations

dzonga 2y ago

where did the myth that people prefer apps that look native to the platform come from? There are two types of apps: 1. the ones that professionals use and 2. the ones that consumers use. for 1. they don't care if it looks native, as long as it works and is performant e.g. DAWs, Video Editing tools, Trading, etc. 2. likewise I don't think it matters that much. my guess is the myth came from OS makers.

layer8 2y ago
Native look&feel makes for a consistent UX across apps. Users learn one set of conventions and UI controls that uniformly applies to all applications. In addition, all applications benefit from enhancements made to the native UI toolkit and integration with the OS (input methods, file dialogs, keyboard navigation, automations, …). Moreover, web UIs tend to be less sophisticated and less power user friendly, due to HTML/CSS and browser API limitations. This unfortunately often carries over even to non-browser-based applications that however use a web-like UI.
- regularfry 2y ago
  There's a slightly deeper part to this which is that if I see a native UI toolkit in use, I can be at least relatively confident that the accessibility affordances I expect to be there haven't been half-arsed in some custom widget set implementation. That's part of the "one set of conventions" expectation you mention, but it's an important one. There's a lot of embedded knowledge in native widgets.
- novagameco 2y ago
  I don't personally believe it's ever been true that users want the same UI styling across apps. When given the option to customize the colors or layout of an app, users will do that. People want their applications to follow common UI patterns, but applications should have some kind of personality to them, otherwise they just look like Microsoft or Apple products
  - troupo 2y ago

layer8 2y ago

The readme says it is aiming for a “web look”, with no intention to make it look — and, presumably, behave — native. As a user, that’s not what I expect and hope for from a desktop application.

giancarlostoro 2y ago
Isn't this the case with a lot of desktop GUIs that are cross platform?
- layer8 2y ago
  Cross-platform desktop UI toolkits generally try to replicate a native look&feel as much as possible.
  - giancarlostoro 2y ago
    Do they? I can usually tell... Most cross-platform GUI stacks I've looked at, the app maybe tweaks the style slightly, but the behavior and look is mostly whatever its own interpretation is, or whatever the developer bothered to do.
user432678 2y ago
Following the author for some time and his main point is that “electron” won already, even despite the fact that the author himself doesn’t like it. And he’s not wrong. Majority of desktop users probably don’t care already if it’s native look or not (don’t cite me on that). The goal of the project to provide a way creating quite performant desktop apps with a DX of Clojure. And it’s a nice goal.
- pelagicAustral 2y ago
  I can relate (I think). I mean, I don't care what the general look of the app is, even if gimmicky of what native desktop looks, as long as the design, general aesthetic, and cohesion are kept well defined, structured and organized. I do not like Electron, I hate to have "little chromes" just so I can do X and Y. I crave true native apps, even if they still look kind of web'ish.

BaculumMeumEst 2y ago

If only Clojure wasn't tied to the fucking JVM

askonomm 2y ago
Doesn't have to be: see https://jank-lang.org/ https://jank-lang.org/, https://babashka.org/ https://babashka.org/
Dansvidania 2y ago
may I ask what this sentiment comes from? I sincerely want to know what I am missing, because the fact that Clojure is hosted on the JVM (mainly) seems like a plus to me. I don't much like the build tools in the jvm environment such as maven or gradle, and the error messages could be better for sure. Is there more ugliness that I should look into?
- BaculumMeumEst 2y ago
  What you said, plus applications use a ton of RAM and are a pain in the ass to distribute.
iLemming 2y ago
Well, first of all, JVM, even though it still gets a lot of bad rap (mainly due to Java) turns out to be really nice piece of tech, especially if the aim is to scale CPU-intensive tasks. Besides - Clojure is not JVM-only, Clojure is a hosted language, it can work a top of different platforms: JS engine - Clojurescript; Flutter - ClojureDart; Native Code scripting - Babashka; NodeJS - nbb; .Net - Clojure CLR; Fennel even though technically is not a Clojure, is a lovely little language very similar to it and it works on Lua. There's also jank-lang, currently in development that works on top of LLVM. There are a bunch of other Clojure dialects - for Rust, Go, Python, Erlang, etc.

dig1 2y ago

Clojure and Flatlaf [1] tick all the boxes for me. If I want declarative-ish UI, I can always throw in Seesaw [2]. Everything else I find cumbersome, pulls tons of unnecessary dependencies and (usually) ends up abandoned in a year or two. With Swing, I know it is well-documented and will work for the next 30 years. But YMMV and I'm hoping that HumbleUI could be an exception. [1] https://www.formdev.com/flatlaf/ https://www.formdev.com/flatlaf/ [2] https://github.com/clj-commons/seesaw https://github.com/clj-commons/seesaw

swarthy_avenger 2y ago
FlatLaf is incredible and breathes new life into the Swing UI framework.
iamcalledrob 2y ago
Having worked with Swing recently, I worry that it will not work well on the near-distant future, because it feels frozen in time at about 2005. There are a lot of assumptions baked in that aren't holding up today. For example, high density and multi monitor aren't well supported. There's a bunch of stuff hard-coded in the JDK that no longer makes sense and you have to hack around.
- vips7L 2y ago
  I haven't worked with FX or Swing lately but I could have sworn they delivered hidpi support. Maybe in this JEP? https://openjdk.org/jeps/263 https://openjdk.org/jeps/263
- lemming 2y ago
  I recommend using the JetBrains JRE, they have fixed lots of these sorts of issues, as well as greatly improved hot class reloading for development.

cess11 2y ago

What does it bring that https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx does not?