Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure Desktop UI Framework

github.com

Post reply on HN
Print view View original

81–90 of 139 posts

Re: Clojure Desktop UI Framework

#81

Post by wry_discontent »

socksy wrote: post #29
rlkf wrote: post #26

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

"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 (…

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.

Re: Clojure Desktop UI Framework

#82

Post by Bjartr »

hombre_fatal wrote: post #74
diggan wrote: post #65

Earlier quoted context omitted.

Professional software (think Clip Studio Art, 3DS Max, Autodesk Fusion and alike) are almost exclusively disconnected from "native" looks, behavior and theming, which is perfectly fine, better than having a different experience depending on your OS. I feel like it's mostly consumers who ask for native look, and particular users on macOS, as almost all other professional-oriented software doesn't offer that. But yet i…

I doubt most consumers ask for a native look. It's more like an HN meme. I don't even think native macOS UI is so great cross-plat programs should target it. It's full of its own weird conventions like a "New item" button being a tiny "+" at the bottom of the left sidebar, the last place I always look. Safari is an example of UX that has stuck to hard macOS conventions and was always worse off for it. Not until recen…

> I doubt most consumers ask for a native look. It's more like an HN meme.

The preference for native look was once about the impact of familiarity on usability. When 95% of people's interactions with computers was a single OS and native apps, they would expect controls to look a particular way. They could figure out other variants, sure, but from a UX design perspective, there's little reason to add that minor cognitive overhead needlessly.

Today, people's experiences are less likely to be monoculture like they once were, which dilutes one of the values of native controls. That's not to say designing with familiarity of controls in mind doesn't have value, just that it's less about, for example, buttons looking like buttons native to the OS, and more about visually reading as "this is a button" more generally.

Re: Clojure Desktop UI Framework

#83

Post by itishappy »

exitb wrote: post #30
trentonstrong wrote: post #11

Earlier quoted context omitted.

"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 br…

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.

Honestly both read about the same to me, and I'm largely unfamiliar with Clojure. The main difference appears to be the 3 `str` callouts, which appear extraneous as the following version works just the same:

    (defn color [word letter idx]
      (cond
        (= (nth word idx) letter) :green
        (str/includes? word letter) :yellow
        :else :gray))
Interesting that even with the `str` callouts removed, the function still appears to work on other datatypes such as:

    (def s (seq ("test1"))
A lazy sequence, but one Clojure still allows to be indexed over in O(1) time. That's probably what the `str` conversion was trying to speed up.

Python, meanwhile, fails on lazy input as it isn't indexable.

    word = (c for c in "test1")
I guess I'll be checking out Clojure this weekend.

Re: Clojure Desktop UI Framework

#84

Post by ducktective »

hombre_fatal wrote: post #74
diggan wrote: post #65

Earlier quoted context omitted.

Professional software (think Clip Studio Art, 3DS Max, Autodesk Fusion and alike) are almost exclusively disconnected from "native" looks, behavior and theming, which is perfectly fine, better than having a different experience depending on your OS. I feel like it's mostly consumers who ask for native look, and particular users on macOS, as almost all other professional-oriented software doesn't offer that. But yet i…

I doubt most consumers ask for a native look. It's more like an HN meme. I don't even think native macOS UI is so great cross-plat programs should target it. It's full of its own weird conventions like a "New item" button being a tiny "+" at the bottom of the left sidebar, the last place I always look. Safari is an example of UX that has stuck to hard macOS conventions and was always worse off for it. Not until recen…

>I doubt most consumers ask for a native look. It's more like an HN meme.

So you're ok with a mp3 player that takes 6 seconds to start up, is janky when it starts, takes 300MB of RAM, every row item is 100px high and every interaction with every UI element takes a noticeable delay on the order of 100x milliseconds?

And you're gonna tolerate the same story with the file explorer app, the archive/zip app, the WiFi SSID selection dialog, etc?

Re: Clojure Desktop UI Framework

#85

Post by hyperhello »

exitb wrote: post #30
trentonstrong wrote: post #11

Earlier quoted context omitted.

"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 br…

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.

Having written a wordle clone recently, this produces the wrong result, by the way. For example guess SASSY with the answer STICK.

Re: Clojure Desktop UI Framework

#86

Post by swarthy_avenger »

dig1 wrote: post #72

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/ [2] h…

FlatLaf is incredible and breathes new life into the Swing UI framework.

Re: Clojure Desktop UI Framework

#87

Post by VertanaNinjai »

ducktective wrote: post #84
hombre_fatal wrote: post #74

Earlier quoted context omitted.

I doubt most consumers ask for a native look. It's more like an HN meme. I don't even think native macOS UI is so great cross-plat programs should target it. It's full of its own weird conventions like a "New item" button being a tiny "+" at the bottom of the left sidebar, the last place I always look. Safari is an example of UX that has stuck to hard macOS conventions and was always worse off for it. Not until recen…

>I doubt most consumers ask for a native look. It's more like an HN meme. So you're ok with a mp3 player that takes 6 seconds to start up, is janky when it starts, takes 300MB of RAM, every row item is 100px high and every interaction with every UI element takes a noticeable delay on the order of 100x milliseconds? And you're gonna tolerate the same story with the file explorer app, the archive/zip app, the WiFi SSID…

What did any of your points have to with the topic of “native look”?

Re: Clojure Desktop UI Framework

#88

Post by greener_grass »

diggan wrote: post #65
layer8 wrote: post #32

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.

Professional software (think Clip Studio Art, 3DS Max, Autodesk Fusion and alike) are almost exclusively disconnected from "native" looks, behavior and theming, which is perfectly fine, better than having a different experience depending on your OS. I feel like it's mostly consumers who ask for native look, and particular users on macOS, as almost all other professional-oriented software doesn't offer that. But yet i…

For Linux users it's a non-native look-and-feel or no app at all.

Re: Clojure Desktop UI Framework

#89

Post by Zak »

ducktective wrote: post #84
hombre_fatal wrote: post #74

Earlier quoted context omitted.

I doubt most consumers ask for a native look. It's more like an HN meme. I don't even think native macOS UI is so great cross-plat programs should target it. It's full of its own weird conventions like a "New item" button being a tiny "+" at the bottom of the left sidebar, the last place I always look. Safari is an example of UX that has stuck to hard macOS conventions and was always worse off for it. Not until recen…

>I doubt most consumers ask for a native look. It's more like an HN meme. So you're ok with a mp3 player that takes 6 seconds to start up, is janky when it starts, takes 300MB of RAM, every row item is 100px high and every interaction with every UI element takes a noticeable delay on the order of 100x milliseconds? And you're gonna tolerate the same story with the file explorer app, the archive/zip app, the WiFi SSID…

This comment responds to the idea of native look being important with a list of performance issues. Whether software should be efficient and responsive is separate from whether it should look native to the OS it's running on.

Re: Clojure Desktop UI Framework

#90

Post by jdminhbg »

exitb wrote: post #30
trentonstrong wrote: post #11

Earlier quoted context omitted.

"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 br…

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.

I do definitely get more 2AM alerts going off when I work with Python, so it's got that going for it.
Post reply on HN