
Show HN: An Isomorphic JavaScript Framework Faster Than React - astoilkov
http://jsblocks.com
======
yummybear
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...

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.

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.

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.

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.

~~~
lectrick
> 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.

Every _two weeks_? Try _every day._ I hate to be _that guy,_ but this sounds
like whining. You're a developer, it's an incredible privilege (we're part of
one of the fastest-growing, most-successful businesses ever, and we basically
_get paid to solve puzzles_ by _writing machines directly from our minds_ and
in most dev shops I've worked in _nobody cares if you roll in at 10am_ , not
to mention that we get compensated quite well while arguably becoming
ultimately smarter than doctors yet without any required certification or
schooling... I mean, in the history of human jobs, I can't imagine it getting
much better!!), and staying on top of new developments is part of our job
description. If you're getting fatigued, perhaps it's time to take that
vacation you've been putting off, or to (wo)man-up and ask your superiors for
more. Or to ask yourself if this is the right career path for you (although
there's so much work now that you can get by just fine even relying on
decades-old technology/libraries/languages). OR... to specialize. The full-
stack developer's days are unfortunately numbered, there's no way a full-stack
developer can keep up with every new development while keeping his job
anymore. I myself gave up on keeping up with frontend around the time Angular
came out...

~~~
manigandham
Come on, I'm a full-stack guy and worked on lots of teams/projects/companies.
I have yet to see a need to stay on top of every new development constantly,
especially JS frameworks that still need to be proven.

None of the productive developers I know care about all the daily/weekly
noise, if something is truly new and good it'll become known on a monthly or
quarterly scale.

And about job description - developers are hired to build functionality, not
learn new things. It might help further your personal goals and eventually
help provide functionality faster/better using new tools but at the end of the
day, the business doesn't care and would rather have something that works.
Don't get caught up in the hype. It's great that you seem so passionate about
it but keep in mind what the work is really about.

~~~
lectrick
> the business doesn't care and would rather have something that works

True, but unless you own the business, _the business ' goals are not your
goals._ The business wants a working product; you need to stay relevant in a
career. Sometimes these may align, but not always.

~~~
manigandham
Right, which is why I said learning isn't part of the job description.

When I hire devs, I base their relevancy on what functionality and results
they produced for their employer/project, not how new their tech stack was.

Go ahead and learn new stuff but if you know the fundamentals, the frameworks
are just different syntaxes for the same thing. But don't assume that someone
who doesnt keep up with things every day or week is somehow irrelevant. These
frameworks won't change your productivity that much and your output is what
matters.

------
mambodog
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.

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.

~~~
idibidiart
Correct. But React is also a step behind ClojureScript based React wrappers :)
like Om and Reagent.

~~~
zaynetro
Could you explain why are they step ahead? I am not familiar with
ClojureScript, but my interest in it is really high.

~~~
alejandrodob
Because Clojurescript uses immutable data structures, and keeps the state in a
centralized atom, so comparing different states is as easy (and fast) as
comparing the different versions of the data structure, which in turn (and
thanks to being immutable data structures) reduces to compare their memory
references, which is fast.

~~~
xtrumanx
Immutable.js is a project also from FaceBook that brings immutable data
structures to your JS applications including those using React.

Since Clojurescript compiles down to JS, wouldn't it be possible to use
Immutable.js and a slightly different app design (a single Flux Store for the
entire app) to get the same benefit of using React with Clojurescript?

