[richardofyork]

> ..."it’s not ideal for sites that need to load very fast (like e-commerce sites)"

Sasha, could you elaborate on the quote above a bit more so that we can better understand which use cases are not ideal for Meteor right now? Thanks.

[sgdesign]

Author here. What I meant is that as of now, all Meteor sites have a fairly substantial loading delay (generally a couple seconds) due to the way Meteor works.

So for sites or apps where loading speed has a direct impact on your bottom line and that don't really benefit from real-time features (such as an e-commerce site) I don't think Meteor is a good match, at least for now.

I also don't think Meteor is needed for purely static content sites. For example, for our own book site we're using Jekyll.

(And yes, I know speed is important for every type of site. But in most cases, I feel there's enough other benefits to building Meteor apps that you can ignore this downside for now).

[systemtrigger]

When a template subscribes to data in a server collection, there is a delay between the moment the subscription begins and the moment the client displays the data it receives from the server. On page load you really notice the delay because there is nothing else for the user to see while the client waits to receive the data from the publish action. The way around this is to show something else on the page so that the user doesn't notice the delay. One way to do that is to show only static assets during that time, another way is to use local (client-only) collections.

[adamstac]

I have to agree -- I was wanting Sacha to expand on not being ideal for e-commerce sites as well.

[colinramsay]

Presumably he doesn't specifically mean e-commerce sites, just sites that are required to be highly responsive - where you don't want to send the JavaScript, then the JSON, then do the rendering. You want to start with the static, rendered HTML then decorate that with JavaScript for subsequent interactions.