1. 11

  2. 18

    As a counterpoint to the author’s sweeping generalisation, I don’t think I’ve ever used an application based on Electron. I’ve certainly never used Slack, Hyper, VSCode, etc. which the author says they spend most of their time in.

    My most used programs are probably Emacs, st, Conkeror, Firefox, Pidgin, VLC, cmus, Basket, KBibTeX, …

    I know I’m certainly not “typical”, but I doubt the author is either.

    1. 2

      Thing is that many people out there are using these apps, and this creates network effects. This is especially so for any communication apps like Slack. While you might be able to avoid these apps personally, it’s becoming increasingly difficult to do for the vast majority of people out there. Another aspect to consider is that many apps simply wouldn’t exist on smaller platforms like Linux without Electron. So one very positive aspect of using the web stack is that it helps avoid platform lock in.

      1. 1

        I don’t disagree with what you’re saying in general, although I just want to make clear w.r.t. my anecodote above that I’m not actively avoiding such programs; I’ve just never encountered them, faced a problem that they would help solve, etc.

        Whilst I know it’s pithy, those particular examples do seem a little silly to me: there’s no shortage of terminals (Hyper) or text editors (VSCode). Messaging silos (Slack) are certainly a problem; although I think that’s more societal than technological at this point.

        1. 1

          I think the interesting part with stuff like VSCode is that you have a canvas right in the editor. This allows you to start doing stuff like this very easily. With proto-repl-charts, you could query your database via the REPL, get some data back, and chart it to see trends as an example.

    2. 9

      I am vaguely reminded of The Birth & Death of JavaScript.

      1. 5

        Distaste of Electron in general aside, I think the author does have a point in that you would think we can come up with a way for Electron apps to run more directly in ChromeOS. Do we really need to run basically Chrome on top of a stripped-down Linux, then run another full Linux container inside of that, and run another instance of Chrome inside of that?

        Although looking at his apps list, Slack is already an Android app and web app, can run fine on ChromeOS in multiple ways. Hyper appears to be some sort of Electron-based terminal. I have no idea right now why you would want to do that, but there are several types of terminals on ChromeOS already. Don’t know much about SimpleNote either, but it also looks like it’s already a web app and an Android app. VS Code is the only thing on the list that doesn’t really run in some form on ChromeOS already.

        1. 3

          I think the author does have a point in that you would think we can come up with a way for Electron apps to run more directly in ChromeOS.

          I think it’s called a web browser.

          1. 1

            Web Browsers have a lot of UI messiness around them that a “contained app” doesn’t, and sandbox things enough to where you cannot always make a sane experience (you can’t really do VSCode in a web browser, no access to local files)

        2. 2

          What are your thoughts on https://proton-native.js.org?

          I really like React as a view layer and looks reasonable to me to be able to access native ui libraries through Javascript like being able to use Python for similar purposes.

          1. 2

            The architecture specifics of Electron have helped it succeed, but what really matters are results: a developer can make a desktop application using a single JavaScript codebase, and it compiles into a binary that works on every OS.

            This is obviously bullshit.

            1. 7

              “Works” and “every” obviously require scare quotes, at the very least, but I don’t think the overall point is wrong. Electron succeeded (as far as it has succeeded, at any rate, which IMO is certainly too far to be dismissed) because there are massive numbers of incurious web programmers in the world, and Electron enables them to ship an application that will at least execute on several distinct, popular OSs without having to learn anything at all about those OSs or any languages or concepts other than Javascript.

              Do you see a different high-level reason for its success?

              1. 7

                I think it’s disingenuous to call these web developers “incurious”. There are other practical reasons to use Electron. I had to make a similar decision at my company: how do I allocate limited resources when I need to provide a web app plus iOS and Android apps? Guess what: I chose to go with hybrid mobile apps which shared a lot of code with the web app and between iOS/Android.

                Does that make me incurious, or pragmatic?

                I’m not sure you understand the effort involved in developing applications for multiple platforms. It’s all very nice to proclaim that these lazy developers just need to learn another two-three languages and another two-three monstrous sets of APIs, damnit, but in reality, what’s needed is another two or three teams of developers.

                As a matter of fact, I don’t like Electron and I think companies like Slack can afford the extra developers, but that’s a different argument.