
Isomorphic JavaScript is not the Answer - cyberpanther
http://blog.neutrondrive.com/posts/252697-isomorphic-javascript-is-not-the-answer
======
iamleppert
Isomorphic javascript doesn't mean that you HAVE to run all your code
interchangeably. It's more about organization than a hard and fast rule. It
means using the same package manager for frontend code as server side code
(npm) -- tools like browserify and libraries that provide for design patterns
that can be used with a DOM, or without one. It means treating javascript as
javascript, not having separate repo's for frontend code and backend code.

You still have to logically organize your application and make good choices
about your code organization, as well as separation of concern. Interaction
should always happen on the client.

Also, the technique mentioned in the article about bootstrapping data into the
initial page load is quite old and known about, and not a revelation. It does
save one request round trip, which could potentially speed up your application
by that one request (usually session data or user bootstrap data), but is not
the silver bullet in solving all performance problems as the OP implies.

~~~
cyberpanther
I think having a separate repo for the frontend and backend is important. It
is the same separation I want for my Android and iOS code. If they were mixed
with the backend it becomes messy. So the frontend is just another client like
other platforms.

~~~
Romoku
I think isomorphic JavaScript applications are going to replace the current
frontend paradigm. Microservices are becoming more popular, so imagine an
isomorphic JavaScript application as a frontend consumer of many backend
microservices. Plus there are a slew of security considerations that cannot be
solved with current frontend JavaScript.

For instance, how do I call a protected API without leaking the API
credentials to the consumer? Currently you can do this with trusted hardware
or the traditional server side rendering. An isomorphic JavaScript application
can solve this problem using server side rendering without needing a separate
backend.

~~~
cnp
This is precisely what we're moving towards right now. It allows us to break
away from our current, sub-optimal backend server serving up _all_ the
services to an isomorphic JS app that consumes variety and spits back out
results from API calls. It allows for great flexibility -- not to mention
speed and consistency.

------
laurencerowe
Embedding the API data in the initial bootstrap HTML to avoid an extra round
trip does help a little. Waiting for the Javascript to download, execute and
render will easily dwarf that.

Implementing server-side rendering with React brought the time to content
being readable on our site down from ~3 seconds to ~0.5 seconds. It still
takes a couple of seconds for the JS to kick in, but that happens in the
background and the site visitor doesn't notice.

~~~
cyberpanther
How much of that 3 seconds was rendering?

~~~
laurencerowe
From memory, from js downloaded to rendered html in DOM was about 1.5-2
seconds.

Rendering when the JIT has warmed takes 25-250ms depending on the complexity
of the page. First run maybe 10x that.

------
shittyanalogy
_" isn’t there a better way to speed up client side loads times without having
to mix server side and client side code?"_

You're not mixing them, you're using a javascript engine serverside to pre-run
your client side js. There is still code separation and your back end doesn't
have to be written in JS to accomplish this.

Separately the notion of "isomorphic javascript" if that's what it's called,
is not to "mix" client and server code. It's 2 fold: 1 to take down the
boundary between client and server code so that there is much re-use and code
can just be "marked" as server or client only. 2) So that you can re-use many
of your tools like libraries, testing, and language best practices across your
whole project.

~~~
cyberpanther
I think that boundary is important though. If you design your app correctly
there won't be the need to rewrite code over the front and back. Also if your
building an Android or iOS app you have to build that boundary. So why build
the web frontend differently? They should all consume the same backend.

Of course there will probably be repeat code but I'd rather minimize that than
try to make universal code.

~~~
williamcotton
You're thinking of the wrong boundary. You should definitely have a boundary
for your data that is agnostic of the view code.

However, a web application is not like an iOS or Android application. It has a
server-side that sends pre-rendered view code and it has a client-side that
renders view code on the fly. It still makes sense to share the view code
between the server and the client and it still allows for a separate data
backend.

These systems are surprisingly easy to create and maintain with React.

In essence three things are supplied to a client. A pre-rendered view, raw
data, and the code to turn the raw data in to the pre-rendered view.

~~~
cyberpanther
OK that is where we diverge, i'm thinking no pre-rendered view. Ideally your
frontend would be serving statically from lets say Amazon S3 and your api from
another domain. Treat your frontend as if it were a mobile app. Now if you
apply the data bootstrapping technique this can't happen totally but the only
thing to do dynamically is insert some initial API data.

------
emmab
> The separation of frontend and backend in web development makes a really
> clean separation that I would hate to combine again.

This was the only complaint made about isomorphic JavaScript, and seems to be
a straw man. We can still isolate frontend and backend code even if the
frontend code is being run on a server.

There is still a strong incentive to avoid mixing frontend and backend code so
as to avoid exposing secret business logic to the client.

