Out of Angular Part 1 — ES2015
AngularJS brought much fanfare when it first came on the scene. At ecobee we were quick to adopt it as we had the ecobee3 web portals and mobile apps to build in an 18 month timeframe. 2-way data binding, dependency injection, testing. Angular ticked a lot of the boxes we needed for the new build.
Fast forward 3 years, we had a great hub and spoke model that powered 6 cordova based mobile apps and 3 web portals. This was a huge accomplishment for a team of 4 in that timespan and we wouldn’t have been able to do it without angular.
Angular wasn’t without its share of problems though. The scope, the overlap of .controller and .directive the naive dirty checking, massive testing boilerplate, the list goes on. Still Angular was providing huge value to us.
React was one of those up and coming technologies I was keeping an eye on but at the time there wasn’t an overly compelling reason to port. Our view layer wasn’t where we had most of our problems. Then Angular 2 was announced and angular 1’s decline would be inevitable.
The team needed to figure out what to build out new functionality on but was it going to be React? Ember? Polymer? Angular 2? The one constant between all of these was es2015 so we decided to start there.
Over the holiday break 2014/15 I ported all of our core library code over to es2015 and introduced babel + webpack to bundle everything. With the foundation in place we were able to reap the rewards of working with imports, destructuring, arrow functions and proper scoping.
I had been exploring the react ecosystem at the time but it wasn’t until Elm / Redux came on the scene that there was a really compelling reason to migrate any code. It wasn’t advances in the view layer at all that fuelled our next step. It was the data store. Flux was nice, but still suffered from having dependencies between the various stores, the same issues we fought with angular services. Redux changed all that.
Up next. A problem with our apps gives the leverage we need to bring in Redux.