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

211–220 of 328 posts

Re: Native all the way, until you need text

#211

Post by Someone »

the_gipsy wrote: post #138
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

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.

> It's just headers, lists, block quotes, codeblocks, and a few inner emphasis and link formatters, basically

That, and in-line HTML. https://daringfireball.net/projects/markdown/syntax#html:

“For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.

The only restrictions are that block-level HTML elements — e.g. , , 

, 
, etc. — must be separated from surrounding content by blank lines, and the start and end tags of the block should not be indented with tabs or spaces. Markdown is smart enough not to add extra (unwanted) 
 tags around HTML block-level tags.”
Because of that, I think I would use a html renderer to render markdown. Because people allowing arbitrary HTML opens a huge can of worms I might also whitelist a restricted set of HTML.

Re: Native all the way, until you need text

#212

Post by krzyzanowskim »

CharlesW wrote: post #175
krzyzanowskim wrote: post #168

Earlier quoted context omitted.

I don't know where's the improvements, give it has all the limitations, now scaled to rich text. That's not the direction that this component should get. It need radical new API that is not much compatible with SwiftUI API

You must know far more about this than me, but as of iOS 26, `TextEditor` evolved into a true rich text editor (`AttributedString` binding, `AttributedTextSelection` rich text selection, custom/app-specific text attributes, etc). https://developer.apple.com/videos/play/wwdc2025/280/ Do you really think people should use web views instead of, say, STTextView?

I think people should use anything but SwiftUI.TextEditor is my current stance

Re: Native all the way, until you need text

#214

Post by StilesCrisis »

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.

Electron sits on top of Skia, which renders the text itself. It's designed to look like the host OS but it's not just asking the OS to draw text, because that's actually a lot slower than Skia.

Re: Native all the way, until you need text

#215

Post by StilesCrisis »

Klonoar wrote: post #107
StilesCrisis wrote: post #100

Earlier quoted context omitted.

Slack also basically fails at this. You end up getting a jumble of timestamps, names and messages.

Yeah... people expect that when they copy chat messages. It's correct behavior.

I don't mind the timestamps and names existing, but they're formatted all wrong.

Re: Native all the way, until you need text

#216

Post by StilesCrisis »

tux3 wrote: post #144
StilesCrisis wrote: post #93

Earlier quoted context omitted.

Qt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible.

At this point on Win32 Qt might as well be the native UI. They did a better job of maintaining a coherent visual theme that says "Windows" and fits the design patterns than the actual owners of the platform.

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

Re: Native all the way, until you need text

#217

Post by dive »

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…

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 actually want to build?

Anyhow, my point is not that "it is impossible". My point in the article is that I understand why people choose web technologies over native for such things. They want to build products, not fight the system’s limitations.

Re: Native all the way, until you need text

#218

Post by argee »

zhxiaoliang wrote: post #89

I understand your pain. That’s why I’ve ported my VMPrint layout engine to Rust. It’s early, but it already shows promising performance improvements over the original TypeScript-based engine, which is already very fast. The Rust version can create fully paginated, publishing-grade layout at around 8,500 pages (or 2,000,000 words) per second on a M4 MacBook. It’s even faster at advanced tasks like mixing texts with ir…

Your FAQ says:

    Why not Typst?

    Typst is excellent for authored documents and produces beautiful output. It is also a Rust binary. You cannot import it into a Node process, run it in a browser, deploy it to a Cloudflare Worker, or call it as a library from a TypeScript application. If you need a layout engine embedded in a JS or TS runtime, Typst is not available to you.
So, wouldn't porting VMPrint to Rust make it such that Typst is the clear winner? Or is there something else missing?

Re: Native all the way, until you need text

#219

Post by nottorp »

Wowfunhappy wrote: post #61
stavros wrote: post #58

Earlier quoted context omitted.

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.

HTML is basically analogous to RTF, no?

maybe html 0.9 :)

Re: Native all the way, until you need text

#220

Post by RustSupremacist »

ogoffart wrote: post #119
chromadon wrote: post #11

This is where QT/JUCE can help. Although you are limited to c++.

If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/

This is not what the people want. Understand that. Give us Rust and Qt. Why be so focused on trying to sell something that doesn't measure up? Even beta Bridges is better than Slint. Take the advice and put the energy to better use for the good of Rust.
Post reply on HN