Still, webview UIs are a lazy alternative to actual native apps. I don't like them either, but not every org can afford to hire native devs and write 3x-4x the UI code.
If you're just talking to a localhost server, it's got all the local access it needs. The web UI doesn't have to do anything besides control the native service running. I'd much rather be able to ship a tiny binary and use the local browser than pack around a whole browser just to access otherwise restricted/sandboxed APIs. You can just drop a URL shortcut on the desktop (or wherever) during installation.
Also, doing it this way, you can extend the Javascript to add custom callback functions - if that is something you need.
Also, it’s all in one process so there is less fiddly bits (request / response and all that)
You do bring up a good point though, and I hadn’t thought of the PWA angle. It would be an easy way to add a cli interface (just curl I guess)… I might try that next time.
Nowadays they can even send the PWA manifest to hide the browser appearance.
I wasn't impressed with MSHTML when it came up as Active Desktop, nor I am impressed with anything that followed suit.
That ship has sailed a long time ago. These days sometimes whole operating systems are based on HTML based interfaces (LGs TV OS would be one example).
Doing Web development alongside native since Web exists, hasn't made me like shipping browsers with applications (or Web views) any better during the last 20 years.
> It does not embed a browser, so it is resource efficient. Instead, it uses the native rendering engine for the platform. On Windows, this is the new Microsoft Webview2 library, built on Chromium.
There's also limitations with that, like the inability to use the browser native file browser picker.
Or, to look at it from another angle, you could just click on the app and it opens?
some apps need native functionality, for example, instagram needs access to your camera.