Recently I spoke at the Sitecore User Group at Kagool’s Manchester Office. The topic I covered was based on my experience as a Sitecore front-end developer.
This is the first of a three-part series covering the difference between how front-end developers traditionally work with Sitecore compared with how our front-end team work.
Traditional Front-end Workflow
Development Environment Setup
This normally involves developers agreeing a tool to use on a project. For example, your setup may include:-
- Webpack to bundle and manage package dependencies
- Gulp or Grunt to automate all your tasks
- Adding a pre-processor such as SASS or LESS
- Agreeing a folder structure for the whole team (this varies a lot
- Set up a localhost server to develop to using some NPM modules such as local node server or webpacks dev server
All of these are great tools. The way you set up the front-end environment doesn’t really matter as long as it is consistent for the team and everyone adheres to the same coding standards.
This is great stuff and within our team we use nearly the same tooling and technology. However, I find this traditional setup leads to working in isolation and does not give a great deal of thought for the back-end team. This is where we do things a little differently, as I’ll explain later.
Setup Source Control Repository
In recent months I’ve seen front-end developers add their project code base to a different source control repository.This feels a little strange for me and you might ask why?
I’ve worked on adoption projects where the front-end assets had been source controlled in two different applications; Stash for the front-end application and BitBucket for the back-end application. A lot of the front-end application became out of sync with the back-end application, which can cause issues. Quick bug fixes carried out in the back-end application didn’t make their way into the front-end, resulting in a big mess.
Passing Front-end Assets to the Back-end Application
Pretty self explanatory this one; front-end development is completed and the assets are compiled, then passed over to the back-end application ready to be plumbed into Sitecore renderings.
This way of working can sometimes be troublesome. For example:
- Converting static HTML into Sitecore renderings results in doubling up of code contributes to an increased chance of bugs such as CSS selectors missing, causing styling issues
- Unknown technology limitations between front-end and back-end
- Difficulty working towards and understanding the HELIX principles
These are just some of the few issues I’ve seen.
How does a traditional front-end development setup handle bugs in terms of Sitecore?
From experience working with inherited projects where front-end development didn’t consider Sitecore and Sitecore best practices, avoidable bugs were raised. The usual response I found whenever this happened was “it works in the node application” or “it works on my machine”. Some of my colleagues experienced this first hand and it was really frustrating to manage and help diagnose or replicate a bug.
Traditional Front-end Workflow Benefits and Disadvantages
- Code can be started straight away
- Setup time is minimal
- No dependencies on databases or servers
- Speedy development
- Working in isolation
- No collaboration between the front-end and back-end developers
- Unable to develop for Experience Editor
Sitecore Front-end Workflow
So how do we work differently in Sitecore?
Front-end Workflow In The Same Solution As The Back-end
Our front-end team work in the same solution as the back-end developers, using Visual Studio. We set up our automated task runners and configure this with a handy plugin “Task Runner Explorer” (which is built into Visual Studio) to allow our back-end team to run commands from Visual Studio if required. This promotes collaboration between the teams, knowledge sharing and it’s all done from one location.
Code reviews are carried out regardless of technology stack, encouraging cross skilling.
Exposure to additional languages not traditionally associated with front-end development has made me appreciate other disciplines, and gone are the days that a front-end developer is just seen as someone who “colours in”.
Personally, this has definitely helped me become a better programmer and reason about my code differently.
Write HTML in .cshtml files
Writing HTML directly into a .cshtml file has the reduced risks of missed selectors, converting static HTML into Sitecore view rendering is a thing of the past and there is one single source of truth for each file. Workflow in general feels really smooth.
As the lines between front-end and back-end slowly become blurred, exposing front-end developers to Razor and Sitecore syntax (e.g. @Html.Sitecore().Field(”My field”)) is something I see as a positive change. This gives me the satisfaction of being able to complete a task end-to-end.
Working in Sitecore as a Front-end developer
We don’t shy away from getting stuck into Sitecore and understanding what Sitecore is and does. I won’t cover to much on this topic as part two will have more in-depth details of our ways of working and why.
Bugs becomes simpler to replicate and diagnose because of our way of working, especially if we use tools such as TDS to make sure all our local content is in sync with the live database. Because of this our front-end support tickets are very few and far between, which is great!
Sitecore Front-end Workflow Benefits and Disadvantages
- Once setup you don’t need to setup anything else again
- Single source of truth for all files
- Compiling Front-end assets carried out in one location
- Back-end don’t require front-end to run compiler tasks
- Initial setup takes longer
- Knowledge of Sitecore required
- Learning additional languages not normally covered by front-end developers (this is optional)
Having front-end developers fully exposed to Sitecore and working closely with the back-end developers has helped my fellow front-enders and I become better programmers; we reason about our code more logically.
Personally exposure to back-end languages has allowed me to “spread my wings” slightly and resulted in the ability to take on more responsibilities as well as being able to complete a task end-to-end for all disciplines.
This first blog post in the series gives insight (I hope) to a different front-end workflow for Sitecore. The series will cover overall:-
- Part 1 – Front-end Workflow
- Part 2 – Sitecore Knowledge
- Part 3 – Frameworks and Sitecore
I hope you enjoyed reading this blog post and got a glimpse into how we work as front-end developers within Sitecore. Thanks for reading and happy coding.