7 ms·

1) Smalltalk 80 style design The advantage is that the controller knows nothing about the DOM, so it is usable and testable without the DOM. And while I agree

1) Smalltalk 80 style design The advantage is that the controller knows nothing about the DOM, so it is usable and testable without the DOM. And while I agree that it's a single line to add a binding, that quickly becomes a single line for every single event you ever want to listen to. It ends up being a sizable amount of code. Aside from that, it seems clear that binding data is best done in the view, not in the model or controller, why are events different? 2) Using normal JavaScript objects You don't have to extend the objects with Serenade.Properties. The downside is that data in the view isn't automatically updated. But as in the first examples in the README, it's perfectly acceptable to send in "JSON" directly to the view. In the example right after the one you posted, I show how to add properties to the prototype. The intent is not to sidestep prototypal inheritance, but since multiple inheritance or mixins aren't available in JavaScript, copying over the functions is as close as we can get. 3) Break out I just realized that it's not documented in the README, I'll have to fix that, but it's possible to add custom instructions. Any function added to `Serenade.Helpers` is available as an instruction in the view. This is very similar to handlebar's registerHelper. See the spec here: https://github.com/elabs/serenade.js/blob/master/spec/integration/custom_helper.spec.coffee https://github.com/elabs/serenade.js/blob/master/spec/integr... 4) Performance I have not done any benchmarks, so honestly I can't say how it compares performance wise. I'm not terribly worried about IE7. At the moment, we don't even support it, and it'll be dead soon. We could possible use document fragments to speed up the rendering, but I'm unsure if it actually makes a difference. I would argue that Rails is slow, Ruby is slow, PHP is slow, Java is slow, C is slow, etc..

jashkenas 15y ago
1) Smalltalk 80 style design Right -- you mentioned testing, but I'd like to hear more about benefits in your actual app. Putting something in a separate object just to make it more "testable", but without any actual benefit to, or effect on your app's behavior, strikes me as the essence of unnecessary abstraction. You can certainly test views that "know something" about the DOM without actually using the DOM as well... 4) View/Template Performance Ok then, IE8. It has largely the same DOM performance characteristics (ie, slow) as IE7 -- and it'll be around forever, or as long as Windows XP lasts -- whichever comes first ;) For the purposes of a web application, Rails/PHP/Python being slow matters far less than your template library being slow. They're in the backend, you can run many instances across many servers, you can cache their output, etc. If your JS templating / View library is too slow, it means you can't use it to build the most interactive and interesting parts of your UI -- precisely the parts for which using client-side views would be most helpful. I'm talking about even relatively simple things, like this: http://blog.documentcloud.org/blog/2011/10/entity-charts/ http://blog.documentcloud.org/blog/2011/10/entity-charts/ Better to benchmark now and find out, either way.
- joliss 15y ago
  Jonas wrote: > The advantage is that the controller knows nothing about the DOM, so it is usable and testable without the DOM. Jeremy wrote: > You can certainly test views that "know something" about the DOM without actually using the DOM as well... I've been wondering for a while how to eliminate the slow and brittle Selenium layer from integration tests (perhaps I'm not the only one?). I'm thinking that if you can do away with the DOM, you might be able to somehow run the integration tests on the server, without launching a browser. Do you have any concrete ideas how to do this, or are you only talking about unit tests in the text I quoted?
  - jnicklas 15y ago
    If you move most of the application client side, you could use something like jsdom to test it. That's obviously not going to get you the same level of confidence that a full stack test in a real browser would though. Maybe a combination of the two?
- jnicklas 15y ago
  1) I don't really see how it introduces any abstractions. The only thing we're doing is moving where event bindings are declared from the controller (or Backbone View) to the template. Other than that it's really pretty much the same. 4) I did a very dirty quick benmark. See http://pastie.org/3296683 http://pastie.org/3296683. This just inserts 1000 words into a <ul> in three different ways. With jQuery, by appending each item separately, with jQuery through string concatenation, and with Serenade. I tested this repeatedly with different numbers of words, in different orders and on different browsers. jQuery with append is around 5x SLOWER than Serenade jQuery with an entire template is around an order of magnitude FASTER than Serenade In other words, the difference in how jQuery is used is way bigger than the difference to using Serenade. I then did another dirty benchmark: http://pastie.org/3296747 http://pastie.org/3296747. I've only added a primitive event binding so that clicking the <li>s pops open an alert. A really interesting thing happens. In IE (7,8,9), the difference shrinks to around a factor 5. So jQuery is 5x faster. In all other browsers I tested however, Serenade outperforms even the full string concatenation jQuery example by a slight margin. I don't think this proves that Serenade is fast, but it's at least not deficiently slow.
