While at Umbraco UK Festival 2013, developer Matt Brailsford spoke about bridging the divide (a metaphor for the handover of HTML by front end developers to be integrated by back end developers) in the digital workplace.

As a front end developer, this got me thinking (dangerous I know)... how much back end should a front end developer need to know?

How front end developers are currently working

Matt correctly identified that there are probably two areas that a front end developer currently gets involved:

• HTML and CSS only: all site files (such as HTML, CSS and JavaScript) are created beforehand and are passed to the back end developer to integrate with his code. The site is not dynamic and is usually developed using flat HTML, which makes changes later on very difficult to track and integrate.
• Full access: the front end developer works within the server-side environment. They have access to the same functionality and data as the back end developer. Matt comically describes this as introducing the front end developer to the "dark side" of coding.

I really enjoyed Matt's potential solution; using the Liquid Templating Language with Mixture.io (and as a rendering engine in Umbraco), both the front end developer and the back end developer can work in the same language.

Onus is on the back end developer to then provide the data in the same JSON format that the front end developer has been using for his/her templates.

View Matt's slides online.

We develop alongside each other ("dark side")

I like working in the "dark side" as suggested above, but that doesn't mean Matt's approach is not going to work for you and your digital workplace.

At Gibe, we work together in the same files, using the same server-side technology (usually ASP.NET in Umbraco MVC), sharing the same data and the same availability of the data.

It is important that front end developers work within back end environment in Gibe for the following reasons:

• Build once: the front end developer can create templates directly into the system, so the back end developer doesn't have to handle them or break them in the transition process.
• Speed: it is generally quicker for front end developers to markup loops, conditional information and other basic server-side techniques directly with live or sample data.
• Ongoing maintenance: if the design changes, the front end developer can usually build directly into the server-side templates to reduce the back end developer revisiting the template.
• Better communication: by working together in this way, we are constantly communicating between each other about how we should or could develop a template.
• Reduced dependency: the front end developers are less likely to have to wait for a back end developer to start developing the data required for a template.
• Continuous development: the front end developer can continue to develop even if no template has data available - we can build our dummy HTML mockups within the empty template, ready to be plugged in by a back end developer.
• Great for small teams: sometimes back end developers can be swamped, especially within smaller teams. At Gibe, we all pull together to complete projects and front end development sometimes has more availability in our project timeline.
• Existing knowledge: generally, the front end developer will be familiar with loops, conditional statements and more from using JavaScript or similar. There would be no reason not to trust a front end developer in a server-side language with the same responsibility.

This approach only works when the front end developer knows his/her limitations. Especially with more complex requirements. But communication and close-working between developers should help outline who can do what and by when.

I have to admit, I do understand quite a bit of the ASP.NET/Umbraco MVC environment and I am comfortable with how to use the code correctly and efficiently.

I wouldn't dream of attempting something I don't understand, so it is in Gibe's interest that I can help our team out, reducing the work of back end developers playing with HTML markup.

Thinking

Matt's talk really got me thinking if we can improve how we work, and although using Liquid for HTML and as an Umbraco MVC rendering engine is not our ideal solution, we will continue to improve how we work together, bridging the front end/back end divide.

Many thanks to Matt Brailsford for a great talk!