5 ms·

It's good to see a bit of a variety – we all know that monoculture ends up being a bad thing, and there are obvious downsides to applications hosted by third pa

It's good to see a bit of a variety – we all know that monoculture ends up being a bad thing, and there are obvious downsides to applications hosted by third parties (though of course in some cases it's not a problem!). Of course, there's no real network effect with applications like this either (beyond integrations support) so there's a relatively low bar to switching when compared to something like Facebook. I do hope to see some work on better user interfaces. Our team recently switched to Slack from Hipchat - many features are better, but the desktop UI is really unpleasantly sluggish. It seems unreasonable for a chat application to stutter and freeze on even small amounts of data. The trend for wrapping web UIs in desktop apps is not a good one, in my experience. Hopefully open equivalents will encourage the development of native clients.

wlesieutre 11y ago
Mattermost claims to have "Native Applications". (http://www.mattermost.org/community-applications/#native http://www.mattermost.org/community-applications/#native) Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application." Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.
- benologist 11y ago
  What's wrong with that? VSCode is also such a thing, high performance and beautiful apps are obviously possible.
  - wlesieutre 11y ago
    That's true, but when you roll a "one size fits all" HTML app across all platforms, it's much much less likely to follow operating system conventions and very easy to get layout details wrong. For example, Hipchat's settings overlay (https://i.imgur.com/V3UOyMI.png https://i.imgur.com/V3UOyMI.png) which should: • Be a separate window • Be sized properly for its contents instead of having to scroll • Use tabs along the top for the settings categories • Not have clipped left edges on all of the checkboxes • Put the close button in the top left corner of the window like the rest of the OS Compare to settings in Textual, which is an actual native application: https://i.imgur.com/5GFURBk.png https://i.imgur.com/5GFURBk.png Beyond the design aspects, there's also the issue of performance (the OS's UI layout system is well optimized for doing UI layout) and battery impact. The average "Energy Impact" of Hipchat as measured by Activity Monitor is 24x as high as Textual's. Twenty four! That puts it in 3rd place, beaten only by Google Chrome and Spotify (which IIRC is a similar "wrapped our webapp in CEF or electron). Hipchat does a bit more than Textual (inline image display), but not enough to justify its abuse of my battery life.
    - oblio 11y ago
      Aren't most of those application bugs? For example, I don't see why the check boxes should be clipped in any web application, since in their default configuration (no CSS), they aren't. So the Hipchat CSS borked the default widget.
      - wlesieutre 11y ago
        Yes, the check boxes are a bug in HipChat. That's part of my point: I have literally never seen a native OS X application that couldn't lay out checkboxes properly. Working in html/electron opens you up to making these UI bugs a lot more easily than native development.
        oblio 11y ago
        That's the risk of customizing the UI in any cross platform toolkit. I'd rather have slightly wonky cross platform apps than native apps for a very limited subset of platforms.
        kccqzy 11y ago
        I think transmission did the right thing: a single core shared across all platforms, tailored UI for different platforms. And yes, the existence of a web app makes it available absolutely everywhere, and the existence of fully native UIs make it a joy to use. EDIT: spelling
        deleted 11y ago
        [deleted]
        deleted 11y ago
        [deleted]
    - yeahrightfam 11y ago
      There are no good/bad languages/tools, there are only good/bad developers.
  - kitsunesoba 11y ago
    Apps built with front end web tech are nearly always heavier than their fully native counterparts, for one. It's nothing for an electron-based app to gobble up 150MB, 250MB, and higher amounts of memory while doing (in terms of resources actually required for the given task) nothing. A great comparison is Sublime Text, which takes up ~35MB of memory at cold start, even with a few plugins enabled. Compare this to VS Code or Atom, which take around 200MB right out of the box. That's downright comical, and I can't accept the "but resources are cheap" excuse. That mentality has been robbing users of the lightning-fast, ultra-silky experiences that are possible even on decade-old hardware for years now and it needs to stop. Aside from that, non-native applications inevitably introduce accessibility issues and UX incongruencies with the rest of the system that are difficult if not impossible to resolve entirely. There's a huge trade off made when using web tech for desktop applications and developers would do well to deeply consider their choice of technologies before acting.
    - deleted 11y ago
      [deleted]
    - msbarnett 11y ago
      It's not just RAM, either. If you measure "energy usage" however your OS allows you to (powertop or OS X's Activity Monitor, etc), Electron-based apps are absolute battery killers. You'll lose literally hours of battery life simply by running Atom instead of Sublime. It's absurd how little regard Electron devs are showing for end-user resources.
- cristianpascu 11y ago
  Being build in HTML and being a webapp are very different things. I don't think rendering HTML is significantly worse than rendering some "native" UI kit. If it's not loading pages from the internet, which I'm sure Slack doesn't, than the experience should be pretty much the same.
  - alextgordon 11y ago
    On OS X, Adium, Textual and Colloquy are predominantly built in HTML. It's hardly groundbreaking.
    - wlesieutre 11y ago
      This is a good point. I'm not opposed to using HTML in an app. Back in the early 00's, I did a decent bit of tweaking my Adium conversation display style. It's useful for displaying that kind of content easily. But there's a difference between saying "I put a webview in my app" and "I put my whole app in a webview". Driving the whole thing from HTML/JS tends to have bad implications for: • Performance (laggy animation, excessive CPU use, more drain on battery) • Window management (everything in one box! Modal overlays! Window management is overrated, nobody uses Exposé or multiple windows of one app anyway) • and UI consistency (some popup menus look one way, right click and every other popup menu on the computer looks another way) Adium, Textual, and Colloquy use HTML to display things, but they don't try and shove the whole damn app in it.
      - hobarrera 11y ago
        UI concistency is horrible with these html-in-a-webview app. Every app has to re-invent the wheel here, and there's a lot of native controls that don't exist on HTML. Generally though, window management is unimportant because these apps tend to be single-windowed apps anyway.
        wlesieutre 11y ago
        They're only single-windowed apps because they choose to be. Colloquy and Adium both let you pull channels/servers out into multiple windows (just like tabs in a browser). Slack actually does use multiple windows. The sign-in flow (enter organization, enter email address, choose between magic-email or password authentication, enter password) happens in a popup. What it can't do is pull organizations out into separate windows like Adium or Colloquy. I'm in 3 separate groups on Slack, and sometimes in a conversation in more than one of them simultaneously. And yeah, I can go open up the second one in my web browser, but it kind of defeats the point of having a "native app" if it's going to be crappier than just going to the website.
- r0muald 11y ago
  I think Mattermost has also Android and iOS native apps. The Slack native app for desktop was horrible last year, but right now it's acceptable, apart from annoying notifications polluting the application switcher.
  - ex3ndr 11y ago
    Mattermost's applications are js-based. Brilliant marketing.
- findjashua 11y ago
  Visual Studio Code: 1. is a much more complex application 2. has no perceptible performance issues 3. is also built on Electron
  - betenoire 11y ago
    "and [the] app is a webpage inside of electron" That seems to be the main gripe. Is that true for VSC too (I've never used it)?
    - skrebbel 11y ago
      yes. if you're curious, download it and open devtools, it's in one of the menus. you get the usual Chrome devtools and you can edit the entire editor.
      - wlesieutre 11y ago
        I give VS Code a pass on some of my UI gripes, since it's a text editor and I don't expect it to have much UI beyond a box that the text goes it. The "settings is a text file" setup works fine here. See my reply to benologist for some reasons that I don't love the HipChat app compared to native group chat alternatives.
- pyre 11y ago
  > I use both Slack and Hipchat I've had a lack of issues with Slack, but HipChat seemed to have updates every other day and crash a lot when I used it.

wlesieutre 11y ago

Mattermost claims to have "Native Applications". (http://www.mattermost.org/community-applications/#native http://www.mattermost.org/community-applications/#native) Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application." Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.

benologist 11y ago
What's wrong with that? VSCode is also such a thing, high performance and beautiful apps are obviously possible.
- wlesieutre 11y ago
  That's true, but when you roll a "one size fits all" HTML app across all platforms, it's much much less likely to follow operating system conventions and very easy to get layout details wrong. For example, Hipchat's settings overlay (https://i.imgur.com/V3UOyMI.png https://i.imgur.com/V3UOyMI.png) which should: • Be a separate window • Be sized properly for its contents instead of having to scroll • Use tabs along the top for the settings categories • Not have clipped left edges on all of the checkboxes • Put the close button in the top left corner of the window like the rest of the OS Compare to settings in Textual, which is an actual native application: https://i.imgur.com/5GFURBk.png https://i.imgur.com/5GFURBk.png Beyond the design aspects, there's also the issue of performance (the OS's UI layout system is well optimized for doing UI layout) and battery impact. The average "Energy Impact" of Hipchat as measured by Activity Monitor is 24x as high as Textual's. Twenty four! That puts it in 3rd place, beaten only by Google Chrome and Spotify (which IIRC is a similar "wrapped our webapp in CEF or electron). Hipchat does a bit more than Textual (inline image display), but not enough to justify its abuse of my battery life.
  - oblio 11y ago
    Aren't most of those application bugs? For example, I don't see why the check boxes should be clipped in any web application, since in their default configuration (no CSS), they aren't. So the Hipchat CSS borked the default widget.
    - wlesieutre 11y ago
      Yes, the check boxes are a bug in HipChat. That's part of my point: I have literally never seen a native OS X application that couldn't lay out checkboxes properly. Working in html/electron opens you up to making these UI bugs a lot more easily than native development.
      - oblio 11y ago
        That's the risk of customizing the UI in any cross platform toolkit. I'd rather have slightly wonky cross platform apps than native apps for a very limited subset of platforms.
        kccqzy 11y ago
        I think transmission did the right thing: a single core shared across all platforms, tailored UI for different platforms. And yes, the existence of a web app makes it available absolutely everywhere, and the existence of fully native UIs make it a joy to use. EDIT: spelling
      - deleted 11y ago
        [deleted]
      - deleted 11y ago
        [deleted]
  - yeahrightfam 11y ago
    There are no good/bad languages/tools, there are only good/bad developers.
- kitsunesoba 11y ago
  Apps built with front end web tech are nearly always heavier than their fully native counterparts, for one. It's nothing for an electron-based app to gobble up 150MB, 250MB, and higher amounts of memory while doing (in terms of resources actually required for the given task) nothing. A great comparison is Sublime Text, which takes up ~35MB of memory at cold start, even with a few plugins enabled. Compare this to VS Code or Atom, which take around 200MB right out of the box. That's downright comical, and I can't accept the "but resources are cheap" excuse. That mentality has been robbing users of the lightning-fast, ultra-silky experiences that are possible even on decade-old hardware for years now and it needs to stop. Aside from that, non-native applications inevitably introduce accessibility issues and UX incongruencies with the rest of the system that are difficult if not impossible to resolve entirely. There's a huge trade off made when using web tech for desktop applications and developers would do well to deeply consider their choice of technologies before acting.
  - deleted 11y ago
    [deleted]
  - msbarnett 11y ago
    It's not just RAM, either. If you measure "energy usage" however your OS allows you to (powertop or OS X's Activity Monitor, etc), Electron-based apps are absolute battery killers. You'll lose literally hours of battery life simply by running Atom instead of Sublime. It's absurd how little regard Electron devs are showing for end-user resources.
cristianpascu 11y ago
Being build in HTML and being a webapp are very different things. I don't think rendering HTML is significantly worse than rendering some "native" UI kit. If it's not loading pages from the internet, which I'm sure Slack doesn't, than the experience should be pretty much the same.
- alextgordon 11y ago
  On OS X, Adium, Textual and Colloquy are predominantly built in HTML. It's hardly groundbreaking.
  - wlesieutre 11y ago
    This is a good point. I'm not opposed to using HTML in an app. Back in the early 00's, I did a decent bit of tweaking my Adium conversation display style. It's useful for displaying that kind of content easily. But there's a difference between saying "I put a webview in my app" and "I put my whole app in a webview". Driving the whole thing from HTML/JS tends to have bad implications for: • Performance (laggy animation, excessive CPU use, more drain on battery) • Window management (everything in one box! Modal overlays! Window management is overrated, nobody uses Exposé or multiple windows of one app anyway) • and UI consistency (some popup menus look one way, right click and every other popup menu on the computer looks another way) Adium, Textual, and Colloquy use HTML to display things, but they don't try and shove the whole damn app in it.
    - hobarrera 11y ago
      UI concistency is horrible with these html-in-a-webview app. Every app has to re-invent the wheel here, and there's a lot of native controls that don't exist on HTML. Generally though, window management is unimportant because these apps tend to be single-windowed apps anyway.
      - wlesieutre 11y ago
        They're only single-windowed apps because they choose to be. Colloquy and Adium both let you pull channels/servers out into multiple windows (just like tabs in a browser). Slack actually does use multiple windows. The sign-in flow (enter organization, enter email address, choose between magic-email or password authentication, enter password) happens in a popup. What it can't do is pull organizations out into separate windows like Adium or Colloquy. I'm in 3 separate groups on Slack, and sometimes in a conversation in more than one of them simultaneously. And yeah, I can go open up the second one in my web browser, but it kind of defeats the point of having a "native app" if it's going to be crappier than just going to the website.
r0muald 11y ago
I think Mattermost has also Android and iOS native apps. The Slack native app for desktop was horrible last year, but right now it's acceptable, apart from annoying notifications polluting the application switcher.
- ex3ndr 11y ago
  Mattermost's applications are js-based. Brilliant marketing.
findjashua 11y ago
Visual Studio Code: 1. is a much more complex application 2. has no perceptible performance issues 3. is also built on Electron
- betenoire 11y ago
  "and [the] app is a webpage inside of electron" That seems to be the main gripe. Is that true for VSC too (I've never used it)?
  - skrebbel 11y ago
    yes. if you're curious, download it and open devtools, it's in one of the menus. you get the usual Chrome devtools and you can edit the entire editor.
    - wlesieutre 11y ago
      I give VS Code a pass on some of my UI gripes, since it's a text editor and I don't expect it to have much UI beyond a box that the text goes it. The "settings is a text file" setup works fine here. See my reply to benologist for some reasons that I don't love the HipChat app compared to native group chat alternatives.
pyre 11y ago
> I use both Slack and Hipchat I've had a lack of issues with Slack, but HipChat seemed to have updates every other day and crash a lot when I used it.