What’s Next? SPA 2.0: The Latest in JavaScript Application Frameworks

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.

At work, throughout 2013, 2014, and now into 2015, I have leveraged this momentum to educate cross-discipline teams of developers and designers and execute some very ambitious JavaScript applications for numerous clients. In a rapidly changing environment, it has been a pleasure to grow a team that now possesses framework-level expertise, allowing us to rapidly iterate on application feature sets without having to reinvent the wheel.

O'Reilly's Building Web Apps with Ember.js by Jesse Cravens

For me, all of this has been a culmination of experiences that started in the mid 2000s with PHP and Flash work while doing small business web design and CMS development, to large scale production of JavaScript and mobile hybrid apps in the late 2000s, and to now UI/UX focused, enterprise, rapid application development.

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.

What’s Next?

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.

My latest talk: SPA 2.0: The latest in JavaScript frameworks will address these questions:

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?