Live data from Hacker News

Backbone has made me a better programmer

floatleft.com

1–10 of 88 posts

Re: Backbone has made me a better programmer

#2
I actually prefer the second (complicated) example: everything that happens on the success of the call is right there. If it were to grow more complicated than that I'd move it to its own function and perhaps break it into a few functions: not into several objects.

I find firing events to be useful when I'm writing code that's not meant to be directly accessed, e.g. a jQuery plugin.

Re: Backbone has made me a better programmer

#3
post #2

I actually prefer the second (complicated) example: everything that happens on the success of the call is right there. If it were to grow more complicated than that I'd move it to its own function and perhaps break it into a few functions: not into several objects. I find firing events to be useful when I'm writing code that's not meant to be directly accessed, e.g. a jQuery plugin.

So you have some change, either an xhr or a dom event. You want it to trigger a bunch of other changes somewhere else.

One approach is to call functions (or call functions that call functions...) that directly make that change. This method is fairly clear to read but it becomes messy when more logic gets involved.

The Backbone approach is actually similar to writing a really good jQuery plugin. When the change happens, you convert the raw xhr or dom event into a custom event that is in the language of your domain model. Then anyone who wants can do what they want with it: views can update themselves, other models can update their data and check it with validations, throwing other events, so that changes propagate naturally through the system.

If you aren't familiar with Backbone or MVC this code initially appears to be spaghetti: why does this one event result in functions all over being called, seemingly randomly, even though they're never called directly?

But after a bit of practice, you get used to the pattern. And I find it an excellent way of structuring large front-end applications with lots of reusable behavior.

My mental model of such applications is a directed graph connected by events. Each object has a set of events it is interested in and listening to, and a set of events it is responsible for and firing.

Re: Backbone has made me a better programmer

#4
post #2

I actually prefer the second (complicated) example: everything that happens on the success of the call is right there. If it were to grow more complicated than that I'd move it to its own function and perhaps break it into a few functions: not into several objects. I find firing events to be useful when I'm writing code that's not meant to be directly accessed, e.g. a jQuery plugin.

The "everything is an event" paradigm is a bit overused. There is overhead to event libraries. You should really only use them when you think an object will be observed in more than one place. Otherwise an obj.onsuccess works just fine.

Re: Backbone has made me a better programmer

#6
post #2

I actually prefer the second (complicated) example: everything that happens on the success of the call is right there. If it were to grow more complicated than that I'd move it to its own function and perhaps break it into a few functions: not into several objects. I find firing events to be useful when I'm writing code that's not meant to be directly accessed, e.g. a jQuery plugin.

The "everything is an event" paradigm is a bit overused. There is overhead to event libraries. You should really only use them when you think an object will be observed in more than one place. Otherwise an obj.onsuccess works just fine.

That's where I'm coming from here. It's great Backbone encourages event driven objects, but don't hammer everything with it.

Re: Backbone has made me a better programmer

#7
post #3
post #2

I actually prefer the second (complicated) example: everything that happens on the success of the call is right there. If it were to grow more complicated than that I'd move it to its own function and perhaps break it into a few functions: not into several objects. I find firing events to be useful when I'm writing code that's not meant to be directly accessed, e.g. a jQuery plugin.

So you have some change, either an xhr or a dom event. You want it to trigger a bunch of other changes somewhere else. One approach is to call functions (or call functions that call functions...) that directly make that change. This method is fairly clear to read but it becomes messy when more logic gets involved. The Backbone approach is actually similar to writing a really good jQuery plugin. When the change happen…

Oh for sure. As soon as my code will be touching multiple, disparate parts of an application I'll look to events. But I'm be wary of code that uses events for everything.

Re: Backbone has made me a better programmer

#10
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 limitation of the present js because you can't make getters and setters, but it just completely kills my enthusiasm for backbone, which otherwise seems great. Are there any alternatives out there using Object.defineProperty instead? I know it's still not really web ready, but it'd be far more fun to play with.

Post reply on HN