Native all the way, until you need text

markdown to html. or markdown stays markdown.

the browser never chokes on html.

the only place where native UI is still better is for ultra-complex UIs - image/video/3d/audio editors. and only because it's easier to create custom UI widgets/renderers than on web stack.

that's it, for everything else native UIs are complete garbage compared to HTML/CSS/reactive frameworks.

I once tried mobile development in semi early days android. At the time I made a free Hackaday reader app because I was a daily reader and loved it.

I remember spending 4 hours to make a scrollable element that wasn't jumpy or buggy. There were several stackoverflow answers full of gotchas explaining all you had to do. I finished and published the app but never again. Native stuff has terrible developer experience.

Outside of niche applications (e.g. virtual desktops, gamming, embedded systems) native UIs are dead.

There are even parts of both Windows and MacOS rendered through HTML. If I remember correctly, at least in Windows 10, File Explorer was rendered through Internet Explorer.

Web rendering doesn't need to be only through Electron/Node. There are other libraries much more performant and lean (Dioxus, etc).

do you miss Hypercard yet?

I think the article misses the actual point?

The browser is faster because they went native, in particular, GPU.

Every issue described is text rendering related. Everyone.

And I would bet most of the SwiftUI issues could be solved with a text render cache.

Something like Casey Murati's refterm toy that showed what that can do with no other optimizations, or the work for GPU accelerated terminal emulators like alacritty or ghostty.

[dead]

[dead]

[dead]

I thought models were so good we could vibecode a text renderer for $50. What's the problem here? /s