1. 12
  1.  

  2. 10

    Some of us miss native desktop applications that worked well. It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app. But at the same time not everyone is satisfied with the solution of “build them all as electron apps starting with a cross-platform browser base plus web technology for the UI”. I can sympathize with app developers who in no way want to sign up to build for 2 or 3 platforms, but I feel like berating dissatisfied users is unjust here. Try comparing a high quality native macOS app like Fantastical with literally any other approach to calendar software: electron, web, java, whatever. Native works great, everything else is unbearable.

    1. 8

      I think people are just tired of seeing posts like Electron is cancer every other day. Electron is here, people use it, and it solves a real problem. It would be much more productive to talk about how it can be improved in terms of performance and resource usage at this point.

      1. 3

        One wonders if it really can be improved all that much. It seems like the basic model has a lot of overhead that’s pretty much baked in.

        1. 2

          There’s a huge opening in the space for something Electron-like, which doesn’t have the “actual browser” overhead. I’m certain this is a research / marketing / exposure problem more than a technical one (in that there has to be something that would work better we just don’t know about because it’s sitting unloved in a repo with 3 watchers somewhere.)

          Cheers!

          1. 2

            There’s a huge opening in the space for something Electron-like, which doesn’t have the “actual browser” overhead.

            Is there? Electron’s popularity seems like it’s heavily dependent on the proposition “re-use your HTML/CSS and JS from your web app’s front-end” rather than on “here’s a cross-platform app runtime”. We’ve had the latter forever, and they’ve never been that popular.

            I don’t know if there’s any space for anything to deliver the former while claiming it doesn’t have “actual browser” overhead.

            1. 1

              “re-use your HTML/CSS and JS from your web app’s front-end”

              But that’s not what’s happening here at all - we’re talking about an application that’s written from the ground up for this platform, and will never ever be used in a web-app front end. So, toss out the “web-app” part, and you’re left with HTML/DOM as a tree-based metaphor for UI layout, and a javascript runtime that can push that tree around.

              I don’t know if there’s any space for anything to deliver the former while claiming it doesn’t have “actual browser” overhead.

              There’s a lot more to “actual browser” than a JS runtime, DOM and canvas: does an application platform need to support all the media codecs and image formats, including all the DRM stuff? Does it need always on, compiled in built-in OpenGL contexts and networking and legacy CSS support, etc.?

              I’d argue that “re-use your HTML/CSS/JS skills and understanding” is the thing that makes Electron popular, more so than “re-use your existing front end code”, and we might get a lot further pushing on that while jettisoning webkit than arguing that everything needs to be siloed to the App Store (or Windows Marketplace, or whatever).

              1. 2

                But that’s not what’s happening here at all - we’re talking about an application that’s written from the ground up for this platform, and will never ever be used in a web-app front end. So, toss out the “web-app” part, and you’re left with HTML/DOM as a tree-based metaphor for UI layout, and a javascript runtime that can push that tree around.

                Huh? We’re talking about people complaining that Electron apps are slow, clunky, non-native feeling piles of crap.

                Sure, there are a couple of outliers like Atom and VSCode that went that way for from-scratch development, but most of the worst offenders that people complain about are apps like Slack, Todoist, Twitch – massive power, CPU, and RAM sucks for tiny amounts of functionality that are barely more than app-ized versions of a browser tab.

                “Electron is fine if you ignore all of the bad apps using it” is a terribly uncompelling argument.

                1. 1

                  Huh? We’re talking about people complaining that Electron apps are slow, clunky, non-native feeling piles of crap.

                  Sure, there are a couple of outliers like Atom and VSCode that went that way for from-scratch development, but most of the worst offenders that people complain about are apps like Slack, Todoist, Twitch – massive power, CPU, and RAM sucks for tiny amounts of functionality that are barely more than app-ized versions of a browser tab.

                  “Electron is fine if you ignore all of the bad apps using it” is a terribly uncompelling argument.

                  A couple things:

                  1. Literally no one in this thread up til now has mentioned any of Slack/Twitch/Todoist.
                  2. “Electron is bad because some teams don’t expend the effort to make good apps” is not my favorite argument.

                  I think it’s disingenous to say “there can be no value to this platform because people write bad apps with it.”

                  There are plenty of pretty good or better apps, as you say: Discord, VSCode, Atom with caveats.

                  And there are plenty of bad apps that are native: I mean, how many shitty apps are in the Windows Marketplace? Those are all written “native”. How full is the App Store of desktop apps that are poorly designed and implemented, despite being written in Swift?

                  Is the web bad because lots of people write web apps that don’t work very well?

                  I’m trying to make the case that there’s value to Electron, despite (or possibly due to!) it’s “not-nativeness”, not defending applications which, I agree, don’t really justify their own existence.

                  Tools don’t kill people.

                2. 1

                  we’re talking about an application that’s written from the ground up for this platform, and will never ever be used in a web-app front end.

                  I’m really not an expert in the matter, just genuinely curious from my ignorance: why not? If it is HTML/CSS/JS code and it’s already working, why not just uploading it as a webapp as well? I always wondered why there is no such thing as an Atom webapp. Is it because it would take too long to load? The logic and frontend are already there.

                  1. 2

                    I’m referring to Atom, Hyper, Visual Studio Code, etc. here specifically.

                    I don’t think there’s any problem with bringing your front end to desktop via something like Electron. I do it at work with CEFSharp in Windows to support a USB peripheral in our frontend.

                    If it is HTML/CSS/JS code and it’s already working, why not just uploading it as a webapp as well?

                    I think the goal with the web platform is that you could - see APIs for device access, workers, etc. At the moment, platforms like Electron exist to allow native access to things you couldn’t have otherwise, that feels like a implementation detail to me, and may not be the case forever.

                    no such thing as an Atom webapp

                    https://aws.amazon.com/cloud9/

                    These things exist, the browser is just a not great place for them currently, because of the restrictions we have to put on things for security, performance, etc. But getting to that point is one view of forward progress, and one that I ascribe to.

            2. 1

              I can think of a number of things that could be done off top of my head. For example, the runtime could be modularized. This would allow only loading parts that are relevant to a specific application. Another thing that can be done is to share the runtime between applications. I’m sure there are plenty of other things that can be done. At the same time, a lot can be done in applications themselves. The recent post on Atom development blog documents a slew of optimizations and improvements.

          2. 4

            It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.

            It’s a necessarily sacrifice if you want apps that are and feel truly native that belong on the platform; a cross-platform Qt or (worse) Swing app is better than Electron, but still inferior to the app with a UI designed specifically for the platform and its ideals, HIG, etc.

            1. 1

              If we were talking about, say, a watch vs a VR system, then I understand “the necessary sacrifice” - the two platforms hardly have anything in common in terms of user interface. But desktops? Most people probably can’t even tell the difference between them! The desktop platforms are extremely close to each other in terms of UI, so I agree that it’s tragic to keep writing the same thing over and over.

              I think it’s an example of insane inefficiency inherent in a system based on competition (in this case, between OS vendors), but that’s a whole different rabbit hole.

              1. 2

                I am not a UX person and spend most of my time in a Terminal, Emacs and Firefox, but I don’t think modern GUIs on Linux (Gnome), OS X and Windows are too common. All of them have windows and a bunch of similar widgets, but the conventions what goes where can be quite different. That most people can’t tell, does not mean much because most people can’t tell the difference between a native app and an electron one either. They just feel the difference if you put them on another platform. Just look how disoriented many pro users are if you give them a machine with one of the other major systems.

                1. 1

                  I run Window Maker. I love focus-follows-mouse, where a window can be focused without being on top, which is anathema to MacOS (or macOS or whatever the not-iOS is called this week) and not possible in Windows, either. My point is, there are enough little things (except focus-follows-mouse is hardly little if that’s what you’re used to) which you can’t paper over and say “good enough” if you want it to be good enough.

              2. 2

                It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.

                There is a huge middle ground between shipping a web browser and duplicating code. Unfortunately that requires people to acknowledge something they’ve spent alot of time working to ignore.

                Basically c is very cross platform. This is heresy but true. I’m actually curious: can anyone name a platform where python or javascript run where c doesn’t run?

                UI libraries don’t need to be 100% of your app. If you hire a couple software engineers they can show you how to create business logic interfaces that are separate from the core services provided by the app. Most of your app does not have to be UI toolkit specific logic for displaying buttons and windows.

                Source: was on a team that shipped cross platform caching/network filesystem. It was a few years back, but the portion of our code that had to vary between linux/osx/windows was not that big. Also writing in c opened the door for shared business logic (api client code) on osx/linux/windows/ios/android.

                Electron works because the web technologies have a low bar to entry. That’s not always a bad thing. I’m not trying to be a troll and say web developers aren’t real developers, but in my experience, as someone who started out as a web developer, there’s alot of really bad ones because you start your path with a bit of html and some copy-pasted javascript from the web.

                1. 1

                  There’s nothing heretical about saying C is cross-platform. It’s also too much work for too little gain when it comes to GUI applications most of the time. C is a systems programming language, for software which must run at machine speed and/or interface with low-level machine components. Writing the UI in C is a bad move unless it’s absolutely forced on you by speed constraints.

                2. 1

                  It’s tragic that desktop platforms are utterly non-interoperable and require near-complete duplication of every app.

                  ++ Yes!

                  Try comparing a high quality native macOS app like Fantastical with literally any other approach to calendar software: electron, web, java, whatever. Native works great, everything else is unbearable.

                  Wait, what? I think there’s two different things here. Is Fantastical a great app because it’s written in native Cocoa and ObjC (or Swift), or is it great because it’s been well designed, well implemented, meets your specific user needs, etc? Are those things orthoganal?

                  I think it’s easy to shit on poorly made Electron apps, but I think the promise of crossplatform UI - especially for tools like Atom or Hyper, where “native feeling” UI is less of a goal - is much too great to allow us to be thrown back to “only Windows users get this”, even if it is “only OS X users get this” now.

                  It’s a tricky balancing act, but as a desktop Linux user with no plans to go back, I hope that we don’t give up on it just because it takes more work.

                  Cheers!


                  PS: Thanks for the invite, cross posted my email response if that’s ok :)

                  1. 2

                    Wait, what? I think there’s two different things here. Is Fantastical a great app because it’s written in native Cocoa and ObjC (or Swift), or is it great because it’s been well designed, well implemented, meets your specific user needs, etc? Are those things orthoganal?

                    My personal view is that nothing is truly well designed if it doesn’t play well and fit in with other applications on the system. Fantastical is very well designed, and an integral part of that great design is that it effortlessly fits in with everything else on the platform.

                    “Great design” and “native” aren’t orthogonal; the latter is a necessary-but-not-sufficient part of the former.

                    1. 1

                      “Great design” and “native” aren’t orthogonal; the latter is a necessary-but-not-sufficient part of the former.

                      Have to agree to disagree here, I guess. I definitely can believe that there can be well-designed, not-native application experinces, but I think that depends on the success and ‘well-designed-ness’ of the platform you’re talking about.

                      As part of necessary background context, I run Linux on my laptop, with a WM (i3) rather than a full desktop manager, because I really didn’t like the design and cohesiveness of Gnome and KDE the last time I tried a full suite. Many, many apps that could have been well designed if they weren’t pushed into a framework that didn’t fit them.

                      I look at Tomboy vs. Evernote as a good example. Tomboy is certainly well integrated, and feels very native in a Gnome desktop, and yet if put next to each other, Evernote is going to get the “well-designed” cred, despite not feeling native on really any platform it’s on.

                      Sublime Text isn’t “native” to any of the platforms it runs on either.

                      Anyway, I feel like I’m losing the thread of discussion, and I don’t want to turn this into “App A is better than App B”, so I’ll say that I think I understand a lot of the concerns people have with Electron-like platforms better than I did before, and thank you for the conversation.

                      Cheers!

                3. 2

                  Electron bashings remind of Haskell (or similar) programmers bashing PHP.

                  Just like PHP, Electron has problems, but it has many practical benefits and that’s why it’s popular despite having those problems.

                  Their popularity (despite their problems) shows just how weak and problematic some of the alternatives are.

                  A minority of purists will moan while people continue to produce value using these tools.

                  1. 1

                    Yes, but there’s another thing: PHP had become extremely popular for historic reasons (shared web hosts where you could not execute custom binaries but had mod_php or so; much simpler to get started programming for than CGI binaries) and then just stayed there, at least to some extend, also for economical reasons: There are vast amounts of people who feel comfortable programming PHP and find Jobs doing it, so they often don’t really see a reason to look into anything else. Because a) it’s popular, b) ‘works’ for them c) heard that the other stuff is more complicated.

                    With electron, getting started is easy. When you hit performance problems or so, you often have already invested far too much resources in the platform to switch. With QT for example, getting started, is perceived as much more difficult.