~~~
lewisl9029
The centralized immutable state oriented architecture advocated by Om can
definitely be implemented using plain JavaScript (my favorite in this space is
[https://github.com/moreartyjs/moreartyjs](https://github.com/moreartyjs/moreartyjs)),
but _language features_ like core.async, transducers and macros are not so
easily replicated.

------
snarfy
> <div data-query="each(products)">

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.

~~~
dkersten
_Flow control does not belong in markup._

My favourite templating system is enlive[1] (or enliven[2]). You use CSS-style
selectors to select snippets of HTML to manipulate and then use code to
duplicate, remove, move or replace these snippets, insert content, set
attributes etc.

The "template" is pure HTML without any additional markup and without any
logic. The code then says "repeat this snippet for every item in this list and
insert it over there" (or whatever you need). Markup does what its good at,
code does what its good at. Works out really nicely.

Although nowadays I use reagent and hiccup-style markup and write everything
in code (but keep my components as pure and dumb as possible).

[1] [https://github.com/cgrand/enlive](https://github.com/cgrand/enlive)

[2] [https://github.com/cgrand/enliven](https://github.com/cgrand/enliven)

~~~
astoilkov
What do you think about OneScript -
[https://github.com/astoilkov/OneScript](https://github.com/astoilkov/OneScript)?

~~~
dkersten
Can't say I'm a fan honestly. Reminds me too much of PHP, I guess.

The thing about reagent/hiccup is that the markup is just a clojurescript data
structure and can be composed and manipulated like one. This also means that
you can easily write pure functions to generate the UI (data in, markup out).

The thing about enlive/enliven is that the markup and the logic are completely
separated.

OneScript has neither of the things that I like about enlive or reagent.

EDIT: I should probably add that I'm not particularly a fan of JSX either, so
I'm probably the wrong person to ask for an opinion on this.

------
bananaoomarang
In my view, one of the huge benefits of react is the _lack_ 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 _enough_ , a
little more for a sacrifice of code reason-ability seems undesirable.

------
bshimmin
Top article on the front page of Hacker News as I write this, and not a single
positive comment below. Great job, guys...

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.

~~~
rattray
I think a lot of the negativity has to do with the marketing. This isn't being
sold as "a cool thing I made", but "Better MV-ish Framework" and "Faster than
React". If you try to position it as better than existing alternatives, HN
commenters will tear it down if they don't think it makes the cut. If you put
it out as "exploring interesting new approaches", I think you're likely to see
a lot less negativity here.

Compare to the launch of Mithril:
[https://news.ycombinator.com/item?id=7421652](https://news.ycombinator.com/item?id=7421652)

EDIT: Actually, revisiting this, the problem may be more with the fact that it
hit the front page than the fact it has a lot of negative comments. If nobody
here seems to like it, how did it get 182 upvotes? That seems like a problem
with our community, eg; upvoting before actually looking at the article.
(Note: I don't mean to comment on whether this is a good framework, just that
the HN community doesn't seem to like it much).

~~~
rattray
@dang, if you're listening, an idea:

make the "upvote" buttons invisible on stories that the user hasn't visited
before. This could be done like so:

    
    
        // css
        a.upvote-botton:visited { visibility: hidden };
    
    
        <!-- in html -->
        <a href="{article_link}" onclick="perform_upvote()" class="upvote-button">upvote triangle</a>
    
    

The href & onclick handlers would need to be added in javascript so as not to
affect hn for non-js users.

~~~
svl
That doesn't actually work in pretty much any browser, since it allows for
history-mining by a malicious site. :visited styling changed a couple of years
ago to only honor color changes, thus preventing most ways of exploiting that
issue.

[http://dbaron.org/mozilla/visited-privacy](http://dbaron.org/mozilla/visited-
privacy) is one of the better resources explaining the issue more fully.

I guess you could create the triangle solely with CSS borders, and then style
the border-color to be the same color as the background when not :visited

~~~
kansface
Could you not just render the anchor out of the view port and look at its
color?

------
anshin
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.

~~~
striking
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.

~~~
anilgulecha
> 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.

------
austinhyde
I'm surprised that no one's pointed this out yet, but isn't this basically the
same as Knockout ([http://knockoutjs.com/](http://knockoutjs.com/))?

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.

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.

~~~
astoilkov
It is similar to Knockout. However, Knockout is hard to manage because you
have to invent architecture on your own while jsblocks offers MVC out of the
box. Additionally, Knockout don't have routing, server-side rendering,
animations, filtering, sorting, paging, lazy loading of views, validation,
working with remote data out of the box.

Also the debugging experience is a cool feature -
[http://jsblocks.com/learn/introduction-why-
jsblocks#debuggin...](http://jsblocks.com/learn/introduction-why-
jsblocks#debugging-experience).

------
ttty
Thanks for highlighting 2 things: "Level UP your HTML" and "Two-way data
binding".. Already made my decision, stick with react! (:

~~~
nicklovescode
You perhaps have a reasonable criticism but there is no need to wrap it in a
sarcastic insult

------
beefsack
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.

[1] [https://lhorie.github.io/mithril/](https://lhorie.github.io/mithril/)

~~~
keslag
Mithril's use of helper assisted javascript for it's view templating is a
giant drawback for me. I'd be using it exclusively, but as an old crusty dev,
I've gone down that path more than once, and it's always been a train wreck.

~~~
vvpan
You mean how the DOM is constructed via JS functions? There's this project to
fix it: [https://github.com/insin/msx](https://github.com/insin/msx)

~~~
keslag
Thanks for this, I was looking for something that could keep me using Mithril.

~~~
insin
FYI, you can use Babel to transpile JSX for Mithril by putting this in
.babelrc:

    
    
        {
          "jsxPragma": "m"
        }

------
k__
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.

Mess yourself with Mithril, Mercury or Elm.

~~~
xyzzy123
Right; a large part of the "is this framework worth using" question really
relies on "can we get other developers to work on this", "can we make a
business case for it", "how is hiring going to work", and critically: "will
stack overflow work for us". 50ms on the client is very negotiable and trivial
versus cultural concerns.

------
ndreckshage
Still relies on JavaScript server side rendering - which will be the biggest
performance bottleneck, by far, for both this and React.

If you really want a framework that is faster, check out Tungsten
([https://github.com/wayfair/tungstenjs](https://github.com/wayfair/tungstenjs)),
which is as fast as this client side, and can render in vanilla Mustache using
Go/C++.

~~~
nahiluhmot
I can't speak to this framework, but you do not need to use server-side
rendering for React applications. Instead, you can essentially serve a blank
page on every request, then have the React application bootstrap itself when
the page loads. Alternatively, one could precompile the HTML, and serve it as
static content with nginx, apache, etc.

~~~
towelguy
It's funny Meteor actually has this problem upside down and are trying to add
a way to have server side rendering.

------
alexmuro
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.

~~~
rickr
If you don't mind me asking - how do you manage that? Do you use inline CSS a
la [https://speakerdeck.com/vjeux/react-css-in-
js](https://speakerdeck.com/vjeux/react-css-in-js)?

~~~
alexmuro
My js and my markup live together but I still use seperate css. So maybe I was
over stating my case but generally, I have a predefined set of styles that I
am working from, which means I don't think about the styles too much, other
than setting them using classes. I am definitely interested and excited for
someone to make an excellent inline styles framework though, but I haven't
found one yet.

Currently for most of my projects I still use bootstrap (with a theme or
something) and just include one compiled css file and bootstrap.js in my main
index (everything else gets put together into one javascript file by
browserify). I choose my markup with classes (className) and use bootstraps
interactive pieces (accordians, modals, messages) with the markup data api.

If you are really curious, here is a template app I often use to start from.
([https://github.com/availabs/dashboardTemplate](https://github.com/availabs/dashboardTemplate))

------
emehrkay
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.

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.

~~~
astoilkov
Cool question. Please take a look at OneScript -
[https://github.com/astoilkov/OneScript](https://github.com/astoilkov/OneScript)
and share your opinion. I believe this is the next step in developing
applications. Bringing HTML, CSS and JavaScript in one place where components
are modular and small.

~~~
emehrkay
I like this syntax. How do you pass values to a component and how do you nest
components with values and lets say, loop over an array and create a
(sub)component? Also, when you embed a component, is there a way to interact
with it?

This looks cool, keep it up

~~~
astoilkov
Great questions. I currently filling the documentation so you could watch the
repo or star it and keep an eye on it. The idea is that components will be
like objects and elements so you could easily access them. Take a look at this
example:

<div> { this.each(profiles);

    
    
      <!-- Render all profiles -->
      <Profile>

} <div> { this.find('Profile').setIsMyProfile(true);

    
    
      <!-- render personal profile -->
      My profile.
      <Profile>
    }

------
pothibo
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.

~~~
rattray
React was released by Facebook as a mature project. There wasn't much doubt as
to whether it would be at least worth considering. There also may have been
fewer JavaScript frameworks released that month (Dekku came out something like
last week).

------
andrewstuart
I care less about react's performance than that it at last brings code
organisation that makes sense.

------
anonymoushn
What is it isomorphic to? How do I compute the isomorphism between this
framework and some other thing?

~~~
aikah
> What is it isomorphic to?

Don't bother, most people using this word in the context of javascript apps do
not understand what it really means. It just has became a buzz word meaning :"
you can render your views on client and on the server using JavaScript". IE
you can render an HTML page representing the initial state of your app, then
upgrade to an interactive application using JavaScript on the front-end
seamlessly .

You can't do that with angularjs 1.x for instance without some kind of heavy
machinery relying on a headless browser. That's why angular 2.x basically
ditches 1.x and is a completely different framework.

~~~
gclaramunt
To be fair, it comes from the same people who call node.js "close to the
metal"

------
Finbarr
Have you ever encountered a situation in the browser where 32k ops per second
from underscorejs wasn't enough?

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?

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.

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.

~~~
mozumder
For me 240ms is very slow. I target 60fps for all operations, so that's 17ms.
There's a very noticeable difference when you get to this level in
performance.

A project i'm working on went from 10000ms -> 500ms -> 60ms -> 15ms. Each
phase opened up a new usability model.

------
ojr
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.

[http://cdixon.org/2014/04/07/the-decline-of-the-mobile-
web/](http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/)

~~~
astoilkov
Yeah definitely. It is hard to be compared to React which is built within
Facebook. I am happy to even get here. :)

------
keslag
Looks good, I look forward to playing with this.

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.

------
tracker1
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.

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.

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.

------
jellofiend84
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.

------
dwg
The title of this post "faster than React" is misguided.

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.

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.

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.

------
franzwong
It'd be better to explain more on why it is faster. It's more convincing.

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.

------
norman784
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).

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.

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). ;)

~~~
astoilkov
You are absolutely correct. It is hard to compete with Google and Facebook.
Possibly impossible. I love what I do and it is great experience developing
jsblocks.

And one last thing you could check OneScript -
[https://github.com/astoilkov/OneScript](https://github.com/astoilkov/OneScript).
Do you think it is simple?

~~~
galfarragem
Why not joining Elm instead?

~~~
astoilkov
I believe that HTML, CSS, JavaScript should be combined the way they exist in
the moment. Elm is too revolutionary for me. :)

------
astoilkov
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 -
[http://jsblocks.com/learn/introduction-why-
jsblocks#debuggin...](http://jsblocks.com/learn/introduction-why-
jsblocks#debugging-experience).

It also packs things like routing and animation integration which React lacks
out of the box.

------
onaclov2000
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 _don 't_ 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)

------
galfarragem
Resuming:

I know that we are still in the wild west but _Javascript Land_ should start
learning politics.

 _Javascript Land_ tribes need to merge and get a larger population support, a
small tribe even with _fast weapons_ 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 _tribes_ 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.

Politics are boring and ugly but they work: just look at Meteor.

------
_pmf_
> Isomorphic JavaScript Framework

No. Just no.

~~~
ycitm
Is this just criticism of the "isomorphic" term?

I'm not a fan of it either ("isomorphic" already has a different well-defined
meaning in CS), but it does seem to have some traction now.

Perhaps you have an alternative term you'd prefer these frameworks used?

~~~
barkmadley
I've seen "progressive javascript"[1] and "heterogeneous javascript". Both of
which are much better IMHO.

[1]: [https://medium.com/the-thinkmill/making-the-case-for-
progres...](https://medium.com/the-thinkmill/making-the-case-for-progressive-
javascript-a98dfa82b9d7)

~~~
ycitm
Agreed, both of those are better. Hopefully one will gain traction.

Thanks for the link, good to know people are thinking about the naming issues.

------
endymi0n
Impressive, but Vapor.JS is still _orders of magnitude_ faster than both of
them.
[https://github.com/madrobby/vapor.js/tree/master](https://github.com/madrobby/vapor.js/tree/master)

------
warfangle
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.

~~~
astoilkov
You are correct. I am thinking of removing the functional methods. It would be
better to leave this battle to lodash and underscore.

------
oabm
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.

Rendering:

    
    
      jsblocks: 700ms
      React:    950ms (35% slower)
      Angular: 2200ms (310% slower)
    
    

Doing some maths:

    
    
      700ms + (700ms * 0.35) = 945ms
      700ms + (700ms * 3.10) = 2870ms
    

Looks like they got a little carried away when calculating Angular's rendering
speed. Same thing with the "Syncing Changes" stats.

Edit: formatting

~~~
astoilkov
You are absolutely correct. It actually is an error. Thanks I will fix it.

~~~
Murkin
Also, please add 'track by $index' to the Angular example.. might be a suprise
for you.

(Makes Angular outperform both frameworks)

~~~
astoilkov
Are you sure you are getting correct results. Theoretically Angular can't be
faster than both libraries because it does not implement diffing algorithm.

~~~
Murkin
You can try yourself, the samples are there.

And it does, just not Virtual DOM

------
Murkin
The speed comparison is sadly incorrect:

Adding 'track by $index' to the Angular example makes it run 10x faster
(outperforming both React and Blocks).

~~~
astoilkov
Are you sure you are getting correct results. Theoretically Angular can't be
faster than both libraries because it does not implement something like
diffing.

~~~
Murkin
Yes, you can easily test it - the code they used is in a link on the site.

------
up_and_up
> I am however feeling so overexposed to new libraries and frameworks that I
> can hardly muster the energy to even look at it.

My rule is to ignore pretty much anything and everything until either:

1\. A year goes by and it seems like it is gaining traction.

2\. certain key people that I know personally and respect also start talking
about it etc.

------
amelius
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.

~~~
lhorie
Actually, they do. React has shouldComponentUpdate, Mithril has subtree
directives, Mercury has thunks, etc. One big difference between vdom
frameworks and KVO/dirty checking frameworks is that since the virtual dom
tree is in plain view (pun intended), it's possible to use advanced features
to micro-optimize the hell out of it, whereas other types of engines tend to
be more "black boxy" and make these kinds of optimization nearly impossible.

~~~
acdha
That only helps if you had poor state management and churning updates to
things which hadn't changed.

If you actually have a large number of DOM elements which need to be updated,
you'll find that React is an order of magnitude worse than just using the DOM
directly because it has to do that extra book-keeping multiplied by the number
of elements.

~~~
lhorie
Touching the DOM is by far the biggest bottleneck in performance. Of course
for some arbitrary discrete task, hand coded DOM manipulation code is always
going to be faster than a layer of abstraction on top of it. But the strength
of virtual dom is that a single piece of code can handle insertions,
deletions, sorts, splices and pretty much any data contortion you can throw at
it without increasing code debt. Managing all of those w/ only the DOM API (or
jQuery) as an application grows is difficult, and it's one of the main reasons
why frameworks exist in the first place.

~~~
acdha
> Touching the DOM is by far the biggest bottleneck in performance

My point was simply that this devolves back to Amdahl's law: the only way that
React overhead + the DOM can be faster than the DOM alone is when the pure-DOM
code is doing too much work. It's possible that React makes the code so much
easier to maintain that you write better algorithms but that has very little
to do with the virtualdom rather than the strong push towards better
structure.

~~~
tracker1
There's the fact that dom changes related to a given set of events can be made
as part of the same changes to the DOM as a whole... which can reduce parts of
the render time overall.

However, depending on your needs, a stream of changes may behave differently
in different use cases... to me React simply represents in my mind a better
way to manage components and rendering logic, combined with something like
flux for data and event flows.

~~~
acdha
That productivity gain is, in my mind, the better reason to use React. Browser
performance characteristics change and most of the time you're not pushing the
limits but ugly code is forever.

------
tbolt
Might want to tighten up the spelling and grammar
[http://jsblocks.com/learn/introduction-why-
jsblocks](http://jsblocks.com/learn/introduction-why-jsblocks)

------
smrtinsert
I wish js authors would stop baking functional apis into their libs and let
the available contenders (ramda lodash underscore) do it for them.

this reminds of the days when everyone published their own psuedo oo js lib.
yuck.

~~~
astoilkov
I am actually considering removing the functional API. I agree lodash is
better. It just doesn't make sense to use something that is not proven.

------
nailer
Is isomorphic JavaScript a thing? Isn't it just 'using jsdom'?

~~~
astoilkov
No. jsdom is not the perfect solution. jsblocks is using Virtual DOM and have
specific implementation to support server-side rendering which makes the
framework more powerful and flexible.

~~~
tinganho
How is it Isomorphic? I can't see how the example illustrates server-side
rendering? Just an HTML file?

------
lilkwarrior
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?

~~~
astoilkov
You could load views asynchronously. Observables could be compared to RxJS but
they do not use it. They are inspired by Knockout observables.

------
sairion
"Faster than React" does mean anything?

~~~
JDDunn9
React.js is a new popular toolkit by Facebook
([http://facebook.github.io/react/](http://facebook.github.io/react/))

~~~
seliopou
I think he meant to imply that React is slow.

------
tinganho
I'm not sure if an example beginning with an HTML file gives me good
perception about it being isomorphic.

------
joesb
data-query="val(...)" data-query="css(...)" data-query="click(...)" data-
query="each(...)"

... Really? Are you aiming for single god function?

"It makes so much sense to query a click!!" said no one ever.

------
swah
To demonstrate speed, don't use a very slow CSS transition property...

~~~
astoilkov
You mean the animations demo? This is to showcase how to work with animations
to speed. CSS3 Transitions/Animations have the same performance regardless of
the framework.

~~~
jonahx
I think he's just saying you should have used a lower transition time, like
100 or 200ms. It has to do with nothing more than the impression it makes on
the user. It's "illogical" but if one of your examples uses a slow CSS
transition then the framework "feels" slower, even though the two things have
nothing to do with each other.

------
blairanderson
DBmonster or it didn't happen

------
icemelt8
I seriously think this is some sort of parody of JS. Really? A new framework
every week?

~~~
avinassh
As someone who mostly codes in Python, I don't understand, why JS gets new
framework so often. What is the reason behind? Is Javascript makes thing easy
to develop a new framework? Why doesn't Python get new framework so often?

~~~
moron4hire
It because package management in JS is complete garbage. I can't believe
people _actually_ like using Bower or Browserify or JSPM or any of it. While
NPM for Node has some scaling problems, at least it just works for the simple
cases. I've never not had problems with the client-side JS package systems and
managers.

So package adoption is hard because of this. If you make it a pain for
implementing developers to use your code, they're more likely to just write
their own code.

That's why I think the old style ala jQuery or Google Maps API of packaging
everything manually as just namespacing-objects still makes the most sense,
with the fewest tradeoffs. You give the user a single, minified JS file to
either copy or reference on your CDN. It's a least-common-denominator solution
and it lets the implementing developer figure out how to fit it into their
workflow.

~~~
xyzzy123
Just use npm dude :p </brogrammer>

Seriously though, it's a non-problem now. There is no way I'd go back to
anything else. Webpack and browserify are the only way to go. </religion>

Yes, there is a certain purism to doing your own modules and IIFEs and JS, but
it's like claiming that code is only fast when it's asm. </realcoders>

Besides it can all be optimised out if you add the closure compiler plus
relevant comments </nobodyactuallydoesthat>

------
juliangregorian
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.

~~~
striking
Guess not. [http://jsperf.com/ldash-vs-underscore](http://jsperf.com/ldash-vs-
underscore)

~~~
zilean
Why link version with year old code? [https://jsperf.com/ldash-vs-
underscore/3](https://jsperf.com/ldash-vs-underscore/3)

~~~
bpicolo
Lodash was still slightly slower here for me.

Chrome 43.0.2357.65 on OS X 10.10.0

