
Rendering React without browser JavaScript - firasd
https://medium.com/@firasd/quick-start-tutorial-universal-react-with-server-side-rendering-76fe5363d6e
======
diegorbaquero
We need to get back to server-side cached rendering. Thinking mobile-first and
lightweight websites. I feel in the last few years we've added so many things
and we are no thinking on the people with slow internet. Ember FastBoot now
this, Angular 2 coming with it. We are going towards hybrid awesome front-ends
which load fast and deliver the best UX we've had. Thank you for the great
effort.

~~~
awalGarg
I am curious how this would change with the multiplexed pipe of HTTP2 where
doing a lot of requests is not as expensive. I did a couple little tests a
while ago with nginx 1.9.1 mainline, and while the results did show a little
performance improvements in figures, they weren't observable - but this could
be because I didn't put in much care while doing those tests and I probably
did some mistakes.

Anyone else has done good benchmarks on real world single-page-apps which do a
lot of back-n-forth communication with the server with http2?

I don't expect things to get suddenly extremely better (specially since
resource fetching is only one of the bottlenecks), but maybe it could bring a
mid-way between the server vs client side rendering war.

~~~
frandroid
HTTP2 will help, but it'll also make server-side rendered pages load even
faster, before you load all of your client-side JS.

------
michaelchisari
I love React, but it seems like it would be easier and more productive to use
a toolchain that had a much smaller payload (like Mithril, or React-lite),
than engineering a solution like this.

If performance and time-to-click was your concern.

~~~
leeoniya
I'm consistently amused by the amount of learning, tooling and dependencies
needed to get these things working (and not very fast at that). Accomplish the
same [1] in 15.5k (min): actually fast [2] vdom view layer, router,
isomorphism and observers. IE9+ with an additional 9.5k of polyfills [3].

Disclaimer: i'm the author.

