we write about the things we build and the things we consume
Dan Govan

my first backbone.js

I’ve worked with a few javascript MVC frameworks before, but I’ve never used one to build something from the ground up. It’s been really interesting not only because of that but because I was working on something that had already been fleshed out in the proof of concept stage, so I figured it would be fairly straightforward to lift the bits that we wanted to keep from the old code.

BUT NO!

the journey

Normally with the scripting I do it mainly involved finding out how to do something, doing it, and fixing the edges. But with setting the foundations for a larger piece of work it’s important that things are done the right way, just working isn’t enough. Naming conventions and coding standards are assumed.

A good place to start is splitting all the JS into separate files, one each for models and collections and all the various kinds of views but even that’s not mentioned in most Introduction to Backbone tutorials for more thorough reading backbonejs.org is a great resource but hardly a breezy read at 30,000 words. But it doesn’t talk about how to organise your code either, nor the difference between a panelView and a PanelView, and the documentation for Handlebars is similarly fuzzy in places.

That seems to be an inescapable problem with these frameworks, the thing itself can be as lightweight as a feather but their documentation is never as fun to keep up to date as they evolve organically from many contributors, leaving redundant third-party guides littering the interwebs like Ozymandias’ discarded sandals.

But where was I. Ah yes, standards. So basically to gain The Knowledge in a decent amount of time and be sure that the foundations I was laying would remain mostly useful I had to pester the resident Backbone savant Luke into nodding sagely or cursing with scorn when I did… Well most anything really.

conclusion?

I don’t really like it. There’s no neat little functions to comment and then build into something larger, everything has to be wired into the the wider framework, data bouncing back and forth between views (explicitly thrown and explicitly caught), there’s repetition of code as you write similar functions in different views, you need to have 3+ files open to see what any given thing is doing, and at the end of the day you have to call in a litany of javascript files into the html; nails down a chalkboard for any self-respecting frontender.

Maybe this is just counter to my dev philosophies of going with the grain, maybe there’s another MVC that’s better suited to how I’d like to work, maybe I’m just doing it wrong. But in spite of that we got something working according to the right standards and conventions and that’s a testament to the power of communication. And Luke’s patience.

over to you

So what’s your favourite framework? I’ve worked with Angular and Ember as well as Backbone and they each feel very different, enough to make me think that there might be one out there that I’d get on with just famously. (Though from what I hear on the twitters, React doesn’t count.)

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

blog comments powered by Disqus
sign up to #metabeers
slideshow