5 ms·
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
by pornel 5mo 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.
- embedding-shape 5mo ago> 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 5mo agoMy 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.
- whstl 5mo agoThis is so true. It even happens to me in my 16GB work laptop when I have to use multiple Electron apps at work. My personal 8GB Air is way faster. On the other hand, WebViews can be really fast without the baggage of Electron and Javascript frameworks/libraries.
- domga 5mo agoJavaScript frameworks/libraries are very rarely the problem, Electron just has to bundle Node, V8 and Chromium (granted, V8 is deduplicated). Electron apps are hungry for RAM, but in practice it is close to having a heavy tab active. The thing about browsers is that they are pretty aggressive at offloading inactive tabs but Electron apps never do that.
- cosmic_cheese 5mo agoElectron would be fine… if most of us were running just one electron app. In reality we’re stuck with 2-5 electron/CEF apps plus whatever is running in browser tabs as well as whatever webviews system stuff are running, which all quickly pushes into VM paging territory on low memory devices.
- latexr 5mo ago> 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.
- Dwedit 5mo agoNow RAM use is the main reason to prefer native APIs over web views.
- enbugger 5mo agoA 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 5mo agoIf you can predict the future so accurately, why aren't you the richest man on the planet?
- enbugger 5mo agoI 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
- fauigerzigerk 5mo agoBecause 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.
- 5mo ago
- rubymamis 5mo agoIt'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,%20but%20slow https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20... [2] https://x.com/daniel_nguyenx/status/1734495508746702936 https://x.com/daniel_nguyenx/status/1734495508746702936 [3] https://rubymamistvalove.com/block-editor#8-performance https://rubymamistvalove.com/block-editor#8-performance
- StilesCrisis 5mo agoQt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible.
- deleted 5mo ago[deleted]
- jeremyjh 5mo agoThey 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.
- deleted 5mo ago[deleted]
- tux3 5mo ago
- iTokio 5mo agoWell, 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.
- StilesCrisis 5mo agoAccording to the article, native is slower though.
- CharlesW 5mo agoTFA 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.
- bonesss 5mo agoIf 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 5mo ago
- krzyzanowskim 5mo agoSwiftUI, (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 5mo agoThey 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-codealong-cook-up-a-rich-text-experience-in-swiftui-with-attributedstring/ https://wwdcnotes.com/documentation/wwdcnotes/wwdc25-280-cod...
- krzyzanowskim 5mo agoI 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 5mo agoYou 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/ https://developer.apple.com/videos/play/wwdc2025/280/ Do you really think people should use web views instead of, say, STTextView?
- krzyzanowskim 5mo agoI think people should use anything but SwiftUI.TextEditor is my current stance
- tom1337 5mo agoSystem Preferences also sometimes just render a WebView - most notably in the Apple Account settings
- nielsbot 5mo agoI 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.
- Barbing 5mo agoOh 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)
- titzer 5mo ago> 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.
- nolist_policy 5mo ago> Chromebooks Have you tried with stock ChromeOS?
- cosmic_cheese 5mo agoWeb 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 5mo ago> 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 5mo agoAgreed. 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.
- ajross 5mo agoThis 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 5mo agoExcept 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-port/ https://devblogs.microsoft.com/typescript/typescript-native-... See also: https://blog.metaobject.com/2015/10/jitterdammerung.html https://blog.metaobject.com/2015/10/jitterdammerung.html Please don't use Electron.
- nielsbot 5mo agoI am going to miss being able to host TypeScript in a web view however.
- tardedmeme 5mo agoYou still can. If you port the compiler to something that runs in a web view. WASM sounds easiest.
- ajross 5mo agoMeh. 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.
- hackermanai 5mo ago> 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.
- raincole 5mo agoWebView 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?