Glad you're back. After an improved promise support, now Node has async/await too, which makes everything even sweeter (also, in Node 8.x the performance of promises improved dramatically - not as fast as Bluebird but getting there).
I don't get why so many developers struggled with the async nature of JavaScript, but I guess you're in good company after all.
> The return statement ends function execution
That's not correct in some edge cases. Consider the following:
function foo() {
try {
console.log("foo");
return 0;
} finally {
console.log("bar");
}
}
When executed, it will print both "foo" and "bar".
Also worth mentioning that a return statement inside the finally branch with override any previous one.
It's an option, alright. But not a good option, because it's a solution searching for a problem.
What should we do, create sugar libraries for every CSS spec out there? For grid (I'm sure I have already seen it)? For transforms? For animations? For sticky elements? For filters? For box shadows? For masks? For... ?
Have an idea of what I'm talking about: https://www.w3.org/Style/CSS/specs.en.html
> 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
Why would you do that? You have this in CSS in a well-known, declarative way. Media queries also listen and react to changes on the observed properties, for example when changing the orientation of the device. You're saying that this logic has to be recreated in JavaScript (in a service, presumably?) to pass down a flag from the root container. That's a little crazy for what should be a global state of the page, not to mention the additional overhead of passing yet another property, *and* more code that has to be tested.
> For most things this means simply moving the deterministic logic to the component itself
And doing the same for *all* the FlexContainer/Item around? It's the perfect way to make the UI janky, like the old days of jQuery.
> for other things it allows for applications unavailable in CSS (at least until things like container queries become a real thing)
And exactly what prevents you from doing this for any other component? What's it "allowing" exactly?
> 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.
Definitely not the same thing. All those alternatives have been accused of breaking the separation between functionality and presentation, but it's ultimately wrong because writing styles in JS doesn't imply breaking the separation.
With your library, on the contrary, it's explicit: you have to determine and put presentational directives directly in your code, possibly at run time.
> The goal is to make satisfying the 80% use case a little more frictionless.
I appreciate the sentiment but it ultimately fails to do so. In fact, you might end up having *more* friction.
Think about this from a business point of view. It starts from the fact that another dependency, plus its tree of dependencies, *is* another point of friction.
Then comes the fact that its explicit goal is to simplify the usage of flexbox for those developers *that should already know how to use flexbox!* How can you achieve it? You have to design a *new* API that solves the usage problems of flexbox. And given that the W3C took its sweet time to design it (even though that doesn't grant anything, but well), with contributions from engineers from Google, Apple, Mozilla, Microsoft and others, I'm not saying it's impossible to create a better and *equipotent* alternative but it's definitely not an easy task.
In fact, you ended up pretty much replicating *all* of flexbox CSS properties in form of slightly differently named component attributes and values. That developers have to learn, one by one. Another point of friction.
Then it comes maintenance and real world cases. It may happen that someone has to fix a layout bug in a web app that uses flexor. That someone has never worked on the project, or maybe just marginally, and quite some time has passed. The guy finds the culprit, then can't find where to fix it because the project was supposed to used styles components, not having a clue that flexor creates its own `<style>` elements that injects in the page. Another search begins, more time lost. More friction.
> Or maybe you're tired of fixing flexbox bugs related to inconsistent old browser implementations (https://github.com/philipwalton/flexbugs).
Oh, does flexor do it out of the box? That would be remarkable, but I haven't found trace of it.
And it's actually a good thing, because several of the workarounds about flexbox bugs have limited scope and don't cover all the cases.
Your library reminds me a little of Atomic CSS, which is already a maintainability hell. 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?
I don't want to leave you with just a critique, so here's what I think you should do when creating a layout component: you should create something *novel*. For example, as flexbox solves a plethora of use cases and introduces a lot of complexity doing so, you can focus on a limited subset of cases and offer a new API to achieve the goal. Like this:
<PositioningContainer position="center">
<p>I'm centered horizontally <i>and</i> vertically!</p>
</PositioningContainer>
<PositioningContainer position="bottom right">
<img src="watermark.svg" alt="I'm a little logo!">
</PositioningContainer>
Now this is valuable because it's semantic and clear. `FlexContainer` hardly means anything, and that's not good when creating the content of the page.
So leave to CSS what CSS can do best.
No. Just no.
To every React developer out there: don't do this.
Don't mix content and presentation like this. We have a better tool, it's called CSS. Use it, embrace it.
This is not responsive, it's not semantic, it's hard to maintain, it's less flexible (ironic, isn't it?), it's another dependency and another layer that has to be learnt on top of all the rest. It tries to "save" you from using flexbox in CSS but it doesn't save you from actually *knowing* flexbox OR writing CSS anyway. So just use flexbox, I say!
There is no flexbox "done the React way", unless you're referring to styling your components with flexbox. This is another example of something done while asking yourself if you *could* do it but not asking if you *should* do it.
Nope, sorry, no way I'll ever use it and if I catch one of my colleagues using it I'll bite their pinky fingers.
Sorry if this appears too harsh but I really feel this is a step in the wrong direction, and I invite you to reconsider how you design your components (in React but not only).
I didn't mean an estimation for replacing a Java backend, but rather how much time will pass until Node will be considered a common and valid alternative to Java for building the business logic of an application.
> The return statement ends function execution That's not correct in some edge cases. Consider the following: function foo() { try { console.log("foo"); return 0; } finally { console.log("bar"); } } When executed, it will print both "foo" and "bar". Also worth mentioning that a return statement inside the finally branch with override any previous one.