4 ms·

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.

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.