For the browser neither disk space nor memory usage are in top 10 of list of priorities.
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.
Please don't take it the wrong way but using the same logic gaming engine are not native either because they have a scripting component to draw all the widgets on the screen.
I get exactly what you mean though but I find this logic difficult to understand. ;)
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.
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.
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.
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.
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.
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.
I find it interesting that many people hold so tightly onto the "it is not native unless it is written entirely in %my_favorite_language%". I think a little controversy is good, but what the heck does native mean anymore? Wasn't it really invented as a kind of "shaming" because front-end developers were never considered "real programmers" and when hybrid apps came out some folks felt the need to line their pockets with this differentiation?
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.
In this context, it means that it uses the UI toolkit provided by the OS/display env to do it's UI rather than opening a custom rendered surface and doing it all manually in your app (as a browser engine does). That includes using the browser engine on the system.
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.
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.
What exactly makes a GUI "native", in your view? WebKit and MSHTML/Edge, they all render to the screen with native APIs. They're part of the operating system. Lots of native applications have used these for decades.
