+1

On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <[email protected]> wrote:

> We were evaluating Masonry prior to our new 3rd party lib vetting process (See
> here for more info:
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries),
> but still wanted to do a write up for everyone.
>
> Masonry is a library that allows developers to write autolayout code
> similar to the Visual Format Language, but instead of error prone strings
> to describe relationships, it provides a compact compiler checked syntax.
> You can read more here:
> https://github.com/Masonry/Masonry
>
>
> Below are answers to our standard questions:
>
>
>    - Is the license permissive?
>
> Yes - MIT
>
>    - Is the library ubiquitous?
>
> Yes 4,362+ stars and 475 forks on Github.
>
>    -  Is it installable via CocoaPods?
>
> Yes
>
>    - What is the impact on binary size?
>
> Negligible - no included assets
>
>    - How severe, if at all, are inbuilt subdependencies?
>
> No 3rd party dependencies
>
>    - Will this make the code more, or less, understandable for
>    volunteers?
>
> More understandable - it provides an expressive "english" syntax for
> creating autolayout constraints. It introduces no new concepts, just type
> checking and syntax.
>
>    - What are the performance ramifications of using this library?
>
> None, it uses cocoa autolayout under the covers.
>
>    - What are the complexity ramifications of using this library?
>
> Masonry allows developers to write layout code in a much more concise and
> expressive way - this should reduce number of lines while increasing
> expressiveness.
>
>    - Is it actively maintained?
>
> Yes and receives frequent pull requests.
>
>    - Is it compatible with current deployment targets?
>
> Yep
>
>    - Does it hinder interop (e.g., with Swift)?
>
> Nope
>
>    - What is the exit plan if the library becomes unmaintained?
>
> Since Masonry is basically just a syntax veneer of autolayout - it should
> be possible for us to maintain if needed. There aren't any foreign concepts
> to understand. If we choose not to maintain - the constraints can be
> translated to the VFL language (or Interface Builder) easily.
>
>
>
> If anyone has questions / comments - please reply here.
>
>
>
> _______________________________________________
> Mobile-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>


-- 
EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle
_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Reply via email to