Echo JS 0.11.0

<~>
MaxArt 2704 days ago. link parent 1 point ▲ ▼
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.

Replies

planttheidea 2704 days ago. link 1 point ▲ ▼
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.