While working on a software development project some time ago, I was consumed by a stack of different products and technologies — among them a collection of Windows server installations, the .NET framework, SharePoint, SQL Server, IIS, C#, WebParts, JavaScript, and a lot of either compiled or interpreted source code. While drawing nearer to a “working solution”, I began to notice the performance of the colossus we had been working on — or rather the lack of performance.

When LAMP ruled the world

It brought to mind my experiences working on open source web projects perhaps twenty years ago with PHP and MySQL — the simplicity, speed and flexibility of the LAMP platform was persuasive. It’s been a few years now since I’ve had the chance to work with PHP, and I have to admit I miss it at times.

Javascript everywhere

Node.JS has of course appeared and swept all before it, but I can’t help feeling a certain level of discomfort about it. If you’re unfamiliar, the promise is that you will be able to write both server-side and client-side code in JavaScript — thereby reducing the skillset, and hopefully improving stability and reliability through not having to integrate disparate platforms.

Here’s the thing though — there’s already a magical layer between the server and the client called HTTP. It was invented such that the server and client could be entirely foreign of one another. It’s why the web exploded in the first place.

Not really compiled

Writing server-side code in JavaScript might be an attractive proposition for those that only known JavaScript, but it never gets away from the fact that it’s an interpreted language. While JavaScript compilers have appeared and improved enormously in recent years, we end up in the crazy situation of needing to know exactly how to write code to “suit” the compiler. The difference in performance between code patterns that the compilers like and dislike is stark.

Looking back

When I left college (20+ years ago!), C++ was a new language, and OS2 was promising a world that would never happen. I had learned to program in Pascal, knew a little C, a bit of assembler — and had been taught from day one that great developers wrote clean, fast, elegant code. It came as quite a shock when I entered the world of professional software development and discovered that commercial pressures almost always ensured software was never quite as good as it might be.

There is of course a disconnect between solutions and products — while solutions tend to face death by a thousand cuts to fit a schedule or a budget, products can evolve. Interestingly, in recent years products have become services through the adoption of “software as a service”, and subscription based licenses.

Open-source remains a guiding light

Parallel to my early career, the open-source movement grew like a weed, and it was no accident that I eventually became involved — writing an early blogging script, and a content management system. They were engineered from the ground up for speed, minimal footprint, utility, maintainability, clarity, and elegance. I suppose in many ways they were a reaction to the colossal Win32 API, DLL hell, ActiveX, the “almost ANSI SQL compatible” Jet database engine, and the various other car-crash complexity nightmares of the commercial world at the time.

Open source wasn’t perfect — it still isn’t — but it was a better approach than anything that had come before, and unlocked the door towards selling services instead of products.

The .NET Framework is better than many give credit

While it might sound like I’m continually bashing commercial products, it’s worth pointing out that the .NET framework, and C# to a lesser extent are one hell of an achievement. So is Visual Studio. Granted, they steal ideas from many other software development languages (chiefly Java), but there is a clarity of thought and depth of implementation present that is incredibly impressive.

Most developers admit that Microsoft has always made some of the best software development tools available. They played the long game early on — providing the best tools to build applications for their platform, and it worked — Windows took over the (desktop) world.

Just as an aside, I tend to think Microsoft missed an enormous trick by not letting us compile .NET code directly to machine code. The .NET Framework compiles intermediate language and caches it — why not let developers do it upfront too ?

It’s a shame

It seems a shame to have fantastic hardware thundering away in a server room somewhere, and then lay an operating system on top of it that restricts all access to the hardware, code execution frameworks that compile and cache on demand, innumerable libraries to extend capabilities, followed by numerous client-side frameworks to standarise coding practices.

I have to keep reminding myself that we no longer have to worry about memory management, file handles, pointers, stacks, address space, garbage collection, and the various other demons that haunted software developers for decades.

Building the elephant

I suppose it just feels like some days we start each project with a super-computer humming away in a server farm, and we slowly turn it into an elephant… a really heavy, slow, lethargic elephant.

Originally published at https://jonbeckett.com on January 18, 2021.