Hacker News new | past | comments | ask | show | jobs | submit login

I'm currently using Backbone.js + JQuery in my startup and my decision came down to the following conclusions:

Use Sproutcore or Cappucino if you are trying to emulate a native desktop app and where long load times are acceptable (i.e. the user sacrifices time to load everything to not have to wait much if at all after the initial loading). Also use these two environments when your users are Apple Users.

Use Backbone.js + JQuery in a small startup environment with a lean team where the front-end devs are multitalented (i.e. they can easily move between html/css and javascript)

Use a MVVM framework with bigger teams () and with teams where your front-end guys may be good with html/css and graphic design but have limited or non-existent stills when it comes to programming intermediate to advanced javascript and handling mildly to very complex programming concepts.

MVVM has value and I believe it was invented to solve a common communication/coordination problem in corporate-style environments and especially with "silo"-ed teams and matrix management. However, the way I see it will slow down a good front-end developer. MVC is much more powerful and flexible in the hands of a good dev. MVVM just adds another layer of abstraction so the pure HTML/CSS and graphic design guys don't have to get their hands dirty with real programming.

If you are going the Sproutcore/Cappucino route, you really are commiting yourself to a platform and certain ways of doing things from a user interaction perspective. You will gain a lot in not having to build some basic, common interfaces, but you will lose when you need to invent and create your own custom interfaces.

Summary:

Backbone.js + JQuery = Flexible, powerful, lean - Good for experienced devs

Knockout.js = Less powerful, simple = Overcomes coordination and cooperation issues in teams where "the left hand doesn't know what the right hand is doing"

Cappucino/Sproutcore = Complex apps built fast, inflexibility in interface design patterns. Good for "native-style" apps.

Anyways, those are my opinions. I encourage you to challenge me on anything you don't agree with as my experience with Sproutcore/Cappucino is limited to just research and I only built one small app with Knockout.js.




I think your analysis of Knockout.js is incomplete. You can customize any of the interactions and bindings, and it supports an entire reactive programming model (automatic re-execution of functions) that Backbone does not. Especially with the newer Knockout extensions that turn fromJSON into a full-fledged updateable model, Knockout competes well feature-wise with Backbone, it just has a very different flow-of-control paradigm.


I'm sure that my analysis of Knockout.js is incomplete. I checked out knockout.js when it was first announced on Hacker News several months ago. Backbone.js was announced on HN at roughly the same time. I gave both a test drive and came to the conclusion that Backbone.js was more appropriate for my use as a single developer entirely responsible for the front end, from graphic design to interactions and events. I hand off responsibility to my co-founder at the model later. My co-founder is responsible for the MongoDB and Rails backend.

I'm sure Knockout.js has matured a lot since I first looked at it and that I need to find time to revisit it one day.

From your comment and the comment of Alisson on the blog post associated with this thread, I'm pretty sure that my information about knockout.js is out of date.

However, frameworks aside, I still believe that an MVC approach makes more sense for small teams where developers handle multiple roles and that the MVVM approach works better for larger teams and teams with less experienced front-end developers.

I decided on MVC for my current project working with one other technical co-founder. However at my previous two employers I would have opted for the MVVM approach because because I believe it's more "sociologically" appropriate for corporate environments and for projects where different parts are handled by different teams (i.e. matrix managed companies),


Which flow-of-control paradigm do you prefer?




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

Search: