5 ms·

> While I agree with the premise that css preprocessors are overused I'd like to know how one maintains a huge modular css code base without any sort of pre

by camus2 13y ago

> While I agree with the premise that css preprocessors are overused I'd like to know how one maintains a huge modular css code base without any sort of preprocessor. Preprocessors are here because CSS sucks, and no standard committee seems to want to fix it. That's why people built these tools right, to solve a problem nobody was going to solve for them. That's exactly the same thing with javascript. If javascript was decent we would not need all these compile to javascript languages. These tools bring diversity and choice to a poor plateform with shamefull languages that are not evolving very fast. You cant fix it just by adding features without fixing the core. that's what preprocessors are for and it's ok to abuse them without shame. EDIT: my point is "it's good enough" isnt good enough, in a time where we are supposed to maintain complex front-end projects and asset pipelines, that work on different devices that have their own idea of how to implement (poorly written) standards.

peterhunt 13y ago
Well, I think JavaScript is good enough (I do prefer Python though) and we certainly don't need compile-to-JS languages like CoffeeScript (which IMO just takes a somewhat-ambiguous syntax and makes it more ambiguous). TypeScript is somewhat of an exception, but I view it less as a language (since it doesn't change runtime semantics afaik) and more of hints to a linting tool. The problem with CSS preprocessors is that they are simultaneously too powerful and not powerful enough. That is, things like SASS mixins and nesting make it easy to make mistakes (specificity overload and huge stylesheets are the two big ones). At the same time they don't change runtime semantics so you can't fix the biggest problems in CSS like specificity wars, finding dead selectors and namespacing. I do like variables and expressions though (mainly for colors and grid units). The way you maintain a big modular codebase is to make your stylesheets really stupid and build the smarts into whatever is generating the DOM. The tools we have for generating DOM are both far more mature and we have more control over the semantics of the runtime.

by camus2 13y ago

peterhunt 13y ago

Well, I think JavaScript is good enough (I do prefer Python though) and we certainly don't need compile-to-JS languages like CoffeeScript (which IMO just takes a somewhat-ambiguous syntax and makes it more ambiguous). TypeScript is somewhat of an exception, but I view it less as a language (since it doesn't change runtime semantics afaik) and more of hints to a linting tool. The problem with CSS preprocessors is that they are simultaneously too powerful and not powerful enough. That is, things like SASS mixins and nesting make it easy to make mistakes (specificity overload and huge stylesheets are the two big ones). At the same time they don't change runtime semantics so you can't fix the biggest problems in CSS like specificity wars, finding dead selectors and namespacing. I do like variables and expressions though (mainly for colors and grid units). The way you maintain a big modular codebase is to make your stylesheets really stupid and build the smarts into whatever is generating the DOM. The tools we have for generating DOM are both far more mature and we have more control over the semantics of the runtime.