[HN Gopher] Inspecting Web Views in macOS
___________________________________________________________________
Inspecting Web Views in macOS
Author : ansh_nanda
Score : 492 points
Date : 2022-03-12 02:27 UTC (20 hours ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| cosmotic wrote:
| This seems like a huge security risk. Are they auditing the
| thousands of third-party packages that make up a typical react
| app?
| ThePowerOfFuet wrote:
| Interestingly, the screenshot doesn't show <settings-app>, but
| <settigns-app> [sic].
| efortis wrote:
| Awesome! Do you know more Web Views in use?
| woodruffw wrote:
| Don't quote me on this, but I believe that Apple Music (nee
| iTunes) has used web views for a long time; probably over a
| decade. The entire thing probably isn't a web view, but my
| recollection is that the store components were.
| sitharus wrote:
| Apple Music is now using a technology they developed to
| convert web views back to native -
| https://news.ycombinator.com/item?id=30648424
|
| On macOS 12.2 Music consumes much less RAM, and no longer has
| a webview process.
| comex wrote:
| Wrong link?
| cryoz wrote:
| Still remains quite slow and unresponsive in comparison to
| Spotify.
| woodruffw wrote:
| I think your link is wrong; are you thinking of
| Catalyst[1]?
|
| 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.
|
| [1]: https://developer.apple.com/mac-catalyst/
| sitharus wrote:
| Yes, I intended to link to the 9to5mac article, but it's
| too late to edit
| mrpippy wrote:
| No, it's something internal called JET
|
| https://9to5mac.com/2021/12/16/apple-is-rebuilding-apple-
| mus...
| efortis wrote:
| Library -> Albums has some onHover feedback, which I haven't
| seen anywhere else.
|
| I guess the Help documents are Web Views as well, e.g. right-
| click on an image.
| ksec wrote:
| Yes, both iTunes and Apple Music. That is why they are slow,
| comparatively speaking.
|
| But they are finally rewriting Apple Music app to full
| native.
| lelandfe wrote:
| Unsurprisingly the App Store is another example.
| jeroenhd wrote:
| I remember giving up on my Hackintosh install after the App
| Store started rendering without CSS, breaking update
| functionality. Always thought that to be a weird failure
| mode for a system application.
| galad87 wrote:
| App Store was rewritten in 10.14 and it no longer uses a
| Web View for the main content, some Apple ID setting might
| still be Web Views.
| galad87 wrote:
| A lot of Apple apps used to use Web Views on macOS: Messages,
| Music, TV, App Store, for example. But they have been slowly
| phased out. Messages in Big Sur, App Store in Mojave, Music and
| TV in Monterey.
|
| Right now they are only a bunch of settings panels remaining.
| ehnto wrote:
| I have noticed web being used as a platform for UI in a bunch of
| programs, particularly within games.
| kizer wrote:
| It's replaced ScaleForm (the Flash powered UI option) in many
| places it seems. I'd love to know what kinds of techniques are
| used for really flashy UIs. There are a few companies solely
| focused on this middleware (web-based UI in video games).
| [deleted]
| adamnemecek wrote:
| GUI development is really fucking broken. I get it, it's hard to
| compete with a standardized platform with a probably billion man
| hours poured into it but I'm really hoping that Rust will make it
| possible to write native and web experiences from one codebase.
| throwaway81348 wrote:
| why Rust in particular?
| hiptobecubic wrote:
| What does rust have to do with this?
| zer0-c00l wrote:
| it allows OP to farm karma effectively
| ashton314 wrote:
| Appears to be backfiring somewhat. I say that as a Rust
| enthusiast.
| adamnemecek wrote:
| Its the first language that lends itself to be used both on
| the desktop fornative GUIs as well as in the browser.
| r00tanon wrote:
| I missed the /s ?
| iso8859-1 wrote:
| This post is talking mostly about CSS and it shows a document
| object model tree. JavaScript is also used, given that he
| mentions React.
|
| 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.
| eyelidlessness wrote:
| Amusingly, SwiftUI seems much better suited to this use case
| than any other lower level language, while Elm and Clojure
| are much more obvious contenders. In any case, the space is
| crowded with DSLs and the expression-based DSLs are the ones
| that generally keep gaining traction.
| virchau13 wrote:
| The broken part is that it is worth it to use an inefficient
| rendering method (lots of JS generated by React + an
| interpreter and GC + a render tree (React VDOM) + an
| overcomplicated element tree (DOM) + a rendering system)
| instead of an efficient rendering system (if React-in-Rust
| existed, it would be native executables manipulating an in
| memory tree for a renderer, removing at least two layers of
| complications). And this seems to be simply because the
| React+JS model works so well for DX compared to the rest that
| it allows for way faster feature implementation.
| jkelleyrtp wrote:
| I've been working on this :) https://dioxuslabs.com/
| SkyMarshal wrote:
| _> I get it, it 's hard to compete with a standardized platform
| with a probably billion man hours poured into it_
|
| 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.
| adamnemecek wrote:
| I'm talking about WebKit.
| maxloh wrote:
| How about flutter? It uses native views.
| heavyset_go wrote:
| As far as I'm aware, Flutter is like Qt and React Native in
| that its platform controls are redrawn to look like native
| controls.
| skydhash wrote:
| Flutter replaces the entire views with its own rendering
| engine. That has caused some issues with consistency.
| lucasyvas wrote:
| OK interesting - but why?
| jollybean wrote:
| Probably because the devs want to do something and have no
| properly useful tools available to them, so they use something
| out of convenience.
|
| 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.
| est wrote:
| Looks like it's Apple's Internet offerings, which is a growing
| number of services which makes perfect sense to write them
| inside a server updatable webview.
| 8note wrote:
| React is enjoyable to use?
| lucasyvas wrote:
| As a web developer that primarily codes in React for the last
| 5 years, I strongly disagree. I use it because of the
| ecosystem and I think everyone does. It's not that fast, and
| it's quite verbose.
|
| 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.
| rhodysurf wrote:
| It's definitely a bit disingenuous to call React verbose
| when you are comparing it to Cocoa et all.
| jmull wrote:
| The previous poster wasn't comparing it to Cocoa when
| calling react verbose.
| wetpaws wrote:
| Not sure how do I feel about this, amused or horrified.
| lucasyvas wrote:
| How about bewildered?
| [deleted]
| johnfn wrote:
| Wow. I always thought the argument in favor of using web
| technologies on the desktop was that cross-platform became
| easier. And yet here is an example of the most unambiguously
| single-platform app I can possibly imagine, and under the hood it
| uses web - and React of all things! Crazy.
| cosmotic wrote:
| They probably gave the icloud team, a team largely made up of
| web developers, full authority over that system preference
| pane. Their experience is in react, they chose react; makes a
| lot of sense. Even more so if the data here is used by similar
| pages on the web version of icloud.
| tonyedgecombe wrote:
| I could see that they want the flexibility to change the web
| app without having to roll out a Mac update.
|
| The results aren't good though, the whole thing is painfully
| slow.
| EnKopVand wrote:
| Why is it crazy? Doesn't a lot of the office tools also use
| react these days (maybe just the online ones but still)?
|
| 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.
| ketzo wrote:
| As it turns out, React / CSS / the document-object-model are
| popular for more reasons than "it works on different
| computers." Who knew!
| knome wrote:
| I expect these additional reasons can largely be summed up as
| "I already know it from using it in the browser, so let's use
| that"
| inopinatus wrote:
| I think it's a little unfair that you've been so downvoted
| (at the time of writing), because the old phrase about
| hammers and nails is super applicable to software
| development, and the icloud team may very well know react
| better than cocoa.
| marcosdumay wrote:
| Actually, web pages are a very declarative GUI, with an
| amount of reflexivity and editability that should be on any
| declarative GUI framework, but normally isn't.
|
| 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.
| dymk wrote:
| You'd probably be wrong!
|
| Let me introduce you to https://github.com/ocornut/imgui
| junon wrote:
| Which doesn't use React, CSS, or a DOM...? What's your
| point? ImGUI is imperative UI programming. DOMs are
| declarative.
| dymk wrote:
| ImGui makes UI programming declarative in structure the
| exact same way React makes UI programming declarative.
|
| 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.
| junon wrote:
| No, it absolutely does not. ImGUI is a completely,
| totally different model of GUI programming.
| dymk wrote:
| Sorry, but they are the same concept. They're both
| immediate mode GUI tools that provide a way to
| declaratively describe the UI in an imperative language.
| junon wrote:
| React is not immediate mode, imgui is not declarative.
| __del__ wrote:
| who knew? it sneaked up on us.
|
| 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.
| tonyedgecombe wrote:
| These pages are the least performant part of the
| preferences application.
| olliej wrote:
| Apple has been using web views for apps for more than a
| decade - recognizing that such an object is more generally
| usable than just "a browser" was a motivation for WebView
| (now WKWebView) existing as a platform API from the
| earliest days of WebKit being a thing that existed (The
| logical extreme being the original WebView API exposed an
| objc interface to the DOM)
| chrismorgan wrote:
| And Windows pushed in this direction _heavily_ back
| around 1999-2005, with things like
| https://en.wikipedia.org/wiki/HTML_Application and IE
| being used quite extensively in Windows Explorer in
| Windows XP and a couple of versions around it. (In fact,
| if it weren't for the whole antitrust situation around
| the inclusion of IE, I suspect they would have gone even
| further in on web content on the desktop rather than
| letting it lie fallow for something like fifteen years.)
|
| 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.
| olliej wrote:
| My recollection of using the old windows HTML control was
| that it was very useful outside of being a basic content
| view - obviously there was subsequent additions to the
| web that made some functionality in webkit available, but
| the WebView controls in my extremely limited experience
| seemed a much better fit for minor content views in apps.
|
| 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.
| heavyset_go wrote:
| I'd bet that the reason they're using React is because it's
| cheaper and easier to find front-end developers for the task.
| ketzo wrote:
| I've been hearing this on HN and similar forums for what
| feels like years now: "Electron/web-based GUIs are only
| popular because it's easy to find devs in those ecosystems"
|
| 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.
| heavyset_go wrote:
| > _Why such a huge, huge majority of UI development today
| takes place on the web?_
|
| 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.
| linguae wrote:
| I believe the reason why so much UI development takes
| place on the Web is because there are a lot more people
| making websites and web applications than there are
| making desktop applications. For example, think of all of
| the businesses and institutions, big and small, that need
| a web presence. Because the Web is such an essential part
| of modern commerce, it makes sense that there would be
| much more work available for web UI development than for
| desktop UI development. In addition, the Web is quite
| possibly one of the easiest platforms to deploy an
| application. Want to reach much of the world? Spin up a
| cloud VM, get yourself a static IP and a domain name,
| deploy your web server, and voila!
|
| 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.
| tonyedgecombe wrote:
| >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.
|
| 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.
| dmitriid wrote:
| > I'd hire an iOS developer for a macOS job. There is
| enough commonality for it to be an easy transition.
|
| 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_.
| dmitriid wrote:
| > Perhaps the explanation is that native GUI frameworks
| simply haven't kept up in terms of developer experience.
|
| 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.
| kitsunesoba wrote:
| > Perhaps the explanation is that native GUI frameworks
| simply haven't kept up in terms of developer experience.
|
| 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.
| rhodysurf wrote:
| I'm guessing you haven't tried building something serious
| with SwiftUI then. Because for me React is a million
| times more polished than SwiftUI.
|
| 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
| kitsunesoba wrote:
| SwiftUI is promising, but still green (for now). So no, I
| was talking about just plain old AppKit and UIKit. No
| fancy declarative syntax, but plenty capable.
|
| 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.
| easrng wrote:
| Seriously, have you TRIED non-web, cross platform, UI
| dev? It's a nightmare. At least all the things I've tried
| so far are. I'm trying KDE's Qt IDE out and so far it
| seems much better at getting a working example built,
| though it looks like it's missing a visual interface
| editor. Qt-the-company had a good visual interface editor
| I used in ~2018 I think with PyQt but I can't find a way
| to launch it anymore. It's a mess.
| 0xabe wrote:
| Qt Designer[0] (for widget-based interfaces) is still a
| thing, and they have added Qt Quick[1] and Qt Quick
| Controls (for QML-based interfaces).
|
| 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
| heavyset_go wrote:
| I have, and I found QtQuick and QML to be a better
| experience for reactive UI programming.
| tonyedgecombe wrote:
| Some of us don't think much of Qt either.
| munch117 wrote:
| I am insanely productive writing desktop applications
| with wxPython+wxWize. No GUI designer, no XML, just
| straight up Python code that's easy to follow and easy to
| refactor. I can whip up a prototype as fast as I ever
| could in Delphi, and it transitions cleanly into the
| finished app.
|
| 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.
| xioxox wrote:
| The GUI designer is called Qt designer - it's called
| designer in Ubuntu/Debian. Unfortunately Debian has
| really made a mess of their packaging of Qt/PyQt. They've
| split up everything into tiny packages and their naming
| scheme seems crazy - I can never work out which package
| to install to get what I want. In this case it's
| qttools5-dev-tools.
| pjmlp wrote:
| I have, since the days of 16 bit home computers where
| when I wanted ultimate performance it had to code the
| core of the application in straight Assembly.
|
| 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.
| oefrha wrote:
| A settings view that is largely shared between macOS System
| Preferences, iOS Settings and icloud.com is not single-
| platform. Windows Settings uses React Native for the same
| reason.[1]
|
| [1] https://news.ycombinator.com/item?id=30384494
|
| Edit: mention iOS Settings.
| boogies wrote:
| > between macOS System Preferences, 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?)
| gbear605 wrote:
| You can already use SwiftUI to build apps that work on both
| macOS and iOS, so the libraries are there, Apple just needs
| to use.
| oefrha wrote:
| AppKit and UIKit are very different. SwiftUI and Catalyst
| are the unification efforts, but uptake is gradual. Anyway,
| once you throw icloud.com into the mix it doesn't matter.
| avianlyric wrote:
| It has the advantage of allowing the iCloud team to update the
| preferences panel without the need to release macOS updates.
| Allowing them to decouple iCloud updates from the macOS release
| cycle.
|
| 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.
| tksb wrote:
| Still, they could've probably made some strides with React
| Native on macOS and the win-win that entails. UX improves in
| these instances + arguably RN benefits from the Apple buy-in.
| Karen48 wrote:
| reggaemahn wrote:
| This is something Apple has done for years. Especially with the
| native iTunes UI. They used to use Sproutcore pretty heavily for
| stuff like this, which later became Ember.js
| emkoemko wrote:
| why does this matter? on GNOME i can pull up the javascript
| development console for the whole desktop this is nothing new.
| nguyenkien wrote:
| Gnome use javascript with native UI. Apple simply use webview.
| emkoemko wrote:
| ohh wow that seems inefficient to use a browser
| userbinator wrote:
| This might explain why, although I'm not a constant user of Mac,
| whenever I've had to use it, the UI has felt a little (and in the
| newer versions, significantly) more sluggish than Windows on the
| same hardware. It's not hard to see how someone accustomed to
| that level of responsiveness could find Electron not too
| different from a "native" app that's actually doing much the same
| thing.
| chadstur wrote:
| Certainly consider macOS using rounded corners, heavy drop
| shadowing, font smoothing, and animation.
| heavyset_go wrote:
| Try the settings app in Windows 11. It's just as sluggish and
| unresponsive. At least in a VM, it has the tendency to freeze
| and be unresponsive to input.
| userbinator wrote:
| The one in Windows 10 is already much worse than the one it
| replaced, but I don't think it uses any webviews.
| eropple wrote:
| It's like three webviews in the system preferences app.
|
| So probably not.
| userbinator wrote:
| That's exactly my point. If the true native apps are just as
| slow as the web ones, the latter don't seem any different,
| and thus, Electron apps too.
| simondotau wrote:
| The headline isn't technically wrong but it's a tiny bit
| misleading because the use of web views is limited to a small
| number of iCloud account screens. These aren't really "system"
| preferences so much as Apple cloud service settings which have
| been wedged into System Preferences.
|
| (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.)
| dang wrote:
| We've reverted the title now. Submitted title was "macOS System
| Preferences Uses React".
|
| " _Please use the original title, unless it is misleading or
| linkbait; don 't editorialize._"
|
| https://news.ycombinator.com/newsguidelines.html
| disposedtrolley wrote:
| I wasn't surprised to see the Family Sharing pane in the first
| screenshot. It's easily the most janky part of System Preferences
| that I've had to struggle with:
|
| - 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.
| jgalentine007 wrote:
| Sounds like they need useMemo(), useCallback() and an abort
| pattern, lol.
| hybridtupel wrote:
| My thoughts exactly. I never liked these iCloud system settings
| and now I know why. They are not native but janky web views.
| Same for the Mac App Store which behaves very similar.
| soheil wrote:
| Not really. There is a webview for certain account related stuff
| that gets loaded from a web page which happens to be a React app.
| Most other settings are native code and not loaded from a remote
| URL. Completely misleading post/title.
| makecheck wrote:
| Definitely every one of these is sluggish at best on a very
| modern machine but they are also full of UI annoyances. God I am
| so tired of little spinners for things that would have displayed
| instantaneously on ten-year-old hardware with previous UI
| designs.
|
| 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.
| SheinhardtWigCo wrote:
| > Here's an idea: guess at new features in macOS by using the
| work of Safari team members as a leading indicator.
|
| Shh, please... we don't want WebKit releases to look like xnu
| releases
| exikyut wrote:
| Hmmmm. I wonder which OS will support in-kernel JIT for
| JavaScript first. :v
|
| (/s ... I hope??)
| vlovich123 wrote:
| Why would it need to be in-kernel? What advantage does that
| serve?
|
| 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.
| skavi wrote:
| In kernel eliminates context switching overhead.
| Theoretically a perfect JIT doesn't need hardware security.
|
| Also, JSC has been faster on Mac than V8 until a few days
| ago.
| neximo64 wrote:
| That explains how looking at your iCloud preferences are near the
| most unreliable and slow part of settings. Even more so the Apple
| engineers never consider someone could live outside the US.
| aaronbrethorst wrote:
| I've always wondered why these panes in particular felt like
| total garbage in comparison to the rest of System Preferences.
| Now I know!
| yen223 wrote:
| Confirmation bias!
| [deleted]
| aaronbrethorst wrote:
| Tell me you've never used the iCloud preferences in macOS
| without telling me you've never used the iCloud preferences
| in macOS.
| [deleted]
| lelandfe wrote:
| And non-conformant UI, as well. It's like the HIG just doesn't
| exist anymore. Scroll up inside the Family Sharing family
| table. Does the interior of the table have an elastic scroll?
| NO! The _entire_ Family Sharing pane instead scrolls up.
|
| 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.
| dmitriid wrote:
| > It's like the HIG just doesn't exist anymore.
|
| It really doesn't, and Apple's own apps are the first to
| break all the HIGs
| firecall wrote:
| 100%.
|
| 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.
| tambourine_man wrote:
| I think at some point Apple will just have to recognize that the
| web UI has won. I say that with a heavy heart, I enjoy them as a
| developer but despise them as a user.
|
| 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.
| lenkite wrote:
| Flutter would like to talk to you.
| tambourine_man wrote:
| Elaborate please
| vlovich123 wrote:
| I don't think it has anything to do with trends. It's about $$.
| Web UIs are infinitely faster to develop, there's typically
| better tooling (larger ecosystem), and there's many developers
| which means you can get them cheap.
|
| 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.
| MrWiffles wrote:
| Fascinating. Thanks for sharing! In other news, does anyone know
| of an up to date catalog or list of all the "defaults" settings,
| possible values, and what they do? I looked for this several
| years ago and found nothing, and Apple's documentation on MacOS
| was far better back then. As in, it existed. These days ask i can
| find is incomplete objective c docs that were auto-generated and
| offer absolutely nothing of value whatsoever (to me). So if
| anyone knows of some useful docs, please share!
| InTheArena wrote:
| Quick. Hide the evidence so the ATP purists can still insist on
| ideological purity and in the one true belief that the only way
| to write Mac Applications is to do everything in Swift or
| Objective-C.
|
| After all, If Apple does it....
| olliej wrote:
| It is using webview to display some content in an app that is
| native. That's been common practice in many Mac applications
| for a decade. WebKit exposes native NSView subclasses to make
| embedding them trivial enough that for some content they are
| /better/. Heavily formatted content? Write your own layout
| engine, or just use html?
|
| 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.
| GekkePrutser wrote:
| Nothing wrong with it per se. But the developers choosing tech
| like Electron usually do it because it's low-effort cross-
| platform. With the emphasis on low-effort.
|
| 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.
| int_19h wrote:
| Note all the comments here about how that part of the UI is
| broken in so many ways.
| boogies wrote:
| Source-available variants of [GNU's Not] Unix have often been on
| the leading edge of user interfaces, from immitating the Xerox
| PARC desktop metaphor before Windows did (X11 initial release:
| June 1984, Windows: November 1985) to adding intrusive ads to the
| main system menu / search around the time Windows 8 was released.
| But it's interesting to see macOS's proprietary UI now apparently
| following GNOME's example of powering "native" interfaces with
| JavaScript.
|
| 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).
| nguyenkien wrote:
| Windows settings use react native
| pjmlp wrote:
| Sadly, at least it uses WinUI/UWP underneath.
| marcellus23 wrote:
| Apple has been doing that for ages, see e.g. the iTunes music
| store or Apple Music.
| creatonez wrote:
| > [...] following GNOME's example of powering "native"
| interfaces with JavaScript.
|
| Isn't this javascript but without web tech? That doesn't really
| stray too far from native anyways.
| badsectoracula wrote:
| Windows 98 predated both of these, i.e.
|
| > 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
|
| [0] https://i.imgur.com/9AqdbdM.gif
|
| [1] https://en.wikipedia.org/wiki/HTML_Application
| snowl wrote:
| I really hate reading HN comments involving anything with JS.
| Probably some of the lowest quality comment sections on the site.
| [deleted]
| hombre_fatal wrote:
| Yep. I click in and get ready to cringe at the weird claims.
| Today there's someone claiming that nobody enjoys using React.
| z3t4 wrote:
| Its interesting that so many apps use web views... Is the native
| GUI libs really that bad?
| dmitriid wrote:
| > Is the native GUI libs really that bad
|
| 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...
| naoqj wrote:
| No wonder everything gets slower and slower every year. These
| people are shameless.
___________________________________________________________________
(page generated 2022-03-12 23:01 UTC)