Meteor just hit 1.0 and is not the type of framework you can just start including in your stack.

You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack.

As new startups who use Meteor grow you will see those large-scale projects come about.

So, to put it glibly, the only people who will use Meteor for large-scale projects are those who have no choice?

No, not at all. It's the other way around, really. Those who don't use Meteor for their projects may not be able to without trashing existing codebases.

What I'm hearing is that Meteor doesn't play well with others and that you should make the decision to go with Meteor carefully since changing your mind later will require a ground-up refactor.

This is pretty much my experience as someone who started working on a project where the lead dev had decided to use Meteor and then quit leaving a wonky prototype with "reactive data", poor performance and missing functionality.

Now, some would say "it's not Meteors fault the UI wasn't made well!" and then I'd reply "sure, but if Meteor didn't encourage (and it seems, require) tight coupling of the data access and presentation layers, then maybe we wouldn't have spent the last 3 weeks rebuilding the entire app from the ground up just to add some missing functionality and fix UI bugs".

Honestly, I really can't figure out the lack criticism I see of Meteor around here. All these comments to congratulate on an arbitrary step in version number? I see other articles of accomplishment with a fraction of the positive encouragement and many times the criticisms. Is there a silent majority, or did I spend the last few months being underwhelmed by Meteor because I'm missing something?

Meteor embodies, for me, a tool that makes things 'easy', rather than one that makes things 'simple'.

http://www.infoq.com/presentations/Simple-Made-Easy

Anyways, that's just one developers experience and opinion, take if for whatever you feel it's worth.

Meteor does make things easier, by making things simpler.

It is much simpler dealing with Meteor's API's then working with documentation from 3 or 4 different frameworks that you need to accomplish the same kind of stuff Meteor does.

Meteor gives you a set of clean coherent APIS to work with to get stuff done.

Meteor doesn't require tight coupling between data access and presentation layers. Personally I use meteor with react.

A lot of criticism of "new shiny tech" gets downvoted/flagged on HN so people don't even bother anymore, while another useless library in Go/Javascript gets pushed to the top of the front page.

No, the people who use meteor for big projects are those that started using it when they started it as a small project.

Because if you started a small project in something else, it is not easy to change it to Metero later.

What he said was quite clear.

Quite the opposite. Those who can choose anything choose Meteor.

Actually, you can use Meteor as a frontend-only framework. Just have the Meteor server be the client for a standard REST API. I've built an app using this approach.

So is it a PaaS like Google App Engine? Is it just an MVC like angular or ember?

No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits the actual server response. Client changes to the data are immediately effected in the browser DB, while the change is authorized on the server, synced to other server instances with MongoDB oplog, and then pushed down to all clients subscribed to that data. The templating engine is then reactively informed of the data change, and the DOM is updated at the lowest level possible such as modifying an individual text node.

Thanks for this info.

Does it have to use Node.js on the server can the client side framework work with any server side JSON service?

You need to be running the Node.js Meteor application. The client relies on DDP rather than REST and right now Meteor is the only server framework using DDP. There is, however, an isomorphic HTTP library which makes it easy to communicate with third party REST APIs on both the client and server. It is also easy to create REST endpoints for your Meteor collections, so that third party services which don't support DDP can communicate with your app.

It is very possible to use other client side frameworks such as Angular or Polymer, rather than just using Meteor's Blaze UI engine. However I find that Blaze's Template<--Helper<--Data<--Event system is extremely easy to understand and reason about.

Edit: Actually, they do seem to have a decoupled version of the Blaze UI that you could use just for your reactive DOM code and hook into a REST API. You just won't get any of the server-dependent features like full-stack automated data synchronization, hot-reload, live CSS injection, or Meteor's build chain. You just get a simple reactive template/helper/events system. http://meteor.github.io/blaze/

Thanks!

I think it has to be Node.js all the way down.

Spot-on explanation, wish I could be so coherent when trying to explain Meteor to other people.

It seems like too much magic until you've been exposed to it a bit. It's actually pretty simple to visualize what's going on under the hood, but it takes a bit to click. Reading the DDP spec and the tracker package definitely helped me grasp the concepts. The new subprojects page is also great at explaining the major Meteor components: https://www.meteor.com/projects

It is not a PaaS, it is a framework that goes a bit further than previous frameworks. Angular and ember really just work for front-end code.

Meteor spans both the front-end and back-end to offer a seamless API experience when building your application.

It's basically something like Java Server Face in javascript,which can be a good and a bad idea...

We've built a huge meteor app that has scaled to 1000s of concurrent users and still growing -- there have been some sticky points along the way, but overall, we're extremely pleased. Meteor is an amazing engineering feat.

Do you have any posts on how you scaled Meteor?

We will be sharing more soon. We've been developing with Meteor since the winter of 2012 and two main scaling issues have crept up: (1) the web tier was a bottleneck prior to 0.7.0's implementation of oplog tailing; and (2) post oplog tailing, mongo actually became our bottleneck with the write locks. We were able to get to about 3300 concurrent users (in our very data-intensive application) against a single beefy mongo primary before the database started choking, and at that point, we could set our readPreference to the secondary in order to further scale horizontally.

