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