indiesquidge
commented
9 years ago Intro
Tom is very much a counterpart of DHH. The ideas and principles behind Ember seem to mimic the ideas and principles of Rails, which Tom even points out at the beginning of the podcast. Tom and the Ember team saw that people were struggling with the modular, less mature community of JS frameworks and built Ember to try and create an easier solution that would sacrifice some compromising and open-mindedness and gain a set of conventions making it less complicated to get up and running, much like Rails.
Ember's Goal
Ember's main focus, as with many JS frameworks, is to bring the architecture of client-side, native mobile applications to the web. The processing power of our client side machines (i.e. your iPhone 6) is quickly becoming more powerful than some remote servers, yet that power is rarely used efficiently.
Angular vs. Ember
I really loved the part that discussed the differences between Angular and Ember. Angular seems to be great for sprinkling into existing server-side apps and being dramatically less opinionated about the structure. Ember kind of sees the latter as more of a con than a pro however, since they believe that a more dogmatic approach allows teams to move quickly, not get caught up in arbitrary choices, and onboard new team members with ease since they will be familiar with the conventions. This is exactly the same reason I love Rails apps, and why I could see Ember as a nice framework for larger teams with a long-term application. On top of that, Ember also emphasizes client-side routing and simply having your app as site that hits an API. Kind of seems like the best of both worlds in a lot of cases.
Building a Foundation for Users
I also really loved how much Ember highlights the idea of gaining user trust and working on compatibility. Tom mentioned something he called "stability without stagnation", which is to move forward, advancing the "state of the art" technology in your app, while still maintaining backwards compatibility. They limit themselves to six week sprints for new features, so there can never be a huge overhaul of the codebase, which seems like quite a large pitfall to Angular. This focus on user satisfaction and maintainability is also fantastic. Tom is very convincing about his opinions (much like DHH), but many of his views truly seem like they are spearheading the direction of development in the JavaScript community.
Concluding Thoughts
I must say that after listening to this, I was much more convinced of Ember's superiority than beforehand. However, as I develop more and more, I am realizing how limiting conventional web frameworks are. The opinions of Rails are often a nuisance, and I could see the same problems emerging in Ember. Of course much of my opinion is speculation, as I have never used Ember. The way it is described on paper is honestly fantastic, and I could see it being an amazing way to create client-side apps that gains popularity the same way Rails did.
A problem I see particularly for Turing is how finite our time with Ember would be. We have spent the last five and a half months building our Rails knowledge and we are still very novice. We would have only a few weeks to dabble in Ember, having to learn a whole new set of rules and opinions to code by. While this would be challenging, I still think it would provide a great introduction and gateway to full-stack JavaScript apps, and I would love to try it out.
Optional discussion here about Shop Talk: Tom Dale (1.5 hours). Do you agree with Tom? What parts of his argument are compelling? What parts do you disagree with?