Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Migrating a large JavaScript project from DOM spaghetti to Backbone.js (ofbrooklyn.com)
224 points by conesus on Nov 15, 2012 | hide | past | favorite | 113 comments



Backbone.js is not going to solve your DOM spaghetti problems.

You will still bind to events, you will still manipulate the DOM, you will still do all the manual work.

I really recommend looking at Knockout.js instead.

It really gets rid of all the DOM manipulation code that tends to become so complex and spaghetti like.

How? It provides a declarative language for two-way binding between the UI and the data.

Check out this example: http://jsfiddle.net/FEVbz/

In the HMTL pane, edit the input boxes and watch as the other DOM elements update automagically.

Notice how simple and clean the Javascript code is. All it's doing is initialization and setup. Nothing else. No event binding. No dom manipulation. No spaghetti. No nothing.

Shameless plug:

Here's an article I wrote about why I think Knockout.js is so much better than Backbone.js

http://dev.hasenj.org/post/35572197519


I've taken a look at both Backbone and Knockout over the past week or so, and I definitely prefer the Knockout approach.

Backbone... I just don't get it. It seems like there's too much complexity. I'm mainly a back-end developer, so perhaps it's just me.


Like you, I'm more a back-end developer and attempted to pick Backbone initially for my SaaS, but I wasn't very successful with it.

Later I discovered Knockout and in 2 hours, I was up and running, and it never got in the way so far.

I can only encourage people to at least try the tutorials, it will be time well spent:

http://learn.knockoutjs.com/


  > It seems like there's too much complexity
Backbone helps you to do the things you understand. Knockout let's you do things you don't necessarily understand. Sometimes black-box approach is OK. Sometimes not.


Knockout, while it seems magical at first, is actually not so hard to reason about.

It's not really a "blackbox". It's quite easy to understand and extend too.

For instance, you can create your own custom bindings: http://knockoutjs.com/documentation/custom-bindings.html

This is about the only place where it gets low and dirty and involves you writing DOM manipulation code.


I'm not familiar with Knockout, but it sounds like my experience when we were getting into the Flex framework at work a couple of years ago. We thought the data binding was so magical, but once I started to work with it, I had a very good mental model of how the MXML/ActionScript compilers were doing their magic.

It was much more pleasurable to work with when it was no longer magical.


I'm not familiar with either framework, but at least I can understand the intent (if not mechanics) behind Knockout code. With Backbone, it's like reading a whole different language.


Apples and oranges. They address different areas, and so you'll combine them with different other code to fill in the gaps.

Then can even be used together (see, e.g., knockback.js which combines Knockout data binding with Backbone) to complement each other.

All you're really complaining about seems to be lack of data binding in Backbone. So you pick your preferred data binding mechanism and plug it in.


In theory they are different, but in reality people use backbone because they think it will help them reduce the bloat and mess in their code, when in fact backbone will not help with that.


Really? My experience is that it does. So is the experience of many others. Data binding was far down the list of issues I've needed to fix in the places where I've experimented with Backbone.

For data binding there's tons of alternatives that co-exists nicely with Backbone, including Knockout via Knockback, or Rivets, or any number of modules written specifically to work with Backbone - the choice of data-binding mechanism is orthogonal to the choice of using Backbone or not.


Would be interested to hear more about what you mean here?


> Here's an article I wrote about why I think Knockout.js is so much better than Backbone.js

... and it was written in a horribly obnoxious manner. The disclaimer clearly shows you realize they have different purposes. So why the antagonistic tone? If your issue is really as stated that people use Backbone for the wrong things and to highlight the benefits of data binding for views, then address that, instead of writing some inane comparison blasting Backbone for not providing features you the at the end admit isn't its focus.

It's a bit as if I were to review your blog post as musical theatre and then at the end admit I knew all along it was actually a technical blog post but that I'd decided to slate it for lack of singing anyway.


> The disclaimer clearly shows you realize they have different purposes. So why the antagonistic tone?

As stated in the disclaimer itself; because people use backbone as if it will help them manage the complexities of creating rich client side UI, when I actually think it's a terrible choice for that.

> If your issue is really as stated that people use Backbone for the wrong things and to highlight the benefits of data binding for views, then address that, instead of writing some inane comparison blasting Backbone for not providing features you the at the end admit isn't its focus.

