What I Learned in 2018

I write a post like this every year and it feels like it gets harder each time. There was a time when I could rattle through a list of new tech, tools or libraries that I’d been using. It feels like I’m much more focused on soft skills these days or firming up what I already know.

Running Workshops

This year I’ve started running workshops to share knowledge with other developers. I’ve run short half hour workshops on Semantic HTML, Sass, Web Workers, Service Workers and Flexbox. I’m not a natural teacher or presenter but it’s been great to give other developers dedicated time to learn something new and by putting together a workshop it’s made me firm up my knowledge of each subject. I’d definitely recommend it as a worthwhile activity to anyone.

Design System

After a period of research and seeing what other companies are doing, I’ve started a design system, documenting UI patterns and styling advice. It feels good to have things documented in one place rather than in my head or having to go back and find the most recent or best usage. I’ve built a base system which loads HTML pages and then created a HTML page for each design element. This gives the flexibility to be able to move the content into another environment in the future without having to start from scratch. It makes heavy use of CodePen embeds to demo the result and share the HTML and CSS.

Design Audit

I’ve learned about design audits and ways of going about bringing designs of separate sites or software together. This is the method we’re planning to adopt:

  1. Select a design element, e.g. buttons.
  2. Go through every page of your site or app and screenshot every different variation which you find.
  3. Put all of the screenshots into an audit document.
  4. Present these differences so that others are aware of the scale of the inconsistency.
  5. Agree on one correct design with which to move forwards.
  6. Change each variation to the new correct design. As you do so, remove that variation from your audit document.
  7. Over time the audit document gets smaller and smaller until it is no longer needed.

Web Workers

Learning about Web Workers and how you can send some operations off to be carried out in the background was very interesting. I’m yet to find a real life use case for them but it certainly opens up a lot of possibilities having multiple threads running instead of just one.

Service Workers

This is another area which seems to have a huge potential, not only for performance by loading resources from the cache but also being able to provide offline content and create a Progressive Web App, a web based app which can run offline just like a native app. I’m hoping to create my own app some time in 2019.

Custom Elements

Towards the end of the year a colleague introduced me to Custom Elements. I was vaguely aware of them before but without the browser support hadn’t taken too much notice. Now they’re usable. Being able to make your own elements that work independently of any framework is very powerful. It means that we’re not longer limited to using a single framework or framework version in an app or across teams.


The final thing that I’ve been working on is trying to improve my use of ES6, gradually trying to break old habits and write in the newer, easier style. The biggest breakthrough I’ve found is the backtick syntax, being able to write HTML and use ${variable} within it for binding. It’s a lot easier than lots of document.createElement() and then setting innerHTML or textContent.


Basically I’m aiming to put all of this new learning from 2018 into practice and get some real working examples.

The DOM Diet and Year Pickers

I think we all know that having a smaller DOM is good for performance but I was never sure what’s considered big or small, or at what points performance is affected. Knowing a little more can change how you approach things.

I was recently doing a performance analysis on some pages and the tool I chose to use was the Chrome Performance Audit. If you open Dev Tools (F12) and go to the Audits tab you’ll see a range of available audits which includes Performance. This uses a tool called Lighthouse and gives estimates for various performance metrics as well as Opportunities and Diagnostics.

One of the diagnostics which came up for me was “Uses an excessive DOM size” and the detail gives us this:

Browser engineers recommend pages contain fewer than ~1,500 DOM nodes. The sweet spot is a tree depth < 32 elements and fewer than 60 children/parent element. A large DOM can increase memory usage, cause longer style calculations, and produce costly layout reflows.

The item that triggered this diagnostic for me was a year picker, a select element with 150 options. Whilst I don’t think it’s really causing any major performance issues it did strike me that 1 parent element and 150 children does seem excessive for just picking out one number from a consecutive range so I started looking at alternative ways we could do this. I wanted to put my year picker on a  “DOM Diet”. I created this pen:

See the Pen Year Pickers by Chris Smith (@chris22smith) on CodePen.dark

Here’s a quick comparison of 4 possible ways of selecting a year from a consecutive range. It’s important to not only look at possible DOM performance but also the user experience side – ease of understanding and ease of use. No point making it faster if it’s confusing or hard work.


This is the standard method. It can have a default value or a blank value as the first option. It’s very familiar, ease to understand and use. It’s probably better to start with a blank value so that we know a user has actually made a selection rather than just left the default. It supports arrow keys and mousewheel. It’s easy to validate using just the required property as the available options are set. It can look untidy in some browsers when long option lists run off the bottom of the screen and it does use a lot of DOM nodes.

