I'm an ex-Knockout fan who became a Backbone fan but missed Knockout's two-way bindings. Great job. I'm going to try this out for my next greenfield project :)
Jsblocks looks like a nice union of the two. It has the clear separation of concerns promoted by Backbone but the power of Knockout. So it fills in the gaps between the two, really. I spend a lot of time writing code which carefully ensures Backbone views are updated efficiently when a model or collection changes, and Jsblocks looks like it'll do that job well for me.
Also I'm glad the authors chose to keep the views as native as possible with HTML everywhere. No Domain-Specific Languages (DSLs) to learn here.
However, I do have some questions and one piece of feedback!
1. Views, I guess, are cached regardless of whether you preload them as per this example: http://jsblocks.com/learn/view-v... (which is a great feature btw). Is that right?
2. I'm trying to work out whether Views are singletons or not. I suspect there's a way to arbitrarily create new instances (as it were) of views within other views?
3. For the "plug in a service" feature, which allows communication with an HTTP API, is there any way to change a URL perhaps by using a function for the url property?? The API documentation for this (http://jsblocks.com/api/Model-read) seems a little bit incomplete for now, is it?
4. On the front page under "Performance" I think you should try inverting the graphs, because at first glance it looks a bit like jsblocks takes longer than the others to do stuff :)
Looking forward to trying this out, first JS framework I've been this interested in in ages. Great job @antoniostoilkov!
@basicallydan Thanks for the feedback and questions.
1. Absolutely. Views are cached
2. Views are singletons. You could place view(ViewName) on couple places on your page but they are not meant to be used as components. I working on components but until then you could use templates(http://jsblocks.com/api/blocks-q...).
3. Your are correct. It is incomplete. You could do dynamic parameters and what you could expect from jQuery ajax call. I will complete the documentation as soon as possible.
4. You are not the first to tell me this. Long story short - a designer told me that jsblocks bars should be the highest and now I am considering changing that. :)
@antoniostoilkov Cool! Thanks for your reply.
Regarding 4, I can see why someone would say that, because "biggest bar = best thing" but I think in this case it's a bit misleading.
Nicely done!
Just to make a clarification, provoked by @ryanseddon. JSblock is fast and there is more behind it, it's not just the speed, that's why I've listed it here. :) Eager to learn more? Go: http://jsblocks.com/learn/introd...
Yeah. Actually the hidden elements have a purpose and that is to showcase that jsblocks have performance improvements when you will be having an elements that will be conditionally hidden. For example editing in this case.
The cool thing is that jsblocks still does not implement diffing algorithm like react do but it is a little bit slower or even faster is some cases. I am currently working on the diffing algorithm and it will make jsblocks faster than react so hold on. :)
Report
@antoniostoilkov That is deceptive. The initial load example should simply be loading some standard content. And react is better at that based on my testing. To just add some arbitrary thing to swing the favor towards jsblocks is not trustworthy.
And I would hardly implement the editing system like you did with react. I would simple use state like react tells you to. The whole reason react was slower was because you were using unnecessary inline styles. Either way when a library claims to be faster and I look into it and there are deceptive examples, you lost my trust. When Facebook announced reacts speed, they clearly said that performance is a bad metric and over time the other libraries will catch up. While you guys claim that it's already faster and will only get faster than everything else.
Not trying to be on the offensive, but I'm so sick of every library claiming ridiculous stuff and not backing it up correctly.
Report
Just looked into the initial load test and it seems to be a little rigged in jsblocks favor. There is this random hidden element being loaded with each table row that doesn't server any purpose. I removed it and react beat jsblocks.
Before (with hidden element)
react: 1250ish
jsblocks: 800ish
After (without element but looks the same)
react: 200-350ish
jsblocks: 350-400ish
Posting misleading tests is not the best sign.
I agree with you. I have done that not to claim jsblocks is the fastest framework but that I care about this and this will continue to be that way. About the initial load example - you are not the first to tell me that and I will do something about it. Thanks for the feedback. I am starting an article about Performance today that will explain my point of view on the topic.
Overall I believe performance is important but not a deal breaker or something that should convince you to switch to another framework.
Marvel
IntelliBar
Marvel
Paint the Cameras Dead
IntelliBar
Paint the Cameras Dead
IntelliBar
Paint the Cameras Dead
IntelliBar
Paint the Cameras Dead