
React: Finally, a great server/client web stack - julien
http://eflorenzano.com/blog/2013/01/23/react-finally-server-client/
======
ForHackernews
Am I the only one that kind of thinks most websites should just be static
pages? Like, I get pretty irritated when I go to read a blog post on Medium or
wherever and it loads a header and a blank page, and then loads a bunch of
javascript (mostly tracking and analytics frameworks), and finally goes out
and gets the actual content. And then if I scroll down, it has to load some
more garbage from Disqus or something.

PLEASE JUST GIVE ME A STATIC PAGE WITH YOUR CONTENT.

I really do not care if the comments don't refresh live.

~~~
sgdesign
Not all use cases are equal. Static pages might work great for static content,
but what about something like GitHub? Wouldn't it be nice to see the issues
list refresh live when somebody else closes one?

~~~
dredmorbius
What are the cases for that feed role?

Why not deliver an RSS/Atom feed with the page and a standard feed reader
within HTML that could present the content, polling at specified intervals.

In the same way that HTML finally standardized on HTML5 semantic page markup
(not that HTML1.0 was grossly inadequate), and we're finally getting
integrated video / multimedia support (though lacking the ever crucial "off"
switch), once you dig through all the bullshit and hype, most of Web 2.0
corresponds to "we can update the page you're looking at while you're looking
at it".

Some client-side capabilities to sort and filter content would finish off
about 90%+ of the use cases. Good enough.

And you'd end up with far fewer monstrosities such as Facebook, Gmail, G+,
etc., in which _a simple content stream_ has a client-side footprint of 1-2
GB. SRSLY?

Yes, the standard problem of having users upgrade their client software to
support the featureset remains, but there are still huge numbers of what are
effectively Web 1.0 sites (Craigslist comes to mind) that are phenomenally
useful and successful.

I've had a very late and passionate come-to-Jesus love affair with RSS/Atom
feeds. Taking Craigslist, for example I can get an RSS feed of any given
category search:

