7 ms·

I know what you're thinking: great, another MVC library for Javascript. But wait: Yehuda knows what he's doing, it will be interesting to see what Amber include

by asolove 15y ago

I know what you're thinking: great, another MVC library for Javascript. But wait: Yehuda knows what he's doing, it will be interesting to see what Amber includes. As I've discussed before [1], the current discussion about MVC frameworks in JavaScript is very superficial, and meaningful API differences between, e.g. Spine and Backbone, are not sufficiently understood by people who are picking between them. Yehuda has a lot of experience thinking about framework APIs from the standpoint of modularity, performance, and developer convenience. He is absolutely right to emphasize that calculated properties and managed attributes on the model layer are the key to easily building JavaScript interfaces. The difference between nice MVC code and poor MVC code or jQuery soup is the idea that in each method data is only flowing one direction: nowhere are you manually updating both a UI and a data object. Two-way data flows make up the majority of the code in non-MVC jQuery-oriented code. In contrast, a robust model layer with lots of events is the best way to get code reuse and composition. [1] http://news.ycombinator.com/item?id=3248552 http://news.ycombinator.com/item?id=3248552

sid6376 15y ago
I am new to web development and have just started using/learning javascript and so my knowledge is limited, to say the least. But isnt what you are saying easily achievable through backbone.js.(by calling a set on a model and triggering an event which the view catches and updates itself.)
- judofyr 15y ago
  Indeed. Bindings are just triggers that makes sure the data model is in sync with the view. It's just for convenience. There is also a model binding plugin to Backbone: https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding
  - sid6376 15y ago
    Thanks for the explanation!
  - jashkenas 15y ago
    Just to be clear -- the Backbone.js "party line" is that automatic 2-way binding between views and models is usually undesirable. The model contains the "truth" -- the current state of the app. Views should be bound to models and automatically update when the model changes. But when the view changes, the reverse is not the case. You don't want every checkbox click, radio button twiddle, and keystroke to be causing your model to change ... thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on. Instead, most apps have a "save" button for some changes, a mouse click for others, or drag and drop, or a gesture, or an "undo" link. It's much more convenient and flexible to allow your app to react to DOM events as it needs to, instead of having specific model attributes hard-bound to concrete DOM elements. ... that said, if the latter is your cup of tea, there's a plugin for that.
    - evlapix 15y ago
      I think what you've pointed out is true. Once I learned BB, I've always felt like I had to decide between fast views with KO, or scalable logic with BB. When the modelbindings plugin came into my life, I was super excited to potentially have the best of both worlds. It was immediately obvious to me, the downsides you suggested. In my simple case it was an append interface, not an edit interface, so I stubbornly worked around it by creating orphaned models that are bound to my user editable view, and then get added into the app focused collection once submitted.
    - ErrantX 15y ago
      > thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on. Hmm, really that sounds like poor application design than anything else. I mean to me in an MVC binding the View to the Model bot ways is critical. The Model should be smart enough to track changes and only persist them on specific request. And your app code should say "hey Model, I am going to query the server now - are you saved?" or "Hey - I have this new data timestamped X, or do you have something more recent?".
      - 15y ago
shiftb 15y ago
What are the meaningful API differences between Spine and Backbone?
- asolove 15y ago
  For the full story, see my comment at: http://news.ycombinator.com/item?id=3248552 http://news.ycombinator.com/item?id=3248552 tl;dr: managed attributes and fine-grained model attribute events make life a lot easier and change the boundary between model and controller.

by asolove 15y ago

sid6376 15y ago

I am new to web development and have just started using/learning javascript and so my knowledge is limited, to say the least. But isnt what you are saying easily achievable through backbone.js.(by calling a set on a model and triggering an event which the view catches and updates itself.)

judofyr 15y ago
Indeed. Bindings are just triggers that makes sure the data model is in sync with the view. It's just for convenience. There is also a model binding plugin to Backbone: https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding
- sid6376 15y ago
  Thanks for the explanation!
- jashkenas 15y ago
  Just to be clear -- the Backbone.js "party line" is that automatic 2-way binding between views and models is usually undesirable. The model contains the "truth" -- the current state of the app. Views should be bound to models and automatically update when the model changes. But when the view changes, the reverse is not the case. You don't want every checkbox click, radio button twiddle, and keystroke to be causing your model to change ... thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on. Instead, most apps have a "save" button for some changes, a mouse click for others, or drag and drop, or a gesture, or an "undo" link. It's much more convenient and flexible to allow your app to react to DOM events as it needs to, instead of having specific model attributes hard-bound to concrete DOM elements. ... that said, if the latter is your cup of tea, there's a plugin for that.
  - evlapix 15y ago
    I think what you've pointed out is true. Once I learned BB, I've always felt like I had to decide between fast views with KO, or scalable logic with BB. When the modelbindings plugin came into my life, I was super excited to potentially have the best of both worlds. It was immediately obvious to me, the downsides you suggested. In my simple case it was an append interface, not an edit interface, so I stubbornly worked around it by creating orphaned models that are bound to my user editable view, and then get added into the app focused collection once submitted.
  - ErrantX 15y ago
    > thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on. Hmm, really that sounds like poor application design than anything else. I mean to me in an MVC binding the View to the Model bot ways is critical. The Model should be smart enough to track changes and only persist them on specific request. And your app code should say "hey Model, I am going to query the server now - are you saved?" or "Hey - I have this new data timestamped X, or do you have something more recent?".
    - 15y ago

shiftb 15y ago

What are the meaningful API differences between Spine and Backbone?

asolove 15y ago
For the full story, see my comment at: http://news.ycombinator.com/item?id=3248552 http://news.ycombinator.com/item?id=3248552 tl;dr: managed attributes and fine-grained model attribute events make life a lot easier and change the boundary between model and controller.