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

161–170 of 328 posts

Re: Native all the way, until you need text

#161

Post by mpweiher »

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

> 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 does the value of TypeScript itself, but in many cases TypeScript has not been able to scale up to the very largest codebases."

And to fix that performance problem, they had to reimplement Typescript (aka "the Typescript compiler") in Go. And that made it 10x faster.

And I am not sure you got "just transpire your code to Go" from, because I sure as hell didn't write it. And if you know it doesn't work like that, and I sure as hell didn't claim it works like that, why did you introduce this straw man?

This is all plain facts.

So yes: please stop the flaming. And please stop using Electron. Dennard scaling hasn't been with us for some time now.

Re: Native all the way, until you need text

#162

Post by mpweiher »

carlosjobim wrote: post #109
Wowfunhappy wrote: post #55

Earlier quoted context omitted.

I mean, this is why I think PDFKit is a good comparison. Could you render your app's entire UI as a series of PDFs? Absolutely! Should you do that? Uh, probably not. You should use the native controls Apple gives you for buttons and dialogs and input fields and so on. But WebKit is the native UI for HTML, and Markdown is intended to be transpiled to HTML.

If think that the MacOS GUI is actually entirely rendered as a series of PDFs, if I have understood things correctly.

You have understood things incorrectly.

Re: Native all the way, until you need text

#163

Post by mpweiher »

jonhohle wrote: post #116
carlosjobim wrote: post #109

Earlier quoted context omitted.

If think that the MacOS GUI is actually entirely rendered as a series of PDFs, if I have understood things correctly.

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.

Re: Native all the way, until you need text

#164

Post by iamcalledrob »

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…

...although the logic in the article is slightly odd:

  1. Discover complex native text rendering is hard
  2. Render text in a low-level way, complain about having to (re)implement native interactions
  3. Try WebKit and it works great!
  4. Throw WebKit away??
  5. Have to re-implement native interactions??
Personally, I would have stopped at (3).

Re: Native all the way, until you need text

#165

Post by bonesss »

CharlesW wrote: post #155
bonesss wrote: post #140

Earlier quoted context omitted.

If you account for dev time, ‘giving up’ and just doing it in a web renderer is totally valid. Choppier, more memory, bad if the device is failing, but 98% of the time that can be acceptable. Native GUI dev, tho, can enable low-resource performant apps just by sticking the rudimentary OS is a way no higher app really can, and with capabilities that’d choke a web app. Load up a listbox with a few tens of thousands of…

> If you account for dev time, ‘giving up’ and just doing it in a web renderer is totally valid. For sure, all software is chock full of "best? no/works? yes" compromises. I object to the article framing of "I couldn't figure it out, therefore TextKit 2 does not play well with anything modern", which is a very silly conclusion.

Agreed, but no such conclusion or framing was stated, supported, or suggested in my comment.

I was agreeing and providing more context to the costs of building at a higher level, like Electron, and the limits even when applied by a unified vendor with incentives for high performance.

Re: Native all the way, until you need text

#166

Post by argee »

sgt wrote: post #117
diego_moita wrote: post #21

Outside of niche applications (e.g. virtual desktops, gamming, embedded systems) native UIs are dead. There are even parts of both Windows and MacOS rendered through HTML. If I remember correctly, at least in Windows 10, File Explorer was rendered through Internet Explorer. Web rendering doesn't need to be only through Electron/Node. There are other libraries much more performant and lean (Dioxus, etc).

> 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?

Re: Native all the way, until you need text

#167

Post by tpmoney »

pier25 wrote: post #118

Maybe controversial but I think HTML + CSS is truly the most powerful system to make GUIs. There’s really nothing else out there that competes with a similar performance and productivity. This old article by the Missive team (the email client) convinced me. https://medium.com/missive-app/our-dirty-little-secret-cross...

In a way it really is, in part because HTML + CSS is the back door "universal native GUI framework" that various projects have been chasing for years. Because browsers and GUI elements in them are so important to modern computer use, every OS vendor has a vested interest in ensuring the default look and behavior of elements in their browsers are native (or as native as possible). As a result, if you can render your UI in a browser (or in a browser frame/view) chances are you can get a native looking and native feeling UI for your application with a well understood and robust piece of technology that will retain that look and feel even as the underlying OS changes around it.

Re: Native all the way, until you need text

#168

Post by krzyzanowskim »

CharlesW wrote: post #101
krzyzanowskim wrote: post #84

Earlier quoted context omitted.

SwiftUI, (but not specifically "SwiftUI", more of paradigm) is not the right tool to incremental changes of large portion of data, and SwiftUI specifically is very bad at it and offer no good API to make incremental changes more optimal. That's one of the reason behind why Apple to this day did not ship usable SwiftUI text view component.

They did last year. I can understand why you're confused, since it came in the form of the radically-improved `TextEditor`. https://wwdcnotes.com/documentation/wwdcnotes/wwdc25-280-cod...

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

Re: Native all the way, until you need text

#169

Post by CharlesW »

bonesss wrote: post #165
CharlesW wrote: post #155

Earlier quoted context omitted.

> If you account for dev time, ‘giving up’ and just doing it in a web renderer is totally valid. For sure, all software is chock full of "best? no/works? yes" compromises. I object to the article framing of "I couldn't figure it out, therefore TextKit 2 does not play well with anything modern", which is a very silly conclusion.

Agreed, but no such conclusion or framing was stated, supported, or suggested in my comment. I was agreeing and providing more context to the costs of building at a higher level, like Electron, and the limits even when applied by a unified vendor with incentives for high performance.

I added the word "article" before the word "framing" to make it clearer in my comment supporting your comment that the last half of my comment wasn't commenting on your comment.

Re: Native all the way, until you need text

#170

Post by enbugger »

LtWorf wrote: post #147
enbugger wrote: post #126

Earlier quoted context omitted.

A decision to move native because of the crisis seems like an expensive populist move to please not very solvent users. Why bother with that if many predict the RAM crisis will last merely until 2027?

If you can predict the future so accurately, why aren't you the richest man on the planet?

I can't. But I'm sure I will be happier and richer person if I don't opt out self from a working stack in favor of saving 100-200mb RAM
Post reply on HN