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

Native all the way, until you need text

justsitandgrin.im

Post reply on HN
Print view View original

251–260 of 328 posts

Re: Native all the way, until you need text

#251

Post by domga »

mpweiher wrote: post #191
Dwedit wrote: post #68

Earlier quoted context omitted.

Now RAM use is the main reason to prefer native APIs over web views.

I am not sure WebViews are the actual problem, and fairly confident it is running the entire application + gargantuan frameworks as JavaScript is. I am currently working on something I call HTMXNative, which is what it sounds like: using HTMX in WebViews for hybrid apps. I haven't really looked much at memory consumption, but when I've looked so far it's been very comparable to equivalent apps using native UI.

The issue with JS is that each page gets its own execution context so they don’t share any memory. I am actually curious what does the WebView do to save on RAM here?

Re: Native all the way, until you need text

#252

Post by domga »

mpweiher wrote: post #131
ajross wrote: post #111

Earlier quoted context omitted.

This is the ActiveX/nacl/wasm/etc... argument recapitulated. For decades, people dithered about how to get fast code into browser environments such that it could be deployed safely. Then the V8 team at Google just asked "well, what if we just made Javascript crazy fast instead?", and here we are. There's still room for native code in environments that don't map nicely to scalar scripting languages, but not a lot of r…

Except JavaScript isn't "crazy fast". Not by a long shot. How did Microsoft just make Typescript 10x faster? Oh right, by reimplementing it in Go. https://devblogs.microsoft.com/typescript/typescript-native-... See also: https://blog.metaobject.com/2015/10/jitterdammerung.html Please don't use Electron.

The problem with Electron is not that people choose it over native tech like WPF or SwiftUI, they choose it over nothing. Without Electron tons of cross platform apps simply wouldn’t exist.

I think macOS suffers the most since it is not that hard to port an iOS app to Mac, and Linux benefits the most.

Re: Native all the way, until you need text

#253

Post by spockz »

cosmic_cheese wrote: post #133
titzer wrote: post #103

Earlier quoted context omitted.

> Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps. They suck on older hardware. Old Chromebooks are a dime a dozen and are decently spec'd light use or purpose-use machines. Browsers run like crap on them.

Web tech in general is responsible for a lot of unnecessary hardware turnover. If you dig up an 18 year old Core 2 Duo box, upgrade its storage to a cheap SSD, and install Linux on it, it’s shocking how snappy and usable it is for most tasks… up until you open a web browser or Electron app. Then it all falls apart. Had it not been for resource creep driven overwhelmingly by heavy web apps and Electron/CEF, there’d be…

I was of this conviction as well. However, since I installed CachyOS on my old desktop (6800k+32gib DDR4, SSDs) I have comparison material with my AMD 5900X and the difference is night and day.

Booting to the password prompt for the encrypted drive alone takes 10+s versus 1-2s. Then booting into desktop is also considerably slower (but oddly not 5x).

Then performance compiling is miles apart with 20x at minimum.

Yes, the “native” apps are still snappy but at any time you require compute you will feel the lack of power. Funnily enough it doesn’t seem to matter too much for the games that I play.

Re: Native all the way, until you need text

#254

Post by vor_ »

CharlesW wrote: post #114
rubymamis wrote: post #77

Earlier quoted context omitted.

