Live data from Hacker News

Sproutcore vs jQuery +backbone.js

ryth.posterous.com

41–48 of 48 posts

Re: Sproutcore vs jQuery +backbone.js

#41

Earlier quoted context omitted.

Could you expand on why you feel like building a UI in JS is a regression? Is this a popular sentiment? I really prefer working on layouts without manipulating markup, so I'm curious to why others feel different. Thanks!

HTML was designed with presentation semantics in mind (eg layout) and using Javascript to do the job HTML was designed seems like a waste. Hope that answers your question.

Thank you -- it does. If it's not too much trouble, do you have any examples or anecdotes for when HTML made layout really easy, or scripting made layout really hard?

In my experience, there's a sweet spot for HTML/CSS. If I keep things really simple, it makes layouts a breeze. The moment I introduce complexity into the design, I usually wish I had the control of a scripted layout.

Re: Sproutcore vs jQuery +backbone.js

#42

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…

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.

Re: Sproutcore vs jQuery +backbone.js

#43

To throw my hat in the ring (full disclosure, I work on Backbone.js): Unless you're a really fastidious coder, some sort of library to help structure large-scale JavaScript applications is important -- it's far too easy to degenerate into nested piles of jQuery callbacks, all tied to concrete DOM elements. To that end, choosing any of these options can be a positive step, and I have massive respect for Charles and th…

SproutCore Todos: 2.675 MB Uncompressed, onLoad in 1470 milliseconds (loading from localhost). This is not an exactly fair comparison, a lot changes between the developer mode and actual build for deploy mode. Both in terms of performance, and size. Our app (which is much much bigger than the todo app) has a very respectable load time when it production mode while running off localhost.

That was the killer for me. I was quite excited about SproutCore, specially after reading in one of the docs (which, apparently, are severely outdated) that "you could bring it down to something around 300kb uncompressed". Heck, even iPhone users can load 100kb compressed data. But then the generated application was always megabytes big, even when compressed. It's still manageable if you have a heavy application, but kind of overkill for what I need.

Re: Sproutcore vs jQuery +backbone.js

#44
post #27

Earlier quoted context omitted.

A post that contains comments. Say you have: { id: 3, text: 'test', comments: [{ cid:4, bleh:5}, {c id:6, bleh:4}] } You give that to a model. It won't automatically create a collection with comments. The idea behind backbone is that I could insert a new comment in the page by simply .add() something to the comments collection. Automatically, that would trigger a add/change event so that my view could update itself.…

So given: window.Post = Backbone.Model.extend({...}); window.Comments = Backbone.Collection.extend({...}); var p = new Post( id: 3, text: 'test', comments: [ { cid:4, bleh:5}, {c id:6, bleh:4} ] }); You want some way to declare that comments are Comments, so that it is always the case that: (p.attributes.comments instanceof Comments) === true And you also want: p.attributes.comments.add({...}); To trigger a 'change:c…

Yes, perfectly.

Re: Sproutcore vs jQuery +backbone.js

#45

Earlier quoted context omitted.

Could you share how you implemented unit testing your backbone controllers' javascript code?

Right now, I'm just using qunit + sinon.js. I'm not super happy with it (I'd really like to get to the point where all my development is done via. writing unit tests), but so far it works. Honestly, one of the big advantages of backbone is that because of the structure it forces on your code, unit testing is easier. Everything ends up being in a small testable chunk that you can stub out the interfaces for and test (…

Any idea how easy or tough it is to integrate with JSTestDriver? I would like to use backbone for our projects but am finding it tough to implement TDD for Backbone controllers (for models its fine) because of the template. Through tests, I am not able to inject the DOM which is expected by the controller templates. I know this is off topic but if someone can help for the same, it will be great.

Thanks, Leena

Re: Sproutcore vs jQuery +backbone.js

#46

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…

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-contro…

Which flow-of-control paradigm do you prefer?

Re: Sproutcore vs jQuery +backbone.js

#47

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…

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-contro…

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),

Re: Sproutcore vs jQuery +backbone.js

#48
post #44

Earlier quoted context omitted.

So given: window.Post = Backbone.Model.extend({...}); window.Comments = Backbone.Collection.extend({...}); var p = new Post( id: 3, text: 'test', comments: [ { cid:4, bleh:5}, {c id:6, bleh:4} ] }); You want some way to declare that comments are Comments, so that it is always the case that: (p.attributes.comments instanceof Comments) === true And you also want: p.attributes.comments.add({...}); To trigger a 'change:c…

Yes, perfectly.

https://github.com/unspace/faux/issues#issue/33
Post reply on HN