debergalis

Yeah, absolutely. See http://roadmap.meteor.com/ for the high-level view and http://github.com/meteor/meteor/issues for some starting points on building out code. Another good option is building Atmosphere packages at http://atmosphere.meteor.com/.

[meteor dev] Please come help us with this! We have six engineers at Meteor and dozens more contributors in the community working on the platform every day. The plan to 1.0, including REST, is at http://roadmap.meteor.com/.

Here's the guiding principle behind Meteor. There should be a dramatically faster, more accessible way to write applications. Improving that developer experience means rethinking some things: autopublish and minimongo, so you can jump right into a new app's UX in the first five minutes; one-line authentication (http://meteor.com/authcast); synchronous APIs that are more comfortable for a lot of developers; dirt-simple reactive templates; hot code push.

Focusing on that kernel of development experience means some other things -- REST, routing, form building -- need more time to fully bake, with hacks like __meteor_bootstrap__ and phantom for apps that need them now. We think that's a good tradeoff pre 1.0.

[meteor dev] The `spiderable` package is just our hack to let search engines index our own website. It works surprisingly well for that, but it's certainly not the long-term solution.

There's a fuller explanation of our routing / REST plan here: https://trello.com/card/page-model-server-side-rendering-res...

[meteor dev] Meteor treats the server as an environment for running arbitrary privileged code. You can write server-side logic that consults third-party services, logs client writes to a separate audit trail, keeps authentication state between requests, or implements complex transactions across multiple tables. Similarly you can write code to run periodic database updates on an interval, or respond to incoming HTTP requests from other clients.

Not all apps need this stuff right away, of course, and some never do. But it's hard to do these things w/o a secure server environment for privileged code.

And then of course there's the usual tradeoffs between having control over your hosting environment (a la Meteor) and outsourced backends as a service (a la Firebase).

We're big fans of Firebase, BTW. We think more databases will move to a realtime model. Excited to check this out.

[meteor dev] Meteor + Mongo may be a good choice for you. The leaderboard example at http://www.meteor.com/examples/leaderboard already has a lot of what you need. The trick is figuring out how to identify each client: whether you have users log in or just assign a unique ID to each client.

We need both. Many devs love the screencasts.

[meteor dev] I explained a bit more of the philosophy behind the Meteor security model in a Stack Overflow answer: http://stackoverflow.com/questions/13331836/meteor-userid-is...

And of course, http://meteor.com/authcast if you haven't seen the 0.5.0 screencast.

[meteor dev] I had a chance to meet Sacha and Tom a few weeks back. They're two of the nicest fellows I've worked with -- absolutely delighted to have them as leaders in the Meteor community.

[meteor dev here] The latest plan for 1.0 is at http://roadmap.meteor.com/. It's too early to have a specific release date but it'll be well under a year from now.

This is why we used a Trello board. These can move around, and all the votes for i18n help us prioritize it against other items.

Please do: there's a card for additional databases on the roadmap.

[Meteor dev here] This roadmap is a starting point for a discussion. I want SQL too -- the question is whether there's a 1.0 we could ship sooner that's useful for a class of applications based on Mongo.

You can try out the prerelease auth feature right now if you want. A bunch of projects are using it.

https://github.com/meteor/meteor/wiki/Getting-Started-with-A...

Good point. We do use Meteor. Our own site has always run on Meteor, and we build other tools and personal projects with it. Dogfood is good -- we now have an experimental version of server side rendering in Meteor because we had the pressure to get www.meteor.com into Google's index.

It's not a bad strategy to build the framework alongside a product. But shipping real product is a huge commitment. We spent weeks just getting all the pieces in place for the first Meteor release in April: text, design, docs, a screencast, release engineering, community outreach. For now, we think we can move faster and build a better framework if that's our only product focus, instead of trying to ship two great things at the same time.

That's precisely how Meteor auth works. Each client can request a set of documents from the server -- think of it as a predefined query. For each of those requests, your server code decides what (if anything) to send back to the client.

Thanks.

Yes, we now have an authentication system that lets you define limits on which documents each client can read and modify. It's available on the "auth" branch in the Meteor repository.

https://github.com/meteor/meteor/wiki/Getting-Started-with-A...

We got some amazingly specific and valuable feedback -- check some of the Meteor HN threads. MIT is going to be a big part of making Meteor available everywhere.

Thanks! auth is next. But check out the madewith.meteor.com source for a good example of how you can lock down an app today.

[I'm one of the Meteor authors.]

We released under the GPL Tuesday because our single goal was to share our work and direction of thinking with everyone. We hoped to spur a discussion about new ways to build apps that dramatically changes the skill sets required and the time it takes. We look at Meteor as part of an exciting transition from LAMP to a new architecture of rich client applications (see also http://www.firebase.com/ that launched yesterday!).

That's still the main focus for now. Hundreds of developers have deployed apps to meteor.com. We've got pull requests for new features to sort out, and many technical questions to answer. There's a whole buffer of screencast ideas we want to do.

The four of us are a company. We intend to make money while committing ourselves to an open-source strategy. We want to see great software -- not just ours -- be something developers can sell. So while we'll give away much of what we build, we'll also look for places where developers who gain benefit from Meteor can give something back.

We did not expect such strong interest in writing closed source commercial apps this quickly on the platform. It's clearly something we have to sort out faster than we thought, and we will. For now our offer stands: please just write us if you need a commercial license for a closed source project and we will find a way to accommodate your needs. I'd imagine over the next couple weeks we'll have more concrete things to say.

We've actually written a lot of testing for the core framework packages -- those tests are in each package directory. Look for *_test.js files.

https://github.com/meteor/meteor/tree/master/packages/

You're 100% right though. We don't have a fully baked story yet for application level testing. It's something we're trying to push forward as soon as we can.