Yes but the counter argument here is that games are all extremely custom anyway and it makes sense for them to render their UI completely from scratch in a blank canvas.

For typical applications the blank canvas/from scratch approach does not result in the best outcome. Each platform has HIGs, native UI toolkits etc and those are what should be used, I assume that's what the parent is getting at.

Something like this is what we need:

https://github.com/andlabs/libui

Unfortunately it's a one man band. The author has done great work but it has little support. IMHO it's the only sane UI effort for desktop in the world.

There's a few native widget abstraction libraries.

* Libui is newer, and uses C

* wxWidgets is relatively ancient, and is written in C++

* Qt is sort of in the same ballpark, but relies on platform themes rather than native widgets

And who is best to decide what is best for the application but the developer who created it? If I want to create an app that looks like a game and just happen not to run fullscreen why should we even discuss conformity with native UIs as a feature? The user have the right not to bother installing the software if they don't like it.

The whole argument is just silly. Are shell scripts native? And if my compiled binary prints a control character in the terminal screen that is not supported by the terminal you use, does that mean that the binary is not native because it does not conform with the expected behaviour?

I know that I am not convincing anyone with this comment but it is fascinating to see people having such a constrained view on software. Software is what you make out of it and sometimes its weird looks and behaviour is what makes it special. There are many such examples.

Let's drop this "not native" argument and simply talk about not having the same performance because JavaScript is interpreted.

Javascript being interpreted is not a big deal for most UI (it's not like your code has to be in JS, it just needs to interop with it for the UI) and JS has been optimized more than most languages (eg it'll run circles around "desktop" languages like Python that don't ffi to C libraries).

The problem is the non-nativeness of it more than anything else. It's also what brings the bloat and the slowdowns because everything is reimplemented from scratch.

Of course everyone is free to build apps in whichever way they want, others are free to take issue with it.

My argument here is that these "blank canvas" cross platform UI toolkits are trading an improved developer experience for hard to spot, but very real, user experience issues. A very concrete way in which many "blank canvas" cross platform UI fails the user is accessibility especially on platforms that are renowned and used for their good accessibility like iOS. There's also memory and energy consumption concerns with solutions that abstract over native tooling at the cost of increased memory and energy use, you could argue this is unethical or at least needlessly limits your addressable market by locking out segments of world.

Not all users are in charge of the apps they have to use either so the argument that they can chose to not install an app doesn't hold water.

The iOS SDKs provide a number of features that increase developer productivity, many of which are related accessibility because this is what iOS SDKs are all about. It is not like the iOS OS automatically does all of the work for you, it is the libraries and how you use them! Without the libraries, you have to implement these features yourself.

Equally, the web platform increases developer productivity by providing an easy to use cross-platform UI libraries you can use whichever way you like. The leverage is different - it is still leverage no different than the iOS SDKs. Without these libraries, you have to write it all by yourself.

We are looking at the same thing from two different angles, hence why I find the argument silly. Everything is native if not emulated. We can argue about performance or the conformity with style guides and UX best practices but to brush off the web as irrelevant software development platform is crazy given that you can attribute a lot of the progress we made over the recent history due to the progress and standardization of web technologies. There is still a lot to do but, guess what, to create an open cross-platform programming environment with such a large adoption is a pretty difficult task.

From a UX perspective, there is frankly no particular reason for all apps to look and behave the same. Your browser is open 100% of the time, it occupies 30-50% of the screen estate, yet 99% of the UX is custom and significant changes from one web page to another. I don't think that bothers anyone.

> There's also memory and energy consumption concerns with solutions that abstract over native tooling

I agree that the web can be made greener but you can write an equally sloppy app with Swift and Objective-C. But here is the question for which I have no answer. Is it ethical to write the same software in 3 different ways due to platform differences and does that contribute to a larger carbon footprint than one app that is written sloppily with web technologies? Maybe we will never know but it is an interesting question don't you think?

> Not all users are in charge of the apps they have to use either so the argument that they can chose to not install an app doesn't hold water.

And luckily no one is in charge of what software people should write and how they should write it.

> And who is best to decide what is best for the application but the developer who created it?

Probably a UX researcher.

> why should we even discuss conformity with native UIs as a feature?

accessibility, integration with the user's workflow, accessibility, consistent theming, accessibility, interface coherency, accessibility...

By your logic, all apps that run on a computer are "native apps", because they are somehow using the native features of the computer to render the webview.

When you say "native" apps in this context, it 100% refers to non-webview based apps.

Are Norton Antivirus, Avast, BitDefender and others are native applications in your classification?

For the note they use HTML/CSS for defining/rendering their UI (Sciter).

Are Windows 10 UWP applications native? They use XAML and JS...

And so on.

They are just "apps". I think you miss my point.

My point is that when an app developer adds the "native" qualifier to describe their product, it means they are trying to emphasize that aspect.

> Are Norton Antivirus, Avast, BitDefender and other are native applications in your classification?

None of these companies call their apps "native apps". They are just apps, and they are not lying. But unnecessarily adding the "native" qualifier when it is not "native" is false advertising, and that's what i'm pointing out.

Companies like Slack don't falsely advertise their apps as "Native apps". They instead own it 100%. If Slack called themselves "native app", a lot of people on HN will probably throw stones at them for lyiing.

Is standard editor of Gnome desktops (gedit or xed) "native" one? And pretty much all Gnome apps for that matter?

They use XML and CSS for UI definitions...

I mean it is hard (if at all possible) to draw clear "native"/"non-native" divider these days.

It seems that "non-native app" is just a synonym for "app that uses browser based UI" ...

You're still using analogies to make a point? You still don't get my point.

Let me try one last time. When you call yourself a "toolchain for building native apps", what people are expecting is not another Electron like scheme. If electron called itself "a toolchain for building native apps", people will say it's false advertising.

Yes. Game engines structured like that don't have native UIs.