Isomorphic JavaScript is not the Answer

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.

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.

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.

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.

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

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.

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

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.

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?

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

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

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.

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?

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

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

Am I curmudgeon?

https://github.com/bloomberg/brisket