In practice, almost everything that you ever want to achieve with Grid can be achieved with Flexbox. Time and time again, I’ve encountered examples of “what Grid enables”, and been able to replicate it precisely with Flexbox.
Not always—there are definitely practical things you can achieve with Grid that you can’t with previous layout options, I’ve made a couple myself—but almost always.
Interesting, having used them both a lot I feel exactly the opposite way – I think grid's capabilities apply to more situations and suspect it will be the go-to layout/alignment tool once it catches on more. Grid is the more powerful tool, I think the only feature it can't do that flexbox does is making wrapped items not line up (since grid, of course, wants to make them line up into a grid). Wanting items not to line up seems less common, doesn't it?
Flex is about single-dimensional layout, grid is about two-dimensional layout.
Most layout scenarios that are in two dimensions can actually be solved with nested single-dimensional layout. Sometimes it’ll be easier to solve them with a proper two-dimensional layout, and I tend to prefer the markup that Grid lets me have, but I find two-dimensional layout that can’t be solved with nested single-dimensional layout to be uncommon.
Also, most interface problems are actually single-dimensional.
I think Grid will become more popular than it is, but never overtake Flexbox as most people’s go-to for layout, because Flexbox is normally enough, and Grid is too complex. I use it from time to time, and I have taken the trouble to know exactly what it’s capable of, so that I know when I should reach for it rather than Flexbox or something else or giving up, but I normally need to look up various properties when I go to use it. Meanwhile, most of what people want to achieve with Flexbox is just `display: flex;` plus `flex-direction`, `flex`, `align-items` and `justify-content`, and there are few enough knobs that you can essentially brute-force it without trouble—and the Flexbox Inspector makes it even easier, in a way that the Grid Inspector can’t really because Grid is just too powerful.
I like because it has the "applies to: container/items" clearly shown for each property, which I always forget...
The next thing I want to try is using css transitions to "animate" flexbox containers so that dynamic content inside smoothly expands the height of the container down the page, instead of the abrupt jump we're used to. I haven't managed to crack this yet, but heard a rumour that it's possible. So if anyone has tips.... (edit: found this which details the issue, and describes said flexbox trick: https://css-tricks.com/using-css-transitions-auto-dimensions... )
Installed Firefox Developer Edition after using only Chrome for awhile. Pleasantly surprised how well everything works, especially the dev tools pane -- feels more smooth than Chrome's dev tools.
This is weird. Some people claim that Firefox's dev tools are better, others claim that the Chrome dev tools are better and that Firefox doesn't even compare. I wonder who is right. Is this like comparing different car brands where you can never reach a good conclusion? I personally have always been using Firefox, so its dev tools are most familiar to me, but there have been times where I've run into unimplemented features that were implemented in Chrome.
In matters of layout, Firefox has tended to have a substantial lead. In matters of script debugging, Chrome has tended to have a substantial lead. In other places, it’s not so consistent.
Take debugging as an area where I think it is fair to say that Chrome is miles ahead at present:
Chrome’s debugger is fast; pausing normally takes under a second to finish updating the UI, and stepping mostly takes a slight fraction of a second. It is also particularly helpful, showing the values of variables at the end of each line when stepping through.
Firefox’s debugger is slow; pausing typically takes several seconds for the UI to catch up, and stepping tends to take a second or two, with some UI thrashing. It is unreliable in the presence of source maps (you put a breakpoint on line 1234 of the source? Well that translated to line 1 in what’s actually being executed, and breakpoints are no more precise than linewise, so… yeah). Firefox Nightly’s debugger is also currently completely broken for me at FastMail due to https://bugzilla.mozilla.org/show_bug.cgi?id=1516941, so I’m having to spin up Chrome when I need to do any debugging, which I don’t like having to do. In the normal run of things, I stick with Firefox even through its slow debugger, because I do find that it does a better job in some areas of debugging (I think it was examining values and operating at varying layers of the stack).
For personal context: I’ve been a Firefox user since about 0.93, and have had Nightly as my daily driver most of the time for several years. I don’t much like Chrome. That doesn’t stop it from being better in certain areas, though.
This has been my experience too. Firefox is my primary browser but I never could get the debugger to work inside promises for some reason. The firefox layouting engine is amazing. I develop some crazy inefficient DOM layouts when prototyping and Firefox will happily chug through it while Chrome will choke. But when I have to debug I go back into Chrome..
7 billion people, probably room for at least 2 choices, especially given most other categories of services/products have 10x as many. I’d say the car or luxury brand reference is fitting, since it probably comes down to trade-offs/personal opinions.
Since the flexbox inspector is is a sidebar in the DevTools, they're working with similar size constraints as a mobile device. I think taking design inspiration from mobile makes sense.
