Though we are often sold into the idea that software development is better than ever before, the measure of better is open for debate. Surely you now have fancy stuff/words like DevOps, CI/CD, TDD, BDD, and more acronyms than there are three letter agencies in the US government.

But, for those old enough, there was a time when you could build stuff with just a notepad. It “got the job done”.

On the desktop, Microsoft had FoxPro, VB6 or, even, Microsoft Access. I say Microsoft because there was a time that’s “all” there was.

On the web, sure, spaghetti code is ugly but it worked. If you just needed some quick reports, you could drop a script in a cgi-bin folder, do some tables and framesets and move on to the next thing.

Nowadays all this things look more complicated for the “amateur” software developer. That is, solo developers or small business owners that are not tech-startups.

On our definition of “amateur” there’s nothing simpler than desktop. I have FoxPro 6 apps still running in the office, and the only thing that will kill them is lack of 64bit compatibility. Zero maintenance: just a folder with an .exe file to care about. 20 years running. The biggest pain would be updates, but this is internal stuff: just put that folder in a shared drive. You don’t even have to care about libraries, there’s only one dll…

The current lack of a desktop story

What is out there that allows you to build a desktop application that will still run 20 years from now? Most business software does not need constant updates and new features, but it needs to be able to be open 5-10 years from now to print a report for a tax audit, for example.

There is no compelling desktop story from anyone.

On the Microsoft side (still major desktop OS): FoxPro is gone, Lightswitch too, VB.NET is not VB6, there’s still MS Access.. completely stalled (read: VBA).

You might think of Java: Eclipse RCP is, definitely, not for amateurs, and NetBeans RCP is stalled. Though NetBeans RCP might get a boost now with the donation to Apache, it is not at VFP/VB6 “ease of use” level.

Then there are a few “stories” out there that lack something in some ways:

  • Lazarus. If not dealt with it enough to form an opinion, but it is a contender.
  • Lianja. Which promises lots but I’m not sure about it’s long term maintainability, specialy on desktop deployments. Though this is kind of a gut-guess.
  • PC Soft WINDEV. This is probably the best desktop story if seen so far on the last few years. though it’s language lacks some features of modern ones, you can get a lot done. Better JSON/REST support would do a lot, which it appears has been cared for in the latest release.
  • FileMaker. I just hate it’s licensing model (per-user), otherwise it’d be almost fine, until you want to integrate with other stuff. It makes for amazing interfaces, but it’s coding facilities are nowhere near any mainstream language like Python.

The Microsoft front is probably the worst as it not only lacks a story, it’s changing it every few years (WPF, WinForms, UWP, …).

Russell Keith-Magee noted on the PyCon 2019 Keynote that Python lacks a compelling desktop story. I’d go further: everyone lacks a compelling desktop story.

The web is no better

The web front is not as sad, as long as you know how to setup a web server you can still drop scripts in a cgi-bin folder and go with it.

Web backends for small-scale applications are doable still with PHP, Python, … though frontend is a completely different matter. Nowadays all “has to” be JavaScript intensive, React! Angular! which means that most resources available work under that premise.

A CSS framework that does not require you to setup npm, bower or another tool of the day is rare to be seen. Some frameworks that did not presume a bloated frontend before do so now, raising concern about the future of the non-react-non-angular builds. Maybe Bulma CSS might be an exception, no javascript at all, so not all is lost.

Truth be told, on the web front, there is nothing as easy and straightforward than server side rendered content. Specially if you are on PHP or Python.

There are some promises of rapid application development which, IMHO, are just that: promises. Rapid prototyping would be a more adequate wording.

  • OpenXava, not much to say. You simply need to really understand Java to go further from the basics. And “really understand Java” is not “amateur development”.
  • Apache Isis, I personally like it’s philosophy a lot. But has the same issue as OpenXava: you really need to understand Java.
  • CUBA Platform, I also happen to like it a lot. You can probably go further than with OpenXava or Isis without knowing a lot of Java, but it’s still Java. furthermore, it has that ugly project structure that came from GWT days where you need to work with three separate modules for every “module” of you app: client, shared, server. That might improve when they move to Vaadin >10, though it’s not in the horizon.

Java options basically all have the same issue for the amateur developer: once you need to move from “prototype” to the next stage you really need to understand what’s going on under the hood, and that in Java is not easy.

There are quite a few more, but I’ll skip them as the point would be the same: there’s nothing which will allow you to reliably build a simple CRUD / Line-Of-Business application without having to take care of a lot of infrastucture stuff like databases, web servers, etc.

Invasion of subscription model

I lied on my last paragraph. There is. WaveMaker, Microsoft PowerApps, Google AppMaker, … there is a plethora of low-code / no-code solutions out there. But:

  • They are, generaly, cloud based or with super-expensive on-premises options.
  • They are subscription based and with per-user pricing models.
  • They use propietary technologies which is the worst lock-in you can voluntarily subject yourself to.
  • The moment you need to do something out of “the normal” you will either not be able to do it, end up writting Java, or having to deploy something somewhere and call it via REST.

But, more importantly, you can’t fire that up 20 years from now and expect it to “just work” and be able to print some reports. Even if you pay for the applicable subscription fee for 20 years, I doubt you’d get there without any code changes, etc.

When integrating those tools, you will probably end up with a serverless function, because it’s the easiest thing to deploy. Or a Kubernetes cluster, or anything else. You will be introducing cross dependencies and points of failure which you will then need to monitor and care about. Now imagine having to put that up again in 10 years because a court order asks for some records only avaiable in that (then in the future) legacy system.

Conclusions

I really believe there’s a space for such tools to come back to the front lines of application development. Applications that can run on their own either on the desktop or sandboxed in a browser but that do not require an infrastructure setup more than you need a monitor.

Just as I also believe that the next economic crisis (soon to come) will end with lots of the current subscription based businesses moving companies back to things whose operation do not rely on being able to pay the next month’s fee.