An embedded webview gives you more control over the browser chrome (as in UI), extensions, cookies, etc. It also gives you a shim into some filesystem/OS APIs that a regular sandboxed browser page wouldn't have. It gives you a predictable HTML/JS renderer that you control, instead of blindly hoping that your user will happen to have a compatible browser.

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.

> It also gives you a shim into some filesystem/OS APIs that a regular sandboxed browser page wouldn't have.

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.

It required webkit, almost same shit

Using the the apps I have built in this style as an example (not this library in particular though) - starting a whole browser comes with a lot of baggage you may not need - plug-ins as a small example. It’s easier to target 3 OSs than some random permutation.

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.

Because you might ship this to users and just having an app for them to click on and open is a lot more user friendly than telling people to type in some localhost URL or open browser tabs with "cryptic" urls.

Just have the application start the browser like daemons used to 20 years ago.

Nowadays they can even send the PWA manifest to hide the browser appearance.

Are we really arguing why someone might want to have a "native" app instead of a browser window? There's many reasons why someone might want to have that.

Yes we are, Web technologies belong in the browser.

I wasn't impressed with MSHTML when it came up as Active Desktop, nor I am impressed with anything that followed suit.

> Web technologies belong in the browser

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

WebOS applications don't ship a browser alongside them, they use what is already installed.

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.

This framework does this same thing:

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

https://wails.io/docs/introduction#native-elements

You missed my remark between parenthesis.

Not really sure what your point is. That these things are unimpressive? Agreed. It's just one lazy approach to a problem (multi-platform apps) that's not easy to solve. Webviews are a cheap way to get there.

The way is to use the Web as is, and native for everything else.

Yeah, if you have unlimited time and money.

Apparently plenty of business do.

May you be lucky enough to work for them.

Plenty of people are.

Mostly because with Wails/Tauri/Electron, you get file system access, native code etc.

yeah, the exe running the server (Go in the current case) has access to all that.

This way you know exactly which browser people are using and you don't have to deal with idiosyncrasies.

Because normal users expect a unified app experience and launching a local server that opens a tab in the browser is not an acceptable experience to them.

There's also limitations with that, like the inability to use the browser native file browser picker.

Why would you run visual studio code in your computer?

To use all the RAM.

That's what WebStorm is for.

Some people don't like the user experience of doing everything in the default browser. It's subjective.

How did the local url get there?

Or, to look at it from another angle, you could just click on the app and it opens?

performance.

some apps need native functionality, for example, instagram needs access to your camera.