Setting up >>> | Stories >>> | Words, words, words >>>

Introduction

This is the first in a series of articles on the subject of web apps.

First of all, what is a Web App? I'll define it by saying it's any program that runs in a browser and takes control over its own affairs. This is not to say that web apps do everything in the browser, though; many will call a server to provide services such as database access, most likely using the REST protocol. In this series, to keep things as simple as possible I'll use an example that is entirely browser-based.

My target audience

I write articles mostly for people with levels of technical skill ranging from near-beginner to intermediate. Professionals will find much to disagree with but they have the skills and ability to do things better, while the rest of us, struggling to stay afloat in the incoming tide of technology, look for simple ways to do things. These are becoming ever harder to find and my mission is to help where I can, partly by taking some lessons from the past that have been forgotten in the rush to embrace the new.

Warning: The code and examples I will use in this series, being also aimed at the same people, are unlikely to find favor with professionals working in big teams. However, most websites are relatively small projects and I don't believe in taking a sledgehammer to crack a nut. In any case, those professionals don't need a series of articles like this as they already know a lot more than I do.

Why build a Web App?

There are several reasons to build a web app:

1. You've been contracted to do it
2. You need to have something to put on your CV that proves you're a real programmer
3. You want to test new ideas
4. You're doing it for fun

If you are doing it for the first of these reasons, then you're likely to be heavily constrained in how you approach the work. Judging by vacancy notices alone, most prospective employers have a fixed idea about how they want software to be constructed. Most ask for a depressingly similar list of technologies that represent the current received wisdom about how things are done and leave little hope that new ideas will be encouraged.

This leads inevitably to reason 2. Programmers everywhere are cramming themselves with training about the currently most fashionable technology and praying that they'll get a job before something brighter and newer comes along and makes them redundant. It's hard to live with rapid evolution.

The last 2 reasons are just plain self-indulgence. You want to have fun, and why not? You only get one life.

Frameworks and Tools

A recent question on Quora asked if the current profusion of frameworks and tools has a negative effect on programming. There were two responses that gave diametrically opposite but equally valid answers. The first was that it's impossible to compete effectively without these tools because it takes longer and costs more to build an application with traditional programming methods. The second was that using the Lego approach leads to a vast dependency chain that ends up pulling in the entire universe, resulting in bloated code that's hard to maintain.

The first of these answers is right because if you can't compete you don't have a business. It assumes that the only important consideration is the up-front cost of building something, while maintenance, unquantifiable but of secondary importance, can be safely ignored. Sadly, that's the prevailing view. But if you care about maintenance the effect of these tools can indeed be negative. I wrote an earlier article which cited what I call the Titchmarsh Effect to show how easy it is to build something that can't be maintained by its owner and therefore has a short useful life. As with most things in life, it's always best if you can find a good compromise.

The parts in this series

These are the topics I'll write about in future parts of this series:

1. Setting up. I assume you want to show someone else your work; this means having a website you can point people to. Many would-be programmers seem to give this a low priority but I think we should all engage in a little self-publicity.
2. Stories. Before starting coding, be sure to document the user-level view of what is to be built, otherwise you have nothing to test the result against. Here I'll break with convention and describe a coding approach that keeps the stories visible so they can be understood by the domain experts who wrote them.
3. Library components. Most systems include parts that can be regarded as self-contained entites that are potentially useful elsewhere. Don't construct these directly in your project; build them as separate libraries. My article will include an example.

Coming up...

The next part of this series, Setting up the System, covers setting up a public-facing WordPress system, including how to customize a theme to give you a clean page in which you can put your code.

Title photo by Clément H on Unsplash