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

131–140 of 328 posts

Re: Native all the way, until you need text

#131

Post by mpweiher »

ajross wrote: post #111
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…

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

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.

Re: Native all the way, until you need text

#132

Post by sandoze »

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.

Re: Native all the way, until you need text

#133

Post by cosmic_cheese »

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.

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.

Re: Native all the way, until you need text

#134

Post by sznio »

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.

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.

Re: Native all the way, until you need text

#136

Post by [deleted] »

stavros wrote: post #58
Wowfunhappy wrote: post #55

Earlier quoted context omitted.

I mean, this is why I think PDFKit is a good comparison. Could you render your app's entire UI as a series of PDFs? Absolutely! Should you do that? Uh, probably not. You should use the native controls Apple gives you for buttons and dialogs and input fields and so on. But WebKit is the native UI for HTML, and Markdown is intended to be transpiled to HTML.

It's irrelevant what Markdown was meant to be transpiled to. When people say "Markdown support" these days, they mean "rich text support", since Markdown is actually just ASCII. It is ridiculous to need a Web renderer to render rich text, on any platform. Even terminal emulators can do it.

[deleted]

Re: Native all the way, until you need text

#137

Post by satvikpendem »

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…

[flagged]

Re: Native all the way, until you need text

#138

Post by the_gipsy »

throawayonthe wrote: post #105
the_gipsy wrote: post #92

Earlier quoted context omitted.

> Using WebKit to render Markdown seems completely appropriate. It doesn't? Needs an explanation.

markdown is a markup language 'intended' to be rendered as HTML, WebKit seems appropriate to render HTML

Still seems overkill. It's just headers, lists, block quotes, codeblocks, and a few inner emphasis and link formatters, basically. HTML is the whole jungle for a gorilla with a few bananas here.

Re: Native all the way, until you need text

#139

Post by the_gipsy »

TingPing wrote: post #122
throawayonthe wrote: post #105

Earlier quoted context omitted.

markdown is a markup language 'intended' to be rendered as HTML, WebKit seems appropriate to render HTML

More importantly all HTML is valid markdown.

Putting HTML in markdown defeats the purpose IMHO.

Re: Native all the way, until you need text

#140

Post by bonesss »

CharlesW wrote: post #110
StilesCrisis wrote: post #98

Earlier quoted context omitted.

According to the article, native is slower though.

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.

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.

Post reply on HN