It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps. [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20... [2] https://x.com/daniel_nguyenx/status/…

> It's SwiftUI that is at fault here, not native apps in general. The article you cited is from 2022 and so is irrelevant, since SwiftUI's performance profile completely changed as of xOS 26. Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory, but more importantly, the reality is there are only "SwiftUI-first apps". All non-trivial SwiftUI-first apps will also use UIKit/AppKit as…

> Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory

I don't know why SwiftUI evangelists are still doing this in 2026. How many examples of SwiftUI's poor performance have to be demonstrated over the years? Even basic things like List continue to lag behind NSTableView in the most recent releases.

Re: Native all the way, until you need text

#255

Post by vor_ »

CharlesW wrote: post #70
inatreecrown2 wrote: post #7

Not just text. Try to build a ui where you need non-trivial and non-standard behavior and SwiftUI will fail. AppKit is still better in this regard.

> Try to build a ui where you need non-trivial and non-standard behavior and SwiftUI will fail. I think this may be a misundertstanding of what SwiftUI is. SwiftUI makes it convenient to create apps that look and behave in a way that align with Apple's HIG using controls like `List`, `Form`, etc., but nothing makes you use any of those. For example, it's straightfoward to build a game engine on SwiftUI. https://blog.…

They're saying that if you try to step outside the box or achieve a complex design, SwiftUI falls short, which is also my experience with the framework after using it for many years, especially on macOS.

Re: Native all the way, until you need text

#256

Post by Bolwin »

singpolyma3 wrote: post #154
StilesCrisis wrote: post #93

Earlier quoted context omitted.

Qt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible.

Unless you're on KDE where it's literally native?

Not unless you use their theme system and components from my understanding.

Re: Native all the way, until you need text

#257

Post by bobajeff »

RustSupremacist wrote: post #220
ogoffart wrote: post #119

Earlier quoted context omitted.

If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/

This is not what the people want. Understand that. Give us Rust and Qt. Why be so focused on trying to sell something that doesn't measure up? Even beta Bridges is better than Slint. Take the advice and put the energy to better use for the good of Rust.

Qt Bridges might be better if your project can use the `Qt Design Studio Enterprise license`. Otherwise Slint looks like the better option.

Not that I'd use either when I can just make a Web based UI most of the time and be done with it.

Re: Native all the way, until you need text

#258

Post by Bolwin »

mpweiher wrote: post #131
ajross wrote: post #111

Earlier quoted context omitted.

This is the ActiveX/nacl/wasm/etc... argument recapitulated. For decades, people dithered about how to get fast code into browser environments such that it could be deployed safely. Then the V8 team at Google just asked "well, what if we just made Javascript crazy fast instead?", and here we are. There's still room for native code in environments that don't map nicely to scalar scripting languages, but not a lot of r…

Except JavaScript isn't "crazy fast". Not by a long shot. How did Microsoft just make Typescript 10x faster? Oh right, by reimplementing it in Go. https://devblogs.microsoft.com/typescript/typescript-native-... See also: https://blog.metaobject.com/2015/10/jitterdammerung.html Please don't use Electron.

The author said the mean reason for the speedup was parallelization, not Go being particularly faster. The JS JIT is very good. In most benchmarks I've seen its not much slower than Go.

Re: Native all the way, until you need text

#259

Post by CharlesW »

vor_ wrote: post #254
CharlesW wrote: post #114

Earlier quoted context omitted.

> It's SwiftUI that is at fault here, not native apps in general. The article you cited is from 2022 and so is irrelevant, since SwiftUI's performance profile completely changed as of xOS 26. Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory, but more importantly, the reality is there are only "SwiftUI-first apps". All non-trivial SwiftUI-first apps will also use UIKit/AppKit as…

> Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory I don't know why SwiftUI evangelists are still doing this in 2026. How many examples of SwiftUI's poor performance have to be demonstrated over the years? Even basic things like List continue to lag behind NSTableView in the most recent releases.

All I have is my own experience. In my current app, my views are 100% SwiftUI. One of them uses a SwiftUI List which typically has hundreds of thousands of items, each with title, subtitle, duration, cover art, etc. I expect it would still be butter-smooth at 1M items.

Was my initial naive implementation as performant? No. My point is that optimization still matters in SwiftUI, and that optimization looks quite a bit different in SwiftUI than it does in AppKit/UIKit.

Re: Native all the way, until you need text

#260

Post by cosmic_cheese »

spockz wrote: post #253
cosmic_cheese wrote: post #133

Earlier quoted context omitted.

Web tech in general is responsible for a lot of unnecessary hardware turnover. If you dig up an 18 year old Core 2 Duo box, upgrade its storage to a cheap SSD, and install Linux on it, it’s shocking how snappy and usable it is for most tasks… up until you open a web browser or Electron app. Then it all falls apart. Had it not been for resource creep driven overwhelmingly by heavy web apps and Electron/CEF, there’d be…

I was of this conviction as well. However, since I installed CachyOS on my old desktop (6800k+32gib DDR4, SSDs) I have comparison material with my AMD 5900X and the difference is night and day. Booting to the password prompt for the encrypted drive alone takes 10+s versus 1-2s. Then booting into desktop is also considerably slower (but oddly not 5x). Then performance compiling is miles apart with 20x at minimum. Yes,…

Of course there’s a speed difference, but boot times are only occasionally dealt with and only the tiny handful of people capable of developing software will ever need to compile anything.

Also worth noting that if computers had been frozen at Skylake speeds for the past decade, it’s almost a certainty that more attention would’ve been paid to performance since that would’ve been the only way to make computers faster. Countless bits of low hanging fruit in optimization have been ignored because power increases have papered over them, and cumulatively their impact is significant.

Post reply on HN