I want to grab people's attention that they're doing it wrong. It's like when you slap someone in the face to wake them up.

> It's a bit as if I were to review your blog post as musical theatre and then at the end admit I knew all along it was actually a technical blog post but that I'd decided to slate it for lack of singing anyway.

Well, you're evaluating my article as if it was meant to be an objective non-biased review of "pros and cons". It's not. It's an opinionated piece of text that comes from personal frustrations.

Though for the record, I actually respect and admire the author of backbone, after all, he's also the author of coffee-script, which is just awesome.


For anyone tempted: keep in mind, how trivial this example is. When time comes to nontrivial things knockout will bite and bite you hard.


while this is an interesting reply, it could be way more interesting if it contained a "because ...." subsentence, could you expand on this?


We build online trading applications with KO (we use it only for the view, we have our own Presentation Model were we have observers which pretend to be KO observables) and we have found it quite helpful.

The components built are FX tiles, trade and order tickets.


what do you mean by non-trivial?

I've abused knockout to some rather interesting ends, but I've never attempted to use it for as an in browser MVC setup.

I think of Knockout and Backbone as fulfilling two different purposes.


As opposed to Backbone, which doesn't bite you hard?

Dude Backbone only works for trivial examples, and even then, and I mean, even with trivial examples, Backbone is almost useless.

I haven't yet been bitten by Knockout in any bad way.


"Dude Backbone only works for trivial examples, and even then, and I mean, even with trivial examples, Backbone is almost useless."

I disagree. Backbone is a structuring framework; if you can't make it work with bigger projects, you're doing it wrong.


How would you say Knockout compares to AngularJS? I've looked at both and Angular seems really really clean as well.


As I said here: http://news.ycombinator.com/item?id=4792638

Angular is more of a framework than a library. You have to do everything the Angular way or things will become very difficult. In trying to learn it, I found it quite complex (beyond the basic hello world examples).


Only recently i started with AngularJS. Ik took me a few days to understand it and then a week or two to get addicted to it. At first the terminology might scare you off: directives, controllers, watches, promises, services and more. But now it really makes sense to me and i love it.

I would sell it as a framework to invent your own HTML tags, handles the communication with server and does routing, if needed. The two-way data binding is very very nice, but it feels so natural it not even is a selling point :)


Corollaries:

- Knockout's organizational conventions appear inadequate to organizing larger projects, whereas Angular puts its module system right out front

- Yes, Angular definitely has the highest learning curve of any JS framework, but it more than makes up for it in the power, simplicity, composability, and expressiveness of the resulting app code; if it's too difficult for you, stick to something like Knockout or Backbone.

- Oh, and there's no extra hand-waving for data-binding, because Angular uses a much simpler (and in aggregate, more efficient) approach to computing DOM updates


I'm looking at AngularJS to handle some more advanced cases; my understanding is that AngularJS provides roughly what Knockout.js provides, then more features around (but please note I didn't dive very far yet in AngularJS!).

Knockout.js is great to get started at adding interactive UI on a JSON back-end, and I think AngularJS is the natural progression.


I have yet to see a single viable example of a Knockout app that's been progressively enhanced. Until then, I'm not even going to consider touching it.


Knockout is horrible because you end up putting the "messy jquery code" in the html ! While there is no auto-binding in backbone, it is not really an issue in large apps. Furthermore , knockout doesnt have a persistence layer.


You don't put "code" in the html.

Knockout's declarative language is not messy; just verbose.


Backbone is a great framework and moved the industry forward a lot in terms of code quality. But there are definitely couple things broken, like Zombie/Ghost views - everyone(!) is making their own workaround.

View part is too much DIY. Seriously, _.template is okay for views with no input and simple updates, but if you have heavy IO views become bloated. Check the wiki, there are 7 "yet another binding plugins". Make default one, and make it an option (view binding can be slow and not needed sometimes).

Another DIY are models relations & nesting. These two additions wouldn't be big for the core, but they could really improve the ecosystem. Now you have to take in mind those third-party plugins people are using for these covering basic gaps.


In my opinion binding should be included with backbone. Rendering views over and over again is pointless and if it's a form it will lose focus. There is already one binding plugin that isn't being developed anymore. A winner should be picked and integrated.

I haven't created a monolithic backbone application but model relations and nesting could add significant complexity. Adding binding, model relations, and nesting will make backbone look more like Ember which I think they are trying to stay away from.


