Roots vs. Underscores

1

Hey all,

Firstly, let me start out by saying that I have really grown to love Roots and we use it for almost every website we make nowadays. I would assume many people on this forum are going to be in favor of the Roots theme but I’m wondering more so why. I’d like to get some general feedback on why I should continue to use Roots instead of Underscores: http://underscores.me/. I have heard good things about underscores and being that it’s an Automattic creation, I’m sure that the community will grow pretty quickly.

Thoughts?

1 Like
2

Underscores doesn’t use a build script, Bower, or a theme wrapper. Roots offers many advantages (in my opinion, which might be biased ;)):

  • more advanced workflow (write stylesheets with Sass or Less, automatically check JS for errors, optimize images, live reloading, quickly pull in 3rd party front-end packages)
  • stronger, more minimal markup (we’ve used ARIA roles and microformats since the beginning, don’t use id)
  • the theme wrapper is so much better

I think people mainly use Roots for the workflow benefits

6 Likes
3

I agree with everything Ben said, and yes I also have a bias towards Roots as well.

Personally, I really enjoy the workflow enhancements and it’s the main reason why I use Roots. Grunt/Gulp is already setup for me, so I can get right in there and start working. We also have code checking for JS, and on the 8.0.0 branch we have PHPCS working as well now :thumbsup:. I could go on and on but really Ben said a good amount.

Some more reasons:

  • Roots is also VERY well maintained. I think we close out issues and PRs faster than I’ve seen a lot of popular projects on Github, and not just WP ones.
  • I also love how it pushes me to be a better developer and learn more about new front end development tools, without me always having to write it from scratch. I wouldn’t have learned Grunt until later if Roots hadn’t used it and forced me to learn out to use it.
  • As far as I know, there is no forum of support dedicated to _s like we have for Roots.
  • More “freedom” - many _s devs are on the Theme Review team and want to keep it specifically simple for beginner devs or people who have never done theme dev before, I think that’s fine, but IMHO _s will always be tied down to that
  • We also probably have softer t-shirts :wink:

There are, of course, some points to using _s as well:

  • More “the WP way” - which I personally wouldn’t always say is a benefit, but for example they use WP coding standards (4 spaced tabs, etc) so another dev might be able to jump into it quicker or if you’re a purist it’s probably the closest you could get to what WP people might want
  • It’s the recommended starter theme if you want to put your theme on WP.org (not to say you can’t do it with Roots)
  • Easier learning curve Roots is not the first theme you should use, _s is a fine choice for that however.

If you already use Roots, I see no reason to switch unless there’s really a good reason, but again, that’s just my (biased) opinion. At the end of the day it’s about the tools that work for you and get the job done right. For me, one of those tools is Roots.

8 Likes
4

This x1000. Roots has helped me understand Grunt (and Gulp) on a much deeper level than if I’d just ventured into that world on my own. It’s even forced me to actually utilize the modularity of Bootstrap more effectively. I used to discount frameworks as being unnecessary overhead, but I didn’t really get them until I started using Bootstrap as it’s included in Roots.

Similar story for Bedrock and Bedrock-Ansible. Using these tools has helped to make me a sharper, more holistic developer. Plus, it’s fun.

8 Likes
5

I can tell you a little bit about why I like Roots and my experience working with Roots. Then perhaps I can expand a bit on the build process, since I am responsible for implementing almost all of the upcoming overhaul of it.

Also just as a clarification: The Roots Starter Theme is being renamed to Sage. So for this comment “Roots” is the organization and “Sage” is the upcoming 8.0.0 version of the formerly named “Roots Starter Theme”.

Why Roots and Sage?

My primary wheelhouse is building web applications, so for as far as all things WordPress I am usually am an outsider looking in. Even though I am usually working on “apps” 90% of the time, WordPress is definitely still a part of my world. The end-user/business benefits of using WordPress to run content and marketing sites that run alongside “apps” greatly outweigh any hemming and hawing about WordPress’s codebase or workflow. I am happy to contribute to the Roots org because rather than hemming and hawing these dudes actually sling code and show that it is possible to apply proper software engineering principles to WordPress development.

The Wrapper

So I will strongly posit that the wrapper is a good idea. Outside of WordPress land most all modern templating engines implement the concept of Template Inheritance. A good explanation of template inheritance is available here: twig docs. The Roots wrapper is a compromise between using a full templating engine like Twig and the default WordPress templating structure.

