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

151–160 of 328 posts

Re: Native all the way, until you need text

#151

Post by coldtea »

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.

Re: Native all the way, until you need text

#152

Post by tedggh »

One of the reasons I decided to stay in the shadows as an unglamorous, boring backend developer. Every single time I tried any frontend development, either web or mobile, the moment I started running into issues like this requiring witchcraft to accomplish an objectively trivial task, a bit of my soul left my body.

Re: Native all the way, until you need text

#153

Post by CharlesW »

ryeights wrote: post #141
CharlesW wrote: post #110

Earlier quoted context omitted.

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 native rendering primitives. Do you suggest that every developer who wants rich interactive text in their app should write a text rendering engine from the ground up?

I'm suggesting that instead of going with the heaviest-possible option, they first explore built-in capabilities like TextEditor (https://developer.apple.com/documentation/swiftui/texteditor) and/or the many open source projects which offer Markdown support (https://github.com/gonzalezreal/textual).

Re: Native all the way, until you need text

#154

Post by singpolyma3 »

StilesCrisis wrote: post #93
rubymamis wrote: post #77

Earlier quoted context omitted.

It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps. [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20... [2] https://x.com/daniel_nguyenx/status/…

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

Unless you're on KDE where it's literally native?

Re: Native all the way, until you need text

#155

Post by CharlesW »

bonesss wrote: post #140
CharlesW wrote: post #110

Earlier quoted context omitted.

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.

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.

Re: Native all the way, until you need text

#156

Post by iamcalledrob »

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 used to use a webview too. Adium as well. HTML is absolutely the right tool for the job if you're rendering rich/marked-up text.

Re: Native all the way, until you need text

#157

Post by Barbing »

tom1337 wrote: post #91
pornel wrote: post #38

Usually performance was the reason for using native APIs rather than web views, but this doesn't seem to be true any more. Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps. Meanwhile SwiftUI doesn't feel particularly fast. Apple's latest and greatest rewrite of System Preferences has dumbed down the UI to mostly rows of…

System Preferences also sometimes just render a WebView - most notably in the Apple Account settings

Oh that hackjob explains some of the inconsistent, frustrating performance

(I do give them credit for some terrible usability elements that would delay a scammer if they had our elderly relative on the phone.)

The AppleScript that has to be written and rewritten to flip a simple switch in settings… (it’s telling the system to move around and click in the UI by count, and the count gets thrown off by what I now suspect to be unpredictable web view UI loading)

Re: Native all the way, until you need text

#158

Post by sgt »

stephbook wrote: post #125
sgt wrote: post #113

Earlier quoted context omitted.

Agreed. He's basically complaining and moaning about Markdown not being fast to work with in Swift, when nobody has really put a lot of effort into that yet. yet despite this, he's not willing to contribute to that himself.

Sounds like it would be Apple's job to develop their own platform. I think SwiftUI etc al don't work on Linux and Windoes and Android, right? While HTML works?

Give them a break. Why doesn't the OP just help develop a highly efficient SwiftUI extension for Markdown if it's that important? Remember that there are many efficient MD libraries for Swift/ObjC which would in any case be the sensible approach here (and it also explains why he can't find a SwiftUI alternative to his liking).

Re: Native all the way, until you need text

#159

Post by tclancy »

throawayonthe wrote: post #105
the_gipsy wrote: post #92

Earlier quoted context omitted.

> Using WebKit to render Markdown seems completely appropriate. It doesn't? Needs an explanation.

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.

Re: Native all the way, until you need text

#160

Post by [deleted] »

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…

[deleted]
Post reply on HN