5 ms·

Explanation for why this is occurring: Slack's desktop apps are HTML5 webapps wrapped inside native desktop wrappers. Specifically, Slack uses Github's Electro

Explanation for why this is occurring: Slack's desktop apps are HTML5 webapps wrapped inside native desktop wrappers. Specifically, Slack uses Github's Electron (formerly, Atom Shell) which is basically Chromium. The desktop app is a webpage inside Chromium.

JoeAltmaier 11y ago
Yeah, I strenuously object to the fad of calling wrapped web pages 'native apps'. They get zero benefits that would normally accrue to real native apps. They just launch 'as if' they were native.
- szhu 11y ago
  "They just launch 'as if' they were native." That's a pretty big benefit to most end-users.
  - moron4hire 11y ago
    I don't know why you're getting downvoted. I've seen studies that say 80% of users prefer apps over the mobile web. I know I've certainly seen an almost hostile attitude towards web app offerings over native app versions. And it all seems to boil down to one thing. You can get good-enough access to just about everything on the phone through an HTML5 app--certainly enough for a large proportion of apps--except for "installs through the app store".
    - michaelmior 11y ago
      For Slack I believe the discussion was desktop app vs web app, not mobile web app vs native mobile app.
    - toyg 11y ago
      > I don't know why you're getting downvoted. "A is not B" "but A has C properties" Native apps are not defined in terms of having benefits; they have specific technical characteristics that embedded webpages just don't have. So the fact that embedded webpages may or may not have benefits is irrelevant to the statement that they are just not native apps. I guess that's where downvoters are coming from.
  - Retra 11y ago
    That could be the greatest thing in the world, but it doesn't make it a native app.
- yathern 11y ago
  Well, the benefits of Electron or NW.js compared to a Web App are things like filesystem access - as well as the entire Node JS ecosystem, which has many modules, some capable of performing native operations in a variety of different platforms.
- escherize 11y ago
  What do you mean by 'as if'? Try hitting Cmd + , to change change some of your HN settings, or alt-tabbing to your HN tab (the one in your browser).
