6 ms·

„Native“ - uhm no? It just wraps the platform‘s web engine (WebKit or Edge), it’s still resource wasting non native HTML/CSS/JS.

timw4mail 6y ago
At least compared to Electron it uses the most efficient browser engine per platform. Definitely not as good as full native, but a definite step up compared to Electron.
- qppo 6y ago
  Most efficient in terms of what, disk space?
  - abeltensor 6y ago
    Disk space and Memory.
    - gcb0 6y ago
      because Google (and apple) is using the exact same tricky they sued Microsoft for in the 90s: including the browser with the OS.
  - timw4mail 6y ago
    Disk space, memory usage, and often battery life.
    - c-smile 6y ago
      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.
      - noobquestion81 6y ago
        Woosh 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.
gridlockd 6y ago
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.
- distances 6y ago
  For me "native" on desktop still means compiled to target architecture without any runtime VM/interpretation. I agree this is getting more muddy on mobile as, say, "native Android" almost always now means bytecode using the platform SDKs.
_pdp_ 6y ago
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. ;)
- K0nserv 6y ago
  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.
  - _pdp_ 6y ago
    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.
    - vertex-four 6y ago
      > And who is best to decide what is best for the application but the developer who created it? Probably a UX researcher.
    - K0nserv 6y ago
nim2020 6y ago
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.
- monocasa 6y ago
  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.
- bmn__ 6y ago
  It's not native because it does not even make the slightest attempt to adapt to the DE! What a waste of potential. I invite the HN readers to compare: https://i.imgur.com/GVlm9c2.png 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.

timw4mail 6y ago

At least compared to Electron it uses the most efficient browser engine per platform. Definitely not as good as full native, but a definite step up compared to Electron.

qppo 6y ago
Most efficient in terms of what, disk space?
- abeltensor 6y ago
  Disk space and Memory.
  - gcb0 6y ago
    because Google (and apple) is using the exact same tricky they sued Microsoft for in the 90s: including the browser with the OS.
- timw4mail 6y ago
  Disk space, memory usage, and often battery life.
  - c-smile 6y ago
    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.
    - noobquestion81 6y ago
      Woosh 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.

gridlockd 6y ago

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.

distances 6y ago
For me "native" on desktop still means compiled to target architecture without any runtime VM/interpretation. I agree this is getting more muddy on mobile as, say, "native Android" almost always now means bytecode using the platform SDKs.

_pdp_ 6y ago

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

K0nserv 6y ago
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.
- _pdp_ 6y ago
  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.
  - vertex-four 6y ago
    > And who is best to decide what is best for the application but the developer who created it? Probably a UX researcher.
  - K0nserv 6y ago

nim2020 6y ago

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.

monocasa 6y ago
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.
bmn__ 6y ago
It's not native because it does not even make the slightest attempt to adapt to the DE! What a waste of potential. I invite the HN readers to compare: https://i.imgur.com/GVlm9c2.png 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.