[http://www.craigslist.org/about/rss](http://www.craigslist.org/about/rss)

Remember "Web agents", you know "a personal online assistant that would scour
the Internet for you"? Well, this is it.

Combine that feed with rsstail and multitail, and you can track items of
interest in a console window. Find something particularly useful? Fire off an
email alert to yourself.

[http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_...](http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_adventures_in_rss_chrome_reader_extension/)

I've got Chromium running on my Thinkpad T520i, sucking down about a gig and a
half of RAM. newsbeuter tailing 85 feeds is around 300 MB (a single Chromium
browser tab), and rsstail weighs in at about 145 MB resident. Since they're
only intermittently active, they swap out with very little performance
overhead.

The existing Web design model is a fucking trainwreck waiting to happen. The
browser-as-app-platform metaphor has its advantages, mostly in rapid
development, though that's also a weakness (users _HATE_ change), and it's a
bastardization of two competing uses (content vs. app).

Much of the design and feature set serves advertisers and NSA water-carriers
far more effectively than it does users. Sadly, that's where the funding comes
from, so it's no real surprise. Be careful what you incent for, you'll get it.

~~~
antihero
With the amount of inane FUD you're spreading I can't work out if you're
genuine or a troll. Your text only/image minimal feed reader is using less RAM
than a browser designed to load hundreds of images and get the most out of the
RAM available to it? Shock and horror! And this "train wreck" you're referring
to... I don't see it. I see happy clients that can pay once and get an
application that is useable on any platform, from anywhere in the world, is as
fast as a native application, and can be seamlessly scaled up to meet demand.
Where is the downside in that? Game over, purely native apps, you lost the war
(except for specific things that need to operate locally). Sure there are
native phone applications, but they are essentially thin clients for web
applications anyway.

~~~
dredmorbius
You're absolutely correct that browser-based applications offer some very
compelling advantages: they're run-everywhere (or at least, many wheres),
they're rapid-deploy, they're particularly well-suited to data presentation
and interaction tasks (which constitutes a large fraction of all apps), and
rather importantly for small development shops, they offer a compelling path
out of legacy support hell. These are all true.

So are my critiques. In particular, that the Web alternatives _aren 't_ as
fast or light as native apps.

Purely native apps _haven 't_ "lost the war". They _are_ the battleground for
the most part on mobile devices, as you note, though you omit the observation
that these typically operate via an API, which is in fact the direction I'm
leaning as a hybrid browser/app model. Fully native apps retain crucial
advantages in many spaces.

I'm curious as to what aspects of this you consider to be FUD? I'm reporting
actual memory utilization for apps doing comparable tasks, at least as far as
rendering raw information is concerned. If you want to consider graphical
presentation, I've also got a number of PDF files open using xpdf and evince,
both of which perform full graphical rendering including images. The maximum
RSS for these is 14 MB, and the 20 or so processes running here have far less
system impact than my chromium child processes.

The train wreck I'm describing is precisely that. Light websites are generally
not an issue, but the full-fledged app instances, again, Google+, Gmail, and
the like, cause wild amounts of swapping and instability, to the point that I
make minimal use of them, and where possible find alternatives. The RSS/Atom
readers I mention aren't doing the full work of a Web browser, but that's
precisely the point: for keeping me informed of an information stream, they're
far more than sufficient, and require far fewer resources. I can open an item
in a console-mode browser (and yes, that's old-school and an acquired taste),
_or_ pop over to a browser and read the item. It's far less overhead than
keeping the stream in my browser at all times, and as I noted, the RSS readers
offer hooks to perform other local actions if I choose.

I've written recently of the frustrations I'm increasingly having with
browsers in general: they serve neither the needs of application users nor of
content readers particularly well. Quoting myself:

"It's neither a good reading environment -- for that you'd want something like
Readability, Pocket, Instapaper, or an eBook management tool such as
Moon+Reader, Kindle, or (bad as it is) Calibre -- nor a decent applications
environment: it's bloated, crash-prone, slow, full of security holes, and
underfeatured relative to native applications.

"However in both cases the browser's ability to load and display or run
arbitrary content makes it convenient."

[https://news.ycombinator.com/item?id=7062219](https://news.ycombinator.com/item?id=7062219)

I see a few possible directions things could head:

⚫ Continue down the current path. This is the course of least resistance.

⚫ I don't know where the HTML working group(s) are headed, but continuing the
pattern of HTML5 of offering highly semantic markup and leaning in the
direction of an API model of HTML rather than a designer model (or in addition
to) could be useful.

⚫ We now have <header> <article> <aside> and <video>. How about a <stream> as
I described, and perhaps native <plot> features which could present graphics
based on realtime data updates? Again, a huge class of applications now
essentially consists of "poll regularly for new data, update stream, present
graphics, respond to user inputs".

⚫ A content-oriented browser which strips out virtually all distractions, and
provide vastly improved content management and referencing capabilties (see:
zotero). Readability, Instapaper, Pocket, etc. approach this. I presently have
a local "unstyled.css" stylesheet which I apply to many sites. It works best
on bare-naked pages (without any native styling or table/frame based page
layout) but works pretty well on most minimally-styled pages. And it is, for
my purposes at least, almost always a _huge_ improvement over native
presentation. In other cases I've extensively modified how pages present
themselves. See:
[http://www.reddit.com/r/dredmorbius/comments/1tniu3/user_sit...](http://www.reddit.com/r/dredmorbius/comments/1tniu3/user_site_restyling_multicolumn_vs_fullwidth/)

⚫ An application-development platform based on (mostly) standard APIs and an
HTML/SHTML transport back-end. This would be the area you're most interested
in.

I'm not convinced this is the way things should go, but it seems it would
resolve some of the present tensions in Web development and use.

------
rubiquity
If you used this with Backbone, could you throw Backbone's entire View object
away and use this instead?

~~~
jashkenas
Yes, and that's a great use case for it.

But you can also use your existing Backbone Views (if they have some nice,
say, formatting or data-munging-for-display logic in them) and simply replace
your _render_ function with React.

The next step you can take is replacing your HTML templates with React's JSX
templates, if you'd like...

~~~
rubiquity
Thanks for replying and for your work on CoffeeScript and Backbone. I might
give this a try as I love Backbone's Model layer. I think I like the second
approach you suggested better. That might almost turn the Backbone.Views into
ViewModels, right?

I'm still up in the air on how I feel about the whole JSX thing but I'm
willing to give it a try.

~~~
SkyMarshal
Fwiw JSX is totally unnecessary, and more verbose anyway. Using React without
JSX feels almost like using HAML or something for your HTML.

------
thrush
Wouldn't this make it even more difficult for search engines to index your
pages?

Also, I'm not sure we want a full rendering on the server. That will make the
page appear to have a longer loading time rather than the other way around.
Unless I'm misunderstanding what you're trying to say.

It does sound interesting though. I'm looking forward to your follow up posts.

~~~
spicyj
Various companies (in one famous case, Twitter) have found that server
rendering beats client rendering for initial rendering speed. React is
designed so that if you care about server rendering, you can have the best of
both worlds -- using Node you can render a component to HTML on the server,
then pick it up the prepopulated DOM in client-side JS once your page loads.
Since the server sends down plain HTML, search engines are happy too.

~~~
shebson
Exactly this. Serving fully formed html and picking it up by a client-side
framework is great for crawlers and also great for performance. In addition to
React, you should check out Rendr
([https://github.com/airbnb/rendr](https://github.com/airbnb/rendr)) - it's a
really cool library for doing this via server-side rendering of Backbone
views.

~~~
sahat
Downloaded rendr, fired up the first example simple_00, opening links - Users
and Repos, was painfully slow. With server MVC frameworks at least there is an
indication by the browser that page you clicked on is currently loading. With
client-side MVC frameworks pages usually load instantly and data arrives
shortly after. In rendr, maybe it's just a terrible example, you wait 2+
seconds for a page to load and there is zero indication that page is loading.

------
tel
Can someone explain to me what "isomorphic" means in the tagline for the
linked Director library[1]? I have no idea how isomorphism is supposed to play
into all of this?

[1] "a tiny and isomorphic URL router for JavaScript
[http://github.com/flatiron/director"](http://github.com/flatiron/director")

~~~
WickyNilliams
It means that it can be used on client and server. Its a term coined by (I
believe) the nodejitsu people in this article [0]. Airbnb also used the term
to describe their rendr library [1] which aims to allow exactly that:
rendering on both client and server

[0] [http://blog.nodejitsu.com/scaling-isomorphic-javascript-
code...](http://blog.nodejitsu.com/scaling-isomorphic-javascript-code/)

[1] [http://nerds.airbnb.com/isomorphic-javascript-future-web-
app...](http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/)

~~~
tel
While I like the idea man do I her hate that term. You can't just be
isomorphic: you must be isomorphic to or with respect to _aomething_.

It's like McDonald's named their new hamburger the RESTful Patty.

------
tomphoolery
> You can choose to use this, but after getting over my initial distaste for
> it ("Ack! Who got markup in my code!"), I could never go back to not using
> it.

Or you could just use HTMLbars/Handlebars. Seems like "JSX" is just a more
complicated version of a Mustache-esque logic-less template.

~~~
ssorallen
The big difference is that Handlebars always produces strings that your
browser has to parse as HTML. Handlebars also doesn't know how to mutate
between states, meaning if you add a class 10 levels deep in the template the
best you can do is re-render the entire thing.

JSX + React produce functions that return React's representation of the DOM,
their "virtual DOM", and React knows how to make small mutations based on
state. If a change in state only needs to add a class 10 levels deep in the
hierarchy, that is the only change that happens in the real DOM; it doesn't
have to re-render the entire template.

~~~
avolcano
HTMLBars is rendering to DOM instead of to string, to enable React-level
performance: [http://jsfiddle.net/Ut2X6/10/](http://jsfiddle.net/Ut2X6/10/)

~~~
ssorallen
Thanks for the demo link; I hadn't heard of HTMLBars.

It makes for a good demo I suppose, but I prefer React in a couple places:
there's no separate template, style construction is done with an object and
not a string (constructing that style string for HTMLBars seems error prone),
and the connection between the values on the Ember object and how they will be
used in the DOM is guessed only by naming convention. You could use
`this.set('hotdogs', count % 255)` and reference 'hotdogs' in your template in
place of 'color'.

~~~
peterhunt
There is a very nuanced set of performance (mem and cpu) and usability
tradeoffs you make when adopting a dirty checking vs change tracking system.
I'm working on coming up with a reasonable talk about it.

------
lsdafjklsd
I come from an Ember.js background and its router / nested layout management
is the best I have used. I like react, and have been diving into OM as well in
my free time, but I'm not sure of the best way to approach routing / page
transitions.

When I start an app, I do not think from the bottom up, which is the react
way. I want to start with the login page and redirects, or get the major page
transitions down. I'll be interested in seeing how you approach that.

~~~
lumpypua
I don't think react speaks to that, nor does it care to speak to that. It only
addresses the view component of the app.

------
sahat
I would be interested to know what exactly React solves when we already have
so many options - Ember, Angular, Backbone to do the same thing.

Why would one want to increase the complexity of the application by
introducing "yet another new thing" on an already complex architecture.

I am just not sold on React. If someone could show a demo of why should we use
React instead of, Backbone.View for example, then we can talk.

~~~
plaguuuuuu
I'm just reading about React now, but it seems it might be appropriate when
you have a lot of stuff that needs to be reused

Then again, Knockout would also be pretty good at this, so I dunno. There are
a lot of criteria for evaluating a framework... development speed,
maintainability, simplicity, functionality. And a lot of it is better
evaluated experientially rather than theoretically.

~~~
aymeric
Knockout.js is slow. React seems fast thanks to their virtual DOM. It matters
when you want to develop a web app that caters for mobile clients too.

------
xixixao
The lack of understanding and amount of hatred against web applications
(different from web pages) is both sickening and rejuvenating. It is sad
because the article is fairly clear, it describes the future of most computing
(since most "human" computing will happen on the web) and it really shouldn't
be hard to understand. But I am glad that most of the top commenters here
instead focus on hating "webdevs". It means these people will stay on the
desktop and won't create clones of desktop applications in the browser (see
google docs for a missed opportunity of a better office system). History will
show which way things shifted, no need to flame about it here now.

------
jamesbritt
This is confusing. [http://www.reactjs.com/](http://www.reactjs.com/), which I
believe predates this other react.js

~~~
tomphoolery
Not sure anyone actually cares about that older lib since Facebook's ReactJS
is what powers Facebook.

------
kitd
[http://www.ractivejs.org/](http://www.ractivejs.org/) is another similar
client-side view framework that uses a shadow DOM.

I don't know how suitable it would be for server-side rendering though.

------
jbeja
I am learning how to make desktop apps with Reactjs + Backbone + PouchDB and
Brackets-Shell just for fun and learning purposes, so far it has been a very
exciting experience.

~~~
hamxiaoz
I'm doing angular.js + node-webkit for my desktop app, not bad. How is your
Brackets-Shell experience?

------
hamxiaoz
Any demo? Or I guess it's at the end of the series.

~~~
andreypopp
You can see a little demo of React + Express + Browserify + server side
rendering + routing with History API — [https://github.com/andreypopp/react-
app-express](https://github.com/andreypopp/react-app-express)

~~~
xtrumanx
This deserves its own blog post.

You can probably skip explaining client.js (which seems to be stuff one can
learn from React's docs) and just dive in to server.js and the npm packages
that you wrote that this app uses.

I've been uninterested in React but really like the idea of server-side
rendering for js-heavy apps. Besides Rendr, do you know of any other similar
libraries/frameworks?

------
ttty
Can anybody explain to me how to use react.js without their "guard" feature. I
need my app to throw the error natively and not wrapped by the framework.

Thanks ([http://stackoverflow.com/questions/21040538/how-to-
disable-t...](http://stackoverflow.com/questions/21040538/how-to-disable-the-
guard-feature-in-facebook-react-when-working-with-pure-java))

~~~
spicyj
Can you be more specific with the problem you're seeing? An example
jsfiddle/jsbin would help. If you're referring to the fact that React
sometimes catches and rethrows exceptions making it harder to debug, that's
something I'm planning to try to fix soon. In the meantime you can use the
blue stop sign in Chrome's Sources panel to catch the error as soon as it's
thrown.

~~~
ttty
yes, that's the problem.. I don't like too much the blue because hangs all the
time on jquery on page refresh...

------
rurounijones
God I am sick of the passive-agressive "Finally, we have something GOOD! for
X" titles that disparage everything that already exists for X.

I saw a reddit article yesterday about "Finally a way of doing X that doesn't
suck" despite there already being libraries to do X.

This casual dismissal and disparaging of existing work is the kind of thing
that causes people to give up on stuff (WhytheLuckyStiff for example)

It also causes me to be instantly antagonistic towards said new library /
feature. It raises the bar that I expect them ot reach. "Oh? You are the ONLY
good way to do something? Prove it"

~~~
danenania
You are making the same sort of evidence-less dismissal that you accuse the OP
of (whereas the OP actually explains the reasoning behind his assertion).

If you want to question the post's premise, at least point to some of these
libraries that you believe are on par with react. Personally, I'm not aware of
any that have nearly as compelling a model with regard to performance,
composability, and minimization of mutable state. But if they exist, I'd love
to know about them.

~~~
magicalist
There's no dismissal in the GP's post. They were merely stating that
pretending that some project X is an island is off-putting (and it never is
one), and that by claiming that it is, you put some readers already familiar
with the field in a defensive mood rather than ready to read about something
new.

------
ocfx
I don't want to write a bunch of markup next to my javascript.

~~~
squidsoup
JSX isn't markup - it's XML which translates to Reacts internal representation
which looks something like:

<div className='foo'>bar</div> \-->

React.DOM.div({ className: 'foo', children: 'bar' })

You don't have to use it - it's a convenience provided for designers (and
arguably developers who have realised that templating provides a false
separation of concerns). Om notably
([https://github.com/swannodette/om](https://github.com/swannodette/om))
ignores it.

~~~
nacs
"JSX isn't markup - it's [Extensible Markup Language]"?

~~~
rakoo
JSX isn't markup, it's a compiler that transforms common HTML-like to custom
React.DOM objects. From the doc [0]:

> JSX transforms from an XML-like syntax into native JavaScript.

[0] [http://facebook.github.io/react/docs/jsx-in-
depth.html](http://facebook.github.io/react/docs/jsx-in-depth.html)

------
TeeWEE
I still don't get it that you would like to write in an inferior language such
as js on the server side. Cm'on its broken by design. There are a lot of
better alternatives.

The only reason to use .js on the serverside is that you don't know better.

~~~
andybak
To a degree I agree with you but I'm downvoting for the trollish and
inflammatory way you phrased your comment.

However - there are lots of reasons to use javascript on the server even if we
accept there are superior languages.

~~~
jbeja
Can you please name some of those reasons?

~~~
andybak
The main one is the ability to reuse code on server and client. It's not
something to be sniffed at.

