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 Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

I found this Swift version of Masonry: https://github.com/Masonry/Snap Are we confident in it, or does anyone know if the original Masonry repo maintainers have Swift plans? If not, assuming one of our long-term goals is to eventually convert as much of the codebase to Swift as is practical, wouldn't adopting Masonry further entrench Obj-C implementations? i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry syntax back to VFL strings and/or NSLayoutConstraints. If there's not a solid Swift implementation, I'd be unsure if Masonry use is wise strategically. Thoughts? Any concern that Masonry's syntax, while concise/elegant, raises the bar for outside contributions in that it deviates from the "standard" approach at all? On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle <bgerstle(a)wikimedia.org > wrote: > +1 > > On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <cfloyd(a)wikimedia.org> > 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 >> Mobile-l(a)lists.wikimedia.org >> 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 > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

Oooh interesting! I hadn't considered calling back to the Obj-C version from Swift land... On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber &lt;bvibber(a)wikimedia.org&gt; wrote: > It looks like it is possible to use the Obj-C version from Swift: > > https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720 > > so one could probably migrate UI classes using it bit by bit. > > But the new all-Swift version in Snap apparently has a cleaner syntax > that fits with Swift better... > > Actually, do they conflict? Could we start with one in Obj-C and > transition to the Swift one in Swift classes, while both sit in place? In > theory they're creating regular layout constraints so it's just the setup > calls that are different... > > -- brion > > On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd &lt;mhurd(a)wikimedia.org&gt; > wrote: > >> I found this Swift version of Masonry: >> https://github.com/Masonry/Snap >> >> Are we confident in it, or does anyone know if the original Masonry >> repo maintainers have Swift plans? >> >> If not, assuming one of our long-term goals is to eventually convert >> as much of the codebase to Swift as is practical, wouldn't adopting Masonry >> further entrench Obj-C implementations? >> >> i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry >> syntax back to VFL strings and/or NSLayoutConstraints. >> >> If there's not a solid Swift implementation, I'd be unsure if Masonry >> use is wise strategically. Thoughts? >> >> Any concern that Masonry's syntax, while concise/elegant, raises the >> bar for outside contributions in that it deviates from the "standard" >> approach at all? >> >> >> On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle < >> bgerstle(a)wikimedia.org&gt; wrote: >> >>> +1 >>> >>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd &lt;cfloyd(a)wikimedia.org&gt; >>> 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 >>>> Mobile-l(a)lists.wikimedia.org >>>> 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 >>> Mobile-l(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

Here's my take on this is: |_ Establish layout related stuff in XIBs via Interface Builder when possible. |__ If the XIB approach is inadequate, use VFL where it's easy and clear and achieves the desired result. |___ If VFL is insufficient, try the more verbose builtin methods if they don't make it too hard (e.g., 4-8 manual constraints isn't that bad, but when it starts to go over that, things are probably getting messier than needed). |____ When XIBs, VFL, and verbose methods are too cumbersome, use Masonry if it helps achieve the task with greater clarity, easy, and correctness. I trust we'll all be able to make reasonable case-by-case judgments about when to fall back from XIB+VFL+builtins to Masonry. -Adam On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd &lt;cfloyd(a)wikimedia.org&gt; wrote: > Yeah we could swap them out when we need to pretty easily > > On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd &lt;mhurd(a)wikimedia.org&gt; > wrote: > >> Oooh interesting! I hadn't considered calling back to the Obj-C >> version from Swift land... >> >> On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber &lt;bvibber(a)wikimedia.org&gt; >> wrote: >> >>> It looks like it is possible to use the Obj-C version from Swift: >>> >>> https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720 >>> >>> so one could probably migrate UI classes using it bit by bit. >>> >>> But the new all-Swift version in Snap apparently has a cleaner >>> syntax that fits with Swift better... >>> >>> Actually, do they conflict? Could we start with one in Obj-C and >>> transition to the Swift one in Swift classes, while both sit in place? In >>> theory they're creating regular layout constraints so it's just the setup >>> calls that are different... >>> >>> -- brion >>> >>> On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd &lt;mhurd(a)wikimedia.org&gt; >>> wrote: >>> >>>> I found this Swift version of Masonry: >>>> https://github.com/Masonry/Snap >>>> >>>> Are we confident in it, or does anyone know if the original Masonry >>>> repo maintainers have Swift plans? >>>> >>>> If not, assuming one of our long-term goals is to eventually >>>> convert as much of the codebase to Swift as is practical, wouldn't adopting >>>> Masonry further entrench Obj-C implementations? >>>> >>>> i.e. to "Swift-ify" Masonry'ed code we'd have to decompose Masonry >>>> syntax back to VFL strings and/or NSLayoutConstraints. >>>> >>>> If there's not a solid Swift implementation, I'd be unsure if >>>> Masonry use is wise strategically. Thoughts? >>>> >>>> Any concern that Masonry's syntax, while concise/elegant, raises >>>> the bar for outside contributions in that it deviates from the "standard" >>>> approach at all? >>>> >>>> >>>> On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle < >>>> bgerstle(a)wikimedia.org&gt; wrote: >>>> >>>>> +1 >>>>> >>>>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd < >>>>> cfloyd(a)wikimedia.org&gt; 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 >>>>>> Mobile-l(a)lists.wikimedia.org >>>>>> 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 >>>>> Mobile-l(a)lists.wikimedia.org >>>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mobile-l mailing list >>>> Mobile-l(a)lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>> >>>> >>> >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> > > > -- > Corey Floyd > Software Engineer > Mobile Apps / iOS > Wikimedia Foundation > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >