nicklockwood
commented
6 years ago Hi @FranDepascuali, thanks for the feedback! You've made a lot of points here, so I'll try to address them individually:
Another thing I didn't like that much is that views are layout via the frame properties and not autolayouts. There is a reason Apple stopped doing this, as it doesn't scale for different screens. It's true that you can apply a percentage to the view's size by this framework, but I would prefer to stick with constraints. Explictly setting frames have not work for me in the past and brought headaches sooner or later.
Layout is not really frame based in the traditional sense because everything is an expression. When you set the width of a view in Layout, you can set it to be a min/max range, or make it relative to its content, or the width of a sibling view. I think you'll find that the expressions in Layout are every bit as flexible as the constraints in AutoLayout.
I don't think it's optimal that the framework implicitly requires so commitment to the user. I don't see it as composable with what apple suggest. It has at the same time a lot of cool properties, so I have this mixed sensation that I would love to have some of the things here offered but in a simpler, more like extension of current way of designing views and not a whole new approach.
This is a good point. I'd like to make the framework more composable so that you can opt-in to parts of it without using others. I'm open to suggestions on how to do that.
Proprietary, undocumented format (Don't understand exactly what this means)
Apple's Storyboard format is not an open specification. You can't implement your own Storyboard editing tools, or hand-edit the files.
Poor composability and reusability (What exactly is poor composability? Why would it be better by using the framework? Listing so broad terms sounds vague)
It is hard to construct a view from many different re-usable Storyboards, or to mix and match views from storyboards from views made in code.
Hard for humans to read, and consequently hard to resolve merge conflicts (valid point, but only if you use xibs/storyboards (I use code right now)).
Well, Layout is primarily a replacement for Storyboards/Nibs :-)
Simpler to use for basic layouts (relative, what do you mean by simple? Autolayout is simple, it may not be easy (which is subjective, because for me it is)).
I mean that you can achieve the same result with less code.
More deterministic and simpler to debug (relative. Why is not autolayouts deterministic? Because it is, it doesn't change every time you run if you didn't change the constraints. Simpler to debug may be true, it's not simple however the word).
Perhaps "deterministic" is the wrong word. AutoLayout uses a recursive algorithm to approximate the result of competing constraints, so the result is not always predictable, or what you would expect.
More performant (at least in theory :-)) (if talking about performance, a number should be given).
There are too many variables to provide a single number, but I do provide a benchmark app that compares Layout performance against AutoLayout for a set of test views.
It would be great if the user of this framework could use some parts of it only. Like, I would prefer to have a method that set the styling of a view using xibs rather than defining the whole hierarchy using the noes that this framework provides.
That is possible, though only by writing some glue code to load the nib. I guess I could add direct support for loading nibs from XML, although I wonder why you would want to do that since the project is aimed at people who want to get rid of nibs? I guess maybe to re-use nibs you've already written previously?
I've read the readme and had an overview of the code. I actually was thinking to develop something similar to what is achieved here. Basically, what I would like is to be able to style the views and layout constraints via xml/json/reloadable content.
I started reading the readme and was pretty impressed, because this framework seems to have what I need. But then I realize that it is trying to solve a lot of problems at the same time (which imply a whole new way of doing UI stuff) that I don't need. I don't think it is a good idea to be tied up to a framework, specifically because Apple usually apply changes that break stuff (like the introduction of the safe area).
Another thing I didn't like that much is that views are layout via the frame properties and not autolayouts. There is a reason Apple stopped doing this, as it doesn't scale for different screens. It's true that you can apply a percentage to the view's size by this framework, but I would prefer to stick with constraints. Explictly setting frames have not work for me in the past and brought headaches sooner or later.
The last point that I stated before, is that I don't think it's optimal that the framework implicitly requires so commitment to the user. I don't see it as composable with what apple suggest. It has at the same time a lot of cool properties, so I have this mixed sensation that I would love to have some of the things here offered but in a simpler, more like extension of current way of designing views and not a whole new approach.
This just means to be taken as feedback, I think it's a great work. I would definitely not jump in right now, but I think it has a promising future. The README looks really detailed, which is good. Nice work there. I would also mention tradeoffs and caveats. And the list of the why? seems to relative:
It would be great if the user of this framework could use some parts of it only. Like, I would prefer to have a method that set the styling of a view using xibs rather than defining the whole hierarchy using the noes that this framework provides. Anyways, this is a promising project. I think there are really cool stuff here!