[1] [https://github.com/leeoniya/domvm#isomorphism-html-
attach](https://github.com/leeoniya/domvm#isomorphism-html-attach)

[2] [http://leeoniya.github.io/js-repaint-
perfs/domvm/](http://leeoniya.github.io/js-repaint-perfs/domvm/)

[3]
[https://github.com/leeoniya/domvm/blob/1.x-dev/dist/polyfill...](https://github.com/leeoniya/domvm/blob/1.x-dev/dist/polyfills.min.js)

~~~
aaron-lebo
I love it, but what about React Native. How do you match that?

~~~
leeoniya
If you want React Native, then you need React :)

From what i gather, React Native is good enough for simple things and is iOS-
first, but quickly fails to live up to the hype for anything moderately
complicated and is actually slower than apps that are native from the get-go.
I'm not sure if this is still the case, but aiming for the lowest common
denominator seems like a lot to give up.

I would be interested to see a React Native app that truly benefits from being
native, aside from the app store and distribution aspect.

------
matthijs_
Reminds me of Ember FastBoot. Different framework, different use case, but
relatively easy to implement.

[https://github.com/ember-fastboot/ember-cli-
fastboot](https://github.com/ember-fastboot/ember-cli-fastboot)

~~~
sotojuan
Not "relatively easier"... quite literally just two commands! The people
behind FastBoot are amazing.

------
chrisfosterelli
This is cool! It's worth pointing out that, for SEO reasons, Google now
renders Javascript pages [1] without methods like this. The performance
benefit is definitely still a plus though.

[1] [https://webmasters.googleblog.com/2014/05/understanding-
web-...](https://webmasters.googleblog.com/2014/05/understanding-web-pages-
better.html)

~~~
firasd
Google has been saying that for years, but I don’t really believe it…

1) First there were the "hashbang" URLs, that Google said they'd crawl fine,
but that did affect Gawker's SEO: [http://www.webmonkey.com/2011/02/gawker-
learns-the-hard-way-...](http://www.webmonkey.com/2011/02/gawker-learns-the-
hard-way-why-hash-bang-urls-are-evil/)

2) And instagram uses server rendering for SEO:
[https://twitter.com/cpojer/status/711729444323332096](https://twitter.com/cpojer/status/711729444323332096)
(via [http://jamesknelson.com/universal-react-youre-doing-it-
wrong...](http://jamesknelson.com/universal-react-youre-doing-it-wrong/))

~~~
chrisfosterelli
They've been working on it for years, and improving it. They've only recently
started claiming that their javascript rendering was ready for "prime time".

The "hashbang" URLs (they call them Escaped Fragment URLs) actually required
you to use server-side rendering, that had nothing to do with the spider's
javascript rendering engine. I used them on a few sites and it worked pretty
well, but I have heard of mixed results on sites that weren't originally on
hashbang URLs who transitioned to them. They don't recommend you use these
anymore.

~~~
profeta
> "hashbang" URLs (they call them Escaped Fragment URLs)

why not use the RFC terms?
[https://tools.ietf.org/html/rfc3986#section-3](https://tools.ietf.org/html/rfc3986#section-3)
"url fragment"

Also, it won't help you on server side rendering since the server will never
even see it on the request.

~~~
tyingq
>>why not use the RFC terms?

Because it's specifically different, on purpose. The RFC doesn't cover the
"bang" part....the "!".

>>the server will never even see it on the request

Explained on the (now deprecated) page from Google on this "hashbang"
approach:

*"The answer is the URL that is requested by the crawler: the crawler will modify each AJAX URL such as www.example.com/ajax.html#!key=value to temporarily become www.example.com/ajax.html?_escaped_fragment_=key=value"

------
drcode
I was hoping this would be a story about native react-style rendering within
the browser engine itself, something I've been waiting for since virtual DOMs
first started becoming popular.

~~~
daxfohl
I was hoping it would be a story about injecting links/buttons for each
possible state transition on a page, that would cause a full browser refresh
from the server.

~~~
firasd
Not quite sure what you mean? If you turn off JavaScript in the example app
you do get something like that—the links reload the browser page, and the
comment form submits the comment, then renders the new state of comments (just
by processing the comment on the form submit and then re-directing you back to
the page.)

~~~
daxfohl
Something more universal (albeit less useful). i.e. something that
automatically checks your rendered DOM for every possible Redux state
transition, creates a callback URL for it, and sticks a link for that at the
bottom of the page. Essentially, distributed redux: if redux is (state,
action) -> state, then that over HTTP.

------
oolongCat
Every time I see someone mention react and other frameworks are bad for SEO, I
cant help but think, shouldn't search engines have to worry about this.

Google and other search engines have brilliant people working for them who can
create systems which can guess what I want to search before I have entered the
entire query, and you are telling me these same people can't do something
about pages using the latest technology. Sigh.

~~~
firasd
Google has been working on this (I don't have deep knowledge of whether their
solution is adequate for SEO. I just found this article that suggests it works
fine: [http://searchengineland.com/tested-googlebot-crawls-
javascri...](http://searchengineland.com/tested-googlebot-crawls-javascript-
heres-learned-220157))

But I think, while we're making assumptions about the kind of technology good
engineers should create, let's also ask Google-led Angular and Facebook-led
React (and similar projects): if your library can manipulate HTML and the
browser DOM, even while using async network requests to load data, why can't
it take that same data and code to provide an HTML string upfront, as a "First
Render"? This should be the standard way to do it. If React can re-render an
input box every time I type a character, and not just generate HTML but also
directly manipulate the DOM to reflect it, surely it can generate HTML for the
input box upfront. (I don't know enough about the internals of these
libraries, but maybe the fact that React is declarative makes this easier than
it is for other libs.)

~~~
neogenix
Here is another blog that tested it and concludes it works fine on Google:
[http://www.centrical.com/test/google-json-ld-and-
javascript-...](http://www.centrical.com/test/google-json-ld-and-javascript-
crawling-and-indexing-test.html)

I don't think Bing and Yandex are supporting this yet though.

------
daxfohl
Great timing. I was just going through the referenced "Tutorial: Handcrafting
an Isomorphic Redux Application (With Love)", having gone through the React
tutorial the day before. When I first saw _your_ article, I thought it was
nothing more than a rehashed version of the "With Love" one. But as I got to
the end of "With Love" I wondered:

# "With Love" uses an external API server; how would I handle API requests on
the same server?

# There's no real demonstration of how to do routing beyond a single route.

# "With Love" is unfinished, with no live updates etc.

# How to integrate even simplistic file-based persistence?

The Facebook tutorial had all that, but I wasn't sure how to integrate those
features into a server-side-rendered framework. So essentially my next step
would have been to figure out how to do what you just did here. The extra work
of making the application functional (beyond just showing the pre-rendered
screen) is icing on the cake.

------
brudgers
Repository for modified tutorial: [https://github.com/firasd/react-server-
tutorial](https://github.com/firasd/react-server-tutorial)

~~~
e12e
[ed: I got a bit carried away, I should've prefixed this with a big thank you
for a nice and concise intro to setting up a sane reactjs environment! It's
refreshing to see live reloading of comments posted from the console by w3m
show up in Firefox!]

Ouch, any chance that these examples could be dual-lincenced under cc0/public
domain (where applicable) and something like MIT/BSD/APL in jurisdictions
without public domain?

Because, frankly examples that are: "The examples provided by Facebook are for
non-commercial testing and evaluation purposes only. Facebook reserves all
rights not expressly granted." are worse than useless. If you end up using
anything from the examples in production, you're in breach of copyright!?

------
amelius
How would you render (to a cache) server-side if the rendering depends on the
display size in a complicated way (too complicated for CSS to handle)?

Edit: yes, I understand that rendering means generating HTML, but sometimes
the HTML depends on display size.

~~~
firasd
I suppose it depends on how complicated the logic is behind your conditional
HTML. If there is an initial JS payload that checks the screen size, I might
still try to get an HTML string back from the server after checking the size.
But there are certainly diminishing returns to server-side rendering if you're
making multiple HTTP calls anyway.

------
leetbulb
full circle?

~~~
smadge
Was going to say the same thing. Depressing. Most js devs probably don't
realize the irony.

~~~
profeta
love how your comment was downvoted to oblivion and yet, the thread went on
and on.

the irony indeed.

