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.
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.
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 was curious about the claimed collection performance too, since this is an area that a lot of people have looked at, and a 5x improvement there would be pretty impressive.
Apparently, what makes jsblocks different is that it appears to be doing dynamic code generation. That's an interesting idea, though I'd have concerns about how it respects lexical scoping. There are a couple bumps apparent as well:
- the benchmark is only faster because it ends in a .reduce(). I suspect that code generation allows them to remove all collection generation here and just update the reduced value in a loop. If you remove the reduction at the end, then lodash is fastest, as expected.
- the jsblocks code in their own benchmark reports the wrong result. It appears there's either an off-by-one error or the generated code runs the filter step before the map. I'm not counting this against the method, as presumably it's fixable, but it might speak to the difficulty of code generation as a strategy.
I think it's because people are tired of the thrashing between/around the "next big thing." Angular was supposed to fix everything, React is still trying to fix everything... But even Atom stopped using React because it was so slow.
As for this framework, I'd be happier if it came in discrete chunks that you could wire together, because if you're not happy with one part of it, you don't have to accept it. You can instead build your own.
> But even Atom stopped using React because it was so slow
That's a mischaracterization -- it was only slow for a very specific usecase -- rendering a source code text-view. (It's like using an optimized C plugin in your python project for that core part that needs the benefit of performance.)
React makes a LOT of sense for a JS framework, and it's not a surprise that it's among the most popular ones now. To simply call it unusable because ONE particular usecase did not suit it is doing it an injustice.
Nice hearing that. I am currently working on making the framework more modular. This is create powerful individual modules that could be used for other purposes not only in MV* Framework.
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.
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.