
Why bother with a CSS build process? - enuncajon
https://www.lucidchart.com/blog/2013/02/05/our-css-build-process/
======
stringham
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.

~~~
zalew
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.

~~~
mnicole
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.

------
acabal
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?

~~~
hcarvalhoalves
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>

~~~
randomdrake
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.

------
usingpond
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.

~~~
bendilts
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.

~~~
imjared
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.

~~~
bendilts
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.

~~~
BaconJuice
Then what was your explanation behind your previous statement?

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

------
zalew
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.

~~~
bendilts
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.

~~~
zalew
> 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 :)

------
t0f3rchr15
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>

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

Compare

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

    
    
       display: none;
    

}

to

@if $boolean

    
    
        @debug "$boolean is #{$boolean}"
    
        display: block
    
      @else
    
        @debug "$boolean is #{$boolean}"
    
        display: none
    

Note, also, that there's a logger.

~~~
a_m0d
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.

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

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

~~~
sophacles
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.

~~~
moron4hire
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.

~~~
camus
trust me , using less makes CSS easier to maintain.

