Hacker News Reader

Comment by hayksaakian | Hacker News Reader

I don't keep up with meteor, but I have a question for those who do keep up to date on changes.

Can meteor apps be isomorphic -- in the sense that they render plain HTML on the server during first load, and then do the javascript loading thereafter?

I work on several client websites, and passable SEO is a requirement.

I know there's some hackery you can do to get single page apps to be indexed, but I prefer when it "just works" out of the box.

I have some react apps that use this model, and they index perfectly.

View on HN

There is no first-party solution for this yet, since React support came out in this release. Hopefully we can make it automatic in the near future. I think this is a key advantage of the Meteor model - since the parts of the stack are expecting to be used together, they can collaborate to achieve functionality like this isomorphic, re-hydrating, SSR.

There are already some community projects working on this functionality: https://atmospherejs.com/reactrouter/react-router-ssr

If I'm not mistaken every page on this site is React, rendered on the server: https://kadira.io/blog/

More info: https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...

It does indeed appear to be so - and it works great if you disable JavaScript. In fact, if anything, it works better if you disable JavaScript, because it doesn't flicker and jump around as it renders. You might almost be forgiven for wondering why it wasn't just exclusively rendered server-side, really, except it'd probably be heretical to conceive of such an antiquated idea.

They don't exclusively render server-side because it's tremendously CPU-heavy: https://twitter.com/kadirahq/status/620467416749838336

Over the years, Rails has evolved a lot of ways to do server-side rendering while sharing as much as possible between runs. React isn't there yet, but there's no reason that it can't do the same given enough time.

Until then, in many ways, as a user of a site with a modern JS-enabled browser, I'm providing my own CPU power to render dynamic content, thereby subsidizing the site's cost of supporting older/non-JS browsers with SSR at negligible cost to myself (though I suppose everyone's utility function handles occasional flickering differently). I, for one, don't see any problem with this arrangement.

Yep. We don't render all the pages. But most of the pages of https://kadira.io is public. So, we cache a lot.

There are some options that give you server side rendering, for example https://github.com/kadirahq/meteor-react-layout/

You need to use React though, but that's a win in my book since React makes developing Meteor apps so much easier.

It's not just useful for SEO; isomorphic React apps render much quicker on first load and for deep linking into your app.

> isomorphic React apps render much quicker on first load

source?

Evaluate + Layout + Render is not likely to be faster than Layout + Render for equivalent content.

More apt would be Fetch body + Fetch content + Evaluate + Layout + Render vs. Fetch body + Layout + Render

This is a hard generalization to make, but it's certainly true in the worst network condition case. Even if your client-side rendering happens instantaneously and your JS is (magically) 1kB, it's still 2 round trips before you can render anything instead of 1 (well, 4 instead of 3 for TCP connect, SSL handshake, HTML response). On poor mobile connections, a roundtrip will be 500ms+, so if you can render in less time than that on the server, it'll feel faster.

Maybe this? https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...

Sorry if I sound pedantic but the major gain seems to be related to the use of a cache. It is never said that "React apps render much quicker on first load". Actually, the author almost admits that its application was taking 500ms to render a page on server-side.

The issue is not so much about whether React components themselves are rendered on the client or server, it's about the network: all the JS and other data that has to be loaded in general before the browser can begin rendering.

With React you can use the same component code used on the client side to generate HTML on the server side and send that down the wire for first page load. The browser doesn't have to sit there waiting for entire libraries to load and then start building <div>s.

Reply on news.ycombinator.com