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

271–280 of 328 posts

Re: Native all the way, until you need text

#271

Post by Klonoar »

msephton wrote: post #243
dive wrote: post #217

Earlier quoted context omitted.

It makes sense when the editor is a core feature of your paid product. I understand the sentiment. But is not it strange that I would need 8 months & a "development is ongoing" mindset just to render Markdown (which is very secondary to the main app features, and mostly just a user convenience people expect in 2026) with a custom low-level solution, effectively playing hardcore engineer instead of building what I act…

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 makers won’t get the hell in line and offer APIs to do it, then these developers are going to just pick Electron.

Life is way too short to sit down and write half a damn text editor when all you wanted to do was shit out a basic application with blobs of markdown.

Re: Native all the way, until you need text

#272

Post by Klonoar »

kenferry wrote: post #208
iamcalledrob wrote: post #156

Fun fact: This is how Apple used to do it too. Old versions of macOS / AppKit used to use WebKit to render rich text inside their native NSTextFields. Turns out text is hard :) And besides, the native WebView is super fast and lightweight, and its not unreasonable to use it as a text layout engine. You could use separate webviews for every row in a table and you'd still get fantastic performance. iMessage for mac use…

You’re confusing iOS and Mac OS here. The Mac never used WebKit for NSTextField rendering. When iOS was first written, WebKit was used as the text renderer everywhere initially, including in UIKit controls (the “sweet solution”). This proved to be too heavyweight / cumbersome and the coretext/appkit text rendering approach was brought over.

Also NSAttributedString would invoke WebKit under the hood if you went to render an HTML string.

Re: Native all the way, until you need text

#273

Post by TacticalCoder »

Lots of talk about Electron apps but as much as I like HTML+CSS for the view, where are the actual heavyweight Electron apps for: digital audio workstations, 3D modeling (is Blender an Electron app? I don't know, I'm asking), the complex brokerage apps (which typically pack and render a lot of information on screen), typesetting apps (like Adobe's InDesign or, on the other extreme, a document preparation system like LaTeX), video editing, GIS-related apps, engines for games (and tools to develop games), etc.

HTML/CSS/JavaScript looks fine for things where there's more style than substance but once we're talking about the desktop apps that engineers (no matter the discipline) are using, suddenly it's not so much HTML+CSS anymore or is it?

Re: Native all the way, until you need text

#275

Post by array_key_first »

Bolwin wrote: post #264
kenferry wrote: post #206

Earlier quoted context omitted.

The native Apple libraries are terrific at rendering rich text, it’s one of their strongest assets. The poster’s issues seem to be specifically because they want to use markdown as the backing. The native rich text backing for native Apple views is attributed strings. They could translate the markdown to attributed strings, but seems like they don’t want to.

..where did you get that impression? The web also requires you to convert to html. I don't see how this is different

Markdown can contain arbitrary HTML. It only makes sense to use an HTML viewer for what is essentially a dialect of HTML, aka a browser engine.

Re: Native all the way, until you need text

#277

Post by instagary »

I've been working on a MarkdownView library for iOS based on tree sitter: https://github.com/HumanInterfaceDesign/MarkdownView

Like the OP mentioned, it's still surprisingly difficult to build what feels like a trivial interface using SwiftUI. Once you get into rich text, selection, streaming updates, syntax highlighting, diffing, or just smooth scrolling, you very quickly end up fighting the framework instead of building the app

Re: Native all the way, until you need text

#278

Post by longnguyen »

CharlesW wrote: post #259
vor_ wrote: post #254

Earlier quoted context omitted.

> Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory I don't know why SwiftUI evangelists are still doing this in 2026. How many examples of SwiftUI's poor performance have to be demonstrated over the years? Even basic things like List continue to lag behind NSTableView in the most recent releases.

All I have is my own experience. In my current app, my views are 100% SwiftUI. One of them uses a SwiftUI List which typically has hundreds of thousands of items, each with title, subtitle, duration, cover art, etc. I expect it would still be butter-smooth at 1M items. Was my initial naive implementation as performant? No. My point is that optimization still matters in SwiftUI, and that optimization looks quite a bit…

Is that an iOS app? Because List on macOS still has a lot of performance issues.

This guy run a benchmark vs. AppKit and SwiftUI is still slow in macOS26

https://github.com/lemonmojo/swiftui-hierarchical-list-perfo...

Re: Native all the way, until you need text

#279

Post by octorian »

octorian wrote: post #240
StilesCrisis wrote: post #216

Earlier quoted context omitted.

I disagree. I use P4V (Qt-based) regularly. Its lists are quirky and sometimes don't scale property with the OS DPI settings.

I'd be more curious about that specific app. Niche bespoke commercial apps have this habit of being permanently stuck on old versions of Qt that don't handle these things as well as the newer versions. And until they are totally broken on Windows, the developers will never be motivated to lift a finger to fix this. I have no idea if this is the case with P4V, but it absolutely is the case with a few other things I us…

Okay, too late to edit, but I decided to take a look. The latest version of P4V actually is using Qt6, so I guess I have to stand somewhat corrected.

I'm just bitter about a couple of apps I use that are all permanently stuck on Qt4 where the vendor seems to have zero intention of caring to ever update them to a newer version of Qt. And ever since getting a HiDPI display, this has been continuously irritating me.

Post reply on HN