Ryan Doll

View Original

Jaded

HTML template engines really challenge my beliefs about the current state of build processes for client-side development. They do simplify building static sites, and help you reduce repetitive HTML throughout your codebase. However, I have a hard time recommending using one all the time because it feels like it adds one more layer to an already growing front end stack. In my mind, HTML is pretty simple enough, so why would we need to complicate things by adding in one more thing? It seems like there is a new tool every week for Gulp or Grunt that developers can't wait to add to a project.

My overall decision on HTML template engines: larger projects with multiple developers can definately benefit by using them. Choosing the right one really depends on your project, as well as the learning curve it might add for the team. I recently had to seriously evaluate the use of Jade on a project, and determine if it would be the right fit for the task.

I coach a few developers at my job who use Jade daily, and always sing it's praise. However, I have always had on main problem with Jade...the syntax. While I could see their point of it enabling you to write less code, using Emmet within your editor of choice made writing HTML easy enough to not warrant a HTML template engine for syntax alone. By not knowing all the benefits of using it, and only focusing on the syntax, I never could warm up to Jade like they could. I figured I would never end up recommending it on any project.

A few weeks back, I started architecting a project at work for a pure client-side piece that would need to be very flexible and modular for future use within a CMS. Knowing that I would already be recommending Gulp as the task runner for the build, I was planning on using Assemble to build out our templates for the site. I had used it earlier in the year with great success. The only downside was that the Gulp plugin for it was currently in alpha, and given the status and rapid speed the project would be iterating at, I couldn't take the risk of an alpha plugin being a part of the build.

After digging around for some other ways of including Assemble into the project, I knew I would have to really start coming to grips that Jade would be the best candidate for the task. It came down to a few points that, given the project, would heavily influence my decision.

Breaking out reusable sections of client-side code is a must for this project. For instance, using a CSS preprocessor like SASS to build mixins for CSS styling is an easy way to keep styles clean and reusable. It is the Extract Method refactoring method that all developers should be using daily when writing code. HTML can also take advantage of this same principle when using Jade mixins and templates. Client-side developers can easily create reusable components for use throughout an entire site. Changing one small Jade template would implement a change across multiple static pages. Later on in phase two, this would not be an issue because the individual components built would be rendered via a server-side CMS. But for phase one, this would be key for the static only site.

Having a team working efficiently during tight deadlines is vital for my company. My team was already very comfortable with Jade, and by letting them continue to work with a toolset they preferred, I would not be hindering their development speed. I had already made a few architectural decisions that were not part of this team's normal workflow, so adding in another change was a risk I was willing to make if the technology itself was worth it. Jade seemed like a win-win: My team would be able to work quickly with a tool they were used to, and the architecture of the build would be solid. Regardless of my initial thoughts, Jade was a solid choice for the project, and I am glad I didn't try to reason my team away from it based on my original disdain on the syntax alone.

One thing to remember using these kind of tools in your workflow: Don't forget to document your templating process/folder structure. Teams that are used to working with a framework like Jade should start documenting mixins and creating an agreed upon style guide. In this project's case, we will be handing over the build process to another team to possibly implement down the road. By documenting what functionality exists within the templates, the learning curve can be reduced for the new team.

Take Jade for a spin in your project, and let me know your thoughts. There are other libraries out there like it to consider (Assemble being the other one I enjoy). Regardless of which you use, learn to take advantage of them for your static site builds.