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 <bgers...@wikimedia.org> wrote: > +1 > > On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd <cfl...@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@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@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
