back to article Electron devs bond at Covalence conference: We speak to those mastering the cross-platform tech behind Slack, Visual Studio Code, etc

About 150 developers gathered at the headquarters of Slack on Friday to learn about Electron.js, the open-source, cross-platform desktop app framework upon which the IRC-for-hipsters client is built. Felix Rieseberg, senior staff engineer at Slack, a maintainer of Electron, and organizer of the Covalence conference, opened the …

  1. Dan 55 Silver badge

    What?

    Every C++ application, he said, implements pretty much its own networking stack and UI framework.

    This talk must be from some alternate reality where Berkeley Sockets and Qt don't exist.

    1. Anonymous Coward
      Anonymous Coward

      Re: What?

      Came here to say pretty much the same thing. The world has gone mad(der) if it's one where Electron is consiy a good programming framework.

      1. Warm Braw Silver badge

        Re: What?

        The world has gone mad(der)

        That's what I was thinking when I saw:

        the ability to write apps in JavaScript ... has genuine appeal

        1. big_D Silver badge
          Childcatcher

          Re: What?

          Those who can, do. Those that can't JavaScript.

    2. ForthIsNotDead Silver badge
      Unhappy

      Re: What?

      Imagine being sat in the audience, and he says that and instantly you know the speaker doesn't know what he's talking about, and the entire conference trip is likely to be a waste of time...

    3. LDS Silver badge

      Re: What?

      Anytime you don't use the OS native UI you're going to deliver sub-par UIs. Maybe user are now so used to dumb web UI they notice less - but most applications are becoming far less usable as web designers replace UI designers.

      1. Paradroid

        Re: What?

        I kind-of agree with your point, but UI designers haven't exactly been on fire since this trend of "stripping back" interfaces, removing common affordances like knowing you can scroll something, and indications of what has focus

    4. teknopaul Silver badge

      Re: What?

      Word. If you have an electron app port to webkit in QT.

      Port JS to C++. Port dev skills.

      Still quite heavy till you get rid of webkit, but not 20gig of spyware monitoring your every move.

      Cross platform. Actually native.

      GTK has something similar if you prefer webkit & C.

      _Chrome_ has a complete ui toolkit embeded in it and its own network stack, but thta is so they can add "metrics" hooks. No one uses the toolkit (except Chrome itself) because its so bad, lots of chrome itself uses html/js to avoid using its own toolkit.

      Chrome is a mess compared to QT. Riduclous base for a development platform. It was never designed for that. Its unstable. Changes on the whim of Google. Stupidly large. No dev tools. Its just not a platform.

      Shame Mozilla canned XUL. Seems there was a market.

  2. LDS Silver badge

    Isn't WASM going to kill Electron?

    At least WASM will be useful for one thing...

    1. teknopaul Silver badge

      Re: Isn't WASM going to kill Electron?

      No. Wasm does noy have a ui toolkit.

      Wasm requires a runtime and currently, if you take the Google pill, that is v8.

      If your interface to wasm is going to be JavaScript and your ui toolkit is gonna be webkit might as well write you wasm on electron.

      1. LDS Silver badge

        Re: Isn't WASM going to kill Electron?

        Just wait, and WASM-based framework will come - including UI frameworks. I didn't look at the details yet, but if WASM brings a language-independent ABI enough usable for complex calls, you can have WASM compiled libraries to be called from different higher-level languages.

        At least you won't need to install a Google-controlled run-time because WASM application will run on your browser WASM VM - or your operating system one.

        Why you should ever run a WASM application on Electron? High-level language -> WASM -> Javascript??? WASM has been designed exactly to take JavaScript out of the equation and have a low-level "machine" language to be executed directly.

    2. Brewster's Angle Grinder Silver badge

      Re: Isn't WASM going to kill Electron?

      No. Presuming Electron will run Wasm, then it's effectively a Wasm runtime.

      1. LDS Silver badge

        Re: Isn't WASM going to kill Electron?

        WASM runs below Javascript, not above. You can implement it in Javascript virtual machine, but its code is not Javascript - and doesn't tie you to a specific engine - so Electron could run WASM application, but won't be required to run them. And why you should bloat your system with all the Electron code when your browser or even OS will be enough to run them?

        1. Anonymous Coward
          Anonymous Coward

          Re: Isn't WASM going to kill Electron?

          "And why you should bloat your system with all the Electron code when your browser or even OS will be enough to run them?"

          Exactly... exactly what wasm is for. What I think some people are forgetting is that wasm can and is also used to draw.... wan't fancy FX like sprites or smoother transitions? Electron will slowly become the new jquery, but with way less uptake and far less longevity. Electron's only option is to become a IDE for wasm with that Frontpage/Dreamweaver feel.

    3. Anonymous Coward
      Anonymous Coward

      Re: Isn't WASM going to kill Electron?

      Not sure why you're downvoted, but it very well could as it's bringing a huge grey area of APIs that merit a whole new IDE. Which kind of leads into why I came to post....

      "...feel confident the software isn't a fly-by-night whim"

      But it's not software! It's about as much as software as considering GCC software. Want some strange looks? Ask somebody if they have "the latest GCC... GCC". But then again that's a bad simile, as Erectron is basically an interpreted-interpreted-runtime. So it's that script you wrote to emulate FreeDOS to run .bat files... no, nothing wrong with that at all :-/.

  3. Richard 12 Silver badge
    FAIL

    More than one window

    Is that possible at all with Electron? Microsoft claim to have been "working on it" since 2016, so that's not exactly rapid development.

    It also rips apart the security model of the host OS, creating holes large enough to drive several double decker buses through. Sideways.

  4. stratofish

    Try to make them think twice?

    Can we introduce some sort of carbon tax to offset the massive bloated waste of CPU cycles and RAM that things like Electron represent? To try and make the devs actually consider what they are doing for a change.

    It's true that for a lot of people they won't notice if the app they use is electron or not. In the same way that most people won't notice if their petrol uses lead or aerosols use CFCs. But enough people using them because the suppliers can get away with it adds up to disaster and forces the user to unknowlingly be complicit in it.

    1. Electronics'R'Us Silver badge
      Flame

      Re: Try to make them think twice?

      I have lost count of the number of times I have been told that processing cycles and memory are cheap, so bloat is perfectly acceptable.

      I would like to see them try their hand at deep embedded where those things are not cheap because there isn't enough space to put a lot of memory and a very fast processor (because you can't get the heat out).

      Sure, UIs can take up a fair amount of memory but the amount the current ones take is ridiculous (I can hear them writing it..."Oooo! Shiny!") and a simpler interface might well be better anyway (and use fewer resources).

      Icon for the processing required.

      Electron appears to be a problem in search of a solution (yes, I know which way round I put those :)

    2. Korev Silver badge
      Joke

      Re: Try to make them think twice?

      It makes me wonder if the conference was sponsored by RAM manufacturers...

  5. cdegroot

    Funny that a Slack engineer 'fesses up about bad quality software. A quick comparison: HexChat (for the youngsters, a client for a predecessor of Slack called "IRC") uses 57M real, 600M virtual after having ran for a couple of days. I just launched Slack (that hipsterware to keep you off work at work) - 300M real, 2.4G virtual. And I know that HexChat will stay the same and Slack will probably at least quadruple. That's progress for you. And I'm not even touching on the vast difference in usability - one of them I can extend in a bunch of different programming languages and has nifty things like custom hotkeys.

    The whole "multiplatform is hard" thing is bollocks anyway. There are only three platforms left, and I think all of them have decent Qt bindings (at the least; I think Gtk is available as well and I once did a cross-platform thing in Wx that looked surprisingly better than I anticipated). It's sheer laziness that Slack refuses to make a decent client; that, and - of course - being enterprise-directed the CIO, not the user, is the customer. CIOs don't sign cheques for optimized code (so in that sense they're rationally right to sling Eletron crap at their users). So it's a bit more work, would never impact Slack's bottom line but nobody who matters complains loudly enough. And I think that _that_ is the real thing wrong in our industry.

  6. jgard
    Joke

    Visual Code Studio?

    I'm always the last to hear of these new tools that all the cool kids and scrum whatsits are using. I'm still using boring old Visual Studio Code!

    1. This post has been deleted by a moderator

  7. JohnFen

    Then where are they?

    > "We know that building good apps with Electron as possible," said Rieseberg in an interview with The Register.

    If that's true, then where are these good Electron apps? I haven't seen them. The best ones that I've seen are only mediocre.

    1. brianoh

      Re: Then where are they?

      VsCode is the best code editor I've used.

  8. defcon

    Its the same arguments on every Electron story

    "Electron/Chrome is bloated and slow"

    "why don't you use native c++"

    "Qt looks just as good"

    I wonder, have the people who say this ever developed an actual app and faced the issues for any modern UI app that needs to be cross platform? Can you point to any cross platform QT apps that are mainstream?

    Look at https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt - nothing big there at all.

    The simple fact is that HTML+Js is such a vast ecosystem it allows you to build amazing UI in a fraction of the time it'd take with any other tech. The browser and JS engine (V8) have had billions of dollars invested to make them fast and feature rich. Native code just cannot approach that level of richness, and certainly not in a cross platform way.

    Why do you think we have React Native/Xamarin/Flutter etc? Its because devs don't want to write the same app, same UI multiple times in different languages. Qt just covers the desktop. What about the web? Slack's website and desktop apps run the same code.

    No one is going to learn QML. Why should they when we have CSS/HTML? Microsoft had to abandon the vastly superior WPF precisely because no one was using it. Flutter faces the same uphill battle, but it has Google behind it.

    Like it o not, Electron is here to stay. The browser is already shipped with every desktop/mobile OS as a system component. The fact that its a bit expensive to launch and runs in a separate process/tab is an optimization problem. In a few years this will be optimized. There's a very good chance V8 or some JS engine will be part of the OS too. Look at Gnome.

    Standardized apps are a good thing, esp wjhen built on such a flexible stack that is evolving faster than anything. Improving the web helps everyone, and its open.

    1. JohnFen

      Re: Its the same arguments on every Electron story

      > The simple fact is that HTML+Js is such a vast ecosystem it allows you to build amazing UI in a fraction of the time it'd take with any other tech.

      Take "amazing" out of that, and I'd agree with you.

      But HTML+JS simply cannot make applications that are as good as native apps are. They are necessarily full of compromises to the user experience, not to mention being bloated and wasteful.

      > Like it o not, Electron is here to stay.

      That's likely true (if not Electron specifically, then something like it), but because of economics, not because it's a great way to create applications. In any case, I won't be using them, personally.

      1. Dan 55 Silver badge

        Re: Its the same arguments on every Electron story

        And may I also add that "Standardised" is their standard. This godforsaken framework which has everything including the kitchen sink and can happily fill gigabytes of memory because it also needs a browser, a JavaScript engine, and whatever JavaScript libraries are du jour all because web developers like the idea of writing actual desktop software but haven't got the patience to learn anything new and think slapping together some HTML and JavaScript in Electron makes them Real Programmers Now is in no way a definition of a standard but just stuff slapped together that happens to work and is just yet another giant albatross around the neck of modern-day IT.

    2. Dan 55 Silver badge

      Re: Its the same arguments on every Electron story

      I looked here, the list wasn't too shabby and they have the advantage of not using all the available memory given half a chance (see Fucking Teams).

    3. Elledan Silver badge

      Re: Its the same arguments on every Electron story

      Autodesk Maya is written in C++/Qt and is available for Windows, MacOS and Linux.

      You were saying?

  9. brianoh

    RAM usage and performance

    RAM and CPU usage and performance simply don't matter with front-end apps as long as they are performant enough for their purpose.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021