xmlninja 15y ago
I dont see any reason to follow the mvc pattern slave-like. I mean as long as the framework you use gives you the abstraction you need to prevent DOM soup you are fine. It all boils down to taste of coding style, fundamentalism etc. Anyway, you made a framework - you should be proud of it!

jashkenas 15y ago

1) Smalltalk 80 style design Right -- you mentioned testing, but I'd like to hear more about benefits in your actual app. Putting something in a separate object just to make it more "testable", but without any actual benefit to, or effect on your app's behavior, strikes me as the essence of unnecessary abstraction. You can certainly test views that "know something" about the DOM without actually using the DOM as well... 4) View/Template Performance Ok then, IE8. It has largely the same DOM performance characteristics (ie, slow) as IE7 -- and it'll be around forever, or as long as Windows XP lasts -- whichever comes first ;) For the purposes of a web application, Rails/PHP/Python being slow matters far less than your template library being slow. They're in the backend, you can run many instances across many servers, you can cache their output, etc. If your JS templating / View library is too slow, it means you can't use it to build the most interactive and interesting parts of your UI -- precisely the parts for which using client-side views would be most helpful. I'm talking about even relatively simple things, like this: http://blog.documentcloud.org/blog/2011/10/entity-charts/ http://blog.documentcloud.org/blog/2011/10/entity-charts/ Better to benchmark now and find out, either way.

joliss 15y ago
Jonas wrote: > The advantage is that the controller knows nothing about the DOM, so it is usable and testable without the DOM. Jeremy wrote: > You can certainly test views that "know something" about the DOM without actually using the DOM as well... I've been wondering for a while how to eliminate the slow and brittle Selenium layer from integration tests (perhaps I'm not the only one?). I'm thinking that if you can do away with the DOM, you might be able to somehow run the integration tests on the server, without launching a browser. Do you have any concrete ideas how to do this, or are you only talking about unit tests in the text I quoted?
- jnicklas 15y ago
  If you move most of the application client side, you could use something like jsdom to test it. That's obviously not going to get you the same level of confidence that a full stack test in a real browser would though. Maybe a combination of the two?
jnicklas 15y ago
1) I don't really see how it introduces any abstractions. The only thing we're doing is moving where event bindings are declared from the controller (or Backbone View) to the template. Other than that it's really pretty much the same. 4) I did a very dirty quick benmark. See http://pastie.org/3296683 http://pastie.org/3296683. This just inserts 1000 words into a <ul> in three different ways. With jQuery, by appending each item separately, with jQuery through string concatenation, and with Serenade. I tested this repeatedly with different numbers of words, in different orders and on different browsers. jQuery with append is around 5x SLOWER than Serenade jQuery with an entire template is around an order of magnitude FASTER than Serenade In other words, the difference in how jQuery is used is way bigger than the difference to using Serenade. I then did another dirty benchmark: http://pastie.org/3296747 http://pastie.org/3296747. I've only added a primitive event binding so that clicking the <li>s pops open an alert. A really interesting thing happens. In IE (7,8,9), the difference shrinks to around a factor 5. So jQuery is 5x faster. In all other browsers I tested however, Serenade outperforms even the full string concatenation jQuery example by a slight margin. I don't think this proves that Serenade is fast, but it's at least not deficiently slow.

xmlninja 15y ago

I dont see any reason to follow the mvc pattern slave-like. I mean as long as the framework you use gives you the abstraction you need to prevent DOM soup you are fine. It all boils down to taste of coding style, fundamentalism etc. Anyway, you made a framework - you should be proud of it!