3 ms·

I've been interested in using Ember.js in the frontend for a Rails app, especially after watching a mock competition between it and Angular [1]. But it's beta s

by ehsanu1 13y ago

I've been interested in using Ember.js in the frontend for a Rails app, especially after watching a mock competition between it and Angular [1]. But it's beta status kept me from using it, and even now I wonder if it really is production ready, or just API-stable (which they say they will be as per http://semver.org/ http://semver.org/). I also don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product, especially while at a startup trying to set an aggressive release date for the product. I'm also a bit worried about the need for everyone on the team to learn how Ember works and its conventions, when they already know how to figure out whatever mess of ad-hoc jQuery and random objects someone would write instead (as bad as that is for maintainability). And finally, I won't have the advantage of green field development, as there is an existing app which will be added to. So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all.. Which does not seem ideal. Anyone want to chime in with their experiences? [1] https://vimeo.com/68215606 https://vimeo.com/68215606 - Note it's a bit unfair with the project lead for Ember, tomdale, on one of the "cage match"

sandstrom 13y ago
We've used it in production for quite a while, and it has worked well for us. We gradually moved our previous jQuery-implemented app onto Ember, so it's certainly possible to do it in stages (we still have a minor section which we haven't moved yet, because it's up for rewrite regardless). There are still improvements to be made, but we're certainly happy to be using it live.
gavinjoyce 13y ago
> I don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product This is true when considering the introduction of any new technology or when to pay down technical debt. The answer for you will likely depend on the complexity of the product that you are building, how important a great UX is, how close you are to shipping something, and whether the promise of building a clean and scalable browser application outweighs the short term benefits of delivering a "mess of ad-hoc jQuery and random objects". I've worked within a medium sized team building a large Ember application and have seen first hand how beneficial it can be when dealing with application complexity and a need for precise UX attention to detail, even when using a much earlier version. I've also experienced frustration with the documentation and quickly moving goalposts as the framework evolved towards v1.0. Happily, everything has become so much easier in the last few months. The documentation and guides are now a fantastic resource after a huge push from the team and community. The framework itself requires much less boilerplate code, Ember automatically generates controllers, routes and views at runtime should you not need to customise their behaviour. The addition of support for promises across the framework has resulted in more terse and consistent application code. I've found the community to be very helpful and I'm excited to see how it will grow over the coming months. > So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all. I'm helping a client do exactly this at the moment. Their current application consists of a many pages with ball of JavaScript and jQuery sitting on top of their clean REST API. They want to raise the bar for what their application can do and the medium term goal is to deliver a single page Ember application. In the short term, we're building some of the most complex new features in Ember. These features will be accessed through modal iframes for a time allowing us to build out the Ember application without having to rebuild everything.

by ehsanu1 13y ago

sandstrom 13y ago

We've used it in production for quite a while, and it has worked well for us. We gradually moved our previous jQuery-implemented app onto Ember, so it's certainly possible to do it in stages (we still have a minor section which we haven't moved yet, because it's up for rewrite regardless). There are still improvements to be made, but we're certainly happy to be using it live.

gavinjoyce 13y ago

> I don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product This is true when considering the introduction of any new technology or when to pay down technical debt. The answer for you will likely depend on the complexity of the product that you are building, how important a great UX is, how close you are to shipping something, and whether the promise of building a clean and scalable browser application outweighs the short term benefits of delivering a "mess of ad-hoc jQuery and random objects". I've worked within a medium sized team building a large Ember application and have seen first hand how beneficial it can be when dealing with application complexity and a need for precise UX attention to detail, even when using a much earlier version. I've also experienced frustration with the documentation and quickly moving goalposts as the framework evolved towards v1.0. Happily, everything has become so much easier in the last few months. The documentation and guides are now a fantastic resource after a huge push from the team and community. The framework itself requires much less boilerplate code, Ember automatically generates controllers, routes and views at runtime should you not need to customise their behaviour. The addition of support for promises across the framework has resulted in more terse and consistent application code. I've found the community to be very helpful and I'm excited to see how it will grow over the coming months. > So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all. I'm helping a client do exactly this at the moment. Their current application consists of a many pages with ball of JavaScript and jQuery sitting on top of their clean REST API. They want to raise the bar for what their application can do and the medium term goal is to deliver a single page Ember application. In the short term, we're building some of the most complex new features in Ember. These features will be accessed through modal iframes for a time allowing us to build out the Ember application without having to rebuild everything.