Why Are We Making Web Development So Hard?

I don’t think I’m the first person to think this by any stretch. There are lots of infographics around showing the difference between web tooling now and 10 years ago and it’s clearly ballooned at an extraordinary rate.

In the last year or so I’ve started working with Angular (as opposed to Angular.js a.k.a. Angular 1) and have also dabbled in Vue and React. All of these frameworks seem to share the same basic ideas – build everything as a component and push and pull them from the DOM as needed. Each component is made up of a HTML template, embedded CSS styles and a JavaScript controller.

This feels like an efficient way of working, very DRY. But is it? You create a component, let’s say a time picker. One it’s developed you can put it into multiple views or uses relatively quickly. However, if you later modify it to work slightly differently, using adding complexity, you have to test it in each use case and make sure it still works with no detrimental effects.

All UIs are basically built up of HTML, CSS and JavaScript. Traditionally HTML is for content, CSS for styling and JavaScript for reacting to user behaviour. With components we’re adding a whole load of JavaScript just to make the basic elements appear before we even get into any behavioural usage. This adds to page weight (size of files being transferred to the browser) and render times. There’s the library itself, often split into many smaller modules, plus a controller for the UI to assemble it and then the components. It could just be one HTML file, one CSS file and one JavaScript file.

Increasingly, what the developer writes in their editor is becoming further and further from what actually appears in the DOM. The frameworks insert a whole host of IDs and classes to elements, bloating the HTML and making it harder to read. Styles are inserted as inline <style> blocks rather than being cached in an external stylesheet. Opening the browser’s Dev Tools to track down and fix a problem is becoming harder, not easier.

Also, the more tools you use, the more you’ve got to maintain, keep up to date, upgrade and replace. It’s creating work just to keep up and inviting technical debt.

I think that what we’re gaining in terms of being able to develop new UI more quickly is all rooted in developer efficiency and production cost saving. It’s not thinking about the user. We’re making things slower for users. The mobile experience on most sites is still awful and the overhead of these frameworks is partly to blame.

The latest frameworks also rely on good browsers with all the JavaScript features. They do not use progressive enhancement but just grind to a halt on an older browser. This goes against the universal nature of the web – it should be easy to read and easy to write. The bells and whistles on the top is just that and should be optional, not prevent the basics from working.

I think we need to get back to making things simple. Write HTML, CSS and as little JavaScript as we can get away with. Go static wherever possible. Make it fast and simple for users. User experience should trump developer experience.

Setting Performance Targets

I sometimes read things like “A user will abandon a page if it doesn’t load within 2 seconds”. I really don’t think these kinds of generalisations are very helpful.

Users’ expectations vary. They take account of network connectivity and the nature of the information they’re accessing. If I abandoned any requests that were not fulfilled within 2 seconds I don’t think I’d ever see any web pages on my phone. My expectations aren’t that high. I know it’s going to take longer and that’s fine, up to a point.

So, are there benchmarks that we can aim for realistically? We can’t just say “page” and “2 seconds”. It needs to also specify the network connection type – wired, WiFi, 3G, 4G, and the page weight in bytes.

There’s a danger that we strive to keep everything small and light and then give poor experiences on wired desktops with super fast connection speeds. We need to deliver the appropriate experiences.

What’s our definition of “loaded”? Is it when everything is there and available to use? As soon as there’s something to interact with? A sign that something’s happening? A use doesn’t necessarily need it all. They just need to know that it’s coming within a reasonable time frame. There are lots of tactics for keeping a user on side while content is loading too – an entertaining loading animation, flashing up a quote, animating in the various screen elements. As long as there’s something to keep the mind from wandering onto something else it’s generally fine. Does this distraction tactic feel great the first time but really irritate by the tenth time?

How do you benchmark all of that? It’s hard, very hard. Maybe that why all we’ve got is empty generalisations?

Speed, Usability and Speed

When looking at making UX improvements to web apps, I tend to obsess about speed and performance. For me a fast experience is a good experience.

I really think that speed outweighs all other factors. If you can keep all loading and waiting times very short, ideally under a second, it keeps the user engaged and efficient in what they’re trying to achieve. As soon as anything takes longer than a couple of seconds it’s easy to let your mind wander, switch context and then take longer to get back into what you were doing. If this is happening lots of times across a lengthy session it really adds up, not to mention the frustration it causes.

Usability is obviously important too. It needs to be obvious what screen elements you can interact with – is that an underlined heading or a link? It needs to be clear what an interaction with that element will do. Unexpected behaviour makes people feel uneasy and suspicious about other potential interactions. And it’s always good if the user can see how the whole piece fits together, how you get from A to B, B to C, etc.

The usual causes of things being slow are not network issues but bad design. The most common problem is simply trying to send too much too soon. Requirements often ask for a high number of items to be displayed with a high level of detail against each. It’s always worth asking if this can be broken down to show fewer items or less detail with more being available on demand.

If a screen lists 20 items with all their details and it’s taking 5 seconds to load we still don’t have to load it all at once. Rather than the user waiting for 5 seconds, why not just load the first 3 items quickly, so the user has something to see within a more acceptable time frame (before the mind wanders), and then load the other 17 in the background while the first 3 are keeping them occupied.