- gue5t 11y ago
  Thank you. People calling web-render wrappers "native applications" must not realize how great it is when applications are mere coördinators on top of an integrated platform full of services designed to improve user productivity. I guess if that demographic did, there would be less "unix philosophy" cultism, as the efficacy of the unix shell is merely on par with that provided by other relatively coherent software toolsets. The shell is really pretty barebones compared to the rich semantics provided by many toolkits and object systems on which user interfaces have been built: GObject and NeXT are two modern examples. [That said, where shell shines is by providing so few abstractions that virtually any garbage has the same semantic depth as things which were designed to be used in the shell. Bytes are universal on the common computing substrate.] The web, on the other hand, is a platform "designed" by the erosive flow of eyeballs during the 1st-nth browser wars, without much of a direction beyond tacking on additional pretty features without breaking backwards compatibility too much. Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns. Look at how screen readers break on js-heavy and dynamic web pages, the ongoing security disasters of XSS and iframes (and the complexity of login services like Facebook's/oauth/openid), the disappearance of Google reader, and the half-assed way CDNs offer partial, ad-hoc offloading of some resources via surrender to centralization.
  - TazeTSchnitzel 11y ago
    > Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns. ...what? The web is better than most native platforms in these. The web is accessible. It has many features for screen readers and such, but more importantly, it is inherently flexible and allows content's form to be adapted to the reader's needs, thanks to the separation of content from style. A single web page, unmodified, can work on a desktop PC with a mouse and keyboard, a capacitive touch device the size of your palm, a stylus-input device the size of a laptop, a printed page, a screen reader, a ten key mobile phone from yesteryear, and more. The web lets users define custom styling that meets their needs, lets users selectively remove content (ads, for example), etc. No native platform is that flexible. Yes, some sites break screen readers, but this is true of native apps as well. The web is incredibly embeddable. Any web page can, with one line of code, incorporate any other web page, and it "just works". You simply can't do that with native apps. The web is composable as well. Sites can load JavaScript from each other very easily. The web also supports resource sharing in various forms, but people don't necessarily use them.
- sudo_bang_bang 11y ago
  I think this should be the future of native apps. You do get all of the benefits of native apps -- there are plenty of modules to handle key bindings, notifications, file system IO, etc. By using web page rendering you also get the incredible ecosystem of front-end tooling and plugins (React, Bootstrap, the infinite jQuery plugin world). All of this beats Qt in my opinion, having designed both.
  - millstone 11y ago
    You certainly do not get all the benefits. In particular you miss out on the shared "UI vocabulary" that comes from building on a common toolkit. This vocabulary means that users already know how to use your app, because you follow the platform conventions. Build on web technologies, and you are left either ignoring the conventions entirely and producing something very alien, or trying to recreate them from scratch and falling into the uncanny valley. For example, look at Atom. I can type Command-Z on my keyboard to Undo, but it's non-native-feeling in lots of ways: 1. The menu bar doesn't highlight to register that I typed a key equivalent 2. The Undo text doesn't change to e.g. "Undo Typing," telling me what I will Undo 3. The menu item doesn't properly disable when there is nothing to Undo 4. The menu item doesn't respect my settings in Keyboard preferences etc. etc. And that's just one feature - but it's every feature. Needless to say, that stuff comes for free or with very low friction natively. Qt is a bad representative of the native experience, because Qt is non-native everywhere except on Linux, which doesn't have strong UI conventions to begin with. Qt apps definitely feel alien on the Mac.
- EC1 11y ago
  Don't think I've ever heard or read anyone claim this, just that they live in a native wrapper.
userbinator 11y ago
I wonder how many other apps will also have this bug due to being a webapp inside Chromium, and thus require updating when it's fixed. It's not Heartbleed-like criticality, but still seems rather unpleasant, not to mention the waste of keeping multiple copies of Chromium around (I'd guess the typical webapp is much smaller than the browser itself.)
eridius 11y ago
It's Chromium? Then why do the Slack folks keep saying the preferences UI bug is a Webkit bug? It can't be a Webkit bug if they're using Chromium.
- wonkaWonka 11y ago
  Depends on the platform. For Apple devices and workstations it's a wrapped Safari web view, which is not affected by the bug, and does not crash.

JoeAltmaier 11y ago

Yeah, I strenuously object to the fad of calling wrapped web pages 'native apps'. They get zero benefits that would normally accrue to real native apps. They just launch 'as if' they were native.

szhu 11y ago
"They just launch 'as if' they were native." That's a pretty big benefit to most end-users.
- moron4hire 11y ago
  I don't know why you're getting downvoted. I've seen studies that say 80% of users prefer apps over the mobile web. I know I've certainly seen an almost hostile attitude towards web app offerings over native app versions. And it all seems to boil down to one thing. You can get good-enough access to just about everything on the phone through an HTML5 app--certainly enough for a large proportion of apps--except for "installs through the app store".
  - michaelmior 11y ago
    For Slack I believe the discussion was desktop app vs web app, not mobile web app vs native mobile app.
  - toyg 11y ago
    > I don't know why you're getting downvoted. "A is not B" "but A has C properties" Native apps are not defined in terms of having benefits; they have specific technical characteristics that embedded webpages just don't have. So the fact that embedded webpages may or may not have benefits is irrelevant to the statement that they are just not native apps. I guess that's where downvoters are coming from.
- Retra 11y ago
  That could be the greatest thing in the world, but it doesn't make it a native app.
yathern 11y ago
Well, the benefits of Electron or NW.js compared to a Web App are things like filesystem access - as well as the entire Node JS ecosystem, which has many modules, some capable of performing native operations in a variety of different platforms.
escherize 11y ago
What do you mean by 'as if'? Try hitting Cmd + , to change change some of your HN settings, or alt-tabbing to your HN tab (the one in your browser).
gue5t 11y ago
Thank you. People calling web-render wrappers "native applications" must not realize how great it is when applications are mere coördinators on top of an integrated platform full of services designed to improve user productivity. I guess if that demographic did, there would be less "unix philosophy" cultism, as the efficacy of the unix shell is merely on par with that provided by other relatively coherent software toolsets. The shell is really pretty barebones compared to the rich semantics provided by many toolkits and object systems on which user interfaces have been built: GObject and NeXT are two modern examples. [That said, where shell shines is by providing so few abstractions that virtually any garbage has the same semantic depth as things which were designed to be used in the shell. Bytes are universal on the common computing substrate.] The web, on the other hand, is a platform "designed" by the erosive flow of eyeballs during the 1st-nth browser wars, without much of a direction beyond tacking on additional pretty features without breaking backwards compatibility too much. Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns. Look at how screen readers break on js-heavy and dynamic web pages, the ongoing security disasters of XSS and iframes (and the complexity of login services like Facebook's/oauth/openid), the disappearance of Google reader, and the half-assed way CDNs offer partial, ad-hoc offloading of some resources via surrender to centralization.
- TazeTSchnitzel 11y ago
  > Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns. ...what? The web is better than most native platforms in these. The web is accessible. It has many features for screen readers and such, but more importantly, it is inherently flexible and allows content's form to be adapted to the reader's needs, thanks to the separation of content from style. A single web page, unmodified, can work on a desktop PC with a mouse and keyboard, a capacitive touch device the size of your palm, a stylus-input device the size of a laptop, a printed page, a screen reader, a ten key mobile phone from yesteryear, and more. The web lets users define custom styling that meets their needs, lets users selectively remove content (ads, for example), etc. No native platform is that flexible. Yes, some sites break screen readers, but this is true of native apps as well. The web is incredibly embeddable. Any web page can, with one line of code, incorporate any other web page, and it "just works". You simply can't do that with native apps. The web is composable as well. Sites can load JavaScript from each other very easily. The web also supports resource sharing in various forms, but people don't necessarily use them.
sudo_bang_bang 11y ago
I think this should be the future of native apps. You do get all of the benefits of native apps -- there are plenty of modules to handle key bindings, notifications, file system IO, etc. By using web page rendering you also get the incredible ecosystem of front-end tooling and plugins (React, Bootstrap, the infinite jQuery plugin world). All of this beats Qt in my opinion, having designed both.
- millstone 11y ago
  You certainly do not get all the benefits. In particular you miss out on the shared "UI vocabulary" that comes from building on a common toolkit. This vocabulary means that users already know how to use your app, because you follow the platform conventions. Build on web technologies, and you are left either ignoring the conventions entirely and producing something very alien, or trying to recreate them from scratch and falling into the uncanny valley. For example, look at Atom. I can type Command-Z on my keyboard to Undo, but it's non-native-feeling in lots of ways: 1. The menu bar doesn't highlight to register that I typed a key equivalent 2. The Undo text doesn't change to e.g. "Undo Typing," telling me what I will Undo 3. The menu item doesn't properly disable when there is nothing to Undo 4. The menu item doesn't respect my settings in Keyboard preferences etc. etc. And that's just one feature - but it's every feature. Needless to say, that stuff comes for free or with very low friction natively. Qt is a bad representative of the native experience, because Qt is non-native everywhere except on Linux, which doesn't have strong UI conventions to begin with. Qt apps definitely feel alien on the Mac.
EC1 11y ago
Don't think I've ever heard or read anyone claim this, just that they live in a native wrapper.

userbinator 11y ago

I wonder how many other apps will also have this bug due to being a webapp inside Chromium, and thus require updating when it's fixed. It's not Heartbleed-like criticality, but still seems rather unpleasant, not to mention the waste of keeping multiple copies of Chromium around (I'd guess the typical webapp is much smaller than the browser itself.)

eridius 11y ago

It's Chromium? Then why do the Slack folks keep saying the preferences UI bug is a Webkit bug? It can't be a Webkit bug if they're using Chromium.

wonkaWonka 11y ago
Depends on the platform. For Apple devices and workstations it's a wrapped Safari web view, which is not affected by the bug, and does not crash.