So what do you suggest?


I haven't used Backbone.js, but from what I've read there are extensions like Backbone.Marionette for better view and memory management.

https://github.com/marionettejs/backbone.marionette


As obviously stated in other threads... I've moved to Angular. Their 'digest all the changes and update the dom once' makes a lot of sense... and it has basically inverse opinion from Backbone. (Backbone has lots of opinion about data / saving, while Angular has more opinion about binding and logic.)


Backbone is an opinionated software, so it's hard to say if binding would be ever included.

For developers I suggest to try some of plugins, which are listed on GitHub wiki in the binding section and also take a look at Knockout/Ember/Angular so at least you would know what other frameworks offer.


Ember.js?


Wow. After using AngularJS for a few months, it's amazing what a nightmare it looks like to work with Backbone.


I'm going to have to try AngularJS. One of the things that put me off is how much it looks like ASP or JSP with the angular tags. Obviously it must be good as many people rave about it.

We're using Backbone for a large project and yes we have to track and dispose of everything manually but it's so small that we can make it do what we want. I will say this, Backbone has made our team better JavaScript developers because it didn't throw the kitchen sink at us. I just hope AngularJS is not Struts on the client side.


Right? Jquery DOM mess < Backbone < Angular.


Please write your DOM -> Angular or Backbone -> Angualar follow up for this article - would love to see the difference.

Like TodoMVC on steroids :)


Sorry, my time isn't worth so little that I'm going to spend hours writing an article just to prove a point to a guy on HN, but here's an existing example:

https://github.com/angular/peepcode-tunes/commit/87dfa695d99...

Diff stats: 360 additions, 636 deletions, on a total of 628 original lines of JavaScript (app + test code; deletions include redundant lines of template code).


Thanks for your link.

If your time's worth so much, why are you on HN spending time contradicting someone? Saving all your HN-time and writing an article to educate people would give greater value to your time and educate more of humanity...


Thinking that maybe the vague & snarky reply was both more enjoyable and quicker to write.


How is AngularJS compared to Knockout?


Angular is more of a framework than a library. You have to do everything the Angular way or things will become very difficult.

In trying to learn it, I found it quite complex (beyond the basic hello world examples).


It's kind of interesting that we've almost developed an expectation of JavaScript being simple. It's easy to forget what a pain it was to write cross-browser JS even 5 years ago. I like this progress.


Thanks for the info. I've used Knockout but not Angular yet. I've found Knockout to be excellent in not getting in my way and being easily fitted into my existing code. One thing I don't feel comfortable with Ember & Backbone is that they come as a whole framework and require me retrofitting my app to their framework.


Haven't worked with Knockout extensively, but I know their change listeners have cascade issues, and I'll grant this is a preference thing, but compared to Angular, their binding syntax is ass.

Also, Angular is the only framework where the DOM itself is your template. This cannot be explained, only experienced. :-)


> Angular is the only framework where the DOM itself is your template.

Hey, the same applies to Knockout.

Yes, the declarative syntax is verbose, but the DOM is your template.


Seeing the slide about one file that had 8500 lines in it surprised me. Maybe it's a JS thing (I'm not one of those guys) but I've been pushed to make smaller files instead of one large god file. It's hard to traverse a file with that many lines in it, as well as do any meaningful diffs on it.


I've encountered a few ~10K sloc files, in PHP. One ex-colleague preferred them, on the basis that "it makes it easier to use Ctrl+F."


We have some legacy files with > 20K in PHP. I'm yet to find a PHP IDE which will happily consume these files and let me work them. I just jump into VIM when I need to edit them.

For arguments sake, I'm talking an IDE in the model of Eclipse/IntelliJ/Netbeans, not vim/emacs/etc. I'm aware that people have some pretty awesome configurations for such editors, but I'm for the most part extremely happy with IntelliJ.


What makes you keep it that way, given that breaking out large chunks and including the new files back in shouldn't be hard?


Each file represents a module in our business management software (e.g. documents/contacts/memberships/events/etc). Historically, we have replace entire modules with ones that fulfill new/improved/different needs. For example, we have a module called "membership 3", because as we have obtained new clients, "membership" and "membership 2" just were not structured to do the things the new clients needed.

