An Early Adopter of Ember
Outside of architecting and developing complex web apps during my day job at frog design, I spent a good part of 2014 finishing up Building Web Apps with Ember.js, teaching Ember.js workshops, and giving a talk entitled: “The Art and Science of Shipping of SPAs with Ember.js.”
Each of these focus areas were obviously complimentary: the workshops serving as deep dives, the talks as the high level summaries, and the book and companion source code serving as a reference application and detailed documentation.
Perhaps, this excerpt from the prelude of Building Web Apps with Ember.js explains my stance for the last couple of years:
Since 2009, I have worked on numerous applications using Backbone, Angular, and Ember. But today, I often recommend Ember.js to the clients I work with. This is primarily due to the fact that the conventions support well-known web application development patterns that I have custom written or pieced together from multiple open source libraries. Here, are the high level concepts that, in my opinion, make Ember so valuable:
- Ember’s object model supports a classic and well understood, object-oriented pattern of class inheritance through extend, object initialization, getters and setters, and class monkey patching.
- Ember models, controllers, and components extend the Object class, which ensures that these objects inherit Ember’s powerful default data binding.
- The router supports complex nesting for URL-driven applications that manage application state in a conventional way that can be understood by those with web-server-routing backgrounds.
- Recently, build, workflow, and testing tools in Ember have matured and become intuitive.
- Ember’s only dependencies are on jQuery and Handlebars.js, two very wellknown and documented libraries.
- Finally, the community is vibrant, passionate, and extremely active.
Most recently, I find myself moving into a new phase that mirrors the needs and concerns of the clients I interact with on a daily basis: navigating the SPA landscape and making future friendly decisions based on the complex solutions matrix that is now Ember 2.0, Angular 2.0, and current React/Flux.
What does the future hold for the building of complex applications on the Web Platform in 2015? How do we manage the complex SPA landscape, and help our clients make future friendly architectural decisions?
Will an Angular 2.0 breaking rewrite send devs running for something better? Can React/Flux community offer a complete application framework solution for complex applications? Will Ember continue to evolve into a lighter framework that can shed it’s ‘monolithic framework’ reputation?
As the Angular and React communities adopt the Ember Router and the Ember community is inspired by React’s Virtual Dom to take advantage of it’s existing under utilized view graph, the communities are adopting the best of each other. In what other ways are the individual framework communities learning from each other?
Will native, cross browser web components become a reality? What is the IE roadmap in regards to custom elements, HTML templates, HTML imports, and shadow DOM? Will we begin writing web components in Ember without the use of handlebars syntax?
Will functional reactive ‘stream’ patterns become common place with better integration into frameworks, as promises did in 2014?
With ES6 modules ( and transpiler build steps ), as practitioners can we finally lay the JS module debacle to rest? Do Isomorphic JS architectures still make this a challenge?
SPA 2.0 Topic Areas
Here, are the areas my talks will focus on in 2015:
- Framework Maturity and Stability
- Developer Ergonomics, Tooling, and Front End Ops
- View Performance and Mobile
- Async Router
- Data Binding (1-way , 2-way use cases)
- ES6 modules
- Web Components
- Community and Documentation
- Release Cycle
- Client Side Data Stores
- Services and JSON Specifications