This is actually a pretty cool update for FuseBox, but I really had to push through that first sentence. "Renders Babel useless"? Try describing things with a less 2AM infomercial vibe.
Summary: it's great and you should use it! It has no problems or flaws! Here are all the benefits and reasons you would use it covered in the article;
...
Kind of lacking in the substance department.
So this is cool, but there are some naive aspects. For example, all numbers are converted to px values? Hope you never use flexbox properties, line-height, etc.
So maybe this simply means my README needs to be beefed up, since a lot of these arguments appear to be predicated on the fact that you NEED to provide all the flexbox properties to the container and items. Example:
> If you're going to replicate all of flexbox' functionality, how is that better than writing all the properties you need in the `style` attribute?
... you don't. Bsaed on your response, you were probably envisioning something like this:
<FlexContainer alignItems="stretch" flexDirection="column" flexWrap="nowrap">
When in reality it is this:
<FlexContainer column>
There are defaults for all the things, and convenience properties to simplify things, which are meant to remove a lot of boilerplate.
This is the biggest piece here; if you always had to pass down all the properties just like always having to declare your CSS, you would be spot on ... this would be useless and tiresome. But you don't; in most scenarios you are passing down one prop at most. Simply because the option exists to declare all the things doesn't mean its a requirement.
> Oh, does flexor do it out of the box? That would be remarkable
Yes, flexor tries to handle as many of the flexbugs issues as possible (and auto-prefixes for legacy support). Despite your casual dismissal of the limited scope, some users actually fall under that scope, and they like when they are catered to. You make a poignant, if not exaggerated, point when asking if we should develop a sugar abstraction for all CSS specs. Not all CSS specs require the use of multiple property declarations that have buggy and inconsistent implementations historically.
> I don't want to leave you with just a critique, so here's what I think you should do
In truth, I rather appreciate the critique ... less so on the need to instruct. Offering criticism makes it look like you have an opinion, whereas offering instruction makes it look like you think its the only one that is right. It doesn't make you sound knowledgeable (which I believe you are) ... it just makes you sound like a dick.
Emphatic response, appreciate the passion. I totally support your decision to not use this component, but I just wanted to clarify some things.
How is it responsive? How is this the "React way"? The answer is simply that all the responsive aspects you used to use with things like media queries in CSS now are programmatically determined and passable via props to the component. For most things this means simply moving the deterministic logic to the component itself, and for other things it allows for applications unavailable in CSS (at least until things like container queries become a real thing). I've heard this same sort of impassioned response from people the first time they heard about inline styles, and then JSS, and then styled components. It's not an invalidation of the way things have always been done ... it's just a new option.
It's goal is not to save you from flexbox; that knowledge is vital for any developer! The goal is to make satisfying the 80% use case a little more frictionless. Instead of declaring a div and adding styles for it, you just declare a FlexContainer. Or maybe you're using CSS modules and don't want to mix global with local styles but still want to keep a tiny footprint. Or maybe you're tired of fixing flexbox bugs related to inconsistent old browser implementations (https://github.com/philipwalton/flexbugs). Either way ... it's just another option.
¯\_(ツ)_/¯