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

141–150 of 328 posts

Re: Native all the way, until you need text

#141

Post by ryeights »

CharlesW wrote: post #110
StilesCrisis wrote: post #98

Earlier quoted context omitted.

According to the article, native is slower though.

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?

Re: Native all the way, until you need text

#142

Post by ryeights »

tantalor wrote: post #80
Wowfunhappy wrote: post #19

If you're on macOS, WebKit is a native OS framework. Using WebKit to render Markdown seems completely appropriate. Now, if you're rendering everything with WebKit, that's ridiculous, in the same way rendering everything with PDFKit would be ridiculous. But for a Markdown view, WebKit seems like a logical choice. There's no need to subsequently flip the table and replace everything with a Chromium web app.

OP thinks "native" = only using Swift/ObjC primitives WebKit is cheating I guess? Because it exists on other platforms? Might as well use Java

So I can build my entire app in a WebKit wrapper and call it native? I think ‘native’ in this context is well-understood to mean eschewing web or cross-platform renderers

Re: Native all the way, until you need text

#143

Post by xigoi »

dist-epoch wrote: post #36
elch wrote: post #4

How is "performance" defined? Does it take into account the amount of memory required in each case?

first you make it correct, than you make it fast a fast performant incomplete solution will lose to a slow correct complete one

You can’t make a lightweight airplane by making a heavy airplane and cutting off some parts.

Re: Native all the way, until you need text

#144

Post by tux3 »

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.

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.

Re: Native all the way, until you need text

#145

Post by fassssst »

teddyh wrote: post #71

I know nothing about any of these APIs, but the claim of the article seems weird. If naitive APIs are insufficient, or slow, or unsuitable, and implementing your own is too hard, then how does Electron even do what it does? One would assume that Electron has its own library to accomplish the task, in which case this code could either be separated, or re-created once and for all, into its own re-usable library.

Chromium has had an insane amount of investment from many large companies. Way more than native UI frameworks have had over the last decade or so.

Re: Native all the way, until you need text

#146

Post by nielsbot »

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

I assume because there’s no good “render a view hierarchy based on layout delivered from a server” option. Whereas this is what HTML is with caveats.

Re: Native all the way, until you need text

#147

Post by LtWorf »

enbugger wrote: post #126
Dwedit wrote: post #68

Earlier quoted context omitted.

Now RAM use is the main reason to prefer native APIs over web views.

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?

Re: Native all the way, until you need text

#148

Post by nielsbot »

mpweiher wrote: post #131
ajross wrote: post #111

Earlier quoted context omitted.

This is the ActiveX/nacl/wasm/etc... argument recapitulated. For decades, people dithered about how to get fast code into browser environments such that it could be deployed safely. Then the V8 team at Google just asked "well, what if we just made Javascript crazy fast instead?", and here we are. There's still room for native code in environments that don't map nicely to scalar scripting languages, but not a lot of r…

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.

I am going to miss being able to host TypeScript in a web view however.

Re: Native all the way, until you need text

#149

Post by ajross »

mpweiher wrote: post #131
ajross wrote: post #111

Earlier quoted context omitted.

This is the ActiveX/nacl/wasm/etc... argument recapitulated. For decades, people dithered about how to get fast code into browser environments such that it could be deployed safely. Then the V8 team at Google just asked "well, what if we just made Javascript crazy fast instead?", and here we are. There's still room for native code in environments that don't map nicely to scalar scripting languages, but not a lot of r…

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

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.

Re: Native all the way, until you need text

#150

Post by [deleted] »

dive wrote: post #121
Wowfunhappy wrote: post #86

Earlier quoted context omitted.

> But I think it also supports the broader point I was making: if you want to work with rich text, Markdown, selection, typography, and long-form formatted content properly, web technologies quickly become the only viable option. But, like, of course they are. This is what HTML was built for. The other major standard would probably be RTF, but it's a bit less structured, and so less close to Markdown. HTML is the bet…

I am with you here. But I think my opinionated point from the article still stands: if you need rich text & good typography without fighting the platform, then web technologies quickly become the pragmatic choice. For my app, I will probably continue with WebKit. It is the most reasonable middle ground for now. But in this situation, it is tempting to jump to something with a stronger rendering engine, like Chromium…

[deleted]
Post reply on HN