Interestingly, the screenshot doesn't show , but [sic].
Oooh you’re right. I didn’t notice that. I wonder…
Inspecting Web Views in macOS
141–147 of 147 posts
Re: Inspecting Web Views in macOS
#142Earlier quoted context omitted.
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.
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.
What context switching overhead is eliminated? This makes no sense.
Re: Inspecting Web Views in macOS
#143Earlier quoted context omitted.
Flutter would like to talk to you.
Elaborate please
Flutter is the most popular cross-platform mobile SDK (already handily beat react native) and its not web-tech. It's now posing a very stiff challenge to native platform-specific UI frameworks. Many folks who wrote used web-views to developer apps are moving to flutter.
https://stackoverflow.blog/2022/02/21/why-flutter-is-the-mos...
Once the desktop Flutter story kicks off, say good-bye to Electron.
Re: Inspecting Web Views in macOS
#144Earlier quoted context omitted.
>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 .
No. That's wrong. The fact that there are poor quality catalyst apps is neither here nor there. The tooling, languages and large parts of the frameworks are common or so similar that it doesn't matter. You can go straight from writing an iOS app to writing a Mac app without much friction at all. I know because I did it.
Re: Inspecting Web Views in macOS
#145Earlier 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)
that makes sense considering khtml, from which webkit evolved, was designed as a web view for the kde desktop environment.
Re: Inspecting Web Views in macOS
#146Earlier quoted context omitted.
What does rust have to do with this?
Its the first language that lends itself to be used both on the desktop fornative GUIs as well as in the browser.
What? My understanding is that there isn't a native GUI toolkit written in rust for any platform at all. At least, not one that isn't a toy project.
Re: Inspecting Web Views in macOS
#147Awesome! Do you know more Web Views in use?
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.
This macOS dictionary app (Dictionary.app) also uses webviews. This will come as no surprise since it does things like in-line Wikipedia results.