1. 35
  1.  

  2. 6

    This is a great analysis, but I think it’s missing something: Cross-platform toolkits are not themselves written on top of cross-platform toolkits. They have to be ported to every platform and often lack some features on some platforms. This is a bit easier if you’re restricting yourself to Windows/Mac/X11+Linux, but it gets harder if you add Wayland+Linux or X11+FreeBSD to the mix. It gets much harder if you add iOS and Android to the mix because both of them have a very different set of core platform abstractions to the others.

    Last time I checked, Electron supported only desktop operating system, so you still need different iOS and Android applications. If you’re developing an iOS application then Catalyst makes it pretty trivial to also build a Mac version. Maybe it’s easier to sell different feature levels for mobile vs desktop, but as mobile devices become more featureful that’s harder to justify. If you maintain parity between your mobile and desktop versions then the Mac version built with Catalyst will be more popular with your users than one built with Electron.

    One of the big problems with the cross-platform tooling is that you’re at the mercy of the vendor for the set of platforms that you can support. Want to add ChromeOS support? Sorry, Electron can’t target ChromeOS, you need to have your users run effectively a separate Linux install via Crostini. Fine if you’re something like VS Code and you’re targeting programmers, much less fine if you’re something like Spotify. You might be able to easily target it natively if the Electron version is just a thin wrapper around your web version, but if you’ve used anything Electron-specific or if you depend on the Node bits for some local code, then good luck. If a Google device running Fuchsia suddenly becomes mainstream, how quickly can you target it?

    1. 5

      I don’t agree with you.

      The pretty common thing that works for a lot of people is to ship Electron on desktop and one of (Cordova, React Native, Xamarin, Fuschia) on iOS and Android. An Android phone and an iPhone are much more similar to one another from a design perspective (how big the screen is, how far away from your face do you hold it, how big do the buttons have to be to reliably hit them) then a Mac and an iPhone.

      If you’re doing PWA, responsive design & making all features work on the web first, then this gets real straightforward. Ship Electron on the desktop, the app as-is on the web and (one of the Cordova clones) on phones. The platform specific parts are now a tiny proportion of your codebase.

      Even if you aren’t doing that, having fewer silos (desktop, web, mobile) instead of 6+ silos (Android, iOS, Mac, Windows, Linux, toasters with m68k chips in, website) is a huge reduction in coordination costs.

      often lack some features on some platforms

      While a major hassle, this isn’t a coordination problem, which is what the article actually talks about. When you’re doing e.g. React Native development, you do not have siloed teams for Android and iOS, there’s just one team. You have a single codebase with 2 builds. The same people are testing and developing and noticing the bugs on both platforms.

      1. 2

        In practice, Xamarin, React Native, et al still take a layer of native code per platform, and teams in my experience still have Android and iOS specialists to do that work. They do coordinate because they need to agree on shared code, but they tend to silo themselves by specialty. Everyone needs to know another SDK, but they don’t get to forget native tooling. In a sense you have one codebase, but in a sense you have two codebases and a library in three languages. Even then the best place for shared code is often an API, so how much does shared local code buy? I generally don’t observe time savings versus two fully native apps; the total effort is about the same.

        For me, where the article is strongest is in its point about the diminishing returns of separate implementations on very complex apps. That rings true.

        1. 7

          Eli Bendersky once wrote “the benefit of dependencies is inversely proportional to the amount of effort spent on a software project.” I think that really is true. For a sufficiently complex series of apps, you’re better off writing your own crossplatform layer than relying on someone else’s… but the bar for sufficient complexity is very high.

          1. 2

            Maybe submit that article, that is fantastic.

          2. 3

            In practice, Xamarin, React Native, et al still take a layer of native code per platform, and teams in my experience still have Android and iOS specialists to do that work. They do coordinate because they need to agree on shared code, but they tend to silo themselves by specialty.

            My experience with RN for the last few years has been that the native code is a small proportion of the code base and we have seen a cessation of siloing.

            There’s a huge envelope of boring line of business applications where you can work entirely in RN with a handful of off-the-shelf libraries that extend the platform. The OS-specific parts end up being dealing with platform specific bugs in those libraries.

            1. 2

              Yes, especially with the availability of Expo this has been my experience as well.

              1. 1

                My boss evaluated Expo a few years ago and found it untenable due to bugginess/instability, if I remember correctly. Now this year we’re looking at moving to defaulting to working in Expo whenever possible because Expo has gotten so much better, and the productivity improvement is delightful.

      2. 4

        I worked on a cross-platform Windows/Mac desktop app built in C++ using Chrome Embedded Framework, which essentially gives you a webframe to render HTML/CS/JS to. The UI was a small layer on top of a very complex logic layer. It gave us some level of “coordinated featurefulness”. A simple change like adding a button or changing text was always replicated on both platforms. We were able to use the company stylesheets for the UI, just as in the web - so this was good for brand consistency. But some simple and most complex things required significant custom work. Simple things like the default margins of windows meant you had to sometimes change stylesheets per platform. More complex things like accessibility and desktop notifications were totally custom and required weeks of work. Accessibility work required us to learn how the OS screenreader APIs worked, which ones Chrome implemented, and which ones were recognized by screenreaders. There’s a default, built-in one on Mac (VoiceOver), but on Windows we just picked the most popular one (Jaws). Overall, it was a mixed bag. Using CEF didn’t make the hard things easier, but made the easy things easy.

        1. 2

          More complex things like accessibility and desktop notifications were totally custom and required weeks of work. Accessibility work required us to learn how the OS screenreader APIs worked, which ones Chrome implemented, and which ones were recognized by screenreaders. There’s a default, built-in one on Mac (VoiceOver), but on Windows we just picked the most popular one (Jaws). Overall, it was a mixed bag. Using CEF didn’t make the hard things easier, but made the easy things easy.

          I’m pretty sure that CEF still made accessibility easier than it would have been if you had used a custom GUI toolkit or even implemented a custom control using Win32 or Cocoa. It’s unfortunate that you had to test and work around screen-reader-specific quirks, but doing that using HTML and ARIA is still a lot easier than implementing the platform-specific accessibility APIs.

        2. 1

          I think the main complaints about the 1Password UI are its memory usage and its non-native feel.

          Both of these would have been much, much better with Qt.

          Why Electron over Qt? Perhaps you believe you can create a slicker UI, or you don’t want to use C++ or bindings (fair enough!) - or perhaps you have people who know how to use HTML and JavaScript already.

          I’m 100% invested in 1Password and I probably won’t notice the extra memory usage or any UI quirks (the design issues in the current native UI are enough of a pain while using it) but I find it a bit sad that there isn’t a cross-platform native toolkit that is attractive enough for companies like Slack, Spotify and 1Password to choose.

          1. 3

            Both of these would have been much, much better with Qt.

            Really? It took them 10 years to make the text navigation shortcuts in their text view the same as every other text view on OS X, which Electron gets for free by the fact that Blink wraps NSTextView. I generally avoid Qt apps on macOS because they look and feel completely alien. I used VirtualBox last week and it behaved nothing like a native Mac app. Are they using Qt particularly badly?

            1. 2

              Qt takes a lot of work to have proper mouthfeel on Mac; while it can do some stuff for you (i.e. annotate Preferences with a role so it’ll automatically get moved to the right place on Mac, add a proxy icon as needed, etc.), other stuff, it doesn’t, like:

              • Edit menu shortcuts that automatically
              • Proper tab behaviour with tab bara
              • Window menu with window list and basic commands
              • Dock menu with window list
              • Icons in the menu for commands
              • Keeping the application open without windows
              • Unified toolbar (hahah, it’s also buggy as shit!)

              Windows and X11 have much in common, but also a low bar nothing sticks out. On Mac, everything a Qt app will do by default sticks out and it’s your job to prune it down.

            2. 2

              Both 1password and Spotify are bigger than several magnitudes than organisations that manage to make platform-specific apps for different platforms. They employ more programmers for a single platform than other organisations do for their entire development teams. Any coordination problems they have are endemic to their organisation, not to their budget.