This framework is already outdated. Not built with ES6 in mind at all.
The performance metrics are also a sham. So your competitor is 360% slower? What do you even mean?
Agreed there are already a few frameworks that are working with ES7 in mind to ensure longevity. React & Angular are already playing with Object.observe (ES7) to avoid that nasty dirty checking.
I don't really understand why people are so grudge in respect to jsblocks. I personally believe is a great prototype that really proves its concept, and my very personal opinion about the concept is that code can be understandable and performance maintained to a high standard. jsblocks simply gives you all the feature for you to play with the code the way you like, nothing is really imperative. People should give more credit to developers that actually believe in what they do, especially when results are tangible. Keep on it Antonio, I really want to see version 1.x coming off soon.
Why everyone who is building a new framework automatically assumes that speed is all that matter? You can compare speed of another framework, only when you have at least bigger part of the functionality that other framework offers.
It's pretty much the same as to compare drag race car with a luxurious BMW limo, yeah it might be faster and ok if that is all that you need, but in most cases you will pick medium speed but with all the features that comes in BWM...
You are correct. I believe performance is a must but not what is most important. You could see other interesting features like debugging experience in the framework. Server-side rendering I believe is also a really powerful feature.
http://jsblocks.com/learn/introduction-why-jsblocks#debugging-experience
Additionally, I have been developing jsblocks for the past two years and I think that it has a lot of features to build complete applications. However, you could give an example of what jsblocks does not have that other framework has. :)
For starters, right now I can only see a few true frameworks out there - Angular and probably Ember, the rest, like backbone, react and many other so called "frameworks" are only libraries. JSBlocks as I see it from documentation is also only a library, far from true framework.
Now the problem with libraries is that they offer too much freedom and with all that freedom comes loads of different approaches that are difficult to follow or even impossible at later stages... If you are willing to build your own framework out of library that might be fine, but if you want to work in a team and try to recruit members that already know a framework that might get tough and it will be even more difficult when problems stars rising with your "framework" and no answers could be found on stackoverflow or other resources...
Anyways, I believe that someone can compare full frameworks like angular only with another full framework otherwise it might be really unfair comparisement.
Agreed, speed matters if it as you said comes with a more efficient implementation that is far more developer friendly. With ES6 and soon ES7, notably Object.observe, we may be getting the best of both worlds. However, in terms of speed for jsblocks I do not see the server-side rendering feature as a plus or really even a feature.
Yes. ES6/ES7 are great but they are not ready yet. I am looking into ways to make jsblocks more ES6/7 friendly. Regarding the server-side rendering I believe it is very powerful feature. We use client-side framework to improve user experience and server-side rendering does improve user experience because there is no flickering before the framework kicks in. And if you cache the pages you will also get extra performance boost.
Server side rendering... What happens to jsblocks when it's faster to just render client-side in ALL cases? In some cases client-side rendering is already much faster. Under heavy server/network loads client-side is a more efficient & faster method.
If the majority of incoming requests are not first-time visitors, then client-side templating is faster in most cases because they can benefit from all the client-side cache mechanisms. I was really impressed by the results of Offline-first approach applied to one of my professional projects.
Yes. You are correct. Sometimes client-side is better. However, currently http://jsblocks.com is under heavy load and is build using the jsblocks server-side rendering. The server-side rendering have caching enabled. I will introduce caching property that will update only the things like request to services which will help a lot.
You could take a look at the advantages here:
http://jsblocks.com/learn/introduction-why-jsblocks#server-side-rendering
Note: I have load tested http://jsblocks.com and it behavios extremely well.