A guide for backend developers writing front end

Developers, developers, developer

It's not easy being a backend developer. Not only do you have to code massive websites, you also end up being responsible for maintaining things like build scripts and database migrations, and being called on every five minutes to fix the dev system of the front end developer working on your project, who probably caused their problem in the first place. On top of that, you often have to wait for that same front end developer to get on and give you some front end before you can properly check that your website is working correctly.

As a front end developer, I genuinely sympathise, so here's my thoughts on the best way to work on front end when the front end isn't ready yet.

Much of this guide is written based on the assumption that the work is carried out in a particular way, i.e. that once briefed, both sets of developers get to work independently on their side of the site and at some point the front end developer is given access to the templates to start inserting markup. If you have a wildly different approach to that then some of these points may be less relevant to you, but there should still be some points of value in here.

Talk at the start

This is the most obvious but surprisingly overlooked tactic for ensuring a smooth connection between front end and backend - talk about it before you start, decide what the approach will be and who will be responsible for what. Quite often this conversation hinges around JavaScript - is it back end's job, or front end? It helps to have a vague idea before you begin work.

Just wrap stuff in divs

This is hopefully self explanatory. There's no point in wasting effort writing markup that's going to be completely changed anyway - if you want to see things clearly on a page just wrap them in separate DIV elements.

Don't add any classes

I've only seen this rarely - backend developers adding in classes that don't do anything, perhaps as some kind of indication of what content they wrap. This will just confuse the front end dev. If a class doesn't do anything, don't put it in. If it's there to be used as a JavaScript hook, use this convention for JavaScript and classes (or something like it).

Don't use inline styles

This isn't a problem at the start of a project but more later on once some front end is present. Inline styles break class inheritance and fragment the CSS. If you really need to change how something looks quickly, go ahead and use inline styles, but notify front end when you do it so they can move those styles into the right place.

Only use an ID once

Some backend developers get this, and some don't care, because it isn't really their problem. Sometimes this just happens because template code gets reused on a page where it wasn't originally expected. IDs should only be added to elements if they actually do something - such as a JavaScript hook or jump link - and duplicating an ID on a page breaks validation.

Comment your code, particularly JavaScript

If your organisation has a policy regarding code documentation then great. If it doesn't, it's good practice to put a minimal amount of code commenting in place, if only so you don't have to explain to front end what it's there for. This mainly applies for code they'll be working with, like JavaScript.

Don't put markup in code

Markup belongs in templates, not in JavaScript, PHP, Python, or anything else. It just makes it harder for the front end dev to find and modify. Occasionally, there are valid reasons for putting small bits of markup into code, but these are rare.

It's also good to expose markup where possible, or provide training or guidance to front end as to how this can be accomplished. The classic example of this is forms in django templates. Outputting a checkout form as form.as_table might be fine, until the design calls for one of those form elements to have credit card icons alongside them.

Avoid presentational JavaScript

There's a fine line between what JavaScript should be written by backend, and what should be written by front. Often that line will vary depending on the developers. Generally though, if a popup needs to fade in gently or a menu needs to slide out in a funky manner, don't worry about it, leave it to front end.

Stick to what was agreed

Often a site will need some kind of plugin to accomplish a task and that plugin will be needed early in development - for example, to display a graph. Even if this is needed urgently, consult with front end first. They may or may not be happy with your choice of plugin or library, but they'll need to be the ones to decide - it'll end up being their job to support/maintain/develop it.

Put all the JavaScript in one place

This is really a wider point that needs to be agreed upon from the start. Code should be organised and laid out cleanly, including where the files are kept. JavaScript should preferably be in .js files, rather than templates, and it should be organised in a logical way. Again, an early conversation with the whole team is a good idea here.

If in doubt, ask

I can't speak for every front end developer, but I'm more than happy to provide front end advice to a backend developer. Communication is brilliant.

Failing that, any half decent front end dev should have provided a styleguide for the site that should help you to find the right markup and classes that you need.

Advice to front end

Most of this article has been directed at backend developers, but this part is for the front end devs. Build a styleguide. Not just a simple page showing some of the elements in place. Not just a list of classes that can be used in some circumstances. A complete, clearly laid out, simply explained, detail of the whole of the front end.

Think about your styleguide as a toolbox, one that can be used by other developers to quickly and easily assemble new pages based on existing styles. Does a form need building? The 'forms' section of the styleguide should contain everything anyone could ever need to know about putting together forms on this site. A good styleguide isn't just a useful asset, it's an essential part of building front end.


This article is tagged with