~~~
Untit1ed
Exactly - when I read that sentence I wasn't sure the author even knew what
isomorphic javascript was. Pulling business logic into the front-end is
admittedly a bad habit that isomorphic javascript encourages, but it's
certainly not a core part of the concept.

Generally you'll have a central API used by iOS, Android, Web etc - isomorphic
javascript is a way to make your web app better, not an invitation to create a
monolith.

------
ryanisinallofus
How do you keep reading past THIS statement?

"It was created to solve the problem of single page web apps running slowly."

~~~
todd3834
I came here to say something similar. This was never the reason for my
interest in isomorphic JavaScript.

------
wwweston
It probably depends on what you're doing.

Are you serving something that's pretty much a straightforward hypermedia
document with minimal interaction enhancements? Pushing markup generation down
the line to the client probably doesn't make a ton of sense, particularly for
mobile. In this case "isomorphic" JS isn't going to gain you a lot, given that
you don't have to do much on the client, but it does let you do most of the
work on the back end, which is nice if JS is your language of choice (and I
like it enough I have no quarrel with you, though you could probably do as
well with any other language on the back end and a bit of progressive
enhancement).

If you're serving an app that isn't really a hypermedia document anymore...
well, first you should ask yourself if your app _really_ needs to not be a
hypermedia document (and if so, maybe consider some of the tradeoffs between
web/native to boot). But assuming you've made those thoughtful considerations,
then yeah, the idea to send an initial payload of API call results along with
any non-cached essential app code makes a lot of sense.

There's an odd in between place that some apps get to where what you're
managing is still a hypermedia document but it's got a lot of independent
subsections that may have their own specialized interactions (Hi, Facebook!).
If this is your app... well, first you should probably be asking yourself if
you might improve experience by moving from the "everything and the kitchen
sink" model into a few more targeted document endpoints. But assuming you've
done that, having the ability to selectively generate document fragments on
the server or the client is probably helpful. And that seems like a good use
case for an isomorphic JS approach.

------
carsongross
I'm amazed at the lengths people will go to in order to avoid admitting that
Single Page Apps are not always, or even usually, a good thing.

Of the web apps I use regularly, the more SPA-ish they are, the less I enjoy
using them.

~~~
overgard
Yeah, unless you're literally making an app where the concept of pages does
not make sense (ie -- a lot like a desktop application), I think single page
apps are usually just not that necessary. And single page apps are WAY more
complicated to write. There's so much more state management.

------
bigethan
I manage a large isomorphic app (m.trulia.com), and it's wonderful for our
specific use case: Mobile website offering an app-like UI.

All our node layer does is route requests, make API calls to our non-
javascript business logic / data layer, and render the backbone app into HTML
on the initial request. So there's a nice clean separation of UI and business
logic, in different repos even.

But as other posters have mentioned, it's only right for you if a single page
app experience is right for you AND site performance (and SEO) is really
important.

------
dasil003
> _It was created to solve the problem of single page web apps running
> slowly._

Wait a second, is this premise in any way true? Admittedly I don't do
isomorphic JS so maybe I'm out of touch, but in my mind the primary driver of
the development of isomorphic JS is simply the pain of seeing repetition of
code across the front and back ends.

Obviously there is an appealing symmetry and reduction in toolchain complexity
from isomorphic JS, and it's certainly an idea worth exploring, but I don't
see it as holding any kind of dramatic promise. At the end of the day servers
and clients are very different beasts that are not fundamentally served by
attempting to make them look the same; there are probably a lot of incidental
gains when focusing on small details of the code, but I don't see how it
translates into a paradigm shift. Not that I dislike the idea, but is the
article setting up a big strawman?

~~~
nailer
Exactly. Everyone I know who's built isomorphic apps has mainly done it for:

\- SEO - having a static ver of a single page app for Google

\- Efficency, delivering a rendered view to browsers when they're not
transitioning from another rendered view.

I've never heard 'single page apps are slow' being the primary reason before.
The load time of a JS binding is pretty low. Most people don't generally
realise they're in a single page app until they move around the app atand in
those cases the user perception is of speed.

