Hacker News Reader

Comment by yefim | Hacker News Reader

How does Derby stand up to Meteor? I'm really glad Derby has updated but Meteor (at least to me) seems miles ahead of the curve right now.

View on HN

Meteor is more mature, but it doesn't do server side rendering or operational transform for document updates. As far as I know, meteor is also limited to a single server. Derby now supports scaling over multiple processes on multiple machines. On http://sink.derbyjs.com/ I get DOMContentLoaded (including all the page content) in 70ms.

I thought Meteor added server-side rendering a while ago? http://www.meteor.com/blog/2012/08/09/search-engine-optimiza...

Or do you mean something else? I'll admit to only really watching all of this from afar, I could have my terminology backwards.

This module is intended specially for spiders to be able to see something of what the rendered page would look like. That provides an SEO stop gap, but it does not have any effect on regular users. Server-side rendering the first request greatly decreases the first page load time, which is typically extremely slow for complex client-only web apps.

Meteor's server side rendering is a hack that uses PhantomJS and is primarily for googlebot

Sure, but it still does it, no? I agree it's architecturally icky, but it gets the job done, I assume?

It's not really the same thing. Since Derby is natively rendering server side, it's blazingly fast. You get the best of both worlds, render the initial page load on the server, and then all subsequent loads are on the client (with the data being sent over the wire using websockets or browser channel). This means you're getting initial page loads in the 70-300 ms range whereas rendering via PhantomJS and then serving to the client is much slower and much more CPU intensive.

As far as I know, Meteor doesn't even serve those PhantomJS rendered pages to the average user - only to crawlers - presumably for the reasons above.

Gotcha. Thank you.

Reply on news.ycombinator.com