Archive for February, 2019

Feb 10 0 Electron: How did we get here?

It’s extremely hard to write good, cross-platform desktop applications. And by applications I mean actual applications: On Windows that’s an .exe file, on Mac it’s an .app bundle and on Linux … I guess it’s an ELF format binary?

Slack, a popular chat application that’s built in Electron.

And no, by application, I’m not talking about website wrapped in an actual app. I’m not talking about a single-page browser.

I’m not talking about Electron.

You see, an Electron “application” is only mimicking being an application. Yes, with Electron, you’re getting an executable file to download when you go and get VS Code or Slack – and to anyone not knowing the difference, the Atom installer will look exactly the same as a native app … until you install it.

Once you begin using an Electron application, you’ll notice that it doesn’t really fit in. It will look completely different from most other applications on your computer. Most other applications have a standardised menubar; not so with Electron apps, because, in short, an Electron app is a pre-packaged version of Chrome that is designed to only run only one Web site. It includes a HTML renderer, a JavaScript parser, a Web Inspector and all sorts of other components you don’t care about – just so you get the experience of running a Web site as a desktop application. Of course, you’re already running all this anyway – inside your browser. And every Electron app willyou’ll run an additional copy for each Electron app you’re installing.

It’s your only choice

Everybody is creating Electron apps these days. It’s the smart thing to do, really. HTML and CSS and Javascript is the de-facto cross platform graphical application development toolkit. Yes, there’s Java, and QT, and sure, there’s other cross-platform UI toolkits, but there’s no real popular, universal solution. If you want to write a console utility, you could use Go, or maybe C++, or an interpreted language like Python or Ruby. Plenty of choices. But a desktop app with a UI?

For applications like Slack (chat), VS Code or Atom (text editors), Hyper (a terminal emulator), I’d argue Electron is the only feasible choice. There’s simply no alternative.

A common complaint about Slack is how slow it is and how many resources it uses.

The commonality for all Electron apps is that they could run just as well as regular web apps in an actual browser, but there’s no real utility in doing so: Slack needs access to your camera, microphone, desktop (for screen sharing). VS Code and Atom need access to your files, and to run arbitrary commands for code linters, git, compiling and more. Some of these things you could do in-browser; for others, a step outside the browser is needed.

Access, OS integrations and performance – these are the big reasons why a desktop app would need to run outside the browser.

In a way, Electron is a hack for fulfilling the access limitations of Web browsers.

But Electron apps hasn’t cracked the performance part yet: while extremely impressive and feature-rich, applications like Atom and VS Code require absolutely enormous amounts of RAM to do simple things, like just starting – or opening small documents.

It’s not a pretty sight to monitor the RAM usage of an Electron app.

We have to go back

A digression: After I learnt QBasic (a variant of BASIC), my first programming language, in the late 90s, I stumbled upon something called Delphi. Others might have experience with Visual Basic, which is somewhat similar. What it allowed me to do – and is the reason I actually view current Web development as very basic today – is the fact that you could build a complete desktop application using drag and drop and the built-in code editor. Delphi had a complete IDE with code completion and built-in documentation. On the web, you could download thousands and thousands of “components” – mostly free or open source – to use in your application. Needed a way to make a specific type of network connection? Or all sorts of buttons, progress bars, rich text editors? There’s a component for that.

Screenshot of Delphi 7

Delphi 7, a software development IDE for Windows. Delphi was originally released in 1995.

There was even an acronym for this way of developing apps: RAD – Rapid Application Development. As it implies, making a Delphi app is fast.

On-screen, the app could of course be designed to fit on your screen depending on your resolution, window size and so forth – responsive design was around before the Web.

Obviously, Delphi had built-in database connectivity, so you could very easily make the text fields and content in the application connected to a database (of course, back then, there was Paradox and FoxPro, not MongoDB and Elasticsearch). There was no need to mess with grid systems, to write a JSON API that your Angular frontend fetches data from – all the stuff that makes the Web… the Web.

Delphi even had cross platform compatibility, and still has, with Lazarus, an open-source clone of the Delphi series of IDEs. However, it was rough around the edges – and still is: care must be taken to ensure the quality of the user experience on the platforms you’re targeting.

To be honest, having experienced development with things like Delphi, even back in the nineties… These days, it’s hard to appreciate anything about modern Web development besides how it’s truly cross platform the way nothing else is.

When will it get better?

I see no real, technical reason why developing a graphical application shouldn’t also be graphical in a drag-and-drop way. We’ve seen drag-and-drop Web editors like Squarespace becoming hugely popular, and together with WordPress, these types of services have mostly killed the market for low-skilled “Web designers”.

At some point, the Delphi way of developing applications had to make a comeback. At some point, people would notice how much effort it actually is to create a Web app. And come back it has.

Screenshot of Salesforce Lightning app builder

Salesforce Lightning app builder.

On platforms like Salesforce, we see new ways of developing applications, now you can actually build Salesforce applications using drag-and-drop. I think we’re slowly getting there for simple business applications, but if you want to build something out of that realm, like a chat app or a text editor, you need to look elsewhere.

Oracle Application Builder screenshot

Oracle Application Builder – what RAD development like Delphi has transformed into. Everything has moved to the cloud – including your own data and applications.

The difference between the new breed of “application builders” and the old-school RAD apps: everything is in the cloud, so no money spent on infrastructure maintenance. But then you’re locked to that cloud provider. Want to move? You’re SOL.

JS apps with native performance

Electron’s number 1 problem: performance – and developers are working hard to solve that problem.

At some point, and one could argue we’re there already, we’ll begin to see Electron apps becoming feasible for not just text editors, but also image editors and 3D games – or maybe hardware speed will simply begin to outpace Electron’s hunger for CPU cores and RAM. It might be a mix of both.

While I think Electron can get us some of the way, it’s not enough. Bundling a full browser engine with each and every application is a non-starter. Most people won’t run more than 2 Electron apps at a time, so it’s currently somewhat acceptable, but in the longer run we need a better platform for this.

Perhaps a new standard emerges that makes browsers expand to be able to provide desktop experiences for Web apps? Maybe the operating systems themselves move to provide native support for HTML, JS and CSS?

Is it far-fetched to believe that JavaScript will become the operating system?

Cross-platform UI frameworks

I sincerely hope that for desktop applications, something better comes along than HTML and CSS. I think the role of desktop applications need to fit in with the rest of your system (and especially your applications), even though the iOS app scene has eroded what it means to look “native”.

One of the ways to get to application building Nirvana will be to improve and invest in cross-platform application UI frameworks. Until now, all the energy has been spent on the Web, because it’s universal. But there’s no reason that all applications must be Web applications.

Will a genius new way of building native user interfaces be created by the Go community, for example? I sure hope so.

But for now, Electron is the best we have.