zlacker

>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+(OP)
What did any of your points have to with the topic of “native look”?

>>duckte+(OP)
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+E3
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+7a
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+(OP)
what are you talking about? Electron isn't the only tool to make non-native UI.

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

>>xyc+gD
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.

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