zlacker

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.

>>layer8+(OP)
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.

>>user43+41
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.

>>user43+41
There's no native app, even on desktops. There are a bazillion of different UI frameworks with different look & feel on Windows alone, even within Microsoft products. On Linux or macOS, the situation is no better.

Native is what doesn't run in an emulator, in this case everything non-Electron fits the definition.

>>layer8+(OP)
At this point it feels like this argument is dead an buried. So many non-native apps on every platform, most platforms even have multiple official GUI toolkits/widget styles so even first party apps are inconsistent.

>>layer8+(OP)
Isn't this the case with a lot of desktop GUIs that are cross platform?

>>rafael+Gc
The most consistently-looking desktop I have runs under Linux. With a few settings and a right theme, all GTK2, GTK3, Qt, and Java apps look and feel pretty much the same, in a pleasant way.

MacOS is a close second, with a few native apps that can't decide exactly what a checkbox or a button should look like.

And Win10 on my wife's machine is a salad, reminding me of Linux desktop experience from 1998.

>>layer8+(OP)
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 it comes up for every GUI toolkit that lands on the HN frontpage.

>>mirolj+T2
There are native apps, but appa are native to a desktop environment rather than to an operating system.

Unfortunately desktop environments on some proprietary operating systems are themselves comprised of apps written with different toolkits and bearing different looks and feels. But that's just a problem specific to them. KDE apps are all maybe to Plasma, GNOME apps are all native to GNOME.

>>mirolj+T2
WinUI 3 aims to be native, but of course Windows is a tapestry of many eras of Microsoft UI styles. If Microsoft doesn't again change their mind on how Windows should look, then WinUI 3 is indeed the look and behaviour that people will be expecting on a Windows machine.

>>diggan+Es
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 recently did it begin relenting, and now it's bearable to use as a daily driver. Xcode is another classic example of hostile native macOS UX conventions. Finder.app is another.

I'd rather software ask "what's the UX that makes the most sense?" rather than "how can I make my UI look native?" On HN people seem to think by solving the latter, you solve the former. But that isn't the case.

>>nine_k+tq
> 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.

>>layer8+(OP)
It’s a tradeoff. You either make your app native but only for one platform, or you make it look “universal” and run on all three.

>>hombre+dC
> 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.

>>hombre+dC
>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?

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

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

>>duckte+JN
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.

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

>>Zak+nR
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.

>>tonsky+oH
That’s not accurate, there are cross-platform toolkits that achieve at least a close-to-native look&feel. This is very different from giving up on it entirely and going web-style UI.

>>layer8+gY
If they use native widgets, they usually look really bad If they just “imitate” look and feel, they usually fall very short of the real thing

Either way, it’s bad experience for the end user

>>diggan+TF
> 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.

>>layer8+JX
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.

>>chrisl+R31
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.

>>Pet_An+QX
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, <1% cpu while active and low memory, provided you use sensible dev practices like not import half of npm. Contrary to popular HN belief, web browsers are ridiculously optimized both in terms of rendering and JITed JS execution. The reason web based applications are often perf hogs is not because, but despite the execution environment. Businesses simply don’t prioritize perf, independent of platform.

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.

>>duckte+JN
what are you talking about? Electron isn't the only tool to make non-native UI.

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

>>Pet_An+QX
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).

>>Pet_An+QX
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.

>>duckte+JN
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.

>>chrisl+R31
> People like to hate on them, but their design is actually really good

I'm not complaining/hating, Gnome is my desktop environment of choice since some time ago.

Was more a nod to how awful Microsoft seems to (still) be at UI and UX.

>>xyc+Zq1
That's not an apt comparison because it could be the non-UI portion of that. VS Code would be even faster if it was a native app.

>>nine_k+tq
I couldn't agree more, and would even say more that Windows is just such a mess. Often even new windows programs look like they are from the days of Windows 98.

>>layer8+gY
Do you mean the state of the art java AWT and/or Eclipse toolkit?

>>Pet_An+qG1
Not really. VS Code does have some performance optimizations where even the web browser optimization wouldn't suffice, for example it implements its own scroll bar instead of using the web native scroll bar. But for the most part the browser render optimizations is the crucial factor. After years of optimization you can't easily beat a web browser.

Native app is just another set of layers of abstractions. As a comparison, SwiftUI doesn't render 500 items quickly enough (https://www.reddit.com/r/swift/comments/18dlgv0/improving_pe...), which is a tiny number for web.

>>tonsky+S11
I don't know, I think the Racket GUI toolkit and JavaFX work fine for building cross platform standalone applications.

>>cess11+kH2
That’s two perfect examples! Racket seems to try to use native widgets, and looks horrible as a result, at least on macOS

JavaFX uses the same approach as Humble UI: they draw all the widgets themselves and have custom cross-platform look and feel.

We aim to be better quality version of JavaFX