Short Musings On JavaScript MV* Tech Stacks
January 9, 2012
Lately, there have been a number of developers getting in touch to discuss the tech stacks for their web applications. In this short post, I'd like to focus on the JavaScript side of some of these conversations.
We're at an interesting point in time where not only do we have mature solutions to help organize our scripts based on modularity and separation of concerns, but developers looking to build non-trivial applications are almost spoiled for choice as application architecture has finally gotten the level of attention it deserves.
Maturity in software (framework) development isn't simply about how long a framework has been around. It's about how solid the framework is and more importantly how well it's evolved to fill it's role. Has it become more effective at solving the problems developers use it for? Has it done it's best to adapt to the needs of the market? Some MVC/MVV/MV* frameworks have strived to meet these goals. Let's review some examples.
Frameworks such as Backbone.js have continued to improve and evolve over time as developers build larger and more complex applications with it. For those that perhaps prefer variations on it's flavor of MV*, there's of course an abundance of alternatives such as JavaScriptMVC (Justin Meyer has managed to get the size of many core components down over the last month or so), Ember.js (which is looking like it's going to provide an even more kick-as version of SC 2.0), Spine.js (for CS enthusiasts, which some will say is too similar to Backbone, others will say works better with CS), Knockout and more. As a developer, although it can, on occasion, be painful to see a new architectural framework released each week, I'm happy that if a developer prefers a particular pattern for writing applications, theres likely someone already working on a solution that helps with this regardless.
Understandably, a fraction of the MV* frameworks that have been released in the past year could be seriously considered for use in the production of large applications, but some certainly of the better ones are (and have been) use for exactly this. This is great to see. Regardless of your thoughts on the quality of validity of such frameworks, I think we can all agree that we're in a much better position than we were when developers were writing spaghetti code in single app.js files.
Whilst it may also be controversial to say, it's no longer as black and white as saying "you're simply making a mistake if you're not using Dojo". We probably couldn't have said this a year ago where both communities were still debating over the validity of jQuery for creating 'big' applications. I think we've all moved on beyond that to appreciate DOM manipulation libraries are only a very very small part of building large applications and attention has shifted moreso towards what architectural frameworks can provide to help applications scale.
Asynchronous UIs? Dynamically loading in modules as-needed to improve performance? Intelligently templating widgets? These are the conversations I'm having with intermediate-level developers at the moment and I couldn't be more happy that conversations have shifted more towards tackling larger concerns. To some (more experienced) developers these problems will sound trivial, but I'm hopeful that it means the times ahead will see us focusing on even smarter, better architectures for our applications.
Dojo is still a very strong solution for serious app development (and do invest some time in at least considering it), however, some of the developers writing in have found the level of documentation and assistance available from the community not as great as one might find in the alternatives. (I absolutely *love* that Dojo have moved in the direction of AMD and my hope is that assistance in that community improves). Btw, if you haven't checked it out yet, the Dojo Boilerplate project might be of interest.
Almost all frameworks are in a state of flux, trying to identify and address what concerns are most important to developers using their solutions and I think in time, it'll really come down to preference on style and approach.
My ideal stack
Moving on from this..I was asked what my ideal (current) stack would be if I was to develop a large application today. Whilst I don't in any way advocate this as a blanket solution for all (seriously, do spend time reviewing all solutions, including Dojo), but my stack would probably be:
- Backbone.js for lightweight MV*
- Require.js + AMD + RequireJS text add-on (to assist with external template management)
- Backbone.js LayoutManager (if you require some more intelligent layout management)
- jQuery for DOM manip.
- Handlebars.js for templating, unless you're doing something simple, in which case, opt for Underscore's Micro-templating
- r.js for handling script optimization
- Jasmine + Jenkins for testing and CI
- Node.js + Express (speaking of Node, Miller Medeiros has an excellent write-up on how to use it as a build script)
- MongoDB as a noSQL data-store
I know that some developers may ask why using a multitude of independent solutions may be better than opting for something all encompassing. For me it was merely a personal preference. I view it all as 'just JavaScript' and if someone releases a better say, templating engine - I'll simply swap out Handlebars, update my template syntax and voila.
This approach to building custom stacks works well if you a) know what you're doing and b) are willing to invest sufficient time to really researching your options, but it can and does work. Just make sure to keep your mind open to using the different solutions available, whether it be Dojo or otherwise and you'll (hopefully) be fine ; )
SO/Quora Discussions comparing frameworks:
Backbone.js vs Angular (mainly Angular)