I first learned about Yeoman back in June of this year, when Paul Irish showed it off at Google I/O.

Yeoman was officially released on September 10th.

According to its web site:

Yeoman is a robust and opinionated client-side stack, comprised of tools and frameworks that can help developers quickly build beautiful web applications. We take care of providing everything needed to get started without any of the normal headaches associated with a manual setup.

This post will not be a “getting started with Yeoman” guide because there are already other great posts that cover that. Rather, I just wanted to express some thoughts about the tool. I’ve done some basic tinkering with it but haven’t yet started using it for a real project, hence the title “Yeoman in Theory”. Well, that, and the fact that “Yeoman in Theory” seemed to have a good ring to it.

Installation

Based on the sheer magnitude of Yeoman’s promised capabilities, I wasn’t sure what to expect as far as its install process was concerned. “Single-line installs” are commonplace for many software tools today, and at first glance, Yeoman’s install process seems to fit that pattern.

In general, I have mixed feelings about single-line installers. To make something appear outwardly simple can involve hiding a lot of internal complexity, which is true across many disciplines including creating software. In the case of a software installer–especially if the software has lots of dependencies like Yeoman does–I would prefer to be exposed to the complexity.

Maybe that seems counter-intuitive, but I want to know exactly how installing a piece of software will modify or affect my computer. That information is valuable to me for a few reasons:

• It’s useful for debugging any problems with the software itself.
• It’s useful for debugging any problems the software may cause with the operating system or other software in the future.
• It’s useful for knowing how to completely remove the software since many uninstallers leave traces of the software behind, if an uninstaller is included at all.

I installed Yeoman on my office Mac using the single-line install the day it was released. While installing, I was prompted for my root password several times, but there was never any indication of why it was necessary. What needed root access in order to be installed? How could I troubleshoot or remove it in the future if I didn’t know what it was? I had to reactively guess what was being installed by watching the output on the screen after providing the password, which left me feeling uncomfortable. I realize that I could have read the install script before running it to see what would have required root access, but this should not have been necessary; the installer should have made its intentions clear on its own without requiring the user research them.

Apparently I wasn’t the only person that felt that way because a few short days later, I was pleased to see that the single-line install was abandoned in favor of an audit script. The script doesn’t actually install anything. Rather, it tells users which dependencies they should install on their own before installing Yeoman itself via npm.

In my opinion, the audit script is a vast improvement over the previous install script. It’s true that there is less hand-holding than before and the install process could potentially take more time and research. However, users are directly exposed to some of Yeoman’s dependencies so they’ll know where to look if things go wrong, and they get a better idea of what is actually getting installed on their systems.

Yeoman’s intended users are likely to have previously installed many of its dependencies. I decided to install Yeoman on my personal Mac, this time utilizing the audit script. I was delighted to find out that I already had all of the necessary dependencies installed except for a single Homebrew package. Root access was not required to complete the installation.

A Humble Servant

Immediately after installing Yeoman and initializing my first project, I had feelings of excitement mixed with apprehension.

Getting a project up and running was incredibly quick and easy, just as promised. It’s quite impressive and exiciting to see in action for the first time: Woah, it just did all of that for me?

At the same time, I felt apprehensive for the same reasons that I was uncomfortable with the old install script. The entire purpose of Yeoman is to simplify or even remove the more tedious parts of web development. Through a single command-line interface, it acts a package manager, build system, and testing environment all at once. So, it hides complexity. Seem familiar?

Intended Users

Something I can’t quite pin down about Yeoman is the kind of developer it is intended for in terms of experience level. While Yeoman could certainly be used by new or less-experienced developers to quickly get a project up and running, I don’t know that they should use it. There’s great value in understanding how the many moving parts of a modern web application work together. For any type of software development, understanding as much of the system as possible helps developers write better, more testable and maintainable code. That understanding is also valuable for debugging problems when they inevitably happen. If a developer has never “manually” put together a web application on their own, they will have a superficial understanding of what Yeoman automates for (and hides from) them. They could potentially learn that all abstractions are leaky the hard way.

Any level of abstraction is a compromise. Too much abstraction hides too many details, while too little abstraction forces developers to repeatedly reinvent the wheel. Given that spectrum, I believe that Yeoman should be used by experienced developers who will have an awareness of exactly what is being automated for them.

Development Workflow

I was curious to see how Yeoman could fit into or affect a day-to-day development workflow. While I haven’t used it long enough have detailed answers, a few things occurred to me.

• It seems like Yeoman is great for collaborative/team development. It doesn’t appear to store any proprietary metadata in the project source tree, which should make Yeoman-based projects easy to work with inside revision control.
• Yeoman seems to hide just the right amount complexity by default for everyday tasks, but allows its layers of abstraction to be peeled back for less-frequent tasks. For example, Yeoman utilizes Bower for JavaScript package management. yeoman install jquery will add the latest version of jQuery to a project. Since Yeoman is using Bower behind the scenes to do this, you can use Bower’s syntax directly inside Yeoman (yeoman install jquery#1.8.0 will install that exact release of jQuery, if necessary.)
• For the amount of things it can do, Yeoman seems to have been implemented quite elegantly. That said, I’m worried about how future-proof it is. The sheer number of things it does and software components it depends on could mean that is has many potential points of failure. There’s a chance that upgrading NodeJS, npm/homebrew packages (and so on) could break Yeoman unexpectedly. Are developers left in the dark until Yeoman itself is updated, if they can’t figure out how to fix the problem on their own? Not entirely, since a Yeoman-based project is still just the source of a web application, and all of the tools Yeoman uses behind the scenes can still be used manually. But it would be frustrating to rely on Yeoman, inadvertently break it, and then have to live without it for a while.
• I don’t use Windows as my primary operating system, but Yeoman doesn’t officially support Windows yet. (As I understand it, there are some unofficial ways to get it working in Windows.) This might be a deal-breaker if a team wants to try using Yeoman but has developers who use Windows.

Wrapping Up

Although I’ve made some critical points about Yeoman in this post, I really love the idea behind it and admire its ambition. Tools that strive to remove any friction and tediousness from web development are exactly what web developers need in order to move the web forward.

I’m excited to see how Yeoman and its community will evolve over time, and can’t wait to utilize it for a real project.