zlacker

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

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

>>hombre+bk8
>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+Hv8
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.

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

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