I think it's great that there is such an amount of active development in the JS sphere, and I'm sure your framework is fantastic - so don't take this as directed at your framework specifically. That being said...<p>I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. I constantly feel that I'm behind on my homework having to evaluate new libraries and frameworks showing up. Every two weeks, another one shows up with another paradigm shifting approach.<p>I am getting increasingly apprehensive about committing myself to learning anything new, because in two weeks there's another shiny framework that everyone is proclaiming as the next wunderkind. Sorry about the 6 months spent learning it, but now we're doing something new.<p>The amount of time where I feel that I am confident and productive with a library or framework is getting shorter and shorter, and more and more of my time learning, I feel is wasted.<p>Sorry to barf all over your post - like I said, it's nothing specifically with your framework, and it looks very shiny on the surface, but I think I'll just get back to work instead of studying it in greater detail.
It's not hard to be faster than React, React's performance benefit comes from the fact it makes performance easy to understand and optimise rather than just being magically (but opaquely) fast.<p>However, the real reason React is a good choice is not performance, but rather how it encourages developers to think about, isolate and better manage mutable state in their applications.
> <div data-query="each(products)"><p>Well, one problem is declarative programming has never been as expressive as imperative programming. In React you'd use JavaScript for this iteration. This is why I like React over say Angular, with ng-each, ng-if, etc. Flow control does not belong in markup. I cringed the first time I saw an XML schema with an IF element.
In my view, one of the huge benefits of react is the <i>lack</i> of two-way data binding, since the one-way flow of flux is far easier to think about IMO. Speed is one thing, but when the framework you have is fast <i>enough</i>, a little more for a sacrifice of code reason-ability seems undesirable.
Top article on the front page of Hacker News as I write this, and not a single positive comment below. Great job, guys...<p>To the author: I think the homepage looks great, the examples are clear and informative, and I would definitely give this a try if I weren't wed to a couple of other frameworks right now.
This is interesting, but it doesn't excite me. My initial reaction is to be curious as to why it's able to thrash underscore and lodash (and React too, but separately) on speed.<p>There could be many reasons for this. Maybe I'm personally not interested in adopting a new framework, maybe your target audience (which includes me) has some sort of fatigue or lack of interest, maybe speed isn't enough of a reason to sell me (or us) on its own, or maybe your landing page needs work. I'm not sure, but maybe my comment will help identify an/the issue – or maybe there is no issue, and it's just me.<p>Thanks for making a JS framework and posting it here. That takes a lot of guts and is notorious for inviting hostility. I appreciate it.
I'm surprised that no one's pointed this out yet, but isn't this basically the same as Knockout (<a href="http://knockoutjs.com/" rel="nofollow">http://knockoutjs.com/</a>)?<p>The difference being that Knockout's been around forever (first release was in 2010), does two things and does them well (data binding and observables), and is very mature and feature-complete at this point.<p>I don't have any comparison performance-wise, but I don't see anything new and exciting feature-wise in JSBlocks that Knockout doesn't already do.
I'd be more interested to see a performance comparison with Mithril[1] rather than React, their core functionality is similar but Mitril strives to be lean and fast.<p>[1] <a href="https://lhorie.github.io/mithril/" rel="nofollow">https://lhorie.github.io/mithril/</a>
Performance comparisons with Angular and React aren't that interesting anymore. They are good because they got Facebook/Google behind them and not because they are blazing the rest of the Frameworks away.<p>Mess yourself with Mithril, Mercury or Elm.
Still relies on JavaScript server side rendering - which will be the biggest performance bottleneck, by far, for both this and React.<p>If you really want a framework that is faster, check out Tungsten (<a href="https://github.com/wayfair/tungstenjs" rel="nofollow">https://github.com/wayfair/tungstenjs</a>), which is as fast as this client side, and can render in vanilla Mustache using Go/C++.
Being a current react user the thing that I like the most about react is having my markup and my logic in one self contained file.
React is fast, but that isn't what has me use it on all of my projects. React has toString() which makes isomorphic apps very easy to create but that isn't why I use it either.
I use it because it constantly encourages maintainable solutions for user interfaces.
I've been playing around with RiotJs (actually committed some fixes/features to the repo). I think what is attractive about both Riot and React is that everything is "defined" in JavaScript, there isn't really a separation of markup and behavior. Each little module can act an individual component. React has gone a step further and has shown that the DOM doesn't really matter...your React code could create native apps.<p>Does jsblocks allow users to develop little objects that encapsulate whats's needed for that component to work? The examples seem to have separate html/js/css.
People here dismissing this framework due to 'fatigue' or 'overexposure'. It's weird as I don't recall hearing this when React started to see adoption 8 months ago.
Have you ever encountered a situation in the browser where 32k ops per second from underscorejs wasn't enough?<p>How many rows/columns were in the table being repopulated? 10 times in 2400ms doesn't seem that bad - it's 240ms per refresh. Is this too slow for your use case?<p>The 250ms gain on rendering 1500 rows - is this something you think needs to be optimized? I can't imagine a scenario where all of those rows would fit on the screen at once.<p>I ask as the main area of focus for the framework seems to be speed, and I'm curious to know what inspired you to make it.
This is interesting but the performance comparison is a moot point for me. React also has React Native, the pros of a faster isomorphic javascript framework working in the browser is not a very strong selling point in a world where native apps are dominating the mobile web. React will help me reach more platforms.<p><a href="http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/" rel="nofollow">http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/</a>
Looks good, I look forward to playing with this.<p>One note on site design of the API section, you have some dead zone sizes issues. The window can be larger than trigger to turn the api list into a hoverable sidebar, but too small to display the content. This causes the API definition to fall to the bottom of the page. I was clicking for a while, thinking it not working, before realizing that the content was at the bottom.
While I think this is relatively cool, I'd be somewhat more interested to see how it compares to knockout. Beyond that, none of the demos give any indication as to how one would create discrete components or modules, it seems like you'd wind up with some fairly difficult to manage code on a larger project.<p>React and related tools just feel more right to me... that or going more towards Polymer... There are several alternatives, and in practice, how many times are you going to change all 10k rows in a table 10 times? I'll lean towards more manageable code in this case. We aren't talking the performance drop to say Angular 1.x, or other frameworks that work directly against the DOM.<p>Of course most people don't need absolute performance in a web based application. To me React with something similar to Flux just makes the most sense... I think Flummox brings it to a nice circle, that's easy enough to reason about.
Maybe I'm in the minority but after drinking the React 1-way data flow kool-aid I love it. I can think more logically about what a components state is and I can test for that state very easily. IMHO 2-way data bindings are not a feature anymore they are firmly on the cons list for me.
The title of this post "faster than React" is misguided.<p>React is fast. Most libraries and frameworks have to be fast to be widely adopted. But speed is not, in my opinion, one of the main reasons to use React.<p>I use React professionally. I choose React because of maintainable the resulting code is. There are other libraries/frameworks that I could use which are faster than React. I choose not to because, having used several of them, I found the code produced comparatively more difficult to understand and maintain in the long run.<p>I'm sure jsblocks is awesome and some people will love it. I haven't tried it yet but perhaps I will someday. Nonetheless I think calling it faster than react, while perhaps true, will be misleading to some.
It'd be better to explain more on why it is faster. It's more convincing.<p>I was a Knockout user, but 2 way binding and mixing up logic with html made me choose React. I think the target audience of this framework should be AngularJs user.
Will be hard to compete with those big libraries like angular and react, b/c they have yet a large community, IMO I like angular on top of react (didn't like the way you create DOM with javascript, tried it 2 years ago, maybe it evolve but I doubt it).<p>Also I'll wait till the project get more mature and get a significant community, b/c I'm not with the energy to learn every library that come out there, maybe will test with some small project but not with big projects, yet.<p>Keep working on it, but try to make it more intuitive and easy to use (didn't read well the docs, but just seen it quickly). ;)
I agree. I am not saying jsblocks is better. It is choice of what you prefer. jsblocks offers Backbone like MVC structure and easy to manage observables. It also have a unique debugging experience - <a href="http://jsblocks.com/learn/introduction-why-jsblocks#debugging-experience" rel="nofollow">http://jsblocks.com/learn/introduction-why-jsblocks#debuggin...</a>.<p>It also packs things like routing and animation integration which React lacks out of the box.
MY personal reason I like Angular (haven't had time to look into the others, sorry, but most I assume fit this bill) is that I <i>don't</i> need a server, I can put my application up on a static hosting site, and worry about what is happening in my controller/html/css/etc I like that approach. Putting a server that you now have to maintain is just one reason I wouldn't want to use it. I Love Firebase/Sendgrid/etc because I can write a client side only app exclusively, and let people who are good at databases,email,etc manage the back end. Is it a poor approach? Maybe, but when you only have an hour here and an hour there to build things, spending 6 months just setting up a few simple things seems crazy. Getting to a working application quickly for me is the goal. (I am not amazing with databases, so something like firebase gives me database with ease, and I don't have to figure out how to setup a server, figure out the database, figure out where to host... Same goes for email providers, etc)
Resuming:<p>I know that we are still in the wild west but <i>Javascript Land</i> should start learning politics.<p><i>Javascript Land</i> tribes need to merge and get a larger population support, a small tribe even with <i>fast weapons</i> will never be more than a guerrilla. External support is also crutial (Angular, React and Typescript without Google, Facebook and Microsoft, respectively, wouldn't be nearly as strong. Even Meteor has external support: Horowitz). It completely saddens me watching little <i>tribes</i> as Elm, Purescript or Clojurescript struggling even with such a great weaponry. These little tribes should at least merge. Sometimes is too difficult but other times is just pride: their leaders want to remain as such. Stepping down a bit in the hierarchy doesn't seem acceptable for them, they prefer to be the leaders of the guerrilla till the end - because normally there is an end.<p>Politics are boring and ugly but they work: just look at Meteor.
Impressive, but Vapor.JS is still <i>orders of magnitude</i> faster than both of them. <a href="https://github.com/madrobby/vapor.js/tree/master" rel="nofollow">https://github.com/madrobby/vapor.js/tree/master</a>
Why build in list traversal functions? Some people prefer lodash, some prefer underscore, others prefer VanillaJS. It seems like just a little sugar, but adding a sugar a little at a time gets addictive.
I'm just generally not a big fan of "X is some percent slower than Y" stats, because I find them counterintuitive. However, in this case I think something is wrong.<p>Rendering:<p><pre><code> jsblocks: 700ms
React: 950ms (35% slower)
Angular: 2200ms (310% slower)
</code></pre>
Doing some maths:<p><pre><code> 700ms + (700ms * 0.35) = 945ms
700ms + (700ms * 3.10) = 2870ms
</code></pre>
Looks like they got a little carried away when calculating Angular's rendering speed. Same thing with the "Syncing Changes" stats.<p>Edit: formatting
The speed comparison is sadly incorrect:<p>Adding 'track by $index' to the Angular example makes it run 10x faster (outperforming both React and Blocks).
> I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it.<p>My rule is to ignore pretty much anything and everything until either:<p>1. A year goes by and it seems like it is gaining traction.<p>2. certain key people that I know personally and respect also start talking about it etc.
If you have N virtual dom nodes, and you are going to compare them every time a single thing changes, your performance may be good, as long as N is small. Unfortunately, React and similar frameworks don't deal with the case that N is large.
Might want to tighten up the spelling and grammar
<a href="http://jsblocks.com/learn/introduction-why-jsblocks" rel="nofollow">http://jsblocks.com/learn/introduction-why-jsblocks</a>
I wish js authors would stop baking functional apis into their libs and let the available contenders (ramda lodash underscore) do it for them.<p>this reminds of the days when everyone published their own psuedo oo js lib. yuck.
It's unclear if the views are also leveraging Observables to asynchronous load views. Is so, are Observerables not unlike the ones of RxJS being used?
data-query="val(...)"
data-query="css(...)"
data-query="click(...)"
data-query="each(...)"<p>... Really? Are you aiming for single god function?<p>"It makes so much sense to query a click!!" said no one ever.
lodash slower than underscore? Isn't lodash's primary purpose to be a more performant drop-in for underscore? Would love to see these benchmarks in a jsPerf.