Well, maybe for simple web apps, but for complex applications there is a noticeable slowdown, I am not even talking about monsters such as jira, but well optimized apps such as vs code, there is a performance ceiling which is lower than for native apps.

▲

sznio 4 hours ago | parent | next [-]

For Jira I think the limitation is buried all the backend execution and rendering. It's still fast if you go only by the frontend user-executed part.

▲

pornel 2 hours ago | parent | prev | next [-]

[dead]

▲

StilesCrisis 5 hours ago | parent | prev [-]

According to the article, native is slower though.

▲

CharlesW 4 hours ago | parent [-]

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.

▲

StilesCrisis 18 minutes ago | parent | next [-]

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.

▲

ryeights 4 hours ago | parent | prev | next [-]

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?

	▲	CharlesW 3 hours ago \| parent [-]
		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).

▲

bonesss 4 hours ago | parent | prev [-]

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 items with custom rendering… as a fat client dev you’re only in a little trouble, on the web googlers making google apps force pagination a whole lot.

As a point of comparison: WPF was Microsoft’s attempt to nail the ‘best of the desktop & best of the web’ [And I would argue they effectively nailed it, as a specification.]. But, as a brown belt WPF dev and a blue/orange belt with Win32/MFC, the extra overhead related to WPF broke common scenarios we’d never think twice about on the true native side. The web was made for sharing Robotech technical manuals, OS GUI’s to pump all the rectangles as fast as hardware allows. Apples and oranges.

▲

CharlesW 3 hours ago | parent [-]

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

▲

bonesss 3 hours ago | parent [-]

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.

	▲	CharlesW 3 hours ago \| parent [-]
		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.