It depends.

You could still use a web UI but without embedding Chrome and Node.

That sounds like writing and maintaining your own (cross-platform) version of Electron. And then not ending up with a native app for your troubles.

Not really. Just a shallow native layer that uses the platform as much as possible.

Except for the UI of course.

'Just'. Which platform? What are you going to render HTML with? And know it produces identical output, etc?

For example Webkit on Mac and iOS. Blink in Android and Chrome OS.

You'd need node for file system access though. Unless you write your own io layer

Indeed. That would be written in the native layer.

Twice the work for front-end only, and even that is arguable. The overall logic of the client across different platforms will be very similar. The only thing that will change is language and implementation details.

Different environment, different conventions, different bugs, different design, different support, different everything. Different teams that have to communicate. It is 'arguable' that it's twice the work, that is true. Twice is the lower bound.

There are options that let you write the bulk of your code in one language then code platform specific user-interfaces against that library. This is basically the Xamarin philosophy for iOS/Android development, and Xamarin apps generally offer a much better user experience than these web-app wrappers cluttering the App Store.

We were talking about desktop apps in this case. It's slightly different on mobile but the parameters are similar. The range of options here involve fiddling with dials that affect cost and quality. The comment I'm replying to amounts to 'why not pretend these dials don't exist?'. The answer is, because they're really there, you can't effectively plan development like that.

Yes. It's typical for a team to have different people handle different platform and spreading task on multiple people suddenly slows down the progress than letting 1 set of people handle the front end.