permalink

23

Short Musings On JavaScript MV* Tech Stacks

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 Ember.js

Backbone.js vs. Spine.js

Backbone.js vs Angular (mainly Angular)

Backbone.js vs. KnockoutJS

23 Comments

    • My stack looks almost like that. I haven’t used Backbone Layout yet; I use Backbone-Relational for a lot of stuff and I like DrizzleDB more than any of the NoSQL solutions I’ve seen yet.

      But my biggest shift has been using these tools in a HAML/Less/Coffeescript environment, pre-compiling out the templates, CSS, and Javascript, and assembling them with r.js. I have a boilerplate Cakefile for doing this and use inotifywait to build on-demand as I code. Addy’s right that there is an embarrassment of riches out there at the library level, but the dev environment has also become powerful and useful too.

      And I couldn’t figure out HOW to use Require.JS until ThomasDavis published the source code to his examples; once he showed me what worked, I was able to plug in my own code, and that made all the difference.

  1. Alexander Mackay-Austin January 9, 2012 at 8:38 am Reply

    Ahh the old framework vs rolling your own debate. Great article! Gives us developers more confidence that rolling your own can work. There are some new ideas on here for me also. How would you say rolling your own compares to frameworks in terms of effort?

  2. I’ve been using Dojo for serious app development since about 1.1 and have several fairly large, successful customer projects done that way. I tend to go the Zakas way with a sandbox/app object and quite a lot of pubsub to control the state of the app, which then by necessity is very uncoupled.

    I really love the creativity and the pure research that is being done in all the new frameworks, but for me there haven’t been a reason to use anything else than Dojo. I promise that I would have added something else if needed. No, wait – I have used persistence.js for a mobile app, but as for infrastructure Dojo is a sweet spot.

    The problem with using your approach above is of course that you are now dependent in several frameworks fro bugfixes, updates and future compatibility issues.

  3. I’ve been using a nearly identical front-end stack as yours, except I found backbone-relational to be a lifesaver, did not use the backbone layout manager, and happened to pick jquery-tmpl for templates. Additionally, I wrote my own connectivity manager and offline synchronization module, which was a PITA.

    For UI, I’ve used jquery mobile in a couple of projects and custom HTML/CSS for the most recent one (plus a slew of other libs for mapping, data visualization, etc.) and I have mixed feelings about jquery mobile.

    Sometime this quarter, I plan to do some experimentation around using rhoconnect.js (https://github.com/rhomobile/rhoconnect.js) with backbone models. If this is something that could be of interest as a section in your backbone-fundamentals book, it would greatly speed up my experiments ;-)

  4. For our games we’re using coffeescript + Backbone with some heavy extension + requirejs + mustache. Works well – Backbone covers the basics and is small enough for everyone to pick up quickly. Extensions allow us to cover our specific needs.

    For testing: jsTestDriver to allow us to easily test lots of browsers on the CLI. It’s also hooked up to our CI server (http://tech.picklive.com/2011/12/02/continuous-integration-for-internet-explorer.html).

  5. I usually try to go with the grain of web, not against it. This usually means progressive enhancement and looking for ways of leveraging everything the browsers can do natively.

    UI/Behaviour is usually contained in simple constructor based objects that communicate with the rest of the system using publish/subscribe. Simple controllers take care of hard coupled dependencies, like communicating with data layer (that completely abstracts away communication details). Mustache.js (@janl) and event delegation keeps things simple and tidy (and progressively enhanced). Low level stuff like DOM, Ajax, cookies is handled via libraries (am looking to replace jQuery with something much, much lighter). Most of the code is higher abstraction, pure JavaScript that would work equally well with other libraries.

    Zakas’ talk at FullFrontal 2011 felt like a complete validation of what I’ve been doing for that past few years.

    For testing I use Sinon, and am in the process of replacing JsTestDriver with BusterJS (if you haven’t tried BusterJS yet, you should https://github.com/mroderick/try-busterjs, takes 10 minutes).

    I am constantly on the lookout for better documentation tools, perhaps someone needs to bite the bullet and do a comparative blog post on those? (I might even do that myself).

    • I’ve been trying to improve my tdd approach to ajax, and while sinon provides a way to collect what was sent to ajax, you have to set up some ugly timer and callback to test after the ajax has completed. I use jquery quite a lot for ajax, so i felt it was an obvious choice to create a jquery like facade for testing ajax using sinon.

      Feel free to have a browse. You might find this helpful, but it only works with qunit currently.
      http://www.jqueryspy.com

  6. Pingback: Short Musings On JavaScript MV* Tech Stacks - EtondeGroup Blog of Web Applications | EtondeGroup Blog of Web Applications

  7. I sincerely appreciate the guidance on this!

    I’ve just started learning JavaScript with mobile development as my goal. Although it’s exciting to have so much going on in the development community, it’s like drinking from a fire hose.

    As with everything, I’ve started with the basics – learning JavaScript first while dabbling in a few frameworks to keep it interesting. Coffeescript looks interesting but I want to make sure I understand what is going on under the hood before I start using it. The way I learned C back in the “old days” by examining the intermediate compiler output in assembly.

    I’m also trying to learn the patterns and anti-patterns for mobile development. I have a classic client/server desktop background and have a lot of baggage to unlearn.

    Thanks again.

  8. Pingback: A very basic comparison of some of the JavaScript MVC libraries — Vytautas Jakutis

  9. Something to consider that you did touch on is the language the framework is authored in. For me Spine.JS being authored in CoffeeScript is a HUGE win. I learn by reading code and reading source CoffeeScript is as enjoyable and informative as reading ruby source. I am only a few weeks into my first Spine.JS project but I am already learning tons about jQuery, CoffeeScript and general JS patterns by reading the source.

  10. i appreciate the list, currently this will be my 2nd year using JavaScript and to be quite frank, i think its a lot better compared to then,now there are tons of Frameworks that readily fulfill your requirement like the other day i working on Mobile web project on Dojo packing all views into one html, and had the idea of json defining scenes like Nokia Guarana UI back then, not knowing dojox.app already existed for such. i tend to keep to Dojo and maybe later look into Backbone.js as it looks promising but seriously its even harder to select from this frameworks, today its batman.js tomorrow its angular.js

  11. Have you already checked ExtJS4? This version also follows the MVC pattern and while the framework is quite heavy, it can be interesting for large scale web apps. And don’t forget Sencha touch, the smaller framework for mobile development.

  12. One of the things that attracts me to Ember.js is the data binding. It’s a common pattern to listen for an event (such as a data change), and then grab the appropriate element(s) from the DOM when that event occurs and update them. Some of the frameworks (Ember and Knockout, for example), perform those operations for you automatically, keeping the UI in sync with your data with the only code being the code that sets up the relationship.

    I have used and like Backbone, but the lack of bindings is irritating to me.

  13. I was trying to figure out what “SC 2.0″ and “CS enthusiast” mean, but I couldn’t, and the terms are too generic to google. Sorry for the noob question, but could someone help me out?

  14. Nice write up.

    I am not convinced by the frontend industry’s coining of frameworks using MV** specially MVVM.

    The ViewModel itself is acting as the mediator (GoF mediator pattern), in that it tries to know things on both side Model and View.

    Another way of looking at it is, a View resolver+Renderer would ideally be dealing with Model Data and View Template. Probably MVVM exposes too much flexibility and it could become messy quite fast.

  15. Great post. I’m trying to get started in an Angular env based on a recommendation. But I appreciate coenraets “Node Cellar” demo (http://coenraets.org:3000/) He’s using Backbone.

    fwiw underscore handles inline code within the template itself. Most of the “simple” “micro templating” examples I’ve seen show inline in-code replacements, but you can add your template to your html page with a <script type"text/html" and do some repeater like _.each statements within the template using <% (instead of <%=. See my answer on SO for a quick demo.

    http://stackoverflow.com/questions/4778881/how-to-use-underscore-js-as-a-template-engine/10389847#10389847

Leave a Reply

Required fields are marked *.