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

171–180 of 328 posts

Re: Native all the way, until you need text

#171

Post by Narishma »

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…

> 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.

Re: Native all the way, until you need text

#172

Post by pier25 »

antiframe wrote: post #120
pier25 wrote: post #118

Maybe controversial but I think HTML + CSS is truly the most powerful system to make GUIs. There’s really nothing else out there that competes with a similar performance and productivity. This old article by the Missive team (the email client) convinced me. https://medium.com/missive-app/our-dirty-little-secret-cross...

Powerful, perhaps. Slow, for sure.

I don’t know. Resizing a window with complex ui in html tends to be faster than native guis for me. It haven’t tested this properly though.

Re: Native all the way, until you need text

#173

Post by silvestrov »

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…

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.

Re: Native all the way, until you need text

#174

Post by LtWorf »

enbugger wrote: post #170
LtWorf wrote: post #147

Earlier quoted context omitted.

If you can predict the future so accurately, why aren't you the richest man on the planet?

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

You're off by an order of magnitude there.

Re: Native all the way, until you need text

#175

Post by CharlesW »

krzyzanowskim wrote: post #168
CharlesW wrote: post #101

Earlier quoted context omitted.

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...

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

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?

Re: Native all the way, until you need text

#176

Post by itsthecourier »

sandoze wrote: post #132
msephton wrote: post #129

I recently launched a text editor for iOS that uses TextKit 2 and is highly performant with files of 5,000 lines (I tested with Moby Dick from Project Gutenberg). I made it between Aug 2025 and Apr 2026, development is ongoing. Every keystroke is restyled in under 8ms: no debouncing, no delayed rendering. 20 rapid keystrokes are processed in 150ms with full restyling after each one. Tag and boolean searches complete…

Having worked on an interactive novel in 2012 (NSString and attributes), low level glyphs (API deprecated) on a rogue-like, two chat apps (with markdown support for formatting) in SwiftUI, and an idle game using a mix of iOS tricks but all wrapped in SwiftUI.. I’m going to agree with how I summarized this response: skill issue.

[flagged]

Re: Native all the way, until you need text

#177

Post by pornel »

iTokio wrote: post #82
pornel wrote: post #38

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…

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.

[dead]

Re: Native all the way, until you need text

#178

Post by ajross »

mpweiher wrote: post #161
ajross wrote: post #149

Earlier quoted context omitted.

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,…

> 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 d…

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.

Re: Native all the way, until you need text

#179

Post by appplication »

ozgrakkurt wrote: post #88

The problem here is that you are not choosing based on knowing how the render pipeline is implemented in these tools and how it would work with your usage of it. You can do a couple days to a week of reading to understand the fundamentals once and then you will actually know what you are doing. It is not proper to choose things on “battle tested” or other meaningless words

I think in light of the fact that OP included exactly to what they are trying to do, this comment would be helpful to include a more concrete recommendation.

It’s easy to hand wave and say “this wouldn’t be an issue if you knew what you were doing”, but that indeed is the problem.

Post reply on HN