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

181–190 of 328 posts

Re: Native all the way, until you need text

#181

Post by sgt »

argee wrote: post #166
sgt wrote: post #117

Earlier quoted context omitted.

> native UIs are dead. Not in the world of macOS and iOS at least. Here native apps still rule, as there's literally no performant alternative (the OP's complaints about Markdown are misplaced - there's been no interest in MD and SwiftUI and that's why there's no good option. But in ObjC/Swift there is). In fact, most of the apps I am using on a day to day is native. The Electron apps I use are okay (e.g. Slack) but…

> the native Turing test What does this mean?

Basically that it's easy - for a user - to determine that a particular app is definitely not built using native SDK. Slack is an example.

Re: Native all the way, until you need text

#182

Post by nchie »

the_gipsy wrote: post #139
TingPing wrote: post #122

Earlier quoted context omitted.

More importantly all HTML is valid markdown.

Putting HTML in markdown defeats the purpose IMHO.

That doesn't make it not true though. Markdown generally supports HTML (though oftentimes only a subset), and is typically styled using CSS. Using a web view makes complete sense to me.

Re: Native all the way, until you need text

#184

Post by jonhohle »

mpweiher wrote: post #163
jonhohle wrote: post #116

Earlier quoted context omitted.

That’s how it originally worked, but Apple has moved away from PDF to other native GPU frameworks for drawing. Now window content is stored as bitmaps instead of redrawing vector instructions.

That's not how it ever worked. Quartz is a vector drawing engine whose output can be captured as a PDF and which is closely aligned with the PDF imaging model. Window content was always stored as bitmaps.

You’re correct. I meant to say textures, but even that isn’t completely accurate.

AppKit used to generate the bitmap directly through CoreGraphics (PDF model). Now it uses Core Animation and Metal and no longer draws the bitmap directly.

Re: Native all the way, until you need text

#185

Post by Wowfunhappy »

the_gipsy wrote: post #139
TingPing wrote: post #122

Earlier quoted context omitted.

More importantly all HTML is valid markdown.

Putting HTML in markdown defeats the purpose IMHO.

I don't think it does at all!

> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

https://daringfireball.net/projects/markdown/

Using some semantic HTML as an occasional escape hatch is perfectly in line with this overall goal.

Re: Native all the way, until you need text

#186

Post by danielvaughn »

PaulDavisThe1st wrote: post #95
danielvaughn wrote: post #63

Earlier quoted context omitted.

When I say "this stuff" I'm not talking about a link, I'm talking about the overall markdown/text capabilities that the post is talking about. I meant that I expected more parity with what you'd encounter on the web.

You expected highly capable, generic GUI toolkits to show parity with a development environment that has specifically targetted text above all else (though with lots of other stuff and great depth too) for decades? Even in an era of PWAs and highly reactive UIs, the web is still fundamentally a document presentation mechanism. No generic GUI toolkit fits that description (even if they can be coerced into being one).

Given how much shit the web gets from native developers, yeah kinda? They make it seem like it's light years ahead of the web, often arrogantly so.

Re: Native all the way, until you need text

#187

Post by danielvaughn »

coldtea wrote: post #151
danielvaughn wrote: post #10

I remember being a junior engineer in 2015, and being asked to render a clickable link within a paragraph in an iOS app. Swift had just been released so we were still entirely on the ObjC/UIKit stack. It was an absolute nightmare. I _barely_ managed to make it work. I haven't really touched iOS since about 2016, so I assumed the new SwiftUI stuff would have this stuff built in. Obviously. Kind of insane that it wasn'…

> being asked to render a clickable link within a paragraph in an iOS app The specific ask was already a bad idea.

the whole company was a shitshow; that was probably the least insane thing i was asked to do there.

Re: Native all the way, until you need text

#188

Post by virgil_disgr4ce »

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…

> If I can do it on iOS then it's must be 10x easier on macOS.

I strongly doubt this. I suspect it's the exact opposite situation. But I'd like to hear from someone who knows.

Re: Native all the way, until you need text

#189

Post by bluGill »

rubymamis wrote: post #94
bluGill wrote: post #26

Earlier quoted context omitted.

It is tricky, but it is not unheard of to write Qt applications as something other than C++.

These days you write the logic in C++ and UI in QML which is a very pleasent experience.

Rust bindings exist if you don't like c++

Re: Native all the way, until you need text

#190

Post by mpweiher »

ajross wrote: post #178
mpweiher wrote: post #161

Earlier quoted context omitted.

> that's the typescript compiler, not typescript apps. Of course it's the typescript compiler. What else is an implementation of "Typescript" that you could actually make faster? And how would Microsoft go to all Typescript users and re-implement their code in Go? How would that work? But that doesn't change the simple fact that the Typescript compiler written in Typescript was too slow: "As your codebase grows, so d…

Again, meh. I'm just happy you've admitted that the idea that Go is 10x faster than V8 is bunk. Use what you like. But like I said everyone else is using Electron and winning. I don't make the rules, I'm just trying to explain them.

> you've admitted that the idea that Go is 10x faster than V8 is bunk.

I admitted nothing of the sort. Where did you get that from?

On a comparable project, Microsoft determined that

(a) the performance of the existing JS solution was practically insufficient

(b) doing a rewrite while keeping JS would not be sufficient

(c) rewriting the TS/JS compiler in Go yielded an empirical speed boost of 10x.

And once again, I never claimed that "Go is 10x faster than V8". Please do refrain from these straw-men arguments, it is not conducive to a good discussion.

In general, however, it is true that JIT compilers perform far less well on real-world production code than they do on small synthetic benchmarks, and so the 10x performance penalty that Microsoft found empirically is well within the range of what is observed elsewhere.

Overview and links to research here:

https://blog.metaobject.com/2015/10/jitterdammerung.html

And remember: this was a response to this comment:

"well, what if we just made Javascript crazy fast instead?", and here we are."

JavaScript is not "crazy fast".

Whether it won or is otherwise just the bees knees is irrelevant. It ain't "crazy fast".

Post reply on HN