A Little Bit of History
Two years ago, I was dropped head first into a large corporate Javascript project. Our flagship application's front end at the time was being developed in GWT. It had become too large for its own good: long compile times, a complicated Gradle build process orphaned by a developer who had moved on to a new job, and, most importantly, the difficulty of incorporating new open source Javascript frameworks for things like graphing or animations.
My boss, the VP of Engineering, felt our pain and championed the decision to "forklift" our app over to a pure Javascript implementation. In hindsight, this was probably a too ambitious task given a team of Java developers with minimal and/or rusty Javascript skills. The project was a go, however, and we moved forward.
We spent a good amount of time up front reviewing our options. At the time, Ember and Angular held a lot of promise, but ultimately were too green for our project. We wanted to engage with an outside firm to help kickstart the project and develop some patterns for our team to learn from. We needed to pick something that would assist us in making the language switch without being overly prescriptive.
Enter Backbone
For the first 6 weeks or so, our team of two external consultants took our existing application and created a new framework, based on Backbone. The goal was for a minimally functional application, working end to end - authentication, consuming (existing) REST services, displaying data and persisting changes. A basic CRUD application that our internal team could iterate on.
Of course, our "partners" in Marketing insisted that there be no UX changes, no functional changes, and that it be updated with a new CSS makeover. Additionally, any internal application SMEs had long ago left the company, so any information regarding how a feature worked, why something might be validated in a certain way, etc. was to be gleaned from the existing codebase, written primarily by developers long since gone. Oh, it had to be done in 6 months, and this would be blocking any new feature development and potentially impacting our deliverables.
My team rose to the occasion. Given all of these constraints, they developed a good-looking, performant application that was identically functional in an amazing timeframe. The pace of this development did come at a cost: There was no time for reflection, refinement, or absorption. Development challenges would arise, square pegs were jammed in round holes, and we moved on to the next feature. Aha moments were never shared. But we delivered.
And Now?
In the time since then, I have taken on professional engagements with both Angular and Ember projects. There have been so many times when I have been able to quickly do something that frustrated me for days previously. This, however, is due to simply being more proficient and comfortable in the development space. Both of these frameworks introduce their own flavors of complexity and challenges.
Currently my team maintains and enhances a large, but relatively straightforward, Ember application. Even so, I hear complaints about not 'getting the framework' and developers feel they are 'poking around and making tweaks', having not really had the immersive indoctrination to Ember.
Personally, I have a number of side projects that I would like to work on. My biggest stumbling block is picking a technology stack to start with and actually working on the project part. I find I'll read about a new framework, spend some time dinking through the tutorials, have some minimal Todo MVC clone, and then be left where I started. So I set myself out a challenge.
The Challenge
Instead of working on a project for the feature set, I would work on building out a scaffold that I could then use as a starting point for a project. The scaffold had to be more than some directory structures. It had to be what I asked that consulting firm for a few years ago: A working end to end application with authentication, REST interaction, etc. Something I could start adding features to from the jump.
Recently, Derick Bailey wrote about "opinionated frameworks". This made me think that, even more so than the frameworks, my code is opinionated. I want it to work in a way that makes sense to me. Libraries and frameworks are great at speeding up development, but in many cases they abstract away the details too much, and obscure a fundamental understanding of what they are doing, and more importantly, why. I picked Backbone as my base and dug in.
This past weekend, from scratch, I built up the first iteration of the project. I did in about 20 hours what I formerly paid a couple guys to do in 6 weeks. More importantly, I understand every single line of code and why I put it there. Is it perfect? Hell no. Could it be improved? Of course, and it will be. What it is is tangible. I can fork the repo today and start building out a new app. Which, hopefully, now I will do.
Next Steps
Over the next few weeks, I will break down the app into chunks and talk about how it works and why it works. If you follow along, hopefully, you too will understand a little bit more about how a single page application works end to end. Whether you stay with Backbone or choose a more inclusive framework, I hope that you'll learn a bit more than following along with code samples from a contrived example.
Next Time: Tool Sets and Libraries