6 ms·

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.

Snetry 7y ago
Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution And just because it's electron doesn't mean it's inherently Cross-Platform look at discord for example It took too long for a initial desktop client to be released and then it ha issues with things like screen sharing not working as expected
- tjpnz 7y ago
  >Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution They could but finding engineers with that kind of experience would be harder and cost a lot more. Far easier to retrain web frontend engineers.
  - mileycyrusXOXO 7y ago
    It isn't like Qt is some bizarre arcane wizardry. You give a web developer a few days and they can productively be contributing to a Qt app.
    - sdegutis 7y ago
      Yeah but then the dev has to investigate how to solve certain patterns in Qt's ways which they already know how to solve in the web frameworks, and just like with natural languages, sometimes there are no straightforward ports for concepts, and it requires a ton of extra work that you couldn't foresee until getting halfway through the whole project. Adopting new tech is not without serious costs and risks. Also, no GUI framework I've ever seen has figured out a decent composability solution nearly as well done as the DOM, for better or worse. Not to mention the gigantic web ecosystem that just works in Electron.
      - xg15 7y ago
        Sorry, but if the way forward really is that every desktop application of the future has to ship with a full copy of Chrome, come with all the bloat and baggage of the web platform and continue its questionable UI conventions - all just because companies are too cheap to offer some training - then I really don't see how that is a desirable future.
      - ldh 7y ago
        Electron is bad enough from a user perspective, but it's downright horrible to see how it's instilled a rather defeatist approach in front-end developers. "But I already know Javascript, it's too hard to figure out something else"
xg15 7y ago
> But we are finally seeing emergence of desktop applications from major players for Linux because of electron. In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration. If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?
- therealdrag0 7y ago
  I like the conceptual separation. I like alt-tabbing to "Slack" not "Chrome". It also doesn't have any of the header bar so the electron app has more UX control, including access to OS level window menu options. Also it can do things that you can't do inside the browser. E.g., I've seen electron apps that come with other background processes. I also think it performs better in terms of versioning/caching resources. So an electron app could be just a web-site, but they often are much more.
  - neop1x 7y ago
    That's true but some of that could already be implemented in browsers itself. E.g. web page could request to be in a separate window with different icon and ask for OS-wide api permissions. Now we have to run several fully-featured browser (Elecron) instances, not sharing system libraries, under different versions. This reminds me "write once, run everywhere" Java with bundled binary JREs because of incompatibilities between vendors... But there is some progress - for example IBKR TWS client can't play sounds as it was linked with an old libavformat.so which I no longer have in the system. Browsers have most of libs statically linked.
- CivBase 7y ago
  Web pages are constrained by the functionality made available to them by the browser - which is (purposely) very limited. Electron apps run on a native JavaScript interpreter (NodeJS) and have full access to the OS. As far as UI inconsitencies go, most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS. Many developers simply can't afford to support multiple UIs just because they subjectively look a bit better.
core-questions 7y ago
Most likely, the real solution here is to make a very highly performance tuned Electron for Wayland, and make it possible for multiple Electron apps to share at least some part of the footprint of that runtime.
jcelerier 7y ago
> But we are finally seeing emergence of desktop applications from major players for Linux because of electron It's not like Maya, Steam, Chrome, Firefox, Skype, Adobe Reader, Houdini, DaVinci, Nuke, TeamViewer, Blender... haven't been working on Linux for ages (or more recently Bitwig, Reaper...). And conversely it's not like every Electron app has a linux build.

Snetry 7y ago

Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution And just because it's electron doesn't mean it's inherently Cross-Platform look at discord for example It took too long for a initial desktop client to be released and then it ha issues with things like screen sharing not working as expected

tjpnz 7y ago
>Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution They could but finding engineers with that kind of experience would be harder and cost a lot more. Far easier to retrain web frontend engineers.
- mileycyrusXOXO 7y ago
  It isn't like Qt is some bizarre arcane wizardry. You give a web developer a few days and they can productively be contributing to a Qt app.
  - sdegutis 7y ago
    Yeah but then the dev has to investigate how to solve certain patterns in Qt's ways which they already know how to solve in the web frameworks, and just like with natural languages, sometimes there are no straightforward ports for concepts, and it requires a ton of extra work that you couldn't foresee until getting halfway through the whole project. Adopting new tech is not without serious costs and risks. Also, no GUI framework I've ever seen has figured out a decent composability solution nearly as well done as the DOM, for better or worse. Not to mention the gigantic web ecosystem that just works in Electron.
    - xg15 7y ago
      Sorry, but if the way forward really is that every desktop application of the future has to ship with a full copy of Chrome, come with all the bloat and baggage of the web platform and continue its questionable UI conventions - all just because companies are too cheap to offer some training - then I really don't see how that is a desirable future.
    - ldh 7y ago
      Electron is bad enough from a user perspective, but it's downright horrible to see how it's instilled a rather defeatist approach in front-end developers. "But I already know Javascript, it's too hard to figure out something else"

xg15 7y ago

> But we are finally seeing emergence of desktop applications from major players for Linux because of electron. In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration. If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?

therealdrag0 7y ago
I like the conceptual separation. I like alt-tabbing to "Slack" not "Chrome". It also doesn't have any of the header bar so the electron app has more UX control, including access to OS level window menu options. Also it can do things that you can't do inside the browser. E.g., I've seen electron apps that come with other background processes. I also think it performs better in terms of versioning/caching resources. So an electron app could be just a web-site, but they often are much more.
- neop1x 7y ago
  That's true but some of that could already be implemented in browsers itself. E.g. web page could request to be in a separate window with different icon and ask for OS-wide api permissions. Now we have to run several fully-featured browser (Elecron) instances, not sharing system libraries, under different versions. This reminds me "write once, run everywhere" Java with bundled binary JREs because of incompatibilities between vendors... But there is some progress - for example IBKR TWS client can't play sounds as it was linked with an old libavformat.so which I no longer have in the system. Browsers have most of libs statically linked.
CivBase 7y ago
Web pages are constrained by the functionality made available to them by the browser - which is (purposely) very limited. Electron apps run on a native JavaScript interpreter (NodeJS) and have full access to the OS. As far as UI inconsitencies go, most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS. Many developers simply can't afford to support multiple UIs just because they subjectively look a bit better.

core-questions 7y ago

Most likely, the real solution here is to make a very highly performance tuned Electron for Wayland, and make it possible for multiple Electron apps to share at least some part of the footprint of that runtime.

jcelerier 7y ago

> But we are finally seeing emergence of desktop applications from major players for Linux because of electron It's not like Maya, Steam, Chrome, Firefox, Skype, Adobe Reader, Houdini, DaVinci, Nuke, TeamViewer, Blender... haven't been working on Linux for ages (or more recently Bitwig, Reaper...). And conversely it's not like every Electron app has a linux build.