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

101–110 of 139 posts

Re: Clojure Desktop UI Framework

#101

Post by kazinator »

itishappy wrote: post #83
exitb wrote: post #30

Earlier quoted context omitted.

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…

I'm guessing that str allow it to work when the inputs are symbols? So that they are compared as strings rather than by identity. There could be more than one symbol named "foo"; if you want those to compare the same, you can't use regular symbol equality.

Or possibly the code even uses non-symbols for some of the arguments. Suppose that letter is sometimes the integer 1.

Re: Clojure Desktop UI Framework

#102

Post by giancarlostoro »

layer8 wrote: post #93
giancarlostoro wrote: post #53

Earlier quoted context omitted.

Isn't this the case with a lot of desktop GUIs that are cross platform?

Cross-platform desktop UI toolkits generally try to replicate a native look&feel as much as possible.

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.

Re: Clojure Desktop UI Framework

#103

Post by nine_k »

chrisldgk wrote: post #99
diggan wrote: post #75

Earlier quoted context omitted.

> And Win10 on my wife's machine is a salad, reminding me of Linux desktop experience from 1998. This is pretty funny, because if you just use Gnome apps + desktop environment, you have a consistent experience. But if you only use Microsoft/Windows GUIs, panels and applications, it nowhere near as consistent. So even the Gnome team can build better UI and UX than Windows themselves can, pretty telling.

> even the Gnome team People like to hate on them, but their design is actually really good, innovative and the applications running on GTK are incredibly fast and stable.

I'm not a fan of some of their UX design decisions, but I must admit that they seemingly know what they're doing, and their execution / implementation is pretty good.

I also hope that, unlike MS, they have no infighting between departments, and no stack ranking.

Re: Clojure Desktop UI Framework

#104

Post by iamcalledrob »

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…

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.

Re: Clojure Desktop UI Framework

#105

Post by klabb3 »

Pet_Ant wrote: post #94
Zak wrote: post #89

Earlier quoted context omitted.

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.

Having a bespoke widget tool kit with themeing etc uses more memory and cycles instead of just being a simple app with the native desktop widgets.

Even if that is true in the general case (it isn't necessarily - there are many factors), it’s a matter of what’s acceptable, not a race to 1000fps. If you build a webview based app (using eg tauri) I can assure you that it can be extremely snappy, As an example, look at typical popular iOS apps: they’re often 100-500 Mb, even though they have absolutely no reason to be. LinkedIn is 400Mb, random airline app is 300Mb. Banking app? 350Mb.

Is it bad to bundle Chrome and NodeJS? Yes, undoubtedly (but that’s already changing). Is that the only way to deploy web-based apps to desktop? No. Is native UI gonna fix it? Temporarily at best, while the platform’s native ecosystem is simply too small to cause that level of bloat.

Re: Clojure Desktop UI Framework

#106

Post by gaze »

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 are you talking about? Electron isn't the only tool to make non-native UI.

Re: Clojure Desktop UI Framework

#107

Post by mixmastamyk »

chrisldgk wrote: post #99
diggan wrote: post #75

Earlier quoted context omitted.

> And Win10 on my wife's machine is a salad, reminding me of Linux desktop experience from 1998. This is pretty funny, because if you just use Gnome apps + desktop environment, you have a consistent experience. But if you only use Microsoft/Windows GUIs, panels and applications, it nowhere near as consistent. So even the Gnome team can build better UI and UX than Windows themselves can, pretty telling.

> even the Gnome team People like to hate on them, but their design is actually really good, innovative and the applications running on GTK are incredibly fast and stable.

As long as you don’t use title bars, menus, or scrollbars you’re golden.

Re: Clojure Desktop UI Framework

#108

Post by rafaelmn »

Pet_Ant wrote: post #94
Zak wrote: post #89

Earlier quoted context omitted.

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.

Having a bespoke widget tool kit with themeing etc uses more memory and cycles instead of just being a simple app with the native desktop widgets.

Unless you think native UI runs on magic - it's not that hard to outperform native rendering - you have to be way less general with a bespoke framework (up to a certain point of complexity).

Re: Clojure Desktop UI Framework

#109

Post by xyc »

Pet_Ant wrote: post #94
Zak wrote: post #89

Earlier quoted context omitted.

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.

Having a bespoke widget tool kit with themeing etc uses more memory and cycles instead of just being a simple app with the native desktop widgets.

VS Code vs XCode situation is an exact counter example of this. Non-optimized native apps could be that much slower than well optimized Electron apps.

Re: Clojure Desktop UI Framework

#110

Post by zem »

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…

that is precisely what people in this thread are talking about - users want native performance and memory footprint, they aren't concerned with native look and feel.
Post reply on HN