3 ms·

With one exception. Spellbinder will add/remove classes as the model value is changed. It does the initial rendering and then will alter the html, style, classe

With one exception. Spellbinder will add/remove classes as the model value is changed. It does the initial rendering and then will alter the html, style, classes, properties on the fly as you change the values in the model without reloading the page or re-rendering the view.

jashkenas 13y ago
Yep, exactly -- which is a great thing to do for specific necessary cases, but usually a pervasive overuse of granular data-binding can cause large performance problems down the road. When the app has to track and manage each tiny attribute's expression in the eventual UI, there's a lot of overhead, and a lot of potential computation to be performed. In a perfect world, you're able to bind changes in the data to changes in the view at the level of granularity at which your app needs to update. Most of the time, atomic chunks of HTML will be the most performant. Rarely, but sometimes, attributes. A long-winded way of saying -- Great stuff! But be wary when starting to do it this way by default.
- mattinsler 13y ago
  Absolutely! We actually had a special case of a UI that needed to have many many things updating via push events, and have profiled it a few different ways. Turned out that with the frequency of updates we were making, larger chunks of HTML ended up being multiple times more expensive than adding a class here, or changing the text in a tag over there. This method actually _was_ the optimization.
rraval 13y ago
Even so, the example is a tad puffed up: if (count > 100) { $el.removeClass('low-value'); $el.addClass('high-value'); } else if (count < 50) { $el.removeClass('high-value'); $el.addClass('low-value'); } else { $el.removeClass('high-value'); $el.removeClass('low-value'); } Compare to how this would normally be written: $el.toggleClass('high-value', count > 100); $el.toggleClass('low-value', count < 50);
- adambard 13y ago
  I did not know about this. Thanks!
- mattinsler 13y ago
  Nice code, I'll update the readme to be more realistic.

jashkenas 13y ago

Yep, exactly -- which is a great thing to do for specific necessary cases, but usually a pervasive overuse of granular data-binding can cause large performance problems down the road. When the app has to track and manage each tiny attribute's expression in the eventual UI, there's a lot of overhead, and a lot of potential computation to be performed. In a perfect world, you're able to bind changes in the data to changes in the view at the level of granularity at which your app needs to update. Most of the time, atomic chunks of HTML will be the most performant. Rarely, but sometimes, attributes. A long-winded way of saying -- Great stuff! But be wary when starting to do it this way by default.

mattinsler 13y ago
Absolutely! We actually had a special case of a UI that needed to have many many things updating via push events, and have profiled it a few different ways. Turned out that with the frequency of updates we were making, larger chunks of HTML ended up being multiple times more expensive than adding a class here, or changing the text in a tag over there. This method actually _was_ the optimization.

rraval 13y ago

Even so, the example is a tad puffed up: if (count > 100) { $el.removeClass('low-value'); $el.addClass('high-value'); } else if (count < 50) { $el.removeClass('high-value'); $el.addClass('low-value'); } else { $el.removeClass('high-value'); $el.removeClass('low-value'); } Compare to how this would normally be written: $el.toggleClass('high-value', count > 100); $el.toggleClass('low-value', count < 50);

adambard 13y ago
I did not know about this. Thanks!
mattinsler 13y ago
Nice code, I'll update the readme to be more realistic.