Long ago when I began programming, most programs were standalone executables. Back in those days, almost all programs were run from a command line or executed by clicking on an icon on a GUI. This was before the web existed and most people didn’t even have dial-up access.
Things are very different today, with many applications having migrated to the web. I work in a Ruby on Rails shop at present, so I shouldn’t be surprised that most of the developers I work with immediately think of spinning up a website for any programming task.
In Standalone Command Line Tools, I talked about a command line tool and how some of my co-workers immediately talked about making a website out of it. In a team meeting last week, they began talking about a popular term in recruiting Full Stack Developer. It dawned on me that in their minds the whole world of software development boiled down to:
- Back-end
- Front-end
- Full Stack (which covers both of the above)
In this model, there is no concept of programming outside of a web context. If I push on the concept a bit, some might admit that the operations people write some code in other tools, but they don’t see it as the same as programming.
Website vs Standalone Program
There are some fundamental differences between standalone code and web-based code. The most important difference to me is the intended audience. Web development is inherently aimed at a large group with unknown level of experience and skill. Standalone code generally has an audience of one or a small number of people. I’ve worked on commercial programs that had hundreds to thousands of users. That’s still small compared to many website applications.
Standalone programs can also be focused on smaller problems. This is part of the Unix philosophy: each tool should do one thing well. This means that a standalone program is easier for exploring small or focused ideas. I’m sure almost every programmer has had the experience of wanting to try out a small idea and getting bogged down in building the code around the idea and eventually letting the project die.
This also means that you are less likely to procrastinate by playing with the perfect theme or UI library. You can focus on exploring the idea, not the trappings. Many web development projects I’ve seen flounder at look-and-feel or responsiveness issues that are not the core of the project.
Make the Computer Work for You
One of the other important features of a standalone program is the idea of making the computer work for you instead of the other way around. There are a number of small problems that I have needed to solve over time that do not require a fancy UI. In fact, many of these tools will never be used by anyone but me. It may be cleaning up some data that I get once in a great while, or some maintenance task I run once a month.
None of these tools require a website. In fact, maintenance of the libraries and such around the actual work would swamp any work I’m ever likely to do on the code. If the tool were exposed as a website, I would need to focus much harder on security implications (which aren’t a big deal on a program I wrote for me to run on one computer). All of this extra work is unnecessary for the job I want to do: make the computer solve a problem for me. But, it is absolutely necessary if the tool is ever exposed to the web.
The idea of most standalone tools I’ve written over time is to either reduce the time a job takes me or to encode a process I will need to repeat so that I don’t have to remember the details. In other words, I want the computer to do the boring parts and leave the interesting stuff for me to do.
Web Development
It seems that the whole of programming for most of the developers I know is web development. If it doesn’t get hosted somewhere, and get thousands to millions of hits, what’s the point?
This isn’t to say that they have not done impressive work. Several of my co-workers have built tools that are available on-line and solve problems for many inside the company and out. However, I still see many of them doing repetitive tasks by hand without really thinking about automating them.
I remember when the web was pretty new, some of us would create standalone programs that opened a website on a local port to supply a UI. This was mostly to avoid the annoyance of working with the OS UI libraries, because the relatively simple UIs we needed did not require all of the OS support and overhead.
In the present time, no one would ever be willing to accept one of those simple UIs. You need to decide which CSS framework is the new hotness (or at least which one you won’t have to replace next month if you want your site to look current). You need to pick a JavaScript framework to give yourself the right responsive model. You need to make sure all of your libraries are up to date and there aren’t any known vulnerabilities. Don’t forget to pick where you will host the code (how much are you willing to spend to host this, anyway).
Conclusion
It has been said that “software has eaten the world”, now that processing power and code have gotten advanced enough to replace much special purpose hardware. It now also seems to me that the “web has eaten software development”.