Why bother with a CSS build process? | Hacker News Reader

Why bother with a CSS build process?

lucidchart.com

24 pointsenuncajon38 comments

1. You are exposing your source code to anyone who might be interested.

I think that exposing your CSS source code with comments etc is more beneficial than detrimental. It helps us have a more open web and fosters an environment for new developers to learn from what's already great.

However, the overhead of always sending down the full CSS probably isn't worth it since so few people are actually interested. http://daneden.me/max-css/ suggests including a .max version of your css alongside the .min for this very purpose, which I think is a great idea.

CSS source maps would also be a good solution.

This. If it weren't for sites exposing their sources I wouldn't have been able to teach myself what I know/tinker around when I was just a kid with a dream. This just seems excessive, and one of the employees's responses below about people who show their code not having good jobs seems exactly like the response I'd expect from someone with this mindset. Maybe I'm not understanding this concept, but I'm with Dan on this one; we should be using our code to teach others.

who needs reading a css file when you can inspect the rules in firebug and such, handpick them and even edit live? I can't remember when I opened one's css file from source.

If you're not checking their respective boxes in the inspector, you can miss certain states and pseudo selectors. I also try to add .less and .sass/.scss to the end of stylesheets just to see if the working file is on the server too, since it can be easier to read.

I disagree with the first point, the spirit of the web is to be open. The other points do make sense though.

On a side note, I'd really like to use LESS or an equivalent, but the way I design/develop (and I'm an admittedly bad designer) is to tweak things in CSS, alt-tab, refresh the browser, and see the changes instantly. Likewise I can open up Firebug and tweak some style to see how it would look, then apply that change to the CSS file directly. LESS/SASS would introduce a compilation step there and essentially break my workflow. Am I wrong or is there a way around that while still being able to use a more-sane language to sugar up CSS?

> essentially break my workflow

compass has a watcher who compiles a new css when you change your sass/scss (if you like to copy-paste css, choose the scss syntax over sass), less has a less.js to compile client-side during dev.

There are many tools that automate the compile step. I've used the "guard" Ruby gem, the built-in compass watcher, flat out built static sites in Rails which recompiles on demand, and played with JetBrains WebStorm which can even do some tricky live reloading stuff (cutting out both the compile and refresh browser steps). In the past I've also used emacs, which could be set up to have a key combination save and immediately compile.

Include less.js while developing and it will compile LESS on the fly [1]. Then you just have to compile/minify the LESS files into CSS when you build your project and push to the server.

[1] http://lesscss.org

This is the best way to do it.

It's pretty much the same workflow. I transitioned to this and found it pretty painless (no pun intended). Instead of changing CSS every time, you're changing your LESS stuff. Then, when you're ready to deploy, compile it and push it out.

Checkout GWT (Java... hiss, boo!). It's had automation of all of these best practices and more (inline images, data/urls, class obfuscation, classname compilation, minification/gzipping, browser specific permutations) since before any of these new CSS frameworks (LESS, SASS) existed. If you're already using Java, check it out.

To the refresh speed, with something like GWT these are only done on your final build, not during development. Certainly such a DevMode could be achieved in other frameworks as well. :)

Check out [1]codekit. It watches and automatically compiles your LESS/SASS on save and will even refresh your browser for you.

[1]: http://incident57.com/codekit/

The "edit styles" bookmarklet is a huge time saver. It's a live CSS editor. I usually tweak the styles in there then move them over to the CSS file when done.

Yeah, the first point is silly. It's trivial to run minified CSS through a prettifier. As for workflow, pretty much all the CSS meta languages have some sort of auto compiling upon modification and you can skip the alt-tab (assuming you've got enough monitor space to see the browser window and your editor - and if you don't, you should fix that) and refresh by using LiveReload. As for tweaking the styles in the browser, never really understood that, but Chrome has (experimental) support for Sass source maps so you can see where the styles came from in the Sass file directly.

Stylus also has a --watch flag and will rebuild on the fly.

You might want to check out yeoman, which can run a LiveReload server to auto-refresh the page you're working on, in addition to sass. http://yeoman.io/

I use LESS a lot; with my dual monitor setup I have my IDE on the the left and the browser on the right. If you add #!watch to the end of the url and refresh the page, it will poll any LESS file linked in the page once a second and display changes without needing a refresh.

People who are actually concerned about exposing their amazing Javascript and CSS to the world probably don't have very amazing code to begin with.

People who aren't concerned about exposing their amazing Javascript and CSS to the world probably don't have very amazing jobs to begin with.

