Hacker News Reader

Comment by bmelton | Hacker News Reader

On what grounds do you say that?

Not necessarily disagreeing, I've never used YUI3, but I'd love to hear more about it.

I've recently been dabbling in Backbone and, frankly, I'm struggling with lack of documentation. A better documented "competitor" in this space would likely win me as a user.

I was hoping it would be Ember/Amber, or something to that extent, but that doesn't appear to be significantly better documented either.

What do you consider YUI's strengths / weaknesses vs. Backbone? (Please say documentation).

View on HN

How would you like the documentation to be improved over the resources that currently exist at Backbonejs.org?

I think that the documentation for backbone and underscore is excellent. And the single page, annotated source code is probably even more helpful.

The thing that I wish the project had was some official opinionated best practices guidelines. How to structure a growing app, build/minify workflow, pitfalls, etc. (Note: this wish may be due to my utter noobishness and I'm mostly monitoring the mailing list and reading all the questions to learn)

Other than that, I wish AMD was going to be supported in core, but tbranyen's requirejs use (shim) plugin is going pretty well.

"Lack of guidance" is the way I'd describe it. The documentation is great, but it didn't help to steer me away from making architectural decisions that don't work well with Backbone when I was doing my first experiments.

To follow up -- what sort of architectural decisions were those?

I'll try to think of examples and come back to it tomorrow.

For now: One thing that I'm still not clear on is when to wrap .get/.set.

Should I always write my own getters/setters and only use .get/.set internally? Right now I'm only wrapping them when the attributes need special processing, which leads to an inconsistent-feeling API.

I'd lean towards never, unless you have a case with really special semantics.

For run-of-the-mill attribute massaging, I'd just define a new method on the model specifically for that purpose. eg.

    book.loadFromAmazon(amazonJSON)

Hmmm, interesting. Here's a concrete example:

I've got an 'Organization' model and a 'Person' model. I want to use them interchangeably in some templates, so I need to be able to get their names in a consistent way.

An Organization just has a 'name', but a Person has a 'first_name' and a 'last_name'. I've been using a 'displayName' method to encapsulate the difference; would it make more sense to do something like:

    var Person = Backbone.Model.extend({
      initialize: function() {
        var name = this.get('first_name') + ' ' + this.get('last_name');
        this.set({ name: name }, { silent: true });
      }
    });

.displayName() seems like a perfect encapsulation IMO.

That is perhaps a better answer than the one I gave.

Without said guidance, I ended up created multiple views to represent the same area on the page instead of using subtemplates.

Same thing with Collections -- on my first try at something serious, I ended up with multiple collections to represent the same data set, but in different states.

Perhaps, for people who have been working extensively with Javascript before Backbone, this comes more intuitively, but for me, it's been a pretty painstaking process.

In addition to that, conflicting guidance from the various unofficial docs, without explanation of why they did something differently, led me to wondering which way made sense, and it generally wasn't until well after implementation that I realized I'd done it the wrong way.

I'm also curious. I've found the Backbone and Underscore documentation to be pretty good actually. And, in case I'm wondering what a function does _exactly_, the annotated source code (http://backbonejs.org/docs/backbone.html) is more than enough usually.

Perhaps "lack of documentation" isn't the best synopsis. "lack of documentation for people who don't know what they're doing" is probably more accurate.

I've found the documentation to be a great reference, but invariably, due to lack of examples, if I'm trying to implement something I haven't used before, I have to scour the internet for other information before I can generally make sense of the official backbone docs.

The best documentation I've found thus far has been other people's projects in Github. While trying not to cargo-cult copy/paste, seeing somebody else implement a feature similar to what I'm trying to do has been the best for me.

The Spine documentation is fantastic.

http://spinejs.com/

Reply on news.ycombinator.com