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.
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.
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.
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
- 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.
- Prefer source files broken down into logical separate files/folders.
- Obviously cannot read minified, mangled code.
- Can only read straight CSS
- Have a myriad of browser-prefixed features
- 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
- 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.
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.
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.
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.