Simon Fredsted

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?

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 definitely not talking about Electron.

You see, an Electron app 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.

A computer inside your computer

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 will run an additional copy on top of that.

These days, browsers are virtual computers: they're a sandbox of functionality that's made available to Web sites through JavaScript, and browser developers are constantly trying to ward off new attacks that target your real computer. All these safety measures of trying to isolate malicious Web sites add up; all code has to pass through layers of abstractions in order to reach down to the "bare metal". It's the reason why these apps slow down your computer, even as browser manufacturers have improved the speed.

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.

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.

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 Delphi allowed me to do – and is the reason I actually view current Web development as very basic and limited 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, things that came very late for Web development.

On Delphi Web sites, you could download thousands and thousands of “components” – mostly free or open source – to use in your application (alas, no package manager). 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.

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 distinguishes the Web from desktop applications.

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.

Rapid Application Development

I see no real, technical reason why developing a graphical application shouldn’t also be graphical in the drag-and-drop way Delphi did in 1995.

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 the traditional Web designer/Web master role.

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 just about 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.

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.

At some point, the RAD 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 it looks like the Web is getting there.

When will it get better?

Electron’s number 1 problem is performance – and developers 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.

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.

Some projects, like DeskGap, are attempting to leverage the browser stack of the operating system, thereby taking advantage of the browser code that's in memory anyway. But it comes at a cost: On Windows, DeskGap only runs on Windows 10 versions from October 2018 or later, leaving out the huge swaths of computers still running Windows 7 or 8.

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?

We need to invest in cross-platform UI frameworks

I sincerely hope that for desktop applications, something better comes along than HTML and CSS. I think it's too cumbersome and time consuming to create applications. The Web was made for content, not applications, and the more we try forcing all our computing into it, the more the complexity grows.

I think the role of desktop applications – versus Web apps – is to fit in and integrate with the rest of your system (and especially the applications).

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. It's there anyways: for Google, shovelling money into a browser is a win-win situation. But it doesn't mean 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. And my laptop is burning my lap.

This entry was posted on Sunday, February 10th, 2019 at 20:54 and is filed under Articles. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.