Even if your app is working at acceptable speeds if you haven’t already done so you should still try to make it faster. Use a strategy for how you’re going to load new data and use the usual performance tricks – caching, bundling, minification, pre-fetching – to really give the UX a boost.

What to Look For in a Web Designer or Design Agency

Imagine you’re a business owner or marketing bod and you need to get either a new website or you want a redesign of your current, slightly tired looking site. You need to hire a web designer or design agency. How do you tell the good from the bad?

Web designers range from the top end agencies who have major international corporations in their portfolios down to someone’s neighbour’s kid who made a website for someone once. Chances are you want something in between – not paying over the odds and not getting something held together by sticky tape.

Agency or Freelance Designer

I’d say your first choice is knowing whether to go with an individual or an agency. Traditionally agencies would cost you more as they had an office with bills and marketing costs whereas an individual might be working from their room. Today, with more home working, those lines are a bit more blurred and some very good agencies might be made up of remote workers. An agency brings some reassurance, that if a particular person is on holiday for 3 weeks, off ill or leaves then there’s usually someone else to pick up your work, whereas with an individual you might not have that fallback. By the same token, some designers have very sound fallback plans – working with other designers, passing all relevant access back to the client so it can be picked up by another freelancer. It’s really a case of asking the right questions and making sure you feel adequately covered for what you need.

It’s all about how it looks

Look at what the designers have done previously. Obviously consider if the designs look appealing but look slightly beyond that. Is each design tailored to the content of the site or business it represents or are they trotting out the same template for all their sites? An overuse of templates suggests that they’re bashing out sites as quickly as possible for maximum profit rather than really caring about doing a good job.

Actually, it’s not about how it looks

Looks are one thing but how a site performs for you is much more important. It needs to load quickly and display properly on any device. Some sites have great home page animations or big images which cycle to promote things. Whilst these may look great on a desktop they’re a nightmare on a mobile device without WiFi. If a user has to wait 30 seconds for your page to load and then pinch and zoom to read your page, do you think they’ll hurry back? Fast loading and appropriate sizing for all devices is essential.

Ask about page speed and responsive design. If they don’t seem to know about this, or view it as an extra, run, run fast, far away. Responsive design is not a “nice to have” like it was a few years back, it’s critical. Even if you think you’ll never have any mobile visitors, 1) you’re wrong, by the way, and 2) having a site work on mobile is a key factor in Google’s ranking of search results. If it doesn’t perform well on mobile Google’s search ranking algorithm will lock your site in a dungeon and make it eat nothing but porridge for the rest of its anonymous life. Probably.


You also need to consider if you’re looking for a one-off piece of work that’s signed off and shipped or an ongoing relationship where they will keep working on your site. Make sure you find out costs for any future work – new features or pages or tweaks to existing stuff – even if you don’t think you’ll need it. It’ll give you a good idea of how they operate.


This applies to the UK. I’m not sure quite how Value Added Tax or equivalents work in other territories. If you’re a small business, individual, club, etc and not VAT registered yourself it may pay to find a freelance designer who is also not VAT registered as it will save you having to pay an extra 20%. This does imply that they’re working at a lower turnover level but for a smaller project this might be a better fit.


To bring that all together in a nice to do list, ask about the following:

  • Fallback plans if the designer is not available
  • Use of templates
  • Page loading times, especially on mobile
  • Appearance on different devices
  • Ongoing or future work
  • Are they VAT registered (if relevant)?

Boosting Web Performance

One of the areas of front end development I’ve really got into in the last year or so is performance. It’s always been there in the background (along with SEO and accessibility) but it seems to have a lot more focus in the web community lately.

For a while I’ve been looking at different ways to speed up various sites I work on. This site has given me a perfect guinea pig for trying out some different techniques. Let’s give it a boost! Oooosh!


My first idea for making this site super fast to load was to make all of the pages static. I started off by just making a few pages but soon realised that as things grew and I wanted to make design changes it just wasn’t scalable. It was fast though. If I was building a simple site with only a handful of pages this is the way to go.


To try to get the best of both worlds, static for speed and CMS for convenience, I moved on to using Jekyll, a static site generator. After jumping through a lot of hoops I got it set up. It works really well and if you’re planning to update a site from a single machine I’d say this is the perfect solution.


For various reasons I moved back to good old uncle WordPress. It’s so easy to update from anywhere, which means I actually do it, plus I feel that it’s become so big in the web industry (almost its own industry) that I can’t really afford not to know my way around it.

So, my new challenge is to make my WordPress site fast. There are various well renowned caching plugins, e.g. W3 Total Cache, which would effectively turn my PHP into static pages. Unfortunately, these don’t seem to work with my multisite setup so I’ve tried something different.


I’ve routed my site through Cloudflare. It’s a website fronting service which aims to improve performance and security. They host your site on various servers around the world so you get the benefits of a CDN – fast delivery to far flung parts of the world. They concatenate and minify static files for you – one less job. They also handle security threats and high spikes in traffic so your site doesn’t go down. As if that wasn’t enough, they also serve your files over https – cheaper than SSL hosting and great for SEO.

So far so great. Definitely worth a look on top of whatever other optimisations you’re doing. :)