search

cztomsik / graffiti

HTML/CSS engine for node.js and deno.
http://tomsik.cz/graffiti
MIT License
939 stars 18 forks source link

Why decide against a ready flexbox implementation #186

Closed alex4o closed 2 years ago

alex4o commented 2 years ago

I am pretty sure you have considered, building on top of: A stretch fork eg: https://github.com/elbaro/stretch2, https://github.com/ivanceras/expanse but I am pretty curious why did you decide against it.

If you find this issue irrelevant please close it without responding.

cztomsik commented 2 years ago

Hey, I think this is a good question, so let me explain in a little more detail.

I was using yoga originally because I thought that I will be ok with flexbox-only and I wanted something production-ready. Or I mean something which is used in production (react-native is using yoga).

stretch is a rewrite of yoga in rust, and it was created for the startup called visly. I had a branch using it instead of yoga but there were some api differences/difficulties (impossible to remove a child or insert it at some place or something like that) and that along with the fact that stretch was effectively unmaintained, made me to stay with yoga.

stretch2 (now called sprawl) is fairly new thing, I will keep looking at it but for now I am staying with my own impl. And there are 2 another reasons why I want to stay with my own layout - I want it to operate on "external" tree (so I don't need to do any diffing) and I need Block display mode which unfortunately is not 100% possible to emulate with flexbox.

BTW: there is also one another flexbox engine, called Taitank and there are some reimplementation in other languages: https://github.com/kjk/flex and https://github.com/jordwalke/flex

To wrap it up, sure, flexbox is a lot of code but is also IMHO fairly straightforward thing to do. There are bigger problems and yoga/stretch/xxx wouldn't help me with those, they were actually staying in my way.

alex4o commented 2 years ago

Oh thank you very much, for the suggested alternatives and the response. The only reason I suggested stretch was because I read that the author has designed it with implementing css grid in mind, or so I thought. And I assume that css grid and flex are enough for 99% of any layout anybody might want to build.

cztomsik commented 2 years ago

yeah, I mean the new fork looks promising so far, if it gets maintained again and if we somehow agree on the Tree trait so I don't need to do any diffing/syncing then I might switch again, I didn't put too much energy into layout yet.

I hope to create a ticket in their repo this weekend, and expand my thinking, based on this conversation

cztomsik commented 2 years ago

ticket here https://github.com/DioxusLabs/taffy/issues/182

cztomsik commented 2 years ago

closing for now (limit scope before first release)