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

291–300 of 328 posts

Re: Native all the way, until you need text

#291

Post by what »

Wowfunhappy wrote: post #185
the_gipsy wrote: post #139

Earlier quoted context omitted.

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

> without looking like it’s been marked up with tags or formatting instructions.

From your own quote. Embedding html absolutely violates the spirit.

Re: Native all the way, until you need text

#292

Post by masklinn »

what wrote: post #291
Wowfunhappy wrote: post #185

Earlier quoted context omitted.

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

> without looking like it’s been marked up with tags or formatting instructions. From your own quote. Embedding html absolutely violates the spirit.

That’s for the markdown content.

HTML embedding as an escape was built in Gruber’s markdown from the start, and is part of why markdown is simple bordering on simplistic: https://daringfireball.net/projects/markdown/syntax#html

Re: Native all the way, until you need text

#293

Post by masklinn »

tclancy wrote: post #159
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

That doesn’t track at all. Markdown was created as a simpler way to mark up text than HTML. They are both ways of encoding a document that provide ways to convey intention. HTML is no one’s end goal.

First sentence of the announcement / introduction of markdown:

> Markdown is a text-to-HTML conversion tool for web writers.

HTML embedding was also integral to it: https://daringfireball.net/projects/markdown/syntax#html

> Markdown’s syntax is intended for one purpose: to be used as a format for writing for the web. […] For any markup that is not covered by Markdown’s syntax, you simply use HTML itself.

Re: Native all the way, until you need text

#294

Post by LtWorf »

ethanc8 wrote: post #268
LtWorf wrote: post #230

Earlier quoted context omitted.

Why pay a license fee when you can make a bloated and slow electron app instead?

Both Qt and Electron are LGPL.

From their website:

"Qt comes with Dual Licensing, which includes both commercial and open source options. To build a proprietary mobile application, you need the Commercial Qt license, within which Qt for Application Development is sufficient for pure mobile and desktop app development."

Re: Native all the way, until you need text

#295

Post by vintagedave »

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.

Personally I'd still advocate for Delphi / C++Builder there. The VCL (WinAPI wrapper plus very extensible for custom controls) behaves 'natively' because it is. And it's very nice to use.

Re: Native all the way, until you need text

#296

Post by dwroberts »

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

Re: Native all the way, until you need text

#297

Post by imtringued »

ajross wrote: post #149
mpweiher wrote: post #131

Earlier quoted context omitted.

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.

Meh. Flaming about this is so exhausting given that the war was already fought and we know who the winner is. First, that's the typescript compiler , not typescript apps. And it was a ground-up rewrite effort (a very large one) with a specific eye toward improving the performance of the original, which was widely held to be sub-optimal for reasons entirely unrelated to implementation language. Suffice it to say that,…

>Meh. Flaming about this is so exhausting given that the war was already fought and we know who the winner is.

I mean yeah its obvious that typescript had insufficient performance for the typescript compiler. They made a big public announcement about the rewrite to golang. It's pretty clear who the winner is.

>First, that's the typescript compiler, not typescript apps. And it was a ground-up rewrite effort (a very large one) with a specific eye toward improving the performance of the original, which was widely held to be sub-optimal for reasons entirely unrelated to implementation language.

The typescript compiler uses v8 as a runtime to run itself and it used to be written in typescript. It was probably one of the biggest typescript apps there is.

Here are some reasons why they chose golang over v8:

* the memory allocation patterns of a compiler were a poor fit for the v8 JIT * the runtime is restricted to a single thread * JITs have to make a tradeoff between startup time and how much time they spend optimizing generated code, AOT compilation can spend more time optimizing while having a faster startup time which is critical for a CLI application, where the JIT cost is paid every time the program is started

You can even look at this blog post and see it for yourself: https://grokkingtechcareer.substack.com/p/the-real-reason-mi...

>Suffice it to say that, hell no, you can't just transpile your code to Go and expect it to run faster. We all know it doesn't work like that.

This is a straw man that nobody is proposing, but even a naive attempt would probably have some benefits, primarily relating to startup time and memory consumption.

>But more broadly, landing with "Please don't use Electron" in the context of a comment about a MS product seems weird given the implementation framework of Microsoft's single most impactful new UI project of the last decade...

>Just stop, basically. You lost. Use Electron. It works great and everyone else already does and proved you wrong.

Use Electron for the typescript compiler? Are you crazy? (note that ajross responded with this comment https://news.ycombinator.com/item?id=48170285)

Re: Native all the way, until you need text

#298

Post by imtringued »

ajross wrote: post #270
bigstrat2003 wrote: post #263

Earlier quoted context omitted.

Electron does not, in fact, work great. Apps which use Electron are an absolute drag for the user because they are slow, use a ton of memory, or both. Any developer who cares one iota about the quality of his software will try to avoid Electron.

> Electron does not, in fact, work great. People get so outrageously bent out of shape over the details here. But it's 100% just geek nattering. People who need to develop and ship general use UI code that isn't a game or an iOS app write to the web stack, every time, for very good reasons. And these solutions win every market they're in. Basically: show me someone displacing VSCode (or any other large established El…

I abandoned VSCode for zed, because I was tired of the slow performance of VSCode and how much memory it consumes.

Re: Native all the way, until you need text

#299

Post by Wowfunhappy »

stavros wrote: post #246
tardedmeme wrote: post #241

Earlier quoted context omitted.

Using an HTML renderer to render arbitrarily formatted text with full HTML formatting capabilities makes perfect sense. If that's your problem statement, then you kinda need an HTML renderer.

The author wasn't trying to render HTML. Everyone is focusing on the word "Markdown", I wish the author had just said "rich text" instead so we could actually have a fruitful conversation.

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.

Re: Native all the way, until you need text

#300

Post by stavros »

Wowfunhappy wrote: post #299
stavros wrote: post #246

Earlier quoted context omitted.

The author wasn't trying to render HTML. Everyone is focusing on the word "Markdown", I wish the author had just said "rich text" instead so we could actually have a fruitful conversation.

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.
Post reply on HN