I have some good news for you, the future of software development has arrived! Well, to be precise, the next possible big thing in the future of software development is here… again. What’s next for using Electron with Windows for Windows Application Development?

Works anywhere, just add RAM

I have this mental block about the name Electron. I’m not entirely sure why it is,w but whenever I try to remember the name of this ubiquitous web framework, my little gray cells shout “Eclipse” and, try as I might, I can’t conjure up the correct name at the appropriate moment during the chatty too-and-fro of a webinar.

I think I have a theory though on why this is happening; my unconscious mind is trying to prevent me from crossing over to the dark side to use Electron to create cross-platform applications.

What is wrong with using Electron?

Look, there’s nothing wrong with using Electron as such. I’ve actually used Electron and produced an app which was, in effect a website encapsulated by the Electron framework and runtime. But, that said, it is a voracious eater. It will consume every part of your machine’s RAM and CPU resources if left to its own devices. If you don’t believe me just run a quick web search for “electron problems”.

The pros of Electron are that it can be a quick route to market. If you have a web app it’s not a massive task to wrap that website or web app with the Electron framework. Also, it implements an auto-update system which means you can push out new versions and improvements with fairly low friction.

A web developer is not necessarily an application developer

A couple of problems crop up. Behind the scenes of almost every Electron app is the beast which is Node.js – bringer of NPM, the Node Package Manager. The NPM is a superb repository of add-ons, components, modules and time-saving Nodestuffs. Electron / Node developers can get a package for almost everything. If you’re a web developer who has some JavaScript knowledge the NPM can allow you to pull in components to save you a ton of work.

Isn’t using NPM a bit like installing Delphi Components?

Well, yes it is. Except with one very specific difference: Delphi is compiled down to native code with an optimizing compiler. If you include 1000 Node packages – either deliberately due to some form of overzealous optimism, or inadvertently due to one package having a dependency on another which depends on another five which all depend on another six packages – then you will have 1000 Node packages in your app even if all it does is display a page saying “hello world” in flashing magenta.

If you do the same in a Delphi app you will get a lot of unnecessary junk included – but Delphi’s compiler and linking mechanism will exclude a massive amount of things you pulled in but don’t actually get used. It can’t totally protect you from yourself and your component-hoarding kitchen-sink ways but it will definitely save you from creating a Gigagbyte app when it only needed a few MB at most.

Low code is the Next Big Thing

Right. Low Code apps. You’ve seen some of them and, yes, they can be great for creating apps usually either by answering questions in a wizard or by dragging and dropping pre-defined visual blocks to pretty much draw the program on the screen like a flow-chart on steroids.

Yes, done right and in narrow fields of implementation, these draw-it-yourself programming languages can be very useful, especially in the educational sector where it can help novices visualize the workings of a program’s flow.

We even have a FireMonkey Low Code Wizard for RAD Studio so it’s not a totally horrible idea.

But wait a minute…

Is visual development a new thing?

I’m old enough to have been a computer programmer who learned to program in the 1970s and 1980s. I wrote my first for-money application, an advertising text banner, in 1979. It was text because everything was text. No mice, no pointers, no windows, no directories/folders – no MS-DOS or Windows. I went on to write COBOL for a living and then, later C programs, all done the ‘hard way’ with Vi, Edit or EdLin (yes, I really do know how to exit VIM). For the first three months as a COBOL developer, we junior programmers had to write out our programs on COBOL coding sheets – literally pieces of paper written on with a pen. We wore white lab coats because computing was a science and scientists worked in labs. Then we got ‘terminals’ so we could type the code in ourselves. No more lab coats although we suddenly had to wear three-piece suits since we were now a “business” and business people wore suits.

This is how it was, with little variation, for the next 12 or so years. Seriously, the only ‘visual development’ was a hand-drawn flow-chart.

Microsoft rides to the rescue

Then Visual Basic came along. It was great but was as slow as a slug at a beer festival and compiled into a pseudo-code layer rather than the super-speed of native assembly or C programs. This interpretative nature also generated a problem called “DLL hell” where the runtimes which made tiny Visual Basic programs possible would have multiple versions which were incompatible with one another and gave rise to missing function entry points that were fiendishly difficult to resolve. Also, VB relied a lot on VBX and OCX controls which added functionality, often to do quite ordinary but necessary things missing from the runtime – but they too could be different from the one expected by your app, frequently in ways which were fatal to your poor program.

Doesn’t that sound a lot like the situation with Electron? It also sounds a little like the early days of Dot Net too: “this app requires Dot Net Runtime X.Y.Z, download it now” – which meant a 500MB download; you could safely start it downloading and go to lunch while it did that.

The internet is just a baby