When the company started, we were full of inexperienced devs with no official programming education/experience. Now we have a team that is more aware of things like design patterns. As such, the newer modules are easier to extend and add new features to, so we anticipate that rewriting entire modules should not be necessary when the newer versions need new features.

So to answer your questions, we are just waiting for the old versions to die, and for somebody to pay enough for a job that we can rebuild the old module from scratch :)

Of course, contributing factors such as time, blah, blah, man power, etc. come into play also. Always things that need to be done, never the time to do them.


Well, that's one point where Javascript should - and will! - improve, modularization. At the moment there is no default dependency framework - you can't say 'my module X depends on modules Y and Z'. Well, not by default anyway; there's CommonJS's modules, AMD, and in Javascript Harmony another 'standardized' module framework.

I personally use requireJS in a rather large Backbone project, and it works remarkably well.


People with experience dealing with large-scale software development have been pointing out this flaw with JavaScript for years. It's clear that it just doesn't support modularity properly, and there are severe consequences to this.

Yet there have still been those JavaScript developers who insist that it's a good language to use for anything beyond small (that is, a few lines of code) scripts. They go right ahead creating large amounts of extremely unmaintainable code.

I don't think the solution is to extend JavaScript. Realistically, the only sensible thing to do is to discard JavaScript for anything serious. Sure, maybe the language being used instead will compile down to JavaScript and try to fake properly modularity support, for instance, but this should only be a temporary measure.

All I think it would take is for a major player, like Google or Mozilla, to embed a more capable programming language in their browser. Python, for instance. It's has decent support for modularity, and has been proven with very large systems, yet it still offers the benefits of a scripting language.

The situation wouldn't improve over night, but after a few years we'd likely see Python support in the other major browsers, even if it's just the open source ones, and Opera. These days, that'd likely be enough to gain some good traction. Then we'd at least have a viable option for large-scale, client-side scripts within the browser. It'd be a far better situation that what we've got with JavaScript currently.


Call me crazy, but I think adding modules to JavaScript seems a little more pragmatic than entirely discarding it in favor of Python.

Also: http://wiki.ecmascript.org/doku.php?id=harmony:modules


especially if imports over http in a browser aren't a solved problem in Python either and would also require language extensions


Yeah, I've dealt with 10000 line JS files before. You know, the master JS file that gets included on every page in the application. Too risky to change anything in it. Ever.


There is no easy way to include .js file that are stored on your server.


I've been using PHP Minify [1], a simple script to concatenate, minify, and send out my backbonejs project.

Works well.

[1] - https://github.com/mrclay/minify


That doesn't address my point, which was about includes at runtime of .js files.

The reason why you see big .js files is that it's not easy to split your code in a.js and have it include b.js from the server.


You might look into preprocessing tools like grunt, which are designed for precisely this


huh? post-process them with something like Jammit. Or just `cat file file file file > final.js` and shove it through a minifier.


Depends what your definition of "easy" is. It's harder in JS than in most languages.


Why is it harder? Concatenating the files is literally all that's necessary, as long as you build them intelligently:

  (function() { /* your code */})()
I'd argue that's significantly easier than most languages. But still - this can easily be a single bash line in your deploy script, or you can run `make` before copying the files over FTP. It's not easy, it's trivial.


Why is it harder?

Things like "as long as you build them intelligently", "bash", and "deploy script".


>There is no easy way to include .js file that are stored on your server.

So lets assume you have a totally-static website. That involves copying files over e.g. FTP at worst. So you have an FTP application, editing tools, etc. How unlikely is it that either A) the tools don't offer JS minification, or B) you're using flat text editors, and can't find someone who can write `cat /.js > all.js` or apparently the Windows equivalent `copy /b file+file+file all.js` in an executable text file? Then it's a double-click and drag the all.js file over.

Remember, we already have multiple source files which are included everywhere or this wouldn't be a debating point. So your files must be include-able in every page, which are either order-agnostic or must always be in the same order. Either you maintain that by hand, or you run one of those scripts or you use your editing application. Is editing every file by hand easier or harder than a single double-click?


Nothing wrong with backbone, but I do find it hilarious how it took a lib creating faux classes to get people to stop writing hideous code, you can write clean code with or without Backbone, and it'll look nearly identical. Cleanliness is not in a framework, it's in your head.


I notice the same thing with Rails vs Sinatra. People complain that Sinatra is problematic because it doesn't enforce a directory structure, but you can still make clean, organized code with it.


