| ▲ | pornel 6 hours ago |
| Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more. Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps. Meanwhile SwiftUI doesn't feel particularly fast. Apple's latest and greatest rewrite of System Preferences has dumbed down the UI to mostly rows of checkboxes, and yet switching between sections can lag worse than loading web pages from us-east-1. |
|
| ▲ | rubymamis 5 hours ago | parent | next [-] |
| 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/1734495508746702936 [3] https://rubymamistvalove.com/block-editor#8-performance |
| |
| ▲ | CharlesW 4 hours ago | parent | next [-] | | > 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 needed, typically for capabilties that aren't yet available via SwiftUI. | | |
| ▲ | silvestrov 3 hours ago | parent | next [-] | | iOS 26 is very late to have acceptable performance in the framework that Apple promotes as what you should use. It should have had good performance from the day it was introduced. WebKit have had great performance for a very long time now. Why would any startup dare to use tech that only now got fast? Why not go with the battle tested WebKit? It is also much easier to develop and test html pages than Apple specific tech. | |
| ▲ | KerrAvon an hour ago | parent | prev [-] | | Can you point to a single performant, high-quality SwiftUI-first app with a messages-like chronological transcript and correct scrolling behavior on macOS? The problems with AppKit integration are real and should not be dismissed out of hand. |
| |
| ▲ | StilesCrisis 5 hours ago | parent | prev [-] | | Qt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible. | | |
| ▲ | jeremyjh 4 hours ago | parent | next [-] | | They even used the distinction “native-like” in the block editor article - which is really good, by the way and explains this distinction in more depth - but edited their comment now and that article is the third link and its anchored to the performance section so you won’t see that unless you scroll to the top. Their point is more that SwiftUI has generally poor performance. Lots of native Windows frameworks have poor performance as well. Native UI development is a minefield. If you want to build an app today that will still run in 20 years without a complete rewrite in the UI layer you should probably use wxWidgets if you are committed to native - even if only targeting one OS. But that model is really only appropriate for building traditional desktop apps. I don’t think the market would accept a Slack or Notion built that way today. | |
| ▲ | tux3 3 hours ago | parent | prev | next [-] | | At this point on Win32 Qt might as well be the native UI. They did a better job of maintaining a coherent visual theme that says "Windows" and fits the design patterns than the actual owners of the platform. | | |
| ▲ | StilesCrisis 8 minutes ago | parent [-] | | I disagree. I use P4V (Qt-based) regularly. Its lists are quirky and sometimes don't scale property with the OS DPI settings. |
| |
| ▲ | singpolyma3 3 hours ago | parent | prev | next [-] | | Unless you're on KDE where it's literally native? | |
| ▲ | 4 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | 4 hours ago | parent | prev [-] | | [deleted] |
|
|
|
| ▲ | embedding-shape 5 hours ago | parent | prev | next [-] |
| > Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps. Even so, there is a stark difference, even more so on low-powered devices, between native apps and even the lightest of browser apps. I'm traditionally a web developer, but started developing native cross-platform applications the last 6-12 months, and the performance gap is pretty big even for simple stuff, strangely enough. |
| |
| ▲ | trinix912 an hour ago | parent [-] | | My experience too, and that's not even touching the disproportionately high RAM usage of frameworks like Electron. Sure, "unused RAM is wasted RAM", until the system starts swapping heavily because of the high RAM usage. It doesn't even have to be old devices, there are still laptops being sold with 8GB of RAM in 2026. |
|
|
| ▲ | titzer 5 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | cosmic_cheese 4 hours ago | parent | next [-] | | 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 little reason for most people to use anything more powerful than a Sandy Bridge machine and we could have laptops and smartphones with week-long battery life thanks to efficiency gains not needing to be consumed by performance increases. | | |
| ▲ | Narishma 3 hours ago | parent | next [-] | | > 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. Can confirm. I'm typing this on such an old Core 2 Duo laptop running Debian and even with only 4GB of RAM and a mechanical HDD, it's still very fast for everything I do on it that doesn't involve Web browsers. Windows 10 is practically unusable on it however. The gazillion background things it insists on running bring it to a crawl, mostly stuck on disk I/O. | |
| ▲ | tombert an hour ago | parent | prev [-] | | Agreed. I have a shitty laptop I bought at Micro Center a couple years ago for like $80. I bought it mostly out of curiosity since I wanted to see what an $80 laptop would be capable of. I installed NixOS minimal on there and a few apps to develop, and it was actually quite usable. Then I installed Skype on there and it was horrible and laggy. |
| |
| ▲ | nolist_policy an hour ago | parent | prev [-] | | > Chromebooks Have you tried with stock ChromeOS? |
|
|
| ▲ | iTokio 5 hours ago | parent | prev | next [-] |
| Well, maybe for simple web apps, but for complex applications there is a noticeable slowdown, I am not even talking about monsters such as jira, but well optimized apps such as vs code, there is a performance ceiling which is lower than for native apps. |
| |
| ▲ | sznio 4 hours ago | parent | next [-] | | For Jira I think the limitation is buried all the backend execution and rendering. It's still fast if you go only by the frontend user-executed part. | |
| ▲ | pornel 2 hours ago | parent | prev | next [-] | | [dead] | |
| ▲ | StilesCrisis 5 hours ago | parent | prev [-] | | According to the article, native is slower though. | | |
| ▲ | CharlesW 4 hours ago | parent [-] | | TFA actually says the developer couldn't figure out how to do this with native APIs, not that they're slower: "But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message." Electron ultimiately sits on native APIs, and has its own performance costs on top of them. | | |
| ▲ | StilesCrisis 15 minutes ago | parent | next [-] | | Electron sits on top of Skia, which renders the text itself. It's designed to look like the host OS but it's not just asking the OS to draw text, because that's actually a lot slower than Skia. | |
| ▲ | ryeights 3 hours ago | parent | prev | next [-] | | Electron sits on native rendering primitives. Do you suggest that every developer who wants rich interactive text in their app should write a text rendering engine from the ground up? | | | |
| ▲ | bonesss 4 hours ago | parent | prev [-] | | If you account for dev time, ‘giving up’ and just doing it in a web renderer is totally valid. Choppier, more memory, bad if the device is failing, but 98% of the time that can be acceptable. Native GUI dev, tho, can enable low-resource performant apps just by sticking the rudimentary OS is a way no higher app really can, and with capabilities that’d choke a web app. Load up a listbox with a few tens of thousands of items with custom rendering… as a fat client dev you’re only in a little trouble, on the web googlers making google apps force pagination a whole lot. As a point of comparison: WPF was Microsoft’s attempt to nail the ‘best of the desktop & best of the web’ [And I would argue they effectively nailed it, as a specification.]. But, as a brown belt WPF dev and a blue/orange belt with Win32/MFC, the extra overhead related to WPF broke common scenarios we’d never think twice about on the true native side. The web was made for sharing Robotech technical manuals, OS GUI’s to pump all the rectangles as fast as hardware allows. Apples and oranges. | | |
| ▲ | CharlesW 3 hours ago | parent [-] | | > If you account for dev time, ‘giving up’ and just doing it in a web renderer is totally valid. For sure, all software is chock full of "best? no/works? yes" compromises. I object to the article framing of "I couldn't figure it out, therefore TextKit 2 does not play well with anything modern", which is a very silly conclusion. | | |
| ▲ | bonesss 3 hours ago | parent [-] | | Agreed, but no such conclusion or framing was stated, supported, or suggested in my comment. I was agreeing and providing more context to the costs of building at a higher level, like Electron, and the limits even when applied by a unified vendor with incentives for high performance. | | |
| ▲ | CharlesW 3 hours ago | parent [-] | | I added the word "article" before the word "framing" to make it clearer in my comment supporting your comment that the last half of my comment wasn't commenting on your comment. |
|
|
|
|
|
|
|
| ▲ | hackermanai an hour ago | parent | prev | next [-] |
| > Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more. It's still true. There's no way around it, web views will always be slower. |
|
| ▲ | krzyzanowskim 5 hours ago | parent | prev | next [-] |
| SwiftUI, (but not specifically "SwiftUI", more of paradigm) is not the right tool to incremental changes of large portion of data, and SwiftUI specifically is very bad at it and offer no good API to make incremental changes more optimal. That's one of the reason behind why Apple to this day did not ship usable SwiftUI text view component. |
| |
| ▲ | CharlesW 5 hours ago | parent [-] | | They did last year. I can understand why you're confused, since it came in the form of the radically-improved `TextEditor`. https://wwdcnotes.com/documentation/wwdcnotes/wwdc25-280-cod... | | |
| ▲ | krzyzanowskim 3 hours ago | parent [-] | | I don't know where's the improvements, give it has all the limitations, now scaled to rich text. That's not the direction that this component should get. It need radical new API that is not much compatible with SwiftUI API | | |
| ▲ | CharlesW 2 hours ago | parent [-] | | You must know far more about this than me, but as of iOS 26, `TextEditor` evolved into a true rich text editor (`AttributedString` binding, `AttributedTextSelection` rich text selection, custom/app-specific text attributes, etc). https://developer.apple.com/videos/play/wwdc2025/280/ Do you really think people should use web views instead of, say, STTextView? | | |
|
|
|
|
| ▲ | raincole an hour ago | parent | prev | next [-] |
| WebView is "native" too in the end. It's crazy that people think it's a good idea to throw away thousands of manyears of optimization (and millions of manyears of field testing in real world) just to... Idk, write a lesser text render engine? |
|
| ▲ | tom1337 5 hours ago | parent | prev | next [-] |
| System Preferences also sometimes just render a WebView - most notably in the Apple Account settings |
| |
| ▲ | Barbing 3 hours ago | parent | next [-] | | Oh that hackjob explains some of the inconsistent, frustrating performance (I do give them credit for some terrible usability elements that would delay a scammer if they had our elderly relative on the phone.) The AppleScript that has to be written and rewritten to flip a simple switch in settings… (it’s telling the system to move around and click in the UI by count, and the count gets thrown off by what I now suspect to be unpredictable web view UI loading) | |
| ▲ | nielsbot 3 hours ago | parent | prev [-] | | I assume because there’s no good “render a view hierarchy based on layout delivered from a server” option. Whereas this is what HTML is with caveats. |
|
|
| ▲ | Dwedit 5 hours ago | parent | prev | next [-] |
| Now RAM use is the main reason to prefer native APIs over web views. |
| |
| ▲ | mpweiher an hour ago | parent | next [-] | | 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. | |
| ▲ | enbugger 4 hours ago | parent | prev [-] | | A decision to move native because of the crisis seems like an expensive populist move to please not very solvent users. Why bother with that if many predict the RAM crisis will last merely until 2027? | | |
| ▲ | LtWorf 3 hours ago | parent [-] | | If you can predict the future so accurately, why aren't you the richest man on the planet? | | |
| ▲ | fauigerzigerk an hour ago | parent | next [-] | | Because predicting the future roughly as well as everyone else doesn't make you rich. Predicting a surge in RAM supply after a surge in RAM demand and a huge increase in RAM margins is economics 101. | |
| ▲ | enbugger 3 hours ago | parent | prev [-] | | I can't. But I'm sure I will be happier and richer person if I don't opt out self from a working stack in favor of saving 100-200mb RAM | | |
|
|
|
|
| ▲ | latexr 5 hours ago | parent | prev | next [-] |
| > Meanwhile SwiftUI doesn't feel particularly fast. That’s because SwiftUI isn’t particularly good, not because web rendering is as good as native. AppKit still runs circles around both, in performance and resource consumption. |
|
| ▲ | ajross 4 hours ago | parent | prev [-] |
| 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 room. Basically everyone is best served by ignoring that the problem ever existed. It took the rendering side a little longer, but we're here nonetheless. There's still room for specialty apps with real need to exploit the hardware in ways not abstracted by the DOM (not 100% of it is games, but it's close to that). But for general "I need a GUI" problems? Yeah, just use Electron. |
| |
| ▲ | mpweiher 4 hours ago | parent [-] | | 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. | | |
| ▲ | nielsbot 3 hours ago | parent | next [-] | | I am going to miss being able to host TypeScript in a web view however. | |
| ▲ | ajross 3 hours ago | parent | prev [-] | | Meh. Flaming about this is so exhausting given that the war was already fought and we know who the winner is. First, that's the typescript compiler, not typescript apps. And it was a ground-up rewrite effort (a very large one) with a specific eye toward improving the performance of the original, which was widely held to be sub-optimal for reasons entirely unrelated to implementation language. Suffice it to say that, hell no, you can't just transpile your code to Go and expect it to run faster. We all know it doesn't work like that. But more broadly, landing with "Please don't use Electron" in the context of a comment about a MS product seems weird given the implementation framework of Microsoft's single most impactful new UI project of the last decade... Just stop, basically. You lost. Use Electron. It works great and everyone else already does and proved you wrong. | | |
| ▲ | mpweiher 3 hours ago | parent | next [-] | | > that's the typescript compiler, not typescript apps. Of course it's the typescript compiler. What else is an implementation of "Typescript" that you could actually make faster? And how would Microsoft go to all Typescript users and re-implement their code in Go? How would that work? But that doesn't change the simple fact that the Typescript compiler written in Typescript was too slow: "As your codebase grows, so does the value of TypeScript itself, but in many cases TypeScript has not been able to scale up to the very largest codebases." And to fix that performance problem, they had to reimplement Typescript (aka "the Typescript compiler") in Go. And that made it 10x faster. And I am not sure you got "just transpire your code to Go" from, because I sure as hell didn't write it. And if you know it doesn't work like that, and I sure as hell didn't claim it works like that, why did you introduce this straw man? This is all plain facts. So yes: please stop the flaming. And please stop using Electron. Dennard scaling hasn't been with us for some time now. | | |
| ▲ | ajross 2 hours ago | parent [-] | | Again, meh. I'm just happy you've admitted that the idea that Go is 10x faster than V8 is bunk. Use what you like. But like I said everyone else is using Electron and winning. I don't make the rules, I'm just trying to explain them. | | |
| ▲ | mpweiher an hour ago | parent [-] | | > you've admitted that the idea that Go is 10x faster than V8 is bunk. I admitted nothing of the sort. Where did you get that from? On a comparable project, Microsoft determined that (a) the performance of the existing JS solution was practically insufficient (b) doing a rewrite while keeping JS would not be sufficient (c) rewriting the TS/JS compiler in Go yielded an empirical speed boost of 10x. And once again, I never claimed that "Go is 10x faster than V8". Please do refrain from these straw-men arguments, it is not conducive to a good discussion. In general, however, it is true that JIT compilers perform far less well on real-world production code than they do on small synthetic benchmarks, and so the 10x performance penalty that Microsoft found empirically is well within the range of what is observed elsewhere. Overview and links to research here: https://blog.metaobject.com/2015/10/jitterdammerung.html And remember: this was a response to this comment: "well, what if we just made Javascript crazy fast instead?", and here we are." JavaScript is not "crazy fast". Whether it won or is otherwise just the bees knees is irrelevant. It ain't "crazy fast". |
|
| |
| ▲ | 3836293648 an hour ago | parent | prev [-] | | The typescript compiler is a typescript app. Or was, I guess |
|
|
|