11–20 of 88 posts
i think it's nice to see some javascript design patterns!
i think design patterns are either A) a lack of necessary abstraction - or - B) a sign of unnecessary complexity
Not that magic is a bad thing. Magic is what makes Rails good at what it's good at. The downside, though, is that magic-ful frameworks often obscure language mechanics that an inexperienced user of the language would do well to understand. Thus, Rails is awesome for a programmer who's already good at Ruby, but super frustrating for someone learning Ruby.
On the other hand, Backbone makes idiomatic use of javascript and lays it on the table in a magic-less way. So not only does a new javascript programmer not have to deal with confounding magic, they can also learn from how Backbone uses javascript, and apply that knowledge outside the scope of the library.
I'd never thought of it this way, but I think this is probably one of the most important distinctions between opinionated, magic-y frameworks, and things like Backbone.
Backbone has totally changed all of that - learnt so much about design patterns in such a short space of time - shout out to Addy Osmani for writing such down-to-earth, approachable content.
Totally agree with this post - I was a 'JavaScript =~ jQuery' guy before I picked up Backbone - writing hopelessly average jQuery spaghetti (with the best of intentions - I'm a designer and had never looked at JS as a programming language. Backbone has totally changed all of that - learnt so much about design patterns in such a short space of time - shout out to Addy Osmani for writing such down-to-earth, approachabl…
Backbone is one of those libraries/frameworks/whatever that avoids magic. It's just a pile of reusable parts that make building big javascript applications easier. One can't say the same about, say, Rails. There's a lot of magic in Rails. Not that magic is a bad thing. Magic is what makes Rails good at what it's good at. The downside, though, is that magic-ful frameworks often obscure language mechanics that an inexp…
Using Backbone in no way obviates the need to learn about how browsers work in the end, but it does make it a hell of a lot less painful for you to engage in that process.
also +1 for literate code as a mechanism for learning more about what Backbone's responsibilities and defaults are.
OT: I keep trying to get into backbone but I just get driven crazy by `get` and `set`. Inspecting your object feels like a world of pain, which is no fun when I'm playing with code. And it also makes it feel like you're not programming js any more. Quite a few years back an old company I used to work for had a similar framework and perhaps it's just latent hatred for that rather annoying framework. I know it's a limi…
> perhaps it's just latent hatred for that rather annoying framework
The reason why you need `set` is so that you know when to trigger `change` events. Getters and setters aren't going to fly if you need to support Internet Explorer. One alternative is the Angular.js tradeoff, where you're setting regular properties on vanilla objects and arrays ... but then Angular is going in behind the scenes and traversing all your objects and computing the diffs for you, every time a change might occur.
... in the end, you start to appreciate the transparency of avoiding getters and setters in JavaScript. It's a very nice thing that whenever I write `obj.a = b` -- I can know that that operation has no side effects, and won't trigger any outside-of-the-box behavior. Conversely, whenever I write `model.set('owner', 'Moe')`, it's nice to know that this is the point at which the rest of the app will react to that change.
Totally agree with this post - I was a 'JavaScript =~ jQuery' guy before I picked up Backbone - writing hopelessly average jQuery spaghetti (with the best of intentions - I'm a designer and had never looked at JS as a programming language. Backbone has totally changed all of that - learnt so much about design patterns in such a short space of time - shout out to Addy Osmani for writing such down-to-earth, approachabl…
I also agree, although instead of Backbone I recently found that Twitter Bootstrap's javascript files offer similar insights as to how to structure code in an javascript-style object oriented manner. For example: https://github.com/twitter/bootstrap/blob/master/js/bootstra...
OT: I keep trying to get into backbone but I just get driven crazy by `get` and `set`. Inspecting your object feels like a world of pain, which is no fun when I'm playing with code. And it also makes it feel like you're not programming js any more. Quite a few years back an old company I used to work for had a similar framework and perhaps it's just latent hatred for that rather annoying framework. I know it's a limi…
> perhaps it's just latent hatred for that rather annoying framework ... hopefully ;) The reason why you need `set` is so that you know when to trigger `change` events. Getters and setters aren't going to fly if you need to support Internet Explorer. One alternative is the Angular.js tradeoff, where you're setting regular properties on vanilla objects and arrays ... but then Angular is going in behind the scenes and…
I also pushed some Emacs Yasnippets templates for backbone.js today, feel free to contribute:
Earlier quoted context omitted.
I also agree, although instead of Backbone I recently found that Twitter Bootstrap's javascript files offer similar insights as to how to structure code in an javascript-style object oriented manner. For example: https://github.com/twitter/bootstrap/blob/master/js/bootstra...
Please don't learn anything from that code.