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.