Okay, I'll bite: who is "We"?

"We" is [edSpring](https://www.odesk.com/o/jobs/job/_~0155480bf02dee46f3/), built by [TIES](https://www.linkedin.com/company/948661).

"We" are providing a large scale application in the education space, with more details to follow. I am not able to give much more now, but I can say that given the contractual nature of our application, we've been fortunate to start out with a HUGE user base that has taxed Meteor and exposed its scalability issues more than most typical Meteor apps at this time. It's still young, and there are some significant advances that can be made to its oplog driver, but overall Meteor is incredibly forward-thinking compared to other full-stack implementations. Philosophically speaking, you must be all-in, however, otherwise you will always kick against the goads. As everyone's favorite theologian would say.

I'm excited to hear about it. http://fourbeansoup.com/ has some cool-looking apps!

the site tweet hopper dot com link from this site appears to have been compromised and is pushing malicious scripts be careful.

By “goads” do you mean “gods” (in, like, the Battlestar Galactica sense) or is that supposed to be “gonads”, as in junk? Just askin.

"Apparently, "to kick against the goads" was a common expression found in both Greek and Latin literature—a rural image, which rose from the practice of farmers goading their oxen in the fields. Though unfamiliar to us, everyone in that day understood its meaning. Goads were typically made from slender pieces of timber, blunt on one end and pointed on the other. Farmers used the pointed end to urge a stubborn ox into motion. Occasionally, the beast would kick at the goad. The more the ox kicked, the more likely the goad would stab into the flesh of its leg, causing greater pain."

Src: http://www.jesus.org/early-church-history/the-apostle-paul/h...

the phrase was translated by King James as "kick against the pricks" [1] src: http://www.gotquestions.org/kick-against-the-pricks.html

Did/have you tried tokumx ?

No, we've seen it however...we've lacked the time to investigate properly. Very intriguing.

I wrote something on scaling meteor: http://joshowens.me/how-to-scale-a-meteor-js-app/.

Cool, but could you throw in some RAM and CPU usage stats?

It's definitely a win for hackathons and getting a MVP out there that needs real time features. I can't speak much for large scale projects since I haven't had the fortune of reaching that scale yet with meteor, but I'd imagine it will be ideal for that eventually simply by extrapolating the current growth and improvement trends of the framework.

At last months devshop in SF a speaker discussed straining the system and reaching the limits of Meteor with just hundreds of simultaneous connections:

https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s

Hundreds isn't really exactly "webscale", but I'm sure they'll iron it out, or it could have just been the application that was at fault. It's one data point however on how meteor scales.

[I work at Meteor and contributed to the MongoDB realtime driver]

Scaling low-latency data synchronization is a challenge for scalability for sure! We are gradually building better and better drivers with persistence to MongoDB.

The scalability can vary greatly depending on your application's data schema, usage patterns and amount of writes.

If you watch the mentioned talk carefully, the speaker describes a collaboration tool with log replay with a lot of actions and running from a single box.

The "running from a single box" at the end seems like it could be the most important part of the equation. Would you agree? Or rather, would that be the recommended place to start optimizing if your app runs into scaling problems?

Here is a very fine blog posts series on scaling Meteor horizontally, please consider looking at it: https://meteorhacks.com/pro-meteor/

Interesting, thanks. In that first blog post it mentions that Meteor serves static files. Is that a requirement?

edit: posted too soon they talk about it here https://meteorhacks.com/does-meteor-scale.html

And you can use cloudflare or some other CDN very easily. See: https://meteorhacks.com/cloudflare-meets-meteor.html

No, it is not a requirement. Meteor also supports serving static files from a CDN.

I don't know how you could load balance meteor easily, but you could put your mongodb instance anywhere and pass in its location to meteor. This doubles your risk for downtime because of hardware failure though, your uptime is no longer as good as a system that depends on the uptime of a single machine.

I like this description; "a framework for hackathons and prototypes"

In terms of complexity, the software I'm developing in Meteor has a lot of moving parts (animation, physics, artificial intelligence, and hardware integrations) and Meteor has handled it all tremendously well. In terms of user scale, I haven't had much experience, due to the nature of the project. It has made our development team tremendously happy, and provided a tremendous amount of flexibility compared to other approaches we've tried in the past including Objective-C and Java.

What would concern me is if you ever reach a scale where you need to optimize in ways that Meteor can't support. But, that probably falls into the 'problems you want to have' bucket.

If you look at the main website there are 6 featured videos of real companies using Meteor in production.

It was completely unclear to me that those were links. I guess that's my feedback? Thanks though!

(I work at Meteor) We'll fix this soon! Thanks for the feedback.

I'm wondering if it's true usefullness is potentially in an Enterprise supplemental tool to cobble together some quick apps, maybe like what MS Access was used for a long time ago, except this time you get nice browser-based, reactive applications.

I'm not sure you'd use it to build the infrastructure of your startup on. Or a content heavy site. But I see building tools like for managing a lot of developer instances, internal tools for config, etc to possibly be pretty sweet for this.