> On Apr 15, 2016, at 4:43 AM, Sebastian Kaspari <s.kasp...@gmail.com> wrote:
… > Regarding libraries that introduce new patterns: I'm reserved - They make > life simpler at times but they come with a cost: You need to learn how to use > them. New volunteers might not be able to contribute without learning the > frameworks (in comparison to "vanilla android"). Dagger, for example, is a > great library for dependency injection. But I have seen Junior developers > struggling with understanding where the dependencies come from, where they > are retained and at what point they are created by what code. > And the frameworks change - the Android world doesn't follow hip frameworks > as fast as the JavaScript community though. :) However migrating an existing > app from Roboguice (Back then "the" dependency injection library, Today: "Why > does my app take 10 seconds to start?") to Dagger 1 was one of the most > painful code migrations I did. > The other thing is having all this code already: Having a mix of > libraries/patterns can be cumbersome. We may already have this and at our > size it's something that we will have to live with. I'd make different > decisions about using a library if I'd start with a new app as opposed to > developing an already existing app. > > I just realize that this sounds all negative: I’m definitely of for > exploring new patterns and libraries - Let’s find the best ones where we are > confident that we won’t drop them for something better in 2017 (Actual > helpfulness over syntactic sugar). I don’t think you are negative. I think this is the reality of dependencies that we cannot ignore. I have other concerns around external dependencies: • New code to learn, new APIs to learn. They mask the actual native APIs. I know Snapkit (AutoLayout DSL) really well now, but can I say I know AutoLayout well? Not sure. • Complicate the build. Extra compiling, linking, bigger APK/IPA size. • Swift is a moving target. Every time Apple does a breaking update to the language, we have to wait until our dependencies have caught up. This is a major one. When Swift 3.0 comes out, will our 13 dependencies be updated? • Motivation from authors is sometimes questionable. Long term maintenance is sometimes not there. Sometimes it is, AlamoFire, a great HTTP request arapper actually has a foundation (organisation) behind it, to support it. For others it is ‘my first Swift project’ and then abandoned. I see a lot of value in well maintained frameworks with a clear future. But sometimes it is just better to write the code yourself. I replaced a 800KB ‘conversion’ framework with two short functions because we only used it for hex encoding/decoding. Why did we do that in the first place? We were probably in a hurry. Short term win, long term cost :-) On iOS we have 13 dependencies now. I would love to get that list down to the absolute minimum. S. _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
