Or, just write the display:flex you need, where you need it, as little as you actually need.. easy as pie unless your deadline was days-ago. This here might save you 10 minutes of manual work, at the expense of further code-base bloat, external-lib-dep accumulation, technical debt. OK fair game for your MVP-landing-page-A/B-split-test-shenanigans, granted.
Besides lack of good cross-browser support until recently, I think there are a few reasons why flexbox is still less popular than float- or margin-based grids:
- Steeper learning curve and less accessible than adding a class like "col-3" or "grid--1/2". The latter is almost self-explanatory.
- Requires an existing or new CSS class to bind the styles to. If it's a new class, you have to figure out a good name (which isn't always easy, naming things is hard).
- Requires editing CSS/Less/Sass, which (depending on your setup) can require waiting for it to compile. The wait time for compiling/bundling HTML is usually negligible.
- Traditional grid systems just work, and they work well enough for most things. When you have more important & interesting problems than a CSS grid system, there's a bias towards shipping what works and moving on.
That being said, flexbox is really powerful and a great tool for many things. But for many simple layouts, traditional grid systems can get the job done just fine without requiring much initial investment. On interdisciplinary teams where non-frontend devs can contribute, end-user simplicity is sometimes more important than language sophistication.
This is horrible, IMHO. Flex containers will layout the flex items, which are by definition its direct descendants. If by some reason [1] you get an extra DOM element between the flex container and the item you intend to layout, then you're in for a rewrite of the CSS and maybe some extra classes.
Yes! Flex box has lots going for it, but it breaks a "feature" that many web developers and framework developers have relied on since the earliest days: it being mostly harmless add an extra layer of element at a whim anywhere. One could argue this is a lousy feature (and I would agree). But lots of developers and lots of frameworks do it.
Adding elements just because (and, above it all, just for styling purposes) is wrong, of course. But having - or forcing - a tight coupling between structure (DOM) and layout/styling (CSS) is also wrong. IMHO, standards should try to move in the direction of decoupling; they did the opposite with Flexbox.
Anyway, the most present case for me is really Angular, where DOM elements are usually added because they are needed (and actually beneficial, if you like a component-based architecture and DRYness). Angular 1.x deprecated the `replace` option for element directives a few months ago (i.e. your <my-directive> will be in the DOM). Also, AFAIK, it never supported the `replace` behaviour in components (which are always elements). This means that, currently, Angular and Flexbox don't play very well together...
I would call technical debt to writing it as you go, since there are many small bugs and inconsistencies that (hopefully) are fixed by these libraries. Just a couple of random examples:
True, I thought it was widely know but there's a whole Flexbugs project [1] and that there are many Known Issues with flexbox [2]. Some with solution, some without them.
