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

191–200 of 328 posts

Re: Native all the way, until you need text

#191

Post by mpweiher »

Dwedit wrote: post #68
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…

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.

Re: Native all the way, until you need text

#192

Post by tombert »

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…

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.

Re: Native all the way, until you need text

#193

Post by arjie »

A thing I’ve always wanted was a visual JSON viewer that instantly opened on multi-hundred-meg files. So I used Claude Code to build one with native text views and it’s true it’s pretty raw. But for a thing that doesn’t need formatting, dictionary, and all that it’s great. The viewer opens fast enough that it’s dominated by the window rendering animation which is about what I wanted here.

So I think the text view is pretty low level so that it can support this.

Re: Native all the way, until you need text

#194

Post by raincole »

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…

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?

Re: Native all the way, until you need text

#195

Post by hackermanai »

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…

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

Re: Native all the way, until you need text

#196

Post by ozgrakkurt »

appplication wrote: post #179
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.

This is mainly from my experience developing storage engines using datafusion/polars or arrow2/arrow-rs or rocksdb-msbx.

I was changing between them and searching for comparisons online. This ended up being a massive amount of lost time because all of those choices became crystal clear when I actually roughly understood what these libraries were doing.

And actually learning the thing didn’t take as much time as writing code for comparison and discarding it or doing dead-end web searches.

Recently had a similar experience trying to learn dwarf parsing from LLMs or searching for existing code. Then I just realised that reading the spec is by far the most efficient way to understand it.

I am guessing same principle applies to text rendering because I got the same vibe when watching Raph Levien talk about it on some video.

Searching online to read some “industry-standard” “tried and true” etc. Comments is a big sign that it might be better read some actual source about the topic imo. It doesn’t even take that much time to read a textbook even.

Re: Native all the way, until you need text

#197

Post by nolist_policy »

titzer wrote: post #103
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…

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

> Chromebooks

Have you tried with stock ChromeOS?

Re: Native all the way, until you need text

#198

Post by trinix912 »

embedding-shape wrote: post #65
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…

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

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.

Re: Native all the way, until you need text

#199

Post by fauigerzigerk »

LtWorf wrote: post #147
enbugger wrote: post #126

Earlier quoted context omitted.

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?

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

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.

Re: Native all the way, until you need text

#200

Post by longnguyen »

lenkite wrote: post #44

> But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message. Sorry, sounds like bullsh_t. One can leverage mature markdown renderers in SwiftUI. See https://github.com/gonzalezreal/swift-markdown-ui and its next gen replacement https://github.com/gonzalezreal/textual . Used these myself and had no issues. And I am a moron who doesn't like Swift or SwiftUI - pre…

Either you render the markdown document just once (not streaming) or your document is simple and short.

I used to use swift-markdown-ui for my app but the performance is nowhere near using a wkwebview. When streaming large documents with tricky elements like large tables, code blocks, nested quotes, you may even get beached ball. It never happened when using a wkwebview.

Post reply on HN