131–140 of 168 posts
I wonder if this competes with Qt or GTK?
...I'm not sure that you'd actually want to, but that's a different issue.
They say it has bindings for Android and yea, I can generate these Yoga objects in Java but how exactly would I integrate this with my Android view hierarchy? Do I need to use React for that? The documentation says exactly nothing about this.
What's the piece of information that I'm missing?
Earlier quoted context omitted.
Android has started embracing it with ConstraintLayout. It implements a Cassowary solver in order to resolve the constraint imputed by the dev. I have been using it for some time and it is an huge step in the right direction. A downside of Yoga seems to be its tooling, ConstraintLayout is very well integrated with Android Studio. Actually they created it hand in hand with a rewrite of its layout editor.
I think you're thinking of RelativeLayout? I don't have ConstraintLayout in my IDE right now, but RelativeLayout sounds like what you're talking about.
Actually, CL one of the reasons behind the creation of RL is to improve on RL : - remove the need to nest for complex layouts. Nesting has some intrinsic measure/layout overhead. CL solves this by allowing way more types of relative constraint. The only remaining reasons for manual ViewGroups are performances (still faster than any generalistic approach) or really deep customization.
- solve some of RL qwirks. There are a couple of behaviors which are surprising. CL streamline these corner cases.
- deeper layouting possibilities
- integrated with a better layout editor. By better, I mean something you might choose to use, unlike the previous layout editor.
CL is in beta right now, you can add it as an external lib (that way the android team can update it anytime they want). The layout itself is already useable in production, the layout editor is where there are still some potential bugs.
The API is similar to Yoga. I hadn't seen Yoga before, and I'm surprised at how similar it is. It seems like Yoga is about the same age (or older?) than my Layout library.
It's meant to be easily embedded into existing software, such as game engines, OpenGL-based tools, custom GUI libraries, etc. without requiring its own complicated build system. Its API and layout engine seems to work in a way similar to Yoga, but it doesn't have pre-made bindings for any existing GUI toolkits. There is, however, an example binding for the Lua scripting language.
API comparison:
Yoga:
YGNodeRef root = YGNodeNew();
YGNodeStyleSetWidth(root, 500);
YGNodeStyleSetHeight(root, 120);
YGNodeStyleSetFlexDirection(root, YGFlexDirectionRow);
YGNodeRef image = YGNodeNew();
YGNodeStyleSetWidth(image, 80);
YGNodeStyleSetMargin(image, YGEdgeEnd, 20);
YGNodeInsertChild(root, image, 0);
lay_context ctx;
lay_init_context(&ctx);
lay_id root = lay_item(&ctx);
lay_set_size_xy(&ctx, root, 500, 120);
lay_set_contain(&ctx, root, LAY_ROW);
lay_id image = lay_item(&ctx);
lay_set_size_xy(&ctx, image, 80, 0);
lay_set_margins_ltrb(&ctx, image, 0, 0, 20, 0);
lay_insert(&ctx, root, image);
One major difference I noticed, though, is that Yoga seems to allocate for each individual node, whereas Layout uses a single resizable contiguous buffer. This is gives it pretty good CPU cache performance (writes are all in their own separate region of the buffer) and allows you to do complete rebuilds of the layout hierarchy without any heap allocations. It's nice if you have a dynamic layout and want to keep the layout calculations fast/cheap. It might be interesting to do benchmarks of the two libraries in different scenarios.
Are there any other libraries similar to Yoga and Layout?
Yoga is also the new Lenovo laptop. Human languages need better support for namespaces.
Hardware laptop vs software library?
Why not just embrace Cassowary ( https://en.wikipedia.org/wiki/Cassowary_(software) ) aka the algorithm behind Cocoa's Auto Layout? Auto Layout isn't perfect but I think that it's fundamentally the API/UI that you are working with, the concepts are definitely at the right level of abstraction. Some sort of DSL could really solve this. Flexbox could be implemented as a framework on top of this.
(Original author of css-layout here) I've spend a few months playing with Cassowary before working on css-layout and had long chats with its creator Greg Badros and the people behind https://gridstylesheets.org/ . Cassowary underlying abstraction is a linear inequation solver. So you give it a bunch of constraints of the form ax + by + cz + d ## There are two innovations in Cassowary: 1) There's a concept of strength…
That sounds like "strength" was probably the wrong approach. Why not require the developer to simply resolve conflicts? Your set of inequalities are a basic type system and you tried to resolve your type errors by layering some secondary weird "overriding" type system over top. Better to just resolve the errors from the get-go, and when it compiles, you know it will run correctly.
> The most annoying instance is line breaking. You cannot encode how lines are going to break as a set of linear inequations.
Is this discussed anywhere in more detail? It doesn't sound right to me, unless I'm misunderstanding what you mean here.
Earlier quoted context omitted.
The React wiki has a non exhaustive list of users[0] which includes some rather large companies (BBC, Airbnb, Automattic, Atlassian, eBay, Netflix, etc.). I presume most of those larger companies had their legal departments approve its use. [0] https://github.com/facebook/react/wiki/Sites-Using-React
That may be the case, but I personally would be surprised. My impression is that most companies don't do a good job of managing and monitoring dependency licensing. I have seen tooling that analyzes licenses, but not for node or client-side javascript. Maybe I'm just in the dark.
To answer your original question, I found this statement by Automattic's legal counsel[0]:
> “Automattic looked at the legal issues with Facebook’s patent license on React,” Sieminski said. “The termination provisions of the patent license aren’t ideal, but are not a blocker to using React as part of Calypso.”
[0] https://wptavern.com/automattic-will-continue-to-use-react-j...