„Native“ - uhm no? It just wraps the platform‘s web engine (WebKit or Edge), it’s still resource wasting non native HTML/CSS/JS.
Definitely not as good as full native, but a definite step up compared to Electron.
On the first place in the list, by the way, is safe browsing experience. Rendering is only the second. And that one is the reason why browsers create separate processes for each window/tab. And that one is quite against low memory usage and longer battery life.
Browser are designed for the case when user interacts with them "full screen" - as the main application on desktop and so design decision are focused on that. Browser can afford multithreading/multi-processes but far not all applications can afford loading all CPU and GPU cores for rendering "Hello world".
That's why people who use VSCode prefer more lightweight solutions for "config file editing" scenarios.
It’s not a browser. It’s a webbview-driven GUI library. The platform webview is in charge of rendering the UI thread; or more, if the programmer desires. No idea where “safe browsing experience” factors in here.
I get exactly what you mean though but I find this logic difficult to understand. ;)
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.
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.
Probably a UX researcher.
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.
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.
accessibility, integration with the user's workflow, accessibility, consistent theming, accessibility, interface coherency, accessibility...
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.
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.
* 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
When you say "native" apps in this context, it 100% refers to non-webview based apps.
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.
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.
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" ...
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.
Don't get me wrong, I am very well acquainted with the tragedies of JS - and the propensity of amateurs to just "do it all" in a single-threaded webrenderer. In fact, I think that this is why most of the first and second generation "web-apps" built on cordova and electron were such poor performers.
But nevertheless, what we are trying to do with Tauri is to open up the boundaries between development communities and leverage the particular strengths of each of them. So if you don't feel Tauri is "native" enough, then maybe you are missing the point.
There's a weird impedance mismatch in the UIs of any non native apps that comes simply from recreating the UI elements and not using the system provided ones. This isn't an aspect of trying to 'feel superior' to JS devs, but a reflection of the real trade-offs of the technique. And I say this as the lead from a traditionally systems oriented team that's about to ship our first electron app. We took a look at the costs, and decided that in this particular case the tradeoffs were worth it, but it's not an easy decision.
And one thing I'll say is that a piece of what makes electron attractive at the organizational level is the fact that it doesn't use the system libraries. That greatly reduces QA burden by not having a spread of different versions of underlying infra to deal with. As an enduser I'd love if all the chrome/blink based apps on my machine (let's see, chrome, spotify, vscode, slack are all running) shared resources, but if they had to test against different versions of runtime or each version of their code they released, they probably wouldn't be using this model in the first place.
https://i.imgur.com/GVlm9c2.png
Font size is wrong. Colours are wrong and 250% too many. Hover/active state is wrong. Hyperlinks are unmarked. Context menu in editing widgets missing. Menu bar and status bar missing. Accelerator keys missing.
I agree this is getting more muddy on mobile as, say, "native Android" almost always now means bytecode using the platform SDKs.