re: What should production CSS look like? Share your layout-to-web workflow VIEW POST

FULL DISCUSSION
 

I don’t use grids from 2015, and bem from 2016. Old good plain css (with some help by postcss) and components based architectures with style-in-component (webcomponents, vue or react doesn’t make difference). The “framework phase” is something that i’ve already saw.

 

Sounds like you feel over grids and frameworks.
What do you enjoy about PostCSS (don't know very much about it) as opposed to the other methodologies mentioned? What kind of projects do you feel they are working well for?

 

I just stopped using css frameworks and methodologies since I started workings with components. I now enjoy the benefit of simple architectures and code maintainability dropping complex systems (and now i can see also useless).

Postcss alone is just a a fast AST parser, the advantages come from the plugins you use. I always start with what i need (3 plugins) and i can make everything. No needs of node-sass, huge dependencies and unused functionalities.

About methodologies, i used BEM for years but with components i don’t need it anymore (it’s is still useful in some contexts).

I think people should just try to drop these 2012 approaches and start trying something that solve today problems.

Could you explain what you mean by "components" outside of what i understand as components in frameworks? I've also read the no-framework thinkpieces out there and while I agree for 90% of hobby horse dev projects frameworks are wayyy too bloated and overkill, I'm at a stage where breadth is helpful for developing experience and a profesh opinion. Also as someone semi proficient in everything libraries help solve a lot of problems beginners can't vanilla js their way out of. Not looking to reinvent the wheel here.

i think mattia is talking about components as in javascript classes or functions that render a single visual component, like you find in react, angular or vue. there are approaches that limit styling and stylesheets to the component level and [nearly] completely throw out the notion of a master stylesheet.

so if you find yourself in the future redesigning the login form, you only have to redesign the login form and not the whole login screen or page or other higher level container. it's essentially BEM, but enforced and maintained by the computer and not a person. it reduces a ton mental overhead and eliminates a whole class of typo/misuse bugs in CSS.

Exactly. But non only with vue/react/svelte etc.. i trust it as mindset. An approach that you can apply even with plain html/css/js and drop the monolithic frameworks approaches that are born many years ago to fix different problems.

Thank you @worc for explaining. Your description makes a lot of sense. I like the idea of writing super lean plain html/css/ vanilla js... but I would need to master JS first. Then would come the question of should I CSS functions or still use SASS? I don't want to be obsessed with rigour but I'm trying to understand what's a professional standard. I'm both studying to "pass the test", but also want to self-improve from what was a previously anti-technical, anti-framework, anti-rigour kind of artistic point of view.

correction: Makes a lot of sense for reusable components/features*, and large scale applications, which I should be gearing up to get used to

Yes. But this approach and mindset can be applied even on small website. Every html elememt and composite block is a "reusable component" by default.

styled-components is a good working example in the react ecosystem. @jen chan, in general, you don't need to use sass if you're building CSS blocks in javascript. javascript gives you access to variables and functions and extensibility natively. it's probably not the best looking syntax around, but i've seen it help a ton in keeping CSS definitions from leaking across components and keeping the scope of a styling problem/solution very narrow.

code of conduct - report abuse