[treve]

Meteor is still way too magic for me. Seems great for rapid prototyping of real-time applications, and perhaps things like games... But I don't think I would feel comfortable building a large application on it.

The problem space that it solves is not that hard, it just provides an extremely magical way to go about it. I imagine this makes things a lot harder to change, debug and maintain.

But then I'm the type of person who prefers boring and predictable, with a very big separation between front and back-end concerns.

I've been leaning towards the opposite architecture of what Meteor does, creating 3 entirely different layers for 1) core business logic, 2) web backend, 3) web frontend, whereas Meteor seems to want to blur the lines where things are happening.

[tedchs]

It also depends on MongoDB as your sole backend database. I played with Meteor when it came out and I concur maybe Meteor is OK for prototypes but for something production ready I'd rather just use Angular + Google App Engine + Google Cloud Endpoints.

[goldenkey]

Kind of silly that you wouldn't use MongoDB yet you'd use GAE. GAE is a turd, Google has been struggling to compete in the cloud business and failed to come out with any value. You get locked into a Heroku-like platform with awful performance, awful stability, and arcane quotas.

http://www.carlosble.com/2010/11/goodbye-google-app-engine-g...

http://3.14.by/en/read/why-google-appengine-sucks

[tedchs]

Thanks for the feedback. I would encourage you to note that those blog posts are from 2010 and 2009, and my understanding is the platform has improved dramatically in the ensuing 4-5 years. I'm a Linux systems engineer, but for an app where I'm not going to admin my own infrastructure, I have been happier with App Engine than other PaaS options.

[goldenkey]

No competent Linux admin would use a PaaS. I find it very hard to believe that you'd rather use GAE instead of a virtual dedicated.

[phpnode]

I'm curious about your choices here, I would not really trust MongoDB with my data for a few reasons, but at the same time, building on Google's services seems even more risky - if they shut down those services (which is not inconceivable), you'd be facing a pretty nasty rewrite + migration to a new platform.

[emgee3]

One cool thing about all of Meteor's magic is that it's quite understandable. Chris Mather's EventedMind and Arunoda's MeteorHacks are good resources for looking behind that curtain.

In my experience, once the magic becomes more of an understanding of the Meteor-y way of doing things, then debugging and maintaining isn't any harder than a more traditional architecture.

I wouldn't say that Meteor is a suitable framework for any type of app, but I would say its design is suitable for a lot more than just prototyping and games (with a pre-1.0 caveat).

[jaunkst]

I have to agree with separating the concerns. Different patterns for each are better. This leans towards higher flexibility and understanding of the domain.

[happyscrappy]

You don't have to blur the lines if you don't want to, don't use globals if you want purity.

[treve]

I imagine that the further I would go away from Meteor's style of programming and go to two isolated code-bases (front and back) I would also lose a major part of why one would use Meteor in the first place.

[joshowens]

Having tried to build several businesses where I separated concerns across code bases, it always ended up painful in the end for me.

Perhaps being an older (nee wiser?) developer, I could pull the idea off in a more nuanced way, but I bet I will still hit painful points down the road.