5 ms·

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

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.

sergiotapia 11y ago
There are some options that give you server side rendering, for example https://github.com/kadirahq/meteor-react-layout/ 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.
deleted 11y ago
[deleted]
djmashko2 11y ago
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 https://atmospherejs.com/reactrouter/react-router-ssr
applecore 11y ago
It's not just useful for SEO; isomorphic React apps render much quicker on first load and for deep linking into your app.
- gildas 11y ago
  > isomorphic React apps render much quicker on first load source?
  - lotyrin 11y ago
    Evaluate + Layout + Render is not likely to be faster than Layout + Render for equivalent content.
    - lostPixels 11y ago
      More apt would be Fetch body + Fetch content + Evaluate + Layout + Render vs. Fetch body + Layout + Render
  - phleet 11y ago
    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.
    - deleted 11y ago
      [deleted]
  - rofrol 11y ago
    Maybe this? https://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...
    - gildas 11y ago
      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.
subpixel 11y ago
If I'm not mistaken every page on this site is React, rendered on the server: https://kadira.io/blog/ https://kadira.io/blog/ More info: https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-router-and-react https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...
- bshimmin 11y ago
  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.
  - btown 11y ago
    They don't exclusively render server-side because it's tremendously CPU-heavy: https://twitter.com/kadirahq/status/620467416749838336 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.
    - arunoda 11y ago
      Yep. We don't render all the pages. But most of the pages of https://kadira.io https://kadira.io is public. So, we cache a lot.

sergiotapia 11y ago

There are some options that give you server side rendering, for example https://github.com/kadirahq/meteor-react-layout/ 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.

deleted 11y ago

[deleted]

djmashko2 11y ago

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 https://atmospherejs.com/reactrouter/react-router-ssr

applecore 11y ago

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

gildas 11y ago
> isomorphic React apps render much quicker on first load source?
- lotyrin 11y ago
  Evaluate + Layout + Render is not likely to be faster than Layout + Render for equivalent content.
  - lostPixels 11y ago
    More apt would be Fetch body + Fetch content + Evaluate + Layout + Render vs. Fetch body + Layout + Render
- phleet 11y ago
  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.
  - deleted 11y ago
    [deleted]
- rofrol 11y ago
  Maybe this? https://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui https://signalvnoise.com/posts/3112-how-basecamp-next-got-to...
  - gildas 11y ago
    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.

subpixel 11y ago

If I'm not mistaken every page on this site is React, rendered on the server: https://kadira.io/blog/ https://kadira.io/blog/ More info: https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-router-and-react https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...

bshimmin 11y ago
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.
- btown 11y ago
  They don't exclusively render server-side because it's tremendously CPU-heavy: https://twitter.com/kadirahq/status/620467416749838336 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.
  - arunoda 11y ago
    Yep. We don't render all the pages. But most of the pages of https://kadira.io https://kadira.io is public. So, we cache a lot.