After talking about my post-Standard plans yesterday, I received several questions – some on Twitter, some via email – about my use of LESS rather than Sass since Sass is going into WordPress core.

It’s a good question, to be sure, and it’s one I’ve thought about since this ticket in Trac. Since I’ve been using LESS for over a year in various projects, I’ve had to decide how I want to move forward with development of those projects and future projects, as well.

Using Sass in WordPress

As far as I’m concerned, unless you’re committing to core, it’s not that big of a deal. That is to say that I don’t necessarily think that making the change in the middle of development, or updating your old projects to Sass is a high priority issue.

This is a big deal, right?

This is a big deal, right?

This isn’t to say that I don’t think it should be done for the sake of compatibility at some point, but just that it’s not something for which anyone should sound the alarm.

1. It’s All CSS

Unless you’re committing to core, I can’t think of a compelling reason to immediately move to Sass (or to Sass-up your existing styles) because it all reduces to CSS anyway, and that’s what is served to the browser.

Sure, there’s something to be said about being consistent – and believe me, I’m all for it – but you have to weigh the benefits of making the switch as it relates to your business or your product.

By that, I mean if switching to Sass means better adopting, more sales, or an easier time developing the project, then go for it; otherwise, why swap immediately?

2. Starting with LESS

For some of the things that I’ve slowly been working on, I started out using LESS and don’t feel a need to swap it over “just because.”  There’s no real benefit other than consistency that I would gain at this point.

  • The product isn’t going to be extended by other developers
  • I’ve yet to post the source online should anyone want to enhance it
  • There’s no direct benefit in finalizing 1.0.0 in using Sass over LESS

To that end, I’m more concerned with shipping the product than I am spending even more time retrofitting my CSS preprocessor.

3. Ship and Iterate, Ship and Iterate, …

If you’re working on a product that you hope to have a long lifespan (where long is a bit subjective, I guess), then you’re never really done developing it, right?

You just continue to iterate, meet milestones, and repeat.

To that end, why not build in a milestone for converting the CSS to Sass at some point during the product’s lifetime rather than dereail the entire development effort to swap something over than eventually just reduces to CSS, anyway?

Again, this is not to downplay the consistency factor, but for many products who have non-technical end-users, it doesn’t make a difference.

Ship, iterate, repeat.

But That’s Just Me

Of course, everyone has their opinion on how best to proceed with their work, their CSS preprocessor, and when and how it should be done.

And that’s awesome.

I’ve shared my thoughts above not to try to convince anyone that I have the approach (because I don’t), but because I’ve been asked the question enough such that I thought it might be interesting to share, and worth having something to which I can point others as they ask this question.

Over time, this post will likely become irrelevant, but – for now – it’s right in the middle of a transition than many of us in the WordPress development and design community are [considering] making.

Share:

Leave a Reply