flexboxgrid VS css-modules

May you provide a specific scenario? A decade old 960gs provide a custom grid that could be easily tuned to any "proportion of the screen". Random super minimalistic http://flexboxgrid.com/ from the 10 seconds google search had a flex-basis param that could tune grid on the fly. Every other modern "flex css grid framework" has mediaqueries and basic components slapped on top. Barebones grid and flexbox provide tons of control without much effort for a simple drip-in positioning.

Here is a great CSS library that is just the column system. http://flexboxgrid.com/ It has the same naming as bootstrap. I personally just use flex and grid since it so powerful I have no need for a grid system. I just use grid template columns and then flex for pretty much everything else. Tis is why I love Tailwind CSS. It so much more powerful it has all the break points for you and then just lets you get to work and only generates the styles you actually use. On top of that you can easily create plugins and use the JIT styles where ever you need.

if it helps this is my go-to flex grid system when I start a new project. I usually build the big blocks using the utility classes provided by flexboxgrid (which is percentage-based), and then go in each component and fine tune each one. I also extended it a little bit to cover some uses cases that I felt it missed

Did you check out it's documentation? http://flexboxgrid.com/

Okay, so basically I am just out looking at what other developers do to get some of my own inspiration on how to proceed with my project. As of now, I am using some CSS libraries like normalize.css and flexboxgrid just to get some sense of structure on my design. I have looked at tailwindcss as an alternative too instead of writing most of the CSS myself. I know there are both up/downsides to both. But looking for other peoples opinions on this matter. To be a bit more specific, what I am working with is a Laravel backend with VueJS in the front. I saw earlier today that one should get the design done first, before scratching the backend, so that is basically what I am trying to do right now.

It does and I held off on learning CSS Grid even after I quit my job because flexbox does everything I need it to. I often used flexboxgrid (http://flexboxgrid.com/) to create my grids for my sites but since learning CSS Grid I have found that I can write a lot less HTML (fewer containers) and less CSS (fewer media queries) and layout a site faster and visually with properties like

One aspect of CSS modules that I truly appreciate is its ability to compress class names into very short hashes. This feature allows me to keep my CSS selectors as long and descriptive as needed, while still compressing them into concise three or four character hashes. It aligns with my rule for CSS: selectors should be written for human readability, but compressed for machine efficiency.

Use methodologies such as BEM, and technologies including CSS modules, CSS-in-JS, and Shadow DOM to isolate the styles of each micro-application and prevent conflicts, thus ensuring reliable encapsulation and modularity.

For many years, Culture Amp took the second option, and distributed shared components without compiled CSS. This meant that every app that consumed shared components needed to include the necessary CSS build tooling – at that time CSS Modules and node-sass – with a compatible version and configuration. This was relatively easy to set up, but over time proved difficult to maintain. When node-sass was deprecated in favour of (the much faster but slightly incompatible) Dart Sass, this demanded a difficult lock-step migration across all those codebases, which we have yet to achieve. And as new applications have switched to Tailwind for their own styles, they've had to continue to maintain those old build tools in parallel for the shared components' styles.

So CSS modules are a form of 3rd-party CSS-in-JS, where what you import are the class names, which are then usually obfuscated etc at compile time, and all the actual style declarations are (usually) compiled into a single css file or tag as part of the bundling process. You can read the og docs on'em here, and you've probably seen'em used in React like:

import styles from "./styles.css";

function Example(){
    return (
        

            Hello
        
    );
}

They predate the ability to import non-js files in vanilla by a good while, and rely on the compile process to translate your .css files into .js files that can be imported using whichever loader you use in your bundler.

Import assertions are a vanilla way to import non-js files by telling the browser how to import them; assert { type: "css" } says to treat the file as CSS and create a CSSStyleSheet, assert { type: "json" } says to treat the file as JSON and create a JSON object - and hopefully assert { type: "html" } will hopefully arrive soon and create a #document-fragment or something similar.

Hope that clears it up!

Extensions of CSS: for example, Sass, Less, Tailwind, CSS Modules, to make stuff look a certain way on your own.

The components are styled with CSS modules. When building the library, these styles will get transformed to normal CSS style sheets. This means that the consuming application will not even be required to support CSS modules. (In the future I want to extend this tutorial to use vanilla-extract instead.)

NextJS comes with built-in support for CSS Modules which allows you to scope your styles locally in individual components without worrying about name collisions or messing up other parts of the codebase.

CSS modules are not to be confused with mixins, as they serve the opposite purpose. While mixins are components or functions to be reused globally, modules are style sheets with a local scope used in a similar way as styled components in React.

CSS Modules CSS Modules is a pre-processing step: by default, styles are scoped locally to the current component, and the transpiler ensures no conflicts.