Here are some templating engines that implement the concept of template inheritance:

There are many many more but those are the ones I have actually used.

Template Inheritance is a good idea for wordpress specifically because it:

  • Keeps things DRY
  • By encouraging template reuse you can scale your different types of content while still providing a consistent user experience. Change something and have it cascade across all the different templates.
  • Encourages the separation of application logic from templates. You do not have to have templates with complex conditional statements to differentiate post types and such, just have separate template partials for each.

Professionally Maintained

At the time of writing this starter theme has over 5,000 stars, 500 watchers. In the past month there were 1,257 clones among 607 unique cloners. Despite all of that, issues are squashed extremely fast. There are only two open issues right now. The project maintainers communicate daily and are generally very accepting of feedback and improvements. In my use of roots it has been very stable.

Perfect amount of boilerplate

Sage helps you get started then gets out of the way. The different features are loosely coupled. For instance: I have been using gulp and Sass with Sage for the better half of last year. I just delete the gruntfile, delete the less, drop in my gulpfile, dropped in my Sass, good to go. I have some WordPress projects that don’t use Sage, but I can still grab lib/assets.php or any of those incredibly useful helpers to incorporate Sage features into non-Sage projects.

Why a Build Process?

For the upcoming 8.0.0 release I have done some pretty significant overhauling of the way the build process works.
See the pull request.

Why?

Modern Development Workflow

One of the central axioms of software development is “what is easy for humans to understand is difficult for computers to understand”. Having worked with MIPS and written non-trivial programs in MIPS assembly while pursuing my Computer Science degree: it gets hard as FUCK to write software the closer you get to the metal.

Front-enders are decently far from the metal but the axiom still applies. Few examples:

  • In General
    • Browsers
      • Prefer as few files as possible due to network overhead.
      • Prefers minified and mangled code because it increases the efficiency of gzip by reducing the distance between tokens.
    • Humans
      • Prefer source files broken down into logical separate files/folders.
      • Obviously cannot read minified, mangled code.
  • CSS
    • Browsers
      • Can only read straight CSS
      • Have a myriad of browser-prefixed features
    • Humans
      • Like programming language paradigms provided by CSS preprocessors such as variables, inheritance, functions, partials, loops.
      • Have trouble keeping track of and maintaining browser-prefixed features over time
  • JS
    • Browsers
      • Don’t have a package manager, module system, and don’t care. They just execute javascript in the order it is received.
    • Humans
      • Like to stand on the shoulders of others and use third-party libraries and tools. Package managers like bower allow one to manage a dependency graph easily.

Just like gcc compiles C source files to machine readable executables, web project build processes convert human maintainable source files into a package browsers will be happy with. Your users will thank you as well, since a happy browser means a speedy and smooth experience for your end-users.

Performance

As far as performance and best-practices I only deal with numbers and data. I appreciate and do follow certain subjective or trivial best-practices. However, the only important ones are the ones that are measurable. With the Sage build process and asset management you will see orders of magnitudes of difference in page load time compared to non-optimized assets.

The Sage build process implements a bunch of best-practices. A handful of which are:

When 8.0.0 is ready I am absolutely going to formally benchmark Sage so we have hard numbers. However having used a similar build process in Sage and other projects the performance benefits are obvious.

How?

You can follow our progress at: https://github.com/roots/roots/pull/1251

The annotated gulpfile.js explains exactly what each step does. Here is what it looks like at the time of writing but I would encourage peeping the PR and reading the latest.

Conclusion

The Roots org and Sage stays in touch with how the world works outside of WordPress land. WordPress is an incredibly useful tool, but it is an uphill battle trying to apply modern development practices to it. The Roots org and the Sage starter theme bridges the gap between the business benefit of WordPress and the status quo of web development. Stay tuned for the 8.0.0 release. Definitely would appreciate any feedback or questions.

19 Likes
6

Thanks everyone for the detailed response. I deffinetly have enough reasons to not have to ask any questions like this again – for a while at least :slight_smile:

7

This post alone @austin makes me want to follow through on buying you that beer. We should meet up soon.

All I want to echo is what the other guys have said. We currently build all WP based projects here with roots and have done so for the past year. Roots is what really pushed my team to embrace grunt and now gulp. We are really excited to push Sage in 2015, and will be glad to do what I can to make this a big year for Roots org and Sage.

2 Likes