Over the last two years I have converted from being solely a Microsoft-stack developer into using a mix of technologies. I no longer shy away from tech just because I might need to switch over to my Linux distro to get it fired up. I love to try out new things if for no other reason than just to see how easy it is to use and find out more about why people are adopting it. I have gotten to where I prefer to use Sublime Text as my editor instead of Visual Studio. I like the ease of development that Linux offers me on my dual boot Win 8 / Ubuntu system and how powerful the terminal can be. I still prefer Windows for my every day computing, but I can understand the other side as well.
Sometimes it seems that people on the other side hate on Microsoft technology just because they are so open source. It makes sense sometimes when they argue that Microsoft charges for everything where open source tech is generally free, but to call C# and .NET bad compared to PHP or Python development is mis-informed, but that’s another post entirely. I bring this up because in my quest for the perfect client-side framework I have stumbled upon something that is so open-source and community driven yet is embodying that which I feel is the perfect framework.
Of course it sounds cliche to say the new tech I am adopting and learning is the next greatest thing, but the truth is it is amazing. Say what you want about the .NET framework and ASP.NET MVC and how much overhead is provided that is not needed, but you can’t say that it’s hard to use or slow. The overhead that is provided is there to make the technology easy to learn and use. It’s so easy in fact that it conventionally provides controllers, views, and mark-up for said views to basically build an app from scratch without having to write any code at all. For the purist who loves to build everything from scratch this can be a real pain, but for new developers and for a team of developers who need to share the code base and build a product together this is invaluable. It offers the team a convention to follow to build something great. Why does that matter? Because Ember.js is the new ASP.NET MVC.
Ember took a long time to build. I don’t need to give the history (you can Google that if you wish) but the fact is the core Ember team took a long time to get things right. The early adopters spent countless hours building Ember apps only to have huge breaking changes come. Features were deprecated to get things right. I admire them but I am glad it wasn’t me that had to go through this growing phase. I had applications that I had to build and I built them in a framework that I loved. The problem was that the community for that framework never grew out of the small niche of developers who realized the power and simplicity of it. I plan to write another post on the topic, but the reality is if you want good quality dev’s you have to use technology that excites and draws good talent.
So why am I writing this post? After spending three long weeks of researching Ember.js and trying to understand what problems it solves I had my aha moment – the answer was always there right in front of my face but it was so simple it was hard to comprehend. Ember provides everything by convention. If you don’t build controllers, it builds them for you. Want to change the model from a single item to a collection? No problem, just do it. Ember is so opinionated about the future of the web it doesn’t wait for someone to tell it how to build it – it does it for them.
In a pure Ember application everything can be broken down to routes and resources, and resources and routes. It’s so simple that the first time you see it that it is hard to fathom that a web application can be reduce to that level of simplicity. Web Components can be delivered in many different ways. Views can be rendered or created as partials. Any way you spin it it’s already defined on how it should work and what Ember will do to provide it to you.
Ok, Ember.js is awesome, why should my team adopt it?
One of the biggest complaints about Single Page Application frameworks such as Angular, Backbone, Durandal, and the like are that it’s hard to scale. It’s not hard for a developer to scale the application if they know what they are doing, but when that developer leaves the company it’s hard to scale the application to other developers. Instead of spending the necessary time to learn the technology and scale it most developers see working code and are afraid to hack at it. Ember provides conventions that are easy to follow and therefore it’s easy to look at another developers code and understand what it is doing. This makes building an application that can be shared between many developers easy. Being that Ember promotes code organization and the separation of concerns so well it is no surprise that the application is easier to break out when it grows. The main problem that I have so far is that Ember-Data tries to tackle more than it should – which is why I hope to soon finish building out a Breeze plug-in to use with Ember and provide rich queryable data.
In a time when everyone talks about Angular just because it’s the ‘next big thing (from Google)’ it’s really refreshing to see something that is both more opinionated and easier for developers to understand.
Please feel free to leave comments on why I am wrong or how to help others may land here find bliss in Ember.js