Native all the way, until you need text
Posted by Successful_Bowl2564@reddit | programming | View on Reddit | 42 comments
Posted by Successful_Bowl2564@reddit | programming | View on Reddit | 42 comments
somebodddy@reddit
Just because the native toolkit is not sophisticated enough for your needs, doesn't mean you have to resort to Electron. There are options like GTK or QT that have features like polished text handling and don't hog 153% of your computer's total RAM.
TheRealPomax@reddit
You know what the worst use case of RAM is? Not using it. If you have RAM free while doing your daily driver jobs, you are not getting the most out of your system. This was true in the 486 days, it's true today, it's going to be true 30 years from now. You don't have RAM "to keep it unused", you bought it to make sure every last byte gets used.
Want to complain about dumb RAM use, talk about Chrome tabs. But Electron's memory usage is literally "whatever the developer cared to invest time in". You can make it as lean or as rich as you want, and if they offer what they made to you for free: take it or leave it, but complaining about RAM is 153% entitlement.
pron98@reddit
I'm running three Electron apps (VS Code, Codex, Slack), Safari with about 200 open tabs and Chrome with three open streaming services (not actually streaming right now), Keynote, and a bunch of terminals on an M1 Mac with 16GB of RAM. Only 13GB of physical RAM is used. I have no idea how much virtual memory is used, but I don't care because nothing is sluggish.
davidalayachew@reddit
Ron, I can appreciate this logic when we are talking about a web server running only a single jar file, but you're wrong when talking about an application running on the user's desktop/phone.
The reason people are complaining so much about Electron apps is because most of them are actually multi-tasking, doing multiple heavy-duty things at once.
You're talking about a bunch of unloaded tabs on your browser, a text editor, a chat app, and an AI chat app. The people usually complaining about Electron are the ones trying to run a game, a wiki, and a video, all at once. That is when having an Electron app running in the background alongside those 3 becomes a pain in the neck.
And to that point, VS Code is one of the few examples of an Electron app that is genuinely well optimized. The vast majority of other Electron apps cannot say the same. For example, if I have Microsoft Teams open, my Maven build times improve by a double digit number of seconds.
bla2@reddit
The post is about writing a macOS / iOS app. While GTK or Qt work on macOS, they don't give you a native UI feel at all.
davidalayachew@reddit
I don't work with either of those tools, but any mature UI framework should be able to let you alter the Look & Feel easily. From there, it's just a matter of picking someone else's preset that looks native, and go from there. Maybe tweak it to your needs.
In Java, we have Swing and JavaFX, and both have no trouble mimicking a MacOS L&F. And JavaFX can be used to make mobile apps for iOS and Android. So from there, one codebase, multiple targets, minor amounts of glue code for each, one of which is the L&F config.
somebodddy@reddit
Does Electron?
HighRelevancy@reddit
You'd get the system context menus unless you override them I think. Not an electron dev but I sure use plenty of them. Certainly you're less distant from native constructs.
DeliciousIncident@reddit
Qt is amazing and most of it is freely available under LGPL, so you don't even need a commercial license to use it in a closed source project.
LumpyFlint@reddit
Yeah let me just write a GTK+ app for MacOS lmao
Maybe-monad@reddit
Electron depends on GTK
CelDaemon@reddit
That doesn't mean electron is GTK. Also, using pango directly is another option.
atomic1fire@reddit
Only for a subset of things on Linux.
Otherwise Electron uses views which is a google specific library.
But mostly just the webview portion of the code as far as I can tell.
putergud@reddit
It's hard to do X using tool A so people should stop complaining about tool B. The author doesn't seem to know that tools B, C, D, etc exist.
aka1027@reddit
X is text rendering and manipulation. A is SwiftUI and other apple libraries. B is Electron. What are C, D and E?
wasdninja@reddit
Shouldn't SwiftUI, AppKit, TextKit and WebKit be enough for something that would be really easy in Electron aka a website? That's seems like a really low ask and lots of tools to do it with.
PPatBoyd@reddit
Author says doing it natively is hard, so use Electron or React-Native... React-Native is native. That won't make it easier by much.
Yes text layout is hard, and if your purpose is fundamentally rich or complex text rendering and layout you can't separate text layout from layout. This article feels like it's lamenting that native UI frameworks aren't HTML, as if the creators have spent decades optimizing for the wrong thing instead of converging on everything being rendered by a web browser. I'll show my age pointing out that things like Microsoft's RichEdit exist too, with generalizations for arbitrarily content to be incorporated into rich text layout.
start_select@reddit
React Native isn’t native. It’s interpreted JavaScript that is driving a scripting layer over native components. It’s close to native rendering capabilities but 10x harder to do custom work.
You are bouncing between a single threaded app and multiple service and ui threads which can be blocked by the app thread. Learning to manage that for custom text or 3d rendering isn’t easier than all native, it’s actually more difficult.
RN just provides a somewhat useful abstraction that’s very high level, and kind of translates across platforms. It really doesn’t, but you can write SIMILAR code for two platforms.
DeliciousIncident@reddit
It boggles my mind that Windows 11 Start menu is a React Native app.
----Val----@reddit
Afaik the start menu is mostly still C++, with one section built in React Native.
PPatBoyd@reddit
Yes what you're saying about interpreted JS procedurally generating native UI is correct. React-Native fundamentally projects to another UI framework. When targeting multiple platforms it adds extra constraints and hurdles for top-end polish.
I have a deep appreciation for your ending note about writing similar UI across platforms; the gritty details of different native UI platform expectations for developers emerge on both fronts, from the OS (native UI mechanics) and from users (on-platform look and feel). It's also really easy to couple "business" logic and UI code, which is painful to disentangle.
To me at least, the idea that learning RN is easier than learning native is a minor benefit for webdevs and is somewhat disingenuous. That can be a benefit in some circumstances, e.g. ramping up, but it runs out of small wins quickly.
The greater sell for me is that it can be easier to build and maintain across multiple platforms than having two independent native UI implementations, and if you are also targeting web it's the easiest way to share business logic written in TS/JS. With its model for writing new modules and native UI components, you have an on-ramp and an off-ramp to deciding how much you actually want to share. Let the complex text or 3d rendering be handled by platform-specific native UI components; you can drop down to the native UI framework and do work there directly as needed.
zanotam@reddit
All clankers are bastards
13steinj@reddit
Yeah but it's easier for everyone who doesn't want to do the hard work of writing a truly native application to feel good about themselves.
OTOH, when can you consider an app "native"? If a bunch of logic runs through a Python or Java VM, is that still native? I can make both sides of the argument. At some point desktop Flutter was (still is?) JavaScript based.
I think there needs to be a better qualifier
devbent@reddit
The Rich Text control is so amazing. One of the highlights of my career was just getting a chance to briefly correspond with its creator - Murray Sargent III.
Super brilliant dude, sadly it looks like his Wikipedia page was deleted, which is unfortunate as he has had an awesome career spanning over decades.
PPatBoyd@reddit
Aww I was on Murray's team for a number of years; he's awesome! Genuinely passionate and curious in all directions.
devbent@reddit
While briefly working in the Office org I got to ask him some questions about rich text. One of the few times I've been star struck, and I've worked with more than a handful of programming celebs!
NSRedditShitposter@reddit
SwiftUI is technically native yet it is still a poor fit for Apple platforms.
PPatBoyd@reddit
Genuinely curious and not especially informed on SwiftUI; what do you mean by "technically native"? I'm inferring an aspect of SwiftUI isn't fitting the traditional "native UI framework" mold?
NSRedditShitposter@reddit
My criteria of “native” has more requirements than just “Apple shipped it”.
Cocoa nudges developers into writing apps that have an excellent user experience with code that is organized and generally performant. SwiftUI simplifies user interfaces down to an output of state, [which leads to many problems.](https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html?m=1) SwiftUI apps just don’t have the magic Cocoa apps do, it’s clear the people for whom the framework was designed for are STEMcels who look down upon design and their users, there’s no soul in it.
SensitiveDannyRicc@reddit
So you just use a definition of native that nobody else does lol?
NSRedditShitposter@reddit
Can’t you figure out basic wordplay with “technically native”?
Proof-Attention-7940@reddit
The “React” snippets in that article are bizarre, I’ve never seen production React code written like that. Blind array.prototype.maps, function binding in rendering logic, some sort of mythical “rerender()” method, mutations of props…
cloudsInTheBlueSky@reddit
I think a lot of performance issues with SwiftUI would be solved if Apple gave us more control and a way to interact with the AttributeGraph directly. The state attributes are really easy to use, but it's pretty much impossible to write your own custom state logic without knowing when the "actual view" gets (de)allocated.
start_select@reddit
It’s not a ui framework. It’s a layout engine. That’s pretty much it. It doesn’t even have navigation. It’s for laying out components on the screen and hooking up state/events.
UIKit is the app framework. When swiftUI can’t do something, UIKit does. When UIKit can’t, Core Animation can. When Core Animation can’t, core graphics can. When core graphics can’t, OpenGL and Metal can. So on and so forth.
They are layered APIs. SwiftUI is the simplest abstraction at the top, and the most limited. Metal is the most complicated on the bottom. They are all just rendering engines. UIKit is the app framework.
cloudsInTheBlueSky@reddit
SwiftUI is not just a wrapper for UIKit/AppKit. Views are a blueprint for some private framework that does the rendering. UIKit/AppKit is wrapped where needed, but there are also SwiftUI views like
Textthat don't have an underlying responder.start_select@reddit
It’s not technically native, it is native. It’s compiled code and compiled UI code. Swift is not interpreted.
PaddiM8@reddit
Native GUI is different from native binary. A C program with an Imgui interface would be considered a native binary, but the GUI is not native.
LiftingRecipient420@reddit
Imagine thinking Apple native UI was serious.
nyctrainsplant@reddit
Yes, "jumpy scrolling" is fine. It's called "scrolling". Not the (mostly intentionally) lethargic 'smooth' scrolling that breaks all the time and slows everything down. "Jumpy" scrolling ironically looks even better on mobile a lot of the time.
LegendMotherfuckurrr@reddit
DirectWrite with Windows is good and easy.
RaccoonElaborate@reddit
Apple hates its users and that includes developers. I wonder how whatever type of project the author was working on would fare under GNOME.
start_select@reddit
SwiftUI is mostly about simple layout rendering and simple state handling and simple data fetching to components.
If you want to do something useful you wrap UIKit, AppKit, CoreGraphics, or another lower level view in SwiftUI. Or you avoid SwiftUI all together.
It’s useful but none of these APIs are a kitchen sink. SwiftUI is the MOST abstracted layer at the top. If you want custom rendering, you drop down an api or two until you hit the features you need.