That's a pretty bold (and borderline offensive) statement. You're effectively thumbing your nose at anyone who develops open source projects and even more so, anyone who subscribes to a philosophy of the open-nature of the web.

I think you're taking my tongue-in-cheek reply to a troll a wee bit too seriously :-) We love open source at Lucidchart and employ a lot of people who contribute in meaningful ways to a variety of open-source projects.

What makes the original post not tongue-in-cheek, and your reply not a troll? Telepathy?

Then what was your explanation behind your previous statement?

Might be that the poster had no previous posting or commenting history.

That's pretty big talk coming from someone whose site has ~250 !important declarations in their CSS on a single page, and had to use a jQuery plugin to handle cookies (lol). If working there is an "amazing job" then I'm on a pretty awesome level.

I'm not sure how well you can really obscure it anyway. Anyone who knows what they're doing can still get at the source.

Is it just me, or is this image solution overkill? I'm curious, how is introducing this complexity to the build process better than just using a sprite? SASS + Compass automatic sprite generation kind of solves the problem for you (not a SASS vs LESS flame, just an example).

I took a peak at your website's source, and it's strange that you micro-optimize the image while at the same time you have 6 separate uncompressed js files and you didn't bother to serve your assets from a separate cookie-less domain. What's the reasoning here?

btw since when is exposing CSS a problem? I don't get what OP means in that point.

We do use sprite sheets for almost all of the icon-sized images (there are hundreds) in the application. And those sprite sheets are big enough to not get inlined in the CSS. The images that do get inlined are generally odd-sized--though I suppose that automatically generated sprite sheets could manage that for us as well.

Exposing CSS is much less of an issue than exposing Javascript; that list was speaking about JS and CSS generally ("why a build process"). The post goes on to describe why CSS specifically is worth paying attention to.

Way to edit your post when I was midway through responding :-)

We're relatively unconcerned about our website's (home page) source. Our actual application can be seen at https://www.lucidchart.com/demo. There you'll see a single large Javascript file served from Cloudfront, plus a few third-party-hosted files that we couldn't reasonably CDN (like Google Analytics and some other third-party APIs). There are also three CSS files. One is the bulk of the data (194KB over the wire) which is sent over the CDN. Then there is a separate file for jQuery UI (which will soon be removed) and one that is shared CSS with other parts of our app.

> We're relatively unconcerned about our website's (home page) source. Our actual application can be seen at https://www.lucidchart.com/demo. There you'll see a single large Javascript file served from Cloudfront

oh, ok. now it's not so weird :)

Another way to cut down on overhead is in the php for loops. If the page has many images to load, the size of the array will be large and sizeof() will be called every iteration of the loop. Instead, use for($m = 0, $mm = sizeof(array); $m < $mm; $m++), or set a variable to the size of the array before the loop. This way, the sizeof() method is only called once. http://php.net/manual/en/function.sizeof.php

SASS, imo, is a much more mature and interoperable language.

Compare

.mixin (@a) when (lightness(@a) >= 50%) {

   display: none;

}

@if $boolean

    @debug "$boolean is #{$boolean}"

    display: block

  @else

    @debug "$boolean is #{$boolean}"

    display: none

Note, also, that there's a logger.

How are these two code samples related to each other? They appear to be for completely different use cases, and therefore I'm not sure that they actually demonstrate anything useful.

They are illustrations of two forms of IF statements. One is very weird and hard to use, and the other is... standard.

CSS so complex you need a <strike>compiler</strike> translator (these things aren't compilers) is doing CSS wrong.

I think this ignores the other benefits of things like LESS, SASS, etc. For instance, the variable notion for css. Now a change to a named color requires a single place of change - the definition of that color, not each and every place it is used. Similarly, any place you have to have a half a dozen -browser-specific-properties can be replaced with a single "function". These are nice features.

CSS has a mechanism for defining rules in such a way to abrogate the need for variables. I see far too many people using CSS classes to refer to one or only a handful of things, by a strict hierarchy of the layout of their page. In that case, you're almost always going to run into problems with extremely verbose CSS that repeats itself. But it's completely wrong, it's not how CSS is supposed to be done.

If you need a bunch of objects to, say, have the same background color, that's why you can chain selectors. Your common background color would then only be defined in one place.

CSS doesn't have to be complex to get complex results. I would call a CSS file any longer than 200 lines a bad code smell.

As for browser-specific rules, in my mind they just plain don't exist. Add in an intelligent reset rule-set at the beginning of the file (and no, not one that destroys the margin, padding, and display rules of every single element, but only resets things as needed) then you can easily make completely cross-browser UIs.

trust me , using less makes CSS easier to maintain.

Reply on news.ycombinator.com