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

301–310 of 328 posts

Re: Native all the way, until you need text

#301

Post by lokimedes »

f30e3dfed1c9 wrote: post #269
lokimedes wrote: post #213

We did https://markant.md with TextKit 1, flies through multi-megabytes markdown files with latex rendering etc. took some scaffolding (like only rendering attachments when they are close to the viewport) to make it smooth, but it wasn’t really a big problem.

This app is a good idea but the help refers to a "Help > Install Command Line Tool" menu item that does not appear to exist.

Thank you, great spotted. I did make a CLI tool for it, but it was a bit too cumbersome to distributed it via the App Store for the first release, so I dropped it from the release but forgot to update the help.

Re: Native all the way, until you need text

#303

Post by mpweiher »

domga wrote: post #251
mpweiher wrote: post #191

Earlier quoted context omitted.

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.

The issue with JS is that each page gets its own execution context so they don’t share any memory. I am actually curious what does the WebView do to save on RAM here?

It doesn't have to "do" anything special if you just use it for rendering HTML, and not for running gargantuan layers of JS frameworks.

If you run gargantuan layers of JS frameworks in a WebView it will perform just as badly as a full browser. After all, a browser is (more or less) just a process wrapped around a WebView.

Re: Native all the way, until you need text

#304

Post by tardedmeme »

stavros wrote: post #300
Wowfunhappy wrote: post #299

Earlier quoted context omitted.

But if he'd said rich text the answer would be different! Markdown is designed to be converted to html, and in fact it can contain html.

Right, but he clearly didn't mean HTML, otherwise he wouldn't be trying native elements in the first place.

He means Markdown, but Markdown is mean to turn into HTML. Rendering it any other way than converting it to HTML gives a different result, and if anyone complains about it, it'll be your fault since you didn't render it the proper way. It turns out a lot of things are like this. Another commentator mentioned Slack messages.

Re: Native all the way, until you need text

#306

Post by msephton »

Klonoar wrote: post #271
msephton wrote: post #243

Earlier quoted context omitted.

You're assuming the text editor component alone took 8 months, but of course it did not! That would be crazy. There's a whole app built around the text component, which is what took my time, and the reason people are buying the app. Development is ongoing for the features around the text component. I added folding lists which took a while, and because I offer outliner features I added focus/hoist which was also quite…

Nothing comes for free, but OP’s entire point is that the price to pay for even halfway decent native markdown rendering is too high - and thus a reason why people often give up and go to Electron. They could not have made their point more clearly but people like you are up and down the thread wanting to call “skill issue”. The reality is that nobody gives a shit and they want to ship interesting things fast; if OS m…

So now it's personal and I'm the bad guy because I happened to have already done what the OP says is not possible? Deeply uncool.The price is not high at all, and it's not an opinion or theory because I've proven it by shipping an app. The OS makers already offer "APIs to do it" and, as with any type of component or framework, if you bend it the wrong way you'll get bad results. If you abuse Electron you'll also get bad performance there, it's no silver bullet. This is not ground-breaking information, just common sense.

Re: Native all the way, until you need text

#307

Post by msephton »

dwroberts wrote: post #296
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…

> 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. Not trying to be unpleasant but these times are slow, right? 8ms is an entire frame at 120Hz, that’s an eternity

Are you basing this opinion on feeling or science?

This feels instant on iOS, and scientifically it's faster than almost all keyboards, which have latency between 15ms and 60ms: https://news.ycombinator.com/item?id=33817626 and the best computer latency was the Apple IIe at 30ms https://news.ycombinator.com/item?id=16001407 a network packet takes 190ms to go round the world, that's certainly longer but still not quite an eternity.

Also, you are of course free to do better :)

Re: Native all the way, until you need text

#308

Post by Klonoar »

msephton wrote: post #306
Klonoar wrote: post #271

Earlier quoted context omitted.

Nothing comes for free, but OP’s entire point is that the price to pay for even halfway decent native markdown rendering is too high - and thus a reason why people often give up and go to Electron. They could not have made their point more clearly but people like you are up and down the thread wanting to call “skill issue”. The reality is that nobody gives a shit and they want to ship interesting things fast; if OS m…

So now it's personal and I'm the bad guy because I happened to have already done what the OP says is not possible? Deeply uncool.The price is not high at all, and it's not an opinion or theory because I've proven it by shipping an app. The OS makers already offer "APIs to do it" and, as with any type of component or framework, if you bend it the wrong way you'll get bad results. If you abuse Electron you'll also get…

> So now it's personal and I'm the bad guy

It's not personal, but yes, you're being intentionally obtuse to OP's point.

> and it's not an opinion or theory because I've proven it by shipping an app

You are once again downplaying the level of effort difference that OP is describing, thus missing the point entirely.

> if you bend it the wrong way you'll get bad results

OP did not bend it the wrong way, they tried several different approaches because it wasn't working as intended off the bat (i.e, without bending).

OP's point was never that things were "not possible", it's that it's a stupid amount of effort for table-stakes functionality. If you don't get that point by now then I don't think you'll get it at all.

Re: Native all the way, until you need text

#309

Post by basch »

dataflow wrote: post #288
msephton wrote: post #265

Earlier quoted context omitted.

I'm going from memory here, time marches on never-ending, so please forgive me. I conflated two things: my performance test results are from the first 5,000 lines of Moby Dick. Why 5,000? One user has a 5,000 line taskpaper note file. But the whole 22,000 line book loaded and scrolled and edited just fine (after I fixed some bad assumptions that resulted in bad code). On iOS, I think if you're working on a file of 5,…

I definitely need to edit files that are hundreds of thousands of lines once in a while. Nothing wrong with it, I think you're just assuming it's source code or such when it isn't. It's often data manipulation (CSV, JSON, etc.) and it feels like torture when the editor can't handle it. I've even opened multi-gigabyte text files in my editor and needed to edit them sometimes.

Did you look at the app? It's a todo list. The idea of a multi gigabyte todo list makes me uneasy.

Re: Native all the way, until you need text

#310

Post by msephton »

Klonoar wrote: post #308
msephton wrote: post #306

Earlier quoted context omitted.

So now it's personal and I'm the bad guy because I happened to have already done what the OP says is not possible? Deeply uncool.The price is not high at all, and it's not an opinion or theory because I've proven it by shipping an app. The OS makers already offer "APIs to do it" and, as with any type of component or framework, if you bend it the wrong way you'll get bad results. If you abuse Electron you'll also get…

> So now it's personal and I'm the bad guy It's not personal, but yes, you're being intentionally obtuse to OP's point. > and it's not an opinion or theory because I've proven it by shipping an app You are once again downplaying the level of effort difference that OP is describing, thus missing the point entirely. > if you bend it the wrong way you'll get bad results OP did not bend it the wrong way, they tried sever…

I'm not being obtuse, on the contrary I am bright and focussed enough that my experience building an app around TextKit 2 was opposite to the premise of the OP. It's a few lines of code to add a TextKit2 component to an app, and it just works. It is what the developer does with it afterwards that will make or break it. The same goes for Electron, it is not a panacea. That's just software development, the developer is responsible for the code they write.

So the reader is free to accept my story about my shipped app and my assurance that it didn't take unreasonable effort, or accept a blog post complaining how difficult things are that has no code or shipped app at the end of it.

Post reply on HN