Developing a modern website or web application from the ground up has become monotonously complicated. The quality and power of the web has increased dramatically over the last few years, but in doing so, it has caused fragmentation and confusion for the front-end development community.

Background

That being said, I’ve always been a great admirer of Addy Osmani’s work with web development automation and tooling. I prefer automating any command I have to execute more than once or any task that requires repetitive labour. Humans make mistakes. Machines don’t.

Trying to develop for the web today is hectic — our tooling landscape is getting more complex. Time is a key factor in staying productive, so automate repetitive tasks to stay effective. Automation isn’t about being lazy, it’s about being efficient. ~ Addy Osmani, Automating Front-End Workflow

I first got involved in automating web development when Yeoman was becoming popular. I started using and working on it because I believed in its purpose — focusing on making web development as efficient and structured as possible using the best practices that have evolved in the industry. Since its initial release, Yeoman has evolved at so many different levels, creating a community of followers and contributors along the way.

While Yeoman is still a project I enjoy using and contributing to, I’ve come to realise that it doesn’t perfectly suit my workflow due to it’s opinionated structure. As such, I decided to build my own automation tool. It’s not a replacement for Yeoman, nor a competitor. It’s simply an alternative, a tool that supports the way I like to work and develop my websites.

Forethoughts

The way we create and build scalable web sites and applications change with the workflow of the languages and frameworks we use. Ruby manages its dependencies via the Gemfile and Bundler, Node.js has NPM, the front-end community has Bower and PHP has Composer. Therefore, the question is not “How can we make things easier?”, but rather “How can we best put these existing tools to use?”

I think we’re seeing the emphasis shift from valuing trivia to valuing tools. ~ Rebecca Murphey, A Baseline for Front-End Developers

Over time, we’ve accumulated strategies and code to help us deal with these problems: boilerplates, frameworks, unit testing scaffolds, documentation, performance optimisation and version control to name a few. But with all these emerging technologies, how are we expected to keep up whilst creating web applications with the knowledge we have now?

Lestrade

Technically speaking, Lestrade is a fully-featured, pure-JS web scaffold complete with deployment automation, package management and a robust file structure. It’s used for creating efficient and scalable websites by handling all the repetitive work for you, allowing you to focus on the code rather than the trivia.

Robust boilerplate

As I’ve discussed in my article on Supercharging your HTML boilerplate’s metadata, I’m fairly enthusiastic about robust metadata and I wanted Lestrade to encourage this attitude. As such, Lestrade comes loaded with my boilerplate gist by default. If you’re into something lighter like the HTML5 Boilerplate, it’s fairly easy to swap out.

Website-focused

Lestrade was developed specifically as a website scaffolding tool as opposed to Yeoman’s focus on single-page web applications. I feel like the way we build and deploy websites has been disregarded due to a stronger focus on complex applications, so I wanted a scaffolding tool that brought consistency and power to front-end website developers.

Pre-processing

I had a few principal focuses in mind for Lestrade when I was building it. Firstly, I wanted to pre-process everything — templates, styles and scripts — out of the box. Templates (HTML) would be written in Jade, styles would be written in Less and maintained with Recess and scripts would be written in Coffeescript and maintained with Coffeelint. With everything pre-processed and compiled for you, it’s so much easier to write clean, commented source code without being concerned with compression.

Purely Javascript

If you’re familiar with these languages, you’ll notice a common theme which brings us to the second focus. Yeoman prides itself with processing stylesheets in Sass, a good choice as it’s been called “the most mature, stable, and powerful professional grade CSS extension language in the world”. I like writing Sass, but I wanted my automation tool to process everything entirely with Javascript — even the Javascript.

Powerful pre-configuration

Yeoman’s principles lie with its core features — an opinionated workflow defined by the best practices that have evolved in the industry. Each time I produced a Yeoman scaffold, I ended up adding the same “experimental” plugins to its configuration such as unused CSS removal and image resizing. Lestrade comes with these bleeding-edge tasks pre-configured. As these plugins evolve, Lestrade becomes more stable and robust. It even generates a sitemap for you!

Pagespeed-focused

I’ve spent a good portion of my web development research studying methods for faster rendering and page speed, specifically from Google’s Pagespeed documentation and Yahoo’s YSlow rules. Lestrade focuses on massively compressing stylesheets, scripts, templates and images to give you a deployment build that really kicks ass.

Simplicity and efficiency

It took me a great deal of time to learn the inner workings of the Gruntfile for Yeoman’s webapp generator. While there are a few issues I have with Grunt, such as its I/O nature (necessity to read and write intermediary files to the disk) and verbose configuration, it’s generally a great task runner. However, I decided to build Lestrade on Gulp for three reasons: simpler configuration for developers, memory-based file manipulation and natively asynchronous processing.

What’s next?

As developers, we should always be looking for ways to do things more efficiently and effectively. A successful front-end web developer embraces his preferred workflow, but is always open-minded and willing to try new methods. As a community, we’re coming to understand and appreciate the true value of automation and as such, our most important question is “How can we manage all this better?”. For example, should we focus on:

• Developing un-opinionated or opinionated workflows?
• Improving editor functionality or offloading everything to task runners?
• Creating editor-oriented workflows (tasks designed for text editors)?

3 years ago we didn’t have the kind of tooling support for front-end development that we do nowadays. It was more about knowing the differences between browser compatibility issues. Now we’re able to work directly with tools that handle that trivia for us and we’re to operate focusing on what’s unique about our app. ~ Paul Irish, Workflow and Tooling for Front-End Developers

It’s important to remember that there’s no “best workflow”. Rather than duplicate someone else’s development environment, try to find or build one that suits you and supports the way you like to work. The concept of automating the web development workflow is a continuously evolving idea and new tools are being developed every day to support every area of the development environment.

While Lestrade will always be in development, it’s at production quality now. Feel free to learn from and contribute to the repository:

https://github.com/haydenbleasel/lestrade