The tricky problem I started with was how to go from zero knowledge to a working app with a minimum of effort and a maximum of future-proofing? Sounds like a classic problem for a neural network or genetic algorithm - "John's random walk through programming state space...".

This article is the first in a series documenting the process, which hopefully will be useful to other beginner and new devs trying to disentangle the web.

Exciting New Ventures

When I started developing web apps, I was revisiting software dev after a 10 year break. I've worked previously with UI creation, application development and testing but in Windows desktop apps. Some sort of a mixture of OOP and imperative C++ code. So I thought I knew how to write code in general but knew very little (in hindsight, nothing) about the required technologies or languages for the web. I didn't know how to host a website, build an HTML/CSS interface, develop let alone host a database or link the UI together with code. Neither did I know at first what resources are available in this modern world to help. But it was very exciting finding out a whole bunch of new opportunities.

Project Fear

No doubt there are many resources around which would have told me the 'one true way' straight-off. Some of them may even have been necessary and sufficient to my needs. And the needs of my company. But when there are many unknown unknowns how to proceed?

My strategy was to learn the bare minimum to generate a working app which met the specification. And assume that the next app would incorporate new ideas as I learnt more. So I dived in to the world of introductory tools, examples and libraries to pick those which seemed to meet my requirements without too much extraneous baggage.

It wasn't quite hit-and-hope, but picking an Azure example using Express, Jade (a.k.a. Pug), NodeJS and Cosmosdb on the basis that I understood the example seemed risky but at least achievable! The manual conversion from Jade to Pug was an early lesson in the dangers of compatibility and picking winners (which were actually losers).

At this point I realised there was one aspect of my starter-app (and therefore my knowledge) that was lacking. Just what is CSS and how should it be used? I applied the same level of investigative effort (so I maintain) into figuring out CSS that I'd done for asynchronous single-threaded code, Azure back-end etc. but couldn't really claim to have a clue what I was really doing.

Side projects and outsourcing to the rescue

For the none-CSS bits I followed the principle of 'learn what you need when you need it'. Do what is necessary and sufficient - no doubt there will be frowns about not using the latest ES6 or React wizzy-ness :-). Lowest common denominator turns out to be a very useful approach when you don't fully understand the consequences of choices in an uncertain world. (yes, the Azure example above uses ES6, but it was based on ES5 when I started out - they updated to use async/await but stuck with jade over pug).

In addition, it wasn't (still isn't) completely clear where our apps and shareable code might be needed. It is very useful to have the same code style, language and tools be applicable in as many places as possible to reduce cognitive load and make it easier to spread capability within the team. So JavaScript with as few dependencies and assumptions as possible was the starting point, leading so far to a bunch of side-projects investigating variations of our JavaScript running as a:

• Website (stick with JS for now, consider compiled languages later)
• NodeJS web server (no need to learn more languages)
• NodeJS web API (free your logic and data!)
• Chrome extension (make your web app always available)
• Skype, email and Facebook chatbots (remarkably easy to build interactive systems, but not free-form chat)
• Electron desktop app (take your web app onto the desktop)
• Excel add-in (use a website inside Excel to manipulate Excel!)

The diversity and ease of creating these variations was compelling evidence that the core decision to start simple was valid - we didn't to learn more than a couple JavaScript design patterns (e.g. IIFE, asynchronous calls) to develop a set of solutions that work in a variety of contexts.

So as you can see, ease of on-boarding and flexibility of platform are our key criteria - running with the most modern web app tools is less crucial (until it becomes crucial in the future…). We did of course use elements of a range of well-established libraries, such as:

• jQuery (not really essential but useful to clarify DOM interactions)
• D3 (flexible visualisations but takes some getting used to)
• Async (a great package for managing a range of asynchronous situations)
• Express (most popular routing and server solution, fine for our simple needs)
• Express-validator (flexible way to validate user data)
• Nodemailer (easy way to generate and send emails. We connected it to a Office365 account but spent a long time formatting the inline CSS for the email content)
• Pug (in hindsight might have been over-kill, especially when we increasingly used AJAX, but useful to modularising common page sections)
• Bootstrap (required by my company website guidelines)

Not all of these are needed for Chrome extensions, Add-ins etc. but perhaps you can also see the beginnings of an in-house 'architecture style' or 'framework' emerging. Or maybe I just have commitment issues and should have settled for an early choice of framework? Somehow I'm not ready for such a life-defining choice just yet. Maybe later...

CSS development we basically outsourced to a specialist. Having seen what they did, I now know enough to be dangerous. But I still struggle with why CSS seems to need such a different way of thinking and organising compared to the other areas of development. It isn't really a programming language and has too much physical and mental context switching. I started to wonder if this was really 'the only way' or just an artefact of the past…. More on this later too!

Fear of users

How to find out if anyone uses the thing? Do they like it? Did it break? Did they find out anything useful? Would they recommend it to colleagues? What happens if we find out all these things and don't like the answer?! So many worrying questions!

Side projects aside, I still needed to succeed with the main app. Which was OK functionality-wise, but what about the users? Web development has a different relationship with users compared to the desktop pay-and-install model I was used to. Our offer is currently free to use so we just kinda put it out there and briefly shared the news with our network.

We have users!

The app worked just fine - plenty of scope to improve both the user experience, maintainability and reliability (but more on that later too). Our Google and Azure analytics demonstrated a steady flow of users, although the conversion from brief visits to the front page into active use was of course less than 100%... I'm very happy with the results but also that I can now see so many areas to improve. Counter-intuitively a long and active issues list is a good thing to have!