Your Front-End Does Not Have To Be Rich

by Chris Northwood

Not too long ago, there was a tried and tested approach for building a website or web application. There was a back-end, which generated some HTML and implemented your business logic, and a front-end which styled and presented that to the user, with information being transferred back to the server through forms, often progressively enhanced using some JavaScript for AJAX communication. Over the last decade, the web has become more powerful as a platform, and this approach has fallen out of fashion in favour of richer and richer front-ends, with more of the business logic being implemented in the client.

What do I mean when I say a “rich” front end? I mean one that does not offer value to the user until some client-side scripting has been executed. This could be a single page app which must first load and then fetch further content from an API call before the use can interact with it, for example. Another may be one which has a form for users to use, but that only works with JavaScript enabled. Often frameworks such as AngularJS or React are used for this (excluding isomorphic/universal JavaScript applications which first run the client-side code on the server as a form of progressive enhancement).

For many developers, it’s very tempting to see rich front ends as the default approach to take nowadays. They’re more modern and they seem more powerful (and on the surface, simpler,) but they have drawbacks. Many developers are lucky enough to work on powerful computers and own flagship phones, even if it’s not the latest model. However, for publicly facing websites, this represents only a relatively small set of your actual users, many of whom will be using older and less powerful models. Building richer applications where the front-end does more processing will often have a performance penalty compared to thinner front-ends which do less, especially on first load. However, that’s not to say that any impact on initial load performance may not pay out in the long run - some applications may benefit from being able to run logic locally in the browser, as opposed to a constant communication overhead to a server per request, and this can reduce your server load too.

Understanding your users and the nature of your product is key here. If you are building a content-first website, (for example, a brochureware site or a news article,) then your users will not necessarily benefit from a rich single page app. Optimising for a fast load time with progressive enhancement might work better for you. For a web-based game, having every single turn require a round-trip to a server will cause an overly negative experience, so a rich front-end would be the right thing to do.

Another benefit to using rich client-side frameworks is that they can seem deceptively simple to the developer experience - only having to write code for the client and not the server - but this simplicity can often hide other issues. It is easier to introduce accessibility bugs (and accessibility bugs often go longer before being detected as they require explicit testing, unless you are regularly using assistive technologies,) as well as it is to introduce negative factors for search engine optimisation which must then be worked around.

One reason that I have seen front-ends of web applications end up being rich is that the back-end code is handled by another team or developer. Many developers are now retraining to be “full stack”, so that they feel comfortable working on both the front and back ends of an application, although they typically still have a specialism within it. Agile teams in “digital-native” organisations are commonly structured around organisational units rather than technologies, too, so separate front-end and back-end teams are becoming a dated concept. As a developer who has  trained across the full-stack, if you need to implement a feature, you can implement that feature in the best place for it in the context of the whole system, which is often with some components in the back-end and others in the front-end, rather than just the area you have specialism and control over. Many front-end choices will also have a back-end impact - especially with things like form validation, where only implementing it in one place can have a security impact.

So, when you embark on your next project, take a moment to remember all the choices out there - it’s not just React vs Angular, but leaving most of your business logic server-side could be the right choice for your website. Training full stack skills to be able to do this work will give you the most flexibility to deliver the best experience for your users and meet the business needs too.

About the Author

Chris Northwood is a Senior Engineer working for BBC Research & Development, the research arm of the world's largest public service broadcaster. With a career starting out with Computer Science degrees from the University of York (BEng) and the University of Sheffield (MSc), Chris has worked at major organisations including ThoughtWorks & the University of Oxford, as well as freelance work. He wrote this book distilling the information he learnt over his career as it's the book he wishes he had when he started.

This article was contributed by Chris Northwood, author of The Full Stack Developer.