~~~
cyberpanther
So officially Google says it can crawl these kinds of sites; however, from
experience this is not the case. So until the future comes there is
[https://prerender.io/](https://prerender.io/).

------
ffn
It's kind of hard to say Isomorphic js isn't the answer when we're not even
answering the same question. Granted server side JS probably might not be the
best answer for slow client load times, but it certainly is a pretty decent
answer for rendering the site for tin-foil users who surf the web with
Javascript turned off (you find these guys when you write sites whose initial
market base is found on 4chan/g/, IRC, tor, etc.).

Also, with regard to the slow client load times, I've personally found an
interactive now-loading page (which you can achieve without any js using
:focus and css3 animation) works wonders with user experience (unless you're
build an ultra-professional-suit-and-tie-no-fun-allowed-you-have-the-right-to-
remain-silent website).

------
emidln
The point isn't to dynamically render it on user request on the server. If
you're rendering something that is primarily static and progressively
enhancing it with user-specific input, you can render the vast majority of the
html ahead of time and serve it statically. Your template can be initialized
on push when the source content changes and then initialized again dynamically
in the browser if content needs to be updated/customized. You're sharing
templates along with context processing logic. This lets you perform SEO
optimizations and dramatically decrease page load times while not suffering
many drawbacks when it comes to your live frontend.

------
knappador
Shipping with the API calls pre-loaded helps unless you need to fetch
additional view code. There's a lot more potential usually for multiple round
trips than just API calls. Iso JS frameworks seek to solve the whole range of
problems and provide structure for clean implementation. They're greatly aided
by the portability of JS. Injecting local-fetched API results as JSON into the
page solves one of many potential causes for multiple RTT on fat clients.

------
gonvaled
I think the author is confused: isomorphic javascript's goal is not to run the
same code on server and client - that is just a (minor) side effect, for some
components.

The main goal is to split the UI generation at a more clear boundary, going
down to the server if necessary
([http://www.nczonline.net/blog/2013/10/07/node-js-and-the-
new...](http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-
front-end/))

------
xtrumanx
This is not the solution I need. The biggest problem I face with single page
applications is that I'm usually on a slow internet connection and I've gotten
using a page while scripts are still being downloaded.

This solution will still make the user wait while scripts are being downloaded
(and then run). Not to mention the SEO implications.

If isomorphic javascript isn't the answer, this isn't the answer either.

~~~
EugeneOZ
Concatenate them into 1 file and problem solved (not the SEO one).

------
megaman821
How much response time improved in the typical case?

If you serve your html, JavaScript, and CSS through a CDN, the user should get
those lightning quick. A dynamic API response should be returned faster than a
dynamic full page response. Then the client-side rendering will take place,
but JavaScript is pretty fast now-a-days.

Surely, this will be slower than a server rendered page, but how much slower
than your typical RoR site?

~~~
EugeneOZ
Actually sometimes it's noticeable slower. Solution for this can be entry
point detached from SPA (when index.html is not part of SPA, renders on the
server side and load SPA in background, while user enjoying first 2-3 seconds
of reading index.html), or it can be just hidden (white page) body of
document, while everything is not ready. Second variant is poor copy of usual
sites loading, so detached index.html or cached data in template or even
isomorphic option - they are better.

------
azmenak
I've been using isomorphic rendering with ReactJS for some websites that are
primarily static (static enough for me to build .html files using React as
kind of template-language which get rendered on deploy) and I've found that
it's been the best in terms of performance and SEO benefit.

I'm enjoying being able to write my react render function once and everything
just working.

------
rjurney
This is how I've always done web development. If you care about performance,
instead of having an AJAXy API load JSON, you just load the data all in the
page's controller and stuff it into a template. Nothing about this seems new
or novel in any way.

I have no comment on isomorphic javascript, I haven't figure it out yet. But
this doesn't seem relevant.

Am I curmudgeon?

------
davydog187
[http://bloomberg.com](http://bloomberg.com) just launched a new site using
the isomorphic javascript framework Brisket, and its pretty damn fast.

[https://github.com/bloomberg/brisket](https://github.com/bloomberg/brisket)

------
zachrose
Is this is the same idea as "bootstrap data"? E.g. just a script tag that you
fill with some JSON and render along with the page, and then your MVC
JavaScript dancing monkey absorbs that data and renders before calling APIs?

------
michaelchisari
Although I love this idea for load times, it doesn't necessarily solve the
issue of SEO. I don't think that's an impossible issue to solve, though.

~~~
guntars
And it's still slower since the JS needs to be requested after the first chunk
of html is parsed.

~~~
cyberpanther
Using standard minification techniques and making your JS asynchronous you can
probably overcome a lot of that wait.

------
the_cat_kittles
i love how the word is "isomorphic" instead of symmetrical or some less mathy
word. it seems like a forced nomenclature.

------
platz
This is called bootstrapping I believe. Before I heard it called that I just
called it server globals or something to that effect

------
jonathancreamer
React + express rendering initially on the server and bootstrapping on the
client is awesome.

------
totemizer
blogs telling us what's NOT the answer are NOT the answer

~~~
steego
Comments telling us blogs telling us what's NOT the answer are NOT the answer
are NOT the answer.

(Sentence verified:
[http://nlp.stanford.edu:8080/parser/index.jsp](http://nlp.stanford.edu:8080/parser/index.jsp))