Reading this just makes me scared of Backbone for larger projects. Things like having to keep changes to models silent just because a view isn't ready? Backbone is all good and well for small projects, but I think it's be best to look elsewhere for a larger project. The problem is that backbone has a smaller learning curve so people try to get started with it, and it is better than nothing, but in the long run you'll just run in to more dead ends and spend more time on fixing things and getting around edge cases than if you went for a more fully fledged solution like http://emberjs.com or https://github.com/rhysbrettbowen/PlastronJS


> Backbone is all good and well for small projects, but I think it's be best to look elsewhere for larger projects.

This is such ridiculous FUD, and I'm surprised every time I hear it. Compare the apps built with Backbone section of their site against similar lists of any competing framework. There are some seriously complex apps there. More big ones than any competitor.

Just because a framework is minimal doesn't make it ill suited for large projects. That goes for all frameworks, not just js ones. And yet I see this argument trotted out against minimalist frameworks in every language I work in.


Amen, amen, 100 times amen. It's a real tragedy that this particular line of FUD has caught on, but hey -- so it goes.

Links, for the curious:

http://backbonejs.org/#examples

http://builtwith.angularjs.org

http://knockoutjs.com/examples/


I'm not saying you can't build larger applications using Backbone, I'm just saying the journey to completing one and then maintaining it will be harder. Large javascript application used to bw written without any frameworks but I'm not bringing them up as examples. What would be interesting to see would be the same examples written across frameworks in terms of code written, code organization, maintainability and size.

The main issue as I see it is that people choose a framework for a project in a short period of time and larger frameworks tend to take time before you see where they shine. I hear people's reason for going with Backbone because it was really the first major MVC out there and because of it's popularity. When I hear why people go with another framework it's because of features - not popularity.

Add on to this whenever I've talked to people or read blogs on systems made with other frameworks the majority of talks on backbone are how to solve problems they encountered while talks about larger frameworks are how to use new features and get more from your code. Maybe it's just because Backbone has been around longer that we've all had more time to find the hardships, I don't know but time will tell.

Is it FUD to say all this? Probably a little, but if we don't have any fear, uncertainty or doubt when taking on a new project then you probably haven't got any idea what you're getting yourself in to.


