Inspecting Web Views in macOS
blog.jim-nielsen.com
blog.jim-nielsen.com
(And where it is used, it's doing the barest minimum. The preference window itself, the top bar, and the iCloud sidebar are all still native UI.)
"Please use the original title, unless it is misleading or linkbait; don't editorialize."
- Loading indicators for several seconds when switching between categories in the left sidebar, on a very decent internet connection.
- Janky animations and transitions when opening modals, like clicking the "Details..." button on a family member.
- Within the "Invite people to your family" modal, clicking "Not Now" causes the "Invite People" button (the default, highlighted action) to blink before the modal closes.
Yes while these are absolutely nitpicks, I feel that Apple has lost some of the attention to detail that set them apart.
Sure you could use something like SwiftUI and create some simple DSL to dynamically build a native UI. But at that point you’re basically building a slightly crappier, less flexible version of HTML. So might as well use HTML+CSS and take advantage of the decades of learnings it represents.
I’ve personally used a similar approach to power a banks fraud warning UI. Made it possible for us to quickly iterate and change our UI as various strategies used by fraudsters evolved. Meant we could go from see a new issue, to updating our ML models and deploying new UI in under a week, which is faster than the app review process.
[1] https://news.ycombinator.com/item?id=30384494
Edit: mention iOS Settings.
Why don’t those both use the same UI toolkit, like the convergent GNU/Linux DEs? (macOS seems to be getting more touch-optimized with each update — eg. making sliders giant and iOS-style; why hasn’t Apple merged Cocoa and Cocoa Touch into one yet?)
we spent decades wedging compatibility shims into gaping functionality holes, while heroic visionaries of the web as a platform toiled and bargained to bring us the tools we needed for modularity, performance, and a modicum of basic platform services.
all while making sure <TD STYLE=FLOAT:RIGHT> continued to work.
There’s a reason you get system colours and fonts in CSS: they’ve been round since the ’90s. You certainly wouldn’t get such useful and flexible stuff being added now.
There are very strong parallels in a lot of the progress that’s been happening in the past few years with what happened twenty years before. Probably the most obvious example is dark mode: computers had that twenty years before, then it got lost somewhere along the way, then it gets reinvented in an only slightly different form (both more and less useful: it’s far more restricted, to just one alternative theme rather than many, but for the web you can actually design for it in CSS alone this time).
Cycles.
Of course that's all kind of moot because the important point is that there's a large different between a native app that uses a webview (or the windows/linux equivalent) to display some content, and a cut down browser view trying to act like a native application. Admittedly a number of the bugs in electron apps are a byproduct of their use of chromium which is very much a Mac-second engine and the actual API requires host apps to do much more work for system integration, which is a valid choice: it gives the host app much more flexibility in handling things. The down side is there are some things that apps shouldn't be trying to reimplement themselves.
Those properties open up the possibility of abstracting things and making very powerful libraries over it. There is nothing else as powerful out there.
Yet, everybody stops at plain react. So whatever is the reason for the success, it's not that one I pointed.
Let me introduce you to https://github.com/ocornut/imgui
React brings to the table is the general concept of immediate mode UI programming. So does ImGUI. Reaching for React doesn't mean it's the only thing the programmers knew, it means it's a general pattern that arises in UI programming.
Have we considered asking why it’s so much easier to find React devs? Why such a huge, huge majority of UI development today takes place on the web?
I’m a front end web developer. I’m very biased.
But I’m a little tired of the narrative that “the right way to make a UI is to build it natively, but everyone wants to take the easy way out.”
Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience. And if you spend some time exploring them, I think that becomes very obvious very quickly.
That depends on what one values, in my opinion. Whenever I start poking around with front end web stuff it makes me want to tear my hair out. Not because it isn't technically capable, but it all feels so slapdash, duct-taped, and chaotic compared to what I'm used to writing AppKit/UIKit, even if some aspects of the experience with front end web tech are nicer. Things are solidifying around React which helps, but for me at least, it's still a hard sell to trade away the positive aspects of native development just to get the positive aspects of front end web dev.
I was a native dev before I got into web stuff. The Apple APIs for native GUIs are so good, but they are extremely verbose, and with swift now they are closed source. It’s just not as easy (or fun tbh) to build things with
Closed source isn’t great, but I’ll take that tradeoff for how much less frequently I need to reach for a third party library or write widgets from scratch.
Recently they’ve been integrated into the IDE but with a right click on a file (within the IDE file browser or project browser panes) you can open a .ui file in the external Designer.
[0]: https://doc.qt.io/qt-5/qtdesigner-manual.html [1]: https://doc.qt.io/qt-5/qtquick-index.html
I guess if cross-platform needs to include mobile, then that's not good enough. But for what it does, I'm very happy with it.
Full disclosure: wxWize is my own creation.
The only platform that offers native RAD like tooling for Web Development is OutSystems, most don't come even close, probably WebFlow.
Naturally since most devs don't like to pay for their tools, their target market is enterprise shops, so only Fortune 500 devs get nice tooling.
Native UI toolkits are light years ahead of anything the web can offer in any forseeable future.
Well, WebGL is somewhat of an exception, but then you're literaly bringing native technologies with limitations into the web.
And one major exception: deployability. Nothing can beat the web in deployment.
Business models centered around the web, like the cloud and SaaS, and because it's the lowest common denominator when it comes to cross platform development.
> Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience. And if you spend some time exploring them, I think that becomes very obvious very quickly.
QML works very nicely, it has a pleasant developer experience, it's reactive and declarative, and it even gives you JavaScript. It's similar to React in those regards, and I prefer it.
Another thing to consider is that native app development is fragmented. For one, there are a variety of platforms. There are four major commercial platforms for consumers: Windows, macOS, Android, and iOS. In addition, each platform has multiple ways of doing native development. I don't know much about the Android ecosystem, but in Windows you have a choice between (off the top of my head) Win32, MFC, WPF, and WinRT (and I may have forgotten a few), on the Mac you have a choice between AppKit and SwiftUI, and on iOS there's UIKit vs SwiftUI. Thus, it's not enough just to hire a developer based on platform; it's important to hire based on experience with the API your application uses.
In my opinion, my negative opinion of Electron on the desktop has nothing to do with laziness. There has always been a tradeoff between developer convenience and optimal performance in software engineering; for example, this is why I write machine learning code in Python instead of fine-tuned assembly. If that's lazy, I'm guilty as charged. Rather, my negative opinion is based on these issues:
1. A disregard for conforming to the platform's UI/UX guidelines, which are in place to ensure consistency in behavior across applications. By Webifying the desktop we get rid of one of the strongest advantages of desktop operating systems, which is consistency across applications, and we turn the desktop into the inconsistent hodgepodge of user interfaces that make up the Web.
2. Accessibility problems that are caused by ignoring the native platform's accessibility APIs.
3. Performance issues caused by running instances of entire web browsers to duplicate UI rendering features that already come with the UI toolkit of the system.
4. Applications written with the Web in mind for the desktop often inappropriately use design elements that may make sense in a web browser but do not make sense on a desktop (this is related to #1).
Some would say that #1 has long been the reality for Windows and Linux long before Electron existed due to competing toolkits (especially in the Linux desktop world) and app-centric viewpoints from application vendors where the look-and-feel of an app trumps platform consistency concerns for branding reasons. I agree. However, some say we should shrug, give up the dream of consistency, and accept having inconsistent applications. I believe there should be more consistency between applications (in fact, I disagree with the notion of app-centric desktop computing in general and strongly favor a component-style model, but that's another debate for another time), and I believe one of the strongest selling points of the Mac is the high degree of consistency that existed among the platform's applications for decades. The move toward Webified desktop apps undermine this consistency, however, and that I believe undermines one of the big things that make the Mac special.
I don't think so. I'd hire an iOS developer for a macOS job. There is enough commonality for it to be an easy transition. It's the same on Windows, the Winforms app I work on has a ton of win32 calls and a smattering of XAML/WPF.
No. No there isn't. As evidenced by the crappy Catalyst and other mobile ports that break all possible platform conventions on MacOS.
Yes, it might be easier, but not easy.
The results aren't good though, the whole thing is painfully slow.
I’ve only recently started working with react, but so far it’s been the best experience I’ve had working with GUI in decades of working with different things.
I’ve always been what you’d call a full stack developer, but I’ve always very much not been the front end design developer, and react with bootstrap and font awesome is the first time I’ve been able to effortlessly create GUI stuff that doesn’t look like it should’ve been made by a front end design type.
So to me this is not at all surprising or crazy. It’s simply what happens when you have a really effective tool that a lot of people know how to use.
I’m also really tired of things that pretend to be single apps but every other thing you click on will jerk you into an entirely DIFFERENT app. Oh, a sidebar: logically, clicking any item on the side should always update the right-hand side, right? Nope: some of the items you click on might update the right-hand side (after displaying a stupid spinner of course); others will hurl you into the App Store app and slide in some un-Mac-like UI to display 3 pieces of information (usually with truncation that can’t be fixed in a view that can’t be resized); still others might just open a web page (one that only works in Safari of course, because to hell with your browser preferences).
Why is any of this crap necessary? It’s perfectly clear that Apple just doesn’t care at all anymore about making nice, smooth, usable experiences. More than that, they don’t seem to even know how their own desktop platform has traditionally behaved. But even if they did want to change how things behave, why are so many things behaving differently? It is a complete mess and they should be embarrassed. No leadership AT ALL on the UI front.
Edit: apparently this is actually more similar to Windows, which also uses React for system settings. All this DE stuff is too complicated for a simple person like me (I just use dwm on desktop and mobile).
Isn't this javascript but without web tech? That doesn't really stray too far from native anyways.
> to adding intrusive ads to the main system menu / search around the time Windows 8 was released
...active desktop's channels[0] were basically ads in your desktop
> GNOME’s example of powering “native” interfaces with JavaScript
...HTML Applications, ActiveScripting (with the JScript backend) and an embeddable MSHTML/IE engine enabled both JavaScript and "web views" in applications (in Visual Basic 4 or later all you had to do was to use the web control to get instant HTML rendering capabilities).
With "active desktop" you could even use an HTML or web page as your background, e.g. back then i had a hacker-ish background with scrolling assembly code at the side (the scrolling was done via javascript) ala Terminator - though i disabled it after some days since it was using pretty much all of my CPU :-P
Shh, please... we don't want WebKit releases to look like xnu releases
(/s ... I hope??)
For what it’s worth there’s JavaScriptCore (at least for mobile) which is the only way to do JIT on iOS. It’s constantly criticized as being slower than competing JavaScript JITs while Apple counters that it’s an important security barrier.
Also, JSC has been faster on Mac than V8 until a few days ago.
But it's really hard to compete. On the browser side, the vendor must only implement the standards as correctly and fast as possible, while the community tries all sorts of crazy paradigms and supports the ones that eventually stick.
On the native side, the vendor must anticipate the trend, invest and support it. If it chooses the wrong one or the implementation is bad, it's years down the toilet. I fear that SwiftUI is taking that path.
The counter though is that Web UIs have struggled and continue to struggle with performance - specifically the RAM usage is insane for what the equivalent native UI. RAM is tightly coupled with standby time in sleep since RAM is the most expensive component at that phase. Turning off banks of RAM is important but you can’t do that if the banks are still in use.
https://stackoverflow.blog/2022/02/21/why-flutter-is-the-mos...
Once the desktop Flutter story kicks off, say good-bye to Electron.
On macOS 12.2 Music consumes much less RAM, and no longer has a webview process.
I'm not an Apple insider, but Catalyst looks like the thing that was codenamed Marzipan for a while. I think it's more for converting iOS apps than web views.
https://9to5mac.com/2021/12/16/apple-is-rebuilding-apple-mus...
I guess the Help documents are Web Views as well, e.g. right-click on an image.
But they are finally rewriting Apple Music app to full native.
Right now they are only a bunch of settings panels remaining.
They are pretty good, especially for the simple things like preference panes.
There are just many more web developers than native developers. And when you have a hammer...
It feels a bit tacky to me that Apple would use something a bit janky, it points at a bit of a gap in tooling.
That's besides the point though, because I doubt Apple chose React because they "enjoyed" it here.
I like web tech but I also think it's not worth it for this use case (even if it is shared with the web). What naturally happens is you start asking "well if we did it for that, why not for this?" Sooner or later it invades the system.
I've worked on desktop apps where the same thing happened where webviews were not truly needed.
I don't have a hate for it in general, but Apple was extremely strong in native UI so I would have liked to see them try to stick to that, even if it meant coding it twice.
So probably not.
Ditto for the Details sheet. That one also doesn't honor the system-wide feature of navigating prompts with Cmd-(first letter of buttons), doesn't support Esc to leave, and doesn't have a default button to boot.
The +/- icons that appear in the Family Sharing are also completely unique to the OS. Ugh. I could go on.
It really doesn't, and Apple's own apps are the first to break all the HIGs
It's the worst.
The glacially slow UI performance is terrible. It's also unreliable in weird ways that are hard to explain in a sentence or two.
After all, If Apple does it....
The problem with electron apps is that they are entirely a single webview, that poorly implements the vast majority of standard platform affordances (if you read the other comments, you see a lot of people complaining about this specific part of System Preferences). Add to that these applications using absolutely astounding amounts of ram, huge downloads because you're essentially downloading a full copy of chrome for each app, they all have terrible launch times (because there's each is loading its own copy of chrome), the bad and laggy accessibility features, etc and the reason people dislike them becomes fairly clear.
I get that there's very little standard UI or inter app interaction on linux and windows, but historically that has not been the case on Mac - the increasing prevalence of low quality electron apps is making that less reliable.
The only electron app that is actually a good app is VSCode, and even that is always frustrating to use due to a bunch of basic platform behavior that they at best get wrong, but more often just don't even attempt.
It means they're not really willing to put in the work to make it run well. They just want to cobble something together and get it out there. There's really well-performing Electron apps, like VS Code. But the very same company also produces extreme turds, like MS Teams. This app is extremely unresponsive, takes about 30 seconds to sometimes even a minute to start up on a clean M1 Mac, and often crashes or just hangs. It's really horrible. And unfortunately the app I need the most for work.
These are the apps that give these cross-platform web technologies a bad name. I understand why now that I have to struggle with this crap every day. With slack I just minded the UI not really fitting in but it performed just fine so I didn't hate the tech so much.
Among these options, it seems that Rust is most similar to JavaScript. But this whole article would be the same if React was written with Rust instead.
So what is the broken part of GUI development, and why is Rust positioned to fix it? As I see it, not much would change if we used Rust instead of JavaScript, except that it could be harder to diagnose when ReactInRust is being used.
Are you talking about the MacOS System Preferences app, which has probably been around since Macs switched to Intel, or about React? Either could fit that description.