I was having a conversation with Tony Coconate about the new front end JavaScript framework I’m trying to wrap my head around. Ok, it’s Ember (figured you’d ask).
I appreciate Ember’s ambition in guiding you towards best practices, but I was also failing to realize how it was helping me. I’ve written plenty of client facing functionality, both web and non-web. I know how to isolate things and follow patterns that won’t bite me later. I was curious at what point the pain of learning Ember would go away and I could finally be productive. When will it make me more productive?
“The framework isn’t for you,” he says. “It’s for the team, and the next team.”
I had to think about this for a while. It made sense when reflecting on the transition of a project I recently worked on which used Backbone extensively.
No matter how you roll your own, it’s your own
I like Backbone.js. Jeremy’s a bad ass and I owe him beers for making my life easier (thanks dude). Backbone is simple to grok and be productive with, but it’s more of the library approach which enables you to design your own architecture. It took a little while to get everything into place, but soon we were hyper productive. All it took was dulling a few edges and coming up with some rules around how we communicated state between various components. The rest was glorious. It served our application very well and it proved itself useful in the next application I wrote where I ported most of the same concepts.
Until we rolled off. The guys who took over were no slouches, but I had to have three separate web sessions with them describing the reasoning behind the application’s design. This is because although the architecture was elegant (bias opinion), it was my special snowflake (fact). After explaining the approach we took the new guys were able to run with it, but it wasn’t immediately apparent what was going on inside our heads for the past eight months.
I also realized there were several evolutionary changes in the second application of this architecture. The prior project did not benefit from this as there was no way to upgrade or backport these changes.
Oh the temporary lifespan of beautiful snowflakes.
But frameworks….
Frameworks on the other hand will have opinions about how to design your system’s architecture. They make it difficult, but hopefully not impossible to stray from the conventions they impose. I get frustrated sacrificing this control, but soon I tend to settle into the “framework’s way.” It may not be exactly how I would have done it, but I realize these the “bad decisions” are to satisfy the arbitrary requirements it must accommodate. Sometimes these get in the way, but hopefully the framework is providing enough of a productivity boost to overcome these smaller, less significant issues. I also find it interesting to learn from the design choices frameworks make. Designing to accommodate multiple designs teaches me quite a bit about how to devise my own abstractions.
Frameworks are not going to save you. They will not force you to do good. Some frameworks can get you into situations that are hard to get out of. This isn’t a ringing endorsement to always reach for them. Absolutes are always mostly ridiculous. But good frameworks enable customization while providing sane defaults for things you didn’t need to think about yet.
So after reflecting deeper on what Tony said, I felt a twinge of guilt. I was frustrated with Ember because learning all of its opinions was getting in the way of doing what I already knew how to do. But the reality is that its much more complete than Backbone and I need to consider the benefits of not creating another snowflake to melt. The jury is still out on Ember, but it’s already made me learn about MVC in cocoa and think about an app design that is different that what I already knew. For this I’m glad.
Software Development Services in Chicago and San Francisco with practice areas in digital strategy, human-centered design, UI/UX, and custom mobile and web application development.
