Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inspecting Web Views in macOS

blog.jim-nielsen.com

Post reply on HN
Print view View original

101–110 of 147 posts

Re: Inspecting Web Views in macOS

#101

Post by userbinator »

heavyset_go wrote: post #75
userbinator wrote: post #12

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.

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.

The one in Windows 10 is already much worse than the one it replaced, but I don't think it uses any webviews.

Re: Inspecting Web Views in macOS

#102

Post by sitharus »

woodruffw wrote: post #65
sitharus wrote: post #53

Earlier quoted context omitted.

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.

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/

Yes, I intended to link to the 9to5mac article, but it’s too late to edit

Re: Inspecting Web Views in macOS

#103

Post by dmitriid »

ketzo wrote: post #80
heavyset_go wrote: post #67

Earlier quoted context omitted.

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.

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…

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

Re: Inspecting Web Views in macOS

#104

Post by dmitriid »

tonyedgecombe wrote: post #98
linguae wrote: post #92

Earlier quoted context omitted.

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…

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

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

Re: Inspecting Web Views in macOS

#105

Post by dmitriid »

z3t4 wrote: post #100

Its interesting that so many apps use web views... Is the native GUI libs really that bad?

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

Re: Inspecting Web Views in macOS

#106

Post by dmitriid »

lelandfe wrote: post #37
neximo64 wrote: post #26

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.

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 h…

> 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

Re: Inspecting Web Views in macOS

#107

Post by chrismorgan »

olliej wrote: post #63
__del__ wrote: post #38

Earlier quoted context omitted.

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 continued to work.

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)

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.

Re: Inspecting Web Views in macOS

#108

Post by xioxox »

easrng wrote: post #88
ketzo wrote: post #80

Earlier quoted context omitted.

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…

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 mes…

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.

Re: Inspecting Web Views in macOS

#109

Post by 0xabe »

easrng wrote: post #88
ketzo wrote: post #80

Earlier quoted context omitted.

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…

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 mes…

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

Re: Inspecting Web Views in macOS

#110

Post by olliej »

chrismorgan wrote: post #107
olliej wrote: post #63

Earlier quoted context omitted.

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)

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…

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.

Post reply on HN