Range Input

The input[type=range] doesn’t show a value by default so you have to do a bit of work to show an output value, and a bit more work to do this elegantly. Through testing I found the output value had to go above the slider rather than below so it was not obscured by a finger using the control. I think this is fairly easy to understand but users may not be aware that they can use their arrow keys to get greater precision – either up/down or left/right. It can be hard to control and get the exact figure you want dragging the handle especially using a finger. It can also be wired up to support the wheel event and respond to scrolling up or down on the mousewheel. There’s no way to have a blank value so it has to have a default set. There’s no real validation to be done as it has to use a value in the range. It’s very kind to the DOM too with only 3 nodes.

Number Input

This method is very simple. You just let the user type in the date they want. It can be left blank or have a default value. It can be controlled using arrow keys or the mousewheel though I’m not sure how many users know this. By setting the min, max and step attributes it can limit the range entered when not typing. If the value is typed (or pasted) it will require validation. This uses a single DOM node.

Multiple Number Inputs

This final method is just a bit of a “left field” design. The advantage of it is that it’s very easy to update using the tab key and arrow keys. By having the digits separated the range for each is only ever 10 so in theory it should mean less to change. If left blank it could be set to automatically shift the focus to the next input when a value is added. This makes it as fast to type the 4 digits as a single number input. The min, max and step attributes can limit the range for each digit. It’s light on the DOM too with only 5 nodes. The disadvantage with this method is the validation – it’s going to be a bit more involved, parsing the 4 digits as a single value to be checked and then highlighting the invalid digit(s) could be difficult. On a mobile device with a number pad it also means the pad flashing in and out quickly, which is not a great experience so it’s only really suitable for desktop use.

I’m not sure I’d necessarily go running from the standard dropdown but some of the other methods are certainly possibilities and help keep the DOM smaller.

500 Mile Challenge – Half Way

This year I set myself a challenge, to run 500 miles within the calendar year, 2017. I’m now about half way through the year so thought it was time for a quick update and review.

When exactly is the half way point of the year? With February being short it’s probably around the second of July. Near enough for this post anyway.

So, half way through the year and a touch over half the miles covered. Today, 3rd July, I’ve done 256.9 miles. I’m now in training for Cardiff Half Marathon at the start of October so will start doing longer distance runs and should hopefully pull comfortably ahead in the next couple of months.

It might not seem like the most difficult challenge, and in truth it probably isn’t, but having it there has made a big difference. There have been many times where I might have not bothered going out but the idea of falling behind in my miles has kept me going. It also helps keep it regular, rather than doing nothing for 3 months then going nuts it keeps it steady and means I never get too unfit.

I’m logging each run in Airtable and am using the API data in a CodePen project to plot it on a graph using Chart.js. You can see the chart here:

graph of runs vs target

Getting Feedback on Codepen Demos

At the software company where I work, we’ve started using Codepen as a way of producing interactive demos or prototype pages. It’s slowly replacing the use of static images or mock-ups. We’ve started sharing the URLs for these with customers to get their feedback on new features.

This could be done by sending them 2 URLs, one for the pen and one for the feedback form, but it’s not as good as being able to complete the form whilst viewing the demo content at the same time. I came up with a way of requesting feedback within the pen.


I embedded a SurveyMonkey survey tracking script within the pen. I amended the pen design slightly to add a sidebar div and then added the SurveyMonkey embed JavaScript block within this, in the HTML pane of the pen. The script had to be here so that it rendered in the right place. I gave this sidebar a fixed width so that we could control how the survey contents appeared. We then had to write the survey in such a way that it didn’t require much screen width and that all questions would fit into a sensible minimum screen height. In short, we kept questions short, no lists of 10 radio buttons.


I decided to also embed CrazyEgg. If you don’t know it, it’s a tool that allows you to track mouse clicks. It’s a very useful way of knowing which parts of your screen get the most interaction. We added this script into the head content, within the HTML settings. This is a paid service but you can get a free trial for a short time.

Debug Mode

The 2 scripts seemed to get blocked when we tried using the pen in Editor or Full Screen modes but Debug mode, which runs the code as it is without any header or validation, worked like a dream. You need a PRO account to use this mode. Well worth it anyway in my view.

Feedback Ready

I’m now looking at building this out as a template ready for future feedback gathering.