Your VB program could be really tiny. But that tiny app was actually leveraging a huge monster installation of Visual Basic runtime and lots of VBX/OCX installation artifacts. This was back when modems were considered fast if they went to 56K on a standard telephone line. If you were unlucky your modem was only a 1200/1200 or 2400 speed box. Five megabytes was a slow, tedious and frustrating download, especially if your Mom picked up the telephone to call Auntie Gertrude part way through.

A magazine advert changed my life

Then, one day in 1995, I happened to be looking through a computer magazine (which was actually printed on real paper, ee those were the days) and I saw an advert for this new system called Delphi which would allow you to create your programs by dragging and dropping visual elements onto ‘forms’ – a bit like how you could in Visual Basic – except it was based on a blindingly fast optimizing compiler and linker which could produce native code with no requirement for burgeoning runtimes and was, in effect, immune to the DLL hell that had plagued me – and many 1000s of others – working with Visual Basic.

I ordered a copy of Delphi 1 the day it was released. I still have the receipt.

Hello world the low code way – in the 1990s

So, with this new Delphi you had to take some time to learn Pascal. I thought that would be a bit of a hill to climb but it turned out it was not massively different from BASIC or C. In fact it had the ease of use of BASIC with all the professional, close to the metal power of C while avoiding many of the mind-bending esoteric functions of both.

To create a program which showed a basic window with a button on it that said “hello world” when you clicked on it took one line of written code. Visual Basic was similar, so far so good.

Then I compiled the Delphi app and realized, when running it, that it would launch from anywhere on the computer – or anyone else’s computer – without having to install it first.

Back then we didn’t have USB drives. The floppy disk still ruled the world as the tool of choice to take a program you wrote on one computer and install it on another. I could copy the app onto the floppy disk and then take it over to a colleague’s computer and run it from the floppy disk and all this without installing anything AT ALL on his machine. It wasn’t just low code – it was zero installation too.

You could not do this with a Visual basic program unless the other machine had the Visual Basic runtime installed.

The low code, no install method still works today for Delphi

Wind forwards a couple of decades. Today I have a fairly popular client-server app which is pretty comprehensive for the target market and laden with features. It connects to a MySQL database and ‘speaks’ to a custom-written (in Delphi, by me) Windows service for data marshalling and licensing.

The application, complete with compiled-in multi-resolution graphic resources, compiled-in direct native MySQL access, encryption, PDF and report preview generation – dripping with features, compiles to a finished app size of 10mb. TEN megabytes.

The server part is only 917kb. Yes, less than a megabyte.

You can run it all from a USB memory stick since it still requires no installation for the client side.

Your modern app is a bloated monster

Compare my ten megabyte Delphi app to some of the new darlings of the low code world, especially Electron, and you’ll see that Delphi, the original low code kid, still has plenty of tricks. It’s the same set of tricks it has always had in its repertoire: easy and rapid component-based development, a dizzyingly fast compiler, compiling down to native-level code which produces rock-solid applications that run and keep on running while the operating system and the hardware evolves.

Is Delphi old-fashioned?

Well, RAD Studio Delphi doesn’t stay fixed in the halcyon days of the ‘90s technology boom; apart from the obvious modernity of the IDE, RAD Studio adds now the FireMonkey FMX Low Code Wizard to give you a head start on the donkey work, the REST Debugger to keep you current with the modern world of consuming online services, more and more deployment targets such as iOS, Android and Linux and the Web too. The market for third-party components is still strong with something available for almost anything you could ever want. But, better still, the compiler and linker make sure that, unlike poor Electron’s Node package list, you’re only pulling in actual code which can be executed, not anything and everything just because it’s referenced by nothing more than an include file.

The future of software development

The future of software development looks like it might include some unnervingly accurate “intelligent AI” features such as those in beta at the moment for the Copilot project. Copilot is about trying to guess what code you’re trying to create and then attempt to write it for you based on what the machine learning was trained on, mostly drawn from public repositories.

It’s already run into a little bit of hot water by being a bit too good at regurgitating someone else’s code verbatim and for suggesting license text which turned out to be a perfectly good license but for the wrong context in which the app developer was working.

Will I ever get replaced by an AI programmer wielding machine-learning coding skills? Maybe. Although I’ve heard this said before, over the decades I’ve worked in the industry. The reality is that I’m far more likely to be replaced by outsourcing to some country where the cost of living is sufficiently low that the disparity in what they are prepared to work for is too great for me to compete.

If they use Electron though… I predict the customer will come back… eventually…

---

RAD Studio Delphi is the fastest and most efficient way to create apps with the minimum of effort. Take your ideas and turn them into reality by downloading a trial today.