Here is some more FUD for you ( http://www.thoughtworks.com/articles/technology-radar-octobe... ):

"Backbone.js is a great example of an abstraction pushed too far. While we initially liked the ease of wire-up, in practice it suffers from the same issues as all such data-bound frameworks from WebForms to client/server tools. We find that it blurs the framework and model too much, forcing either bad architectural decisions or elaborate framework hackery in order to preserve sanity.

As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against - these concepts."

This is diametrically opposed to my experience, and I'm really surprised by the stance of ThoughtWorks on the matter. Hope I'm not doing a disservice by spreading the FUD. My belief is that most of the competing JavaScript frameworks are abstractions (and magic) pushed too far.


I'm gonna be puking all day because of that quote.


I'd argue that the problems in large projects are primarily architecture problems, that backbone's philosophy of 'bring your own architecture' means how well an app is structured is entirely up to its authors rather than defined by library choice. Something like your plastronjs or emberjs are saying 'Here, do it like this'. Which is good. Sometimes.

I've certainly run into many issues using backbone for moderately sized applications (form workflows, several different types of records, etc) but every time I get myself out of them I gain general javascript knowledge rather than domain specific knowledge about framework xyz. I'd much rather know how to effectively manage memory in javascript than how to use a particular framework.


Following the same argument, you should probably have started with assembler - because, then you would have gained a significant amount of knowledge about the system ( at such a deep level ).

The point of programming is about creating abstractions, so that you dont have to think in terms of the underlying infrastructure. The higher the level of abstraction, the faster you can code, the faster your output will be and faster the business can progress towards a product.

The question is : Is the end goal of your project a product for a business or a means for you to learn the nitty-gritties of javascript?


That's great, if you frameworks abstractions aren't leaky. Which they almost certainly are.

At that point the question is whether the troubleshooting, as stated, will teach you about how to solve the problem with javascript in general or framework specific contortions to work around it.


Assuming that all frameworks are leaky and writing from scratch is almost always a waste of time. Even if something is leaky and you spend a week trying to fix it, it will probably still be faster to build using those abstractions than to build something from scratch.

In my current company, we were building a multi page form for registration. It took us ( 2 guys ) a whole of 3 weeks ( with html and css pre built! ) to bring it to a level that is acceptable. I had built the same with angular earlier because I was trying to show that it could be done faster and with lesser code. The guys in management did not accept it because it is still "new". So we spent 3 weeks building this which would have taken around 3-5 days in angular.


You raise an interesting point. That technique was developed in response to a difficult part of the migration. I had stories coming in for subsequent pages of an rss feed, but I didn't want to re-render the story view until I had a chance to work with the un-rendered story views.

I realize this can be a bit complicated, but at some point you'll be wishing you could just turn off an event from firing because it's interfering with a juggling act. This is what that technique is used for.

But any project that reaches a certain scale will tend towards having some unfortunate ties between models that makes a more-than-ordinary transition hard to accomplish. It can be done, but I'm not quite there, and I suspect many other developers aren't either. This one's a stopgap.


This is wonderful! I especially like the detailed coverage of Backbone views. They tend to be the most perplexing part of Backbone (do I nest? how much? how do I track them? etc...) and you outlined your use case nicely.


Agreed. Even as someone who feels pretty comfortable in Backbone this was a good exploration.


I use jQuery a lot but Backbone is like Greek to me and so is every tutorial I've seen. I just don't get it and I fail to see the benefits.

Can someone point me toward a good and simple explanation/tutorial?


Simplest explanation:

Backbone is an object-oriented library that can increase maintainability for so-called single-page applications. E.g. it's often used in an architecture which pairs a dynamic web service with static HTML templates, CSS, and JS (no dynamic server-side HTML generation). In this way it is similar to ExtJS/YUI, but generalizes those widget-centric frameworks.

It's not for tightly-scoped JS enhancements.

In terms of patterns, it adheres mainly to the Model-View-Presenter pattern (embodied in the Model class, the HTML template, and the View class respectively). Switching between logical pages in the single-page app is supported by the Router class (which implement the front controller pattern). Data persistence/retrieval is oriented toward RESTful web services (this is customizable) and therefore pairs will with ActiveRecord-based server frameworks like Rails. The separation of concerns it encourages increases testability, and also allows it to pair well with asynchronous module loaders (e.g. RequireJS).


I'm going through the same thing. I just got a small application up and running using Backbone.js yesterday, but it still feels like a more-complex application could get messy.

I did have one question regarding redundancy - if I take advantage of something like validation with Backbone, I still need to do the same validation on the server-side for any data that I POST or PUT back to the server since I can't trust what comes from the client. Is the only gain from doing the client-side validation in Backbone the faster feedback to the user without requiring a round-trip to the server?

I'm currently trying to decide between Backbone.js, Angular.js, Ember.js or sticking closer to what I know with a jquery pjax solution.


The primary gain is faster feedback, but this can also reduce server load. In general, you should never trust user input, so you should validate on the server. (In particular, not only is it possible for users to manipulate/disable your client code, including validation logic, but it's trivial to hand-craft requests to your server.)


I feel exactly the same. I tried to make something simple with bacbone the other day but I just couldn't wrap my had around it. Maybe I'm just stupid, but I too would like to know if there is some article that would explain things more clearly.



As someone about to embark on a large-scale project re factoring to backbone:

Thank you!


Awesome.

I would suggest using something like https://github.com/afeld/backbone-nested to enable a.get('foo.bar.foo') so you don't have to a.get('foo').bar.foo and suffer undefined errors.


http://en.wikipedia.org/wiki/Monad_(functional_programming)#...

It shouldn't have to be a library with custom handling of the edge cases like that :|


It is pretty common to use a function like this when digging into objects in general JS code:

  function get(p, o) {
    var parts = p.split('.');
  
    for (var i = 0, l = parts.length; i < l; i++)
      if (o.hasOwnProperty(parts[i]))
        o = o[parts[i]];
      else return undefined;
  
    return o;
  }
  
  var o = { a: { b: { c: 1 } } };
  
  console.log(get('a.b.c', o));  // 1
  console.log(get('no.way', o)); // undefined
I'd be more likely to reuse something like that because it's already useful in the codebase than bringing on another library.

However, I am speaking out of ignorance, as it appears that the library you cite does a lot more than this simple thing: https://github.com/afeld/backbone-nested/blob/master/backbon...

In any case safe lookup methods are very useful!


Not very composable or nice. Bespoke solutions are besides the point and the very thing I was decrying.


Yeah, is one of the things I don't like about JS. The typeof operator should be able to handle those cases. Or a new operator that returns a boolean would be nice.

    if(defined jQuery.unknown.propierties)


Or use coffeescript and write a.get('foo')?.bar?.foo


I clearly see that backbone version is better. But i wonder if is it just me that thinks there must be a better way than the event driven nature of backbone ?


there are better frameworks out there for larger projects definitely - but event driven is the best way for larger projects.


Great post! Only suggestion I might add as a helpful pattern would be leveraging Backbone.Events to implement a Mediator pattern for communication between Views. This is overkill for between Parent Views and SubViews, but I have found it to be very useful in facilitating communication between unrelated Views.


From the blog post and slides, it looks like this was a big improvement.

But...

You may find that moving to a higher level, more declarative solution (like Knockout) yields a considerable additional improvement.


I thought Knockout and Backbone were two implementations fixing the same problem. Can you expand?


Unless something changed drastically changed in the last year my impression was this: Backbone helps you to fix problem, Knockout just hides it. I think some people just have a problem with backbone being too flexible, because it matches the name perfectly: it is just backbone helping you to solve problems you will have to solve anyway.

Knockout feels more like exoskeleton — it may be very comfortable when you fit in, but as soon as you don't you are in a lot of pain.


I could imagine data binding geting very hairy to develop more complex apps with.


I never understood why people proudly boast about their past mistakes. Is it supposed to make their current achievements sound better? "Oh, we had 8500 lines of spaghetty JS code in one file, but we used AwesomeFrameworkX and it fixed everything!" For me, this doesn't make the framework sound more impressive, but rather undermines credibility of the author. How did it get to 8.5 lines? Did no one notice? Did no one care? Was every line necessary? Does having a file like that is really better than having some stuff handled on the server side? Was Backbone the only way to move forward?


The intention was to allow people to commiserate and understand that this happens to many code bases and there is a path out of the woods.

As far as letting the file deteriorate to that length, NewsBlur was a side project of mine for two years. That's how long it took, and because I only had 45 minutes at a time (my commute) to work on it, large scale refactors were not a priority.

And it took two years before I realized that NewsBlur would be sticking around and I should care for the code base. It was at that point that I began the process of refactoring the bejeezus out of it.


No one's perfect and we all make mistakes, given the circumstances we find ourselves in - we all make choices with incomplete information.

Admitting that there's a better way to do things is a good first step to become better. To share what you've learned is a sign of being humble.


We all make mistakes, but not all of us use those mistakes to promote something. It's an annoying and overused software evangelism trick. You start by decrying your past ignorance, and continue by saying that you were enlightened and started using X. This dramatizes the improvement and subtly implies that everyone who doesn't yet use X are simply not yet as enlightened as you. There is nothing genuinely humble about doing this.


(...)


The move towards rich frontend applications is a fact of life at the moment. There are lots of ad-hoc apps out there that have 1000s of lines of js in a single file. These guys put the work in to fix that - then they kindly spent their time writing it up so we could profit from what they learnt.

Granted 8.5k lines is a lot - but I'll bet there are more shocking projects out there than that. (I've seen much worse than that on the server side)


Totally agree. It shows more of the author's initial failings and then trying to generate buzz with hot HN keywords like 'backbone'.

One file with 8500 lines could have easily been avoided with the module pattern either by handrolling it or using various libraries out there like requirejs, commonjs, etc.; backbone is not required.


You're only addressing part of the problem. File size is a much easier thin to fix than refactoring DOM bound soup.


they weren't boasting, they were sharing their solution to a common problem, in the hope that it will help other people who have the same problem. i'm somewhat surprised that anyone doesn't "get" the motivation behind doing this.


Thanks Samuel, this was the best talk at the summit.


Great post! I wish you had briefly talked about why you picked backbone over other options like AngularJS.


I'll admit, partially it was because I was sitting next to Jeremy as he was pulling backbone out of the documentcloud workspace and into a soon-to-be-released javascript library. Otherwise, the community has embraced Backbone.js and, for better or for worse, you're swimming in the biggest pond. That means more community driven updates and support, as well as more competition to stand out from in the newest javascript writing convention.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: