« Ember is Hard, Part 2: Conventions are Good

I have heard it said that Ember has a steep learning curve, usually in a complaining tone. Though that might be true (I would argue that is isn’t), I don’t think that is a valid reason to skip over a technology.

Most things in life worth doing are hard

I see two situations when deciding on a technology, personal project/ growth and corporate teams working on their company’s product.

If you sit in camp one, someone looking for growth or a framework for new project, I say ‘don’t let the mountain of learning something new scare you and don’t let other people’s negativity sway you.’ there is a lot of negative talk, and people, that find any reason to blame something else instead of admitting their shortcomings.

If you sit in camp two, you might think a learning curve is going to slow on-boarding for new hires and you might be right in some cases, but the things that make Ember hard at first are also the same things that make Ember a delight down the road. The conventions put in place will actually speed up on-boarding (similar to the way they do in rails) for anyone with framework experience. The conventions will also speed up development dramatically as your app grows.

A homebuilder doesn’t build a home without some blueprints to work from. Learning how to read those blueprints, in order to lay the correct foundation and start framing up the house, probably has a steep learning curve, takes some time, and even working with the architect before things really get moving. But that allows the contractor to move quickly once everything’s in place.

Do you want to spend your time creating those conventions at your place of work?

As software developers, we don’t get the option of not building the conventions we work in everyday. we are either wittingly or unwittingly building them everyday. Declaring a list of Javascript libraries that you are using is not building good conventions. That is like buying all the tools and supplies without a plan.

If we look at what goes into building software, we can start to se how we can easily miss a lot of really important practices, and loose a lot of time, if we do not have clear goals and guidelines for building.

So define what your blueprints need to cover and ask yourself, ‘do I want to build my own conventions, or should I spend the time to learn a framework that has done that for me?’ Please do one or the other, otherwise each member of your team is going to have their own conventions and your app will start too look more like the horrible spaghetti we all fear.