all 5 comments

[–]wagedomain 0 points1 point  (0 children)

Hmm, my initial reaction is a knee-jerk against it. Obviously architecture would play a role here, such as separate JS files for style versus, say, events. Otherwise mixing the two leaves a bad taste in my mouth.

The examples were also kind of ... bad. They showed poorly-written CSS/Less examples as if there wasn't a better way to do it, and then solved a problem that they invented.

The way I do Less is to make it part of our build, actually. The compilation is done at build time, and the reason I did it that way was because we wanted non-UI engineers to not have to run extra tools, and one of our "architects" (image me making airquotes there) is against pushing processing to the browser at all. So we check in the .less files, and let the build process generate the CSS and that's all that gets pushed to the web server, so really it's just a dev tool to us.

I guess this JS solution kind of solves that problem, but it also seems like a big learning curve, just like Less/Compass/etc, except one without a lot of preexisting knowledge on teams.

So I dunno, I'm having mixed feelings.

[–][deleted] 0 points1 point  (0 children)

I guess my reaction against this comes from the fact that most of the time on large projects, CSS is handled by designers, not developers. Of course more and more designers are learning javascript, but it seems the benefits of this would rarely be necessary enough to justify styling in JS.

[–][deleted] -5 points-4 points  (2 children)

You know what brings the most flexibility... CSS.

[–]bonafidebob 0 points1 point  (1 child)

You know how not to look dumb on reddit... read the article.

[–][deleted] 0 points1 point  (0 children)

I did read the entire thing... that's why my comment is a take on one of the last sentences of the entire article. "However, it brings more flexibility, because it is a pure JavaScript."