Separate Rendering Sass From Non-Rendering Sass

I don’t always render CSS, but when I do, I keep it all in one spot.

The State of Libsass (versus Ruby Sass)

January 29, 2014

Libsass is a C++ re-implementation of the Ruby-based Sass compiler. It’s an order of magnitude faster than Ruby Sass, but hasn’t seen as much adoption yet.

I recently asked Aaron Leung, the current maintainer, about the state of libsass. He kindly agreed to let me publish his response, rendered below. Shout-out to his employer Moovweb, who, Aaron lets me know, have been paying him to work on libsass.

Hi Jo,
I appreciate your interest in LibSass! It’s been very stable – the company I work for uses it internally in our SDK and build server, and it’s been running fine. Unfortunately, in terms of features, it hasn’t fully caught up with the Ruby implementation yet. The biggest deficiency right now is that @extend isn’t fully functional – LibSass works correctly for more basic uses of @extend, but a full implementation is still 2-3 months out (it’s a very complex feature).
Off the top of my head, other incompatibilities include:
* no 3.3 features yet
* full UTF-8 support is in the works (hopefully will be done in a week or two)
* @media blocks are following the scoping rules of pre-3.2 Sass
* limited support for the new CSS filter functions
* not properly handling namespaced selectors
In addition to those, there are miscellaneous little bugs that cause LibSass to generate incorrect output, mostly in obscure edge-casey stuff. However, thanks to a recent spike in community interest, I’ve been working harder to get all these things sorted out, and my employer is also interested in seeing LibSass become every bit as good as the Ruby version. Thanks to all that, as well as taking a closer look at the Ruby code, I’m hoping to get completely caught up with the Ruby version by mid-summer.
Hope this helps, and let me know if you have any more questions!
Aaron

He adds:

I should also let you know that we’re working on a more detailed feature/compatibility grid. More generally, we’re trying to be better about staying in touch with the community this year (via blog posts, talks at conferences & meetups, etc), so I’ll try to keep you apprised of any LibSass progress.

P.S. Keep in mind that the “mid-summer 2014” estimate above was given in private email to me, and is not an official commitment on anyone’s part. ;-)

Discuss on Twitter

[…]

Using BETWEEN for SQL comparisons

November 14, 2009

Recently, Carlos, suggested that I should start sharing some basic SQL tips that help with performance and/or general usage. I recently came across some code that I didn’t like to read and/or write. For example, let’s take the following…


SELECT * FROM brochures WHERE published_at <= now() AND archived_at >= now()

Essentially, this is pulling back some data WHERE the the brochures are considered published. (We have a project that allows people to manage their brochure launch dates ahead of time.) In fact, in this project, we have no less than 6-8 dates in the database that we’re comparing data on and it’s easy to get lost in the logic when trying to understand it.

Now, there isn’t anything inheriently wrong with how this condition is constuctued. As a matter of personal taste, I find it annoying to mentally parse. Also, I find having to write now() more than once in a WHERE clause to feel like I’m repeating myself.

Read it outloud…

“WHERE the brochures published at date is less than and/or equal to right now AND the archived date is greater than and/or equal to now.”

Who talks like that?

Luckily, there is a better and in my opinion, a more readable way to express this is with the BETWEEN construct in SQL. (postgresql docs, mysql docs)


SELECT * FROM brochures WHERE now() BETWEEN published_at AND archived_at

Let’s read this outloud…

“WHERE the current date is between the published at and archived at dates.”

This sounds more natural to me.

Additionally, you can also do the inverse with NOT.


SELECT ... WHERE now() NOT BETWEEN brochures.published_at AND brochures.archive_at

Remember kids, “code is for humans first and computers second.”—Martin Fowler

[…]

The Ruby Rails Aggregator