We’ve been using Ember 0.3 and then 1.4 for about three years now, building everything with require.js, for single-page apps using ASP.NET MVC in the backend. I’m working with my team on moving to the new Ember 1.13 / 2.0.
If it were up to me, I’d just use Ember-CLI. It streamlines doing everything we want. It enforces doing everything I should. I’m not happy with build performance, but I can live, and I’m hoping it will improve - is it any better if we build in grunt?
However, other members of the team aren’t sold on Ember-CLI:
- Built JavaScript means they aren’t editing the precise source stream that they’re debugging.
- One of the things they like about JS is that it’s pure edit/browse/debug, not edit/build/browse/debug.
- Broccoli’s build is sluggish on Windows - about 10 sec after adjusting indexing and antivirus.
- They like command/response, with full control of what they do when
- Ember serve’s fire-on-save, with lint, test, and autoreload are too “helpful”
They would like to use the new Ember architecture in pretty much the same way they worked with Ember 1.0, using the same surrounding tools they used before - Require for modularity, Jasmine for test, existing jQuery-UI components for controls wherever possible.
- Can we develop with Ember 1.13 using Require/AMD for modularity, with no transpilation?
- Can we complie ‘.hbs’ files on first component instance initialization?
- How do we apply AMD to interact with the new resolver so that Ember finds our pieces by convention?
- What do we have to look out for in particular?
- What new common practices outright won’t work?