3. Tools

One of the earliest decisions to make is what tools to use, as that is dependent upon not only availability and skillset, but also what must be used.

The front end of web development must always use HTML and CSS, just because they provide the structure and presentation respectively. JavaScript is next, and while a lot of the web relies upon it for essential functionality, it doesn't have to be so prominent. I was already quite familiar with these technologies through earlier work, even automatically generating web pages using Visual Basic and XSL for exposing company support information.

What I wasn't very skilled at was backend technologies. The only PHP I had done was a couple of dozen lines of code for a utility on our NAS box to keep only the last three system backups of each computer we had on our network. When I started in early 2014, PHP was the web language, so it was a no-brainer. However, the next question was whether to use ancillary tools with it, such as one of the libraries available that have taken care of a lot of the common tasks serious websites need for their functionality.

This was the where my first real decision was made. That is, do I use a third-party library or invent what I need from scratch? I decided on the latter because my envisioned target audience was people who would not be technically savvy enough to keep things up to date. We know that every third-party library is a source of possible threats, but even from just plain bugs. A library is always overkill for any particular purpose, but even what is not used of them is a source of possible threats.

I decided to bypass all third-party software, except for PHP itself. That is not hard, as while there are many programming languages, PHP as delivered is actually a conglomeration of a lot of third-party software. Its advantage is that all those have been tested and updated before delivery, and PHP is always updated by the hosting provider, absolving my customers of having to look after any software updates themselves, except for my product itself.

Smallsite Design only has about 10,000 actual lines of PHP code, which is a lot less than any major library I could have chosen to work with it at the time, or since. However, the PHP is mainly doing the checking and organising work, while XSL handles the significant presentational aspects and much of the business rules.

While I was familiar with XML and XSL, I originally looked at abandoning my tendency to use the facilities within the presentation technology to store and render content, such as using MS Word or Excel if the result was going to be in one of those. Instead, I was looking at a database and programmatically constructing the HTML. While there is always a bit of building a mini-library to do the legwork required for any combination of tools, this arrangement was just plain clunky.

All the tools used for XML and XSL naturally manage their data in a state that transparently is suitable for HTML, just because they are essentially built on the same technology. I soon switched back to using XML for data storage, and XSL for rendering so that the data was always preconditioned for web page use.

This fit well with another early decision that sites need to be relatively easy to transfer to another hoster, which sort of ruled out MySQL with its need to have real technical smarts to manage moves. Smallsite Design's data requirements are very modest, so while SQLite could easily be put to use for it, there was still the clunkiness of the data conversion between the relational database and what is required for HTML.

Getting back to JavaScript, I made the decision to not rely on it as much as possible, largely because what visitors would be interacting with would be mostly passive, but also because even for the most intensively changing environment of editing, everything had to go back to the server because Unicode, essential for multilingual sites, was poorly supported by HTML and JavaScript in that the pattern attribute had rudimentary support for Unicode, but also there was no normalisation available.

Normalisation is the converting of what might be created as multiple codepoints in an IME (Input Method Editor) into a single codepoint, which to this day can only be done at the server end. This meant that input fields have to allow excess codes but the backend had to determine how many actual characters there were and inform the user afterwards.

The normal way that sites handle round-tripping is to use AJAX calls and update that part of the page with the updated HTML. However, I have provided most management pages with a lot of context information that would all have had to undergo the same update process. So, full-page round-tripping is the norm. I have tried to minimise the page jumping around with each update by using CSS scroll-padding and judicious use of the # location to keep the relevant part of the page in the viewport, though on really complex pages, that CSS command seems to lose itself in Edge.

In all, JavaScript is avoided unless it really adds something significant. This has resulted in the biggest JavaScript file used being only 12kB, but mostly 3kB, which is significantly smaller than the 92kB that jQuery occupies. The only element that totally relies upon JavaScript is the Sequence, which is like a slideshow with audio. It relies upon the Audio API which can only be accessed by JavaScript.