There are a few types of javascript styles that I've found are pretty common.
- Event Based (jQuery-esq)
- Class Based with router (backbone, marionette, et al)
- Declarative with routing (Ember, Angular)
Of those, I think the declarative applications tend to build out into easy to maintain systems. State management is easier, extending is easier, and most tend to build easy to digest components that are small and cohesive.
I've found that Ember scratches a number of itches for me when it comes to building out a declarative system. The biggest win for me is the fact that Ember's router is a really, really fantastic bit of engineering. The way that you can build out state into your router and have classes and components that react to those state changes is a super elegant way to develop web applications, for me. Combined with the outlet system for managing complex view trees, and it's a slam dunk.
Ember's system of routes, controllers, and views help me maintain single responsibility principles, because I have a clear definition of what a route does, what a view does, and what a controller does. Things are even easier when you get down to the refactor stage and start moving everything you possibly can into components (which are forward compatible with the upcoming specifications for web components).
The only reservation is that, because the style of MVC that ember follows, the learning curve can be a bit drastic. They've been solidly improving since 1.0 dropped and the wealth of materials out there that are outdated or old (pre RC days) are dropping off of the SERPs pretty rapidly.
Ember's a joy to work with. For 85% of the web applications out there, you probably won't need to venture out of the framework all that much. However, when you DO need to venture out of the framework, it can be a really frustrating experience. The primary example would be integrating something along the lines of D3 or Three.js, or honestly any library that expects to manipulate the DOM directly, as ember's reliance on handlebars is pretty complete. This means that having a view class manage user interaction events really can't be decoupled from the rendering of the view itself, which I feel like is ember's biggest issue right now. Secondarily, there is a personal need for better hooks for view lifecycle events, for providing things like animations / transitions in and out. animated-outlet is a potential solution, but I'd much rather do it the 'ember way' with hooks I can define in my controller classes rather than using a one-size-fits-all style solution (which is what I feel like animated-outlet is).
Don't let these things detract you from really diving into Ember. It's honestly a super refreshing and highly efficient way to build javascript applications. The state management of URLs within the router as well as the very clear and well enforced separation of concerns helps reduce code rot and smells before they even get started. Once you're past the initial learning curve, you'll be shocked at how rapidly you can develop robust, focused applications.
I've been working on a less-JS heavy declarative client-side library called intercooler: uses partials, REST-ful url conventions and declarative HTML5-style attributes to drive AJAX-based apps:
There are a few types of javascript styles that I've found are pretty common.
- Event Based (jQuery-esq) - Class Based with router (backbone, marionette, et al) - Declarative with routing (Ember, Angular)
Of those, I think the declarative applications tend to build out into easy to maintain systems. State management is easier, extending is easier, and most tend to build easy to digest components that are small and cohesive.
I've found that Ember scratches a number of itches for me when it comes to building out a declarative system. The biggest win for me is the fact that Ember's router is a really, really fantastic bit of engineering. The way that you can build out state into your router and have classes and components that react to those state changes is a super elegant way to develop web applications, for me. Combined with the outlet system for managing complex view trees, and it's a slam dunk.
Ember's system of routes, controllers, and views help me maintain single responsibility principles, because I have a clear definition of what a route does, what a view does, and what a controller does. Things are even easier when you get down to the refactor stage and start moving everything you possibly can into components (which are forward compatible with the upcoming specifications for web components).
The only reservation is that, because the style of MVC that ember follows, the learning curve can be a bit drastic. They've been solidly improving since 1.0 dropped and the wealth of materials out there that are outdated or old (pre RC days) are dropping off of the SERPs pretty rapidly.
Ember's a joy to work with. For 85% of the web applications out there, you probably won't need to venture out of the framework all that much. However, when you DO need to venture out of the framework, it can be a really frustrating experience. The primary example would be integrating something along the lines of D3 or Three.js, or honestly any library that expects to manipulate the DOM directly, as ember's reliance on handlebars is pretty complete. This means that having a view class manage user interaction events really can't be decoupled from the rendering of the view itself, which I feel like is ember's biggest issue right now. Secondarily, there is a personal need for better hooks for view lifecycle events, for providing things like animations / transitions in and out. animated-outlet is a potential solution, but I'd much rather do it the 'ember way' with hooks I can define in my controller classes rather than using a one-size-fits-all style solution (which is what I feel like animated-outlet is).
Don't let these things detract you from really diving into Ember. It's honestly a super refreshing and highly efficient way to build javascript applications. The state management of URLs within the router as well as the very clear and well enforced separation of concerns helps reduce code rot and smells before they even get started. Once you're past the initial learning curve, you'll be shocked at how rapidly you can develop robust, focused applications.