Show HN: Meteor, a realtime JavaScript framework

woha. this looks like what I build using Nowjs and Knockoutjs. (https://github.com/neebz/Real-Time-Notice-Board) plus mongodb access. Great stuff.

Hey, one of the Meteor authors here. Meteor's architecture makes it super easy to make an API. It's one of the advantages of building your architecture around sending data around rather than HTML.

We couldn't go into everything in the video (it was already too long!), but the piece you're missing is Meteor.methods(). This lets you define methods, which are functions that the client can invoke on the server by calling Meteor.call(). If you choose to also ship the code for these methods to the client (it's optional) then you'll get full latency compensation like we talk about in the video. (This means that Meteor can latency-compensate arbitrarily complex functions, like "read this record, then add 2 to X if this field is false, else create a new record Y.")

In fact, every Meteor app already has an API :) Your Meteor client can connect to any other Meteor server by calling Meteor.connect(), and can then subscribe to any realtime datasets that that server is publishing, or invoke any methods available on that server. This is done with a protocol called DDP, but we could map DDP to REST fairly easily.

"Avoided" by, well, reimplementing MongoDB in JavaScript, but it's totally worth it :) And not as many LOC as one might expect.

Anyway, thanks much for the support :)

It depends what the Meteor team has in mind.

If they want this to be the next Django/Rails/Express/whatever, where a large and enthusiastic community both uses and develops the product then the answer is fairly clear: No, this is not a suitable license.

If their idea is that it's an nominally open source project where all control and most development takes place inside the originating company, and the community mostly just pays license fees then: Sure, it's a great license.

Longer clarification: Django is licensed under BSD, Rails and Express under MIT. Why? Because these licenses allow me to use these frameworks for my own webapps, without making the entire client/server code base available. I can toss together a Rails-based contacts manager, or a Django-based todo list app, and let people sign up, and even charge a monthly fee, and NOT have to give the code to the entire app out.

Someone else linked to Sencha's discussion of the GPL and JS webapps, and it's highly relevant: http://www.sencha.com/legal/open-source-faq/

In short, as long as Meteor is under the GPL, I can use the framework for free, but I cannot let anyone use a webapp I create with it without giving away all the source code. Which means that I'm very unlikely to actually install and try Meteor on my next project. My choices are basically "ignore Meteor" and "pay a license fee to the devs". Meteor is awesome, and probably well worth the license fee (whatever it might be), but it's fairly obvious that this is a huge limitation on the frameworks potential for adoption.

(It's worth noting that both Django and Rails were actually developed for a project, and then released under permissive licenses, because the framework wasn't the product, and the dev teams didn't need to try and monetize it. Meteor is the product, and the dev team does need to monetize it. And, again, Meteor looks awesome! So I can fully understand why they chose GPL, and I fully support that choice! But it is worth noting the consequences of that.)

Yeah, there still a few places where Mongo is hardcoded (the prototype assumed Mongo everywhere, and we've gradually factored out these assumptions.) Most of these places have to do with the code that automatically starts mongod for you when you type 'meteor' to run your app in development mode. I think all of the database assumptions have been factored out of livedata, but we'll only know for sure once we have a second database packaged :)

And yes a second time: to package a sql database, you would ideally have a 'minisql', a client-side cache with a sql-compatible interface. It's not strictly necessary though. There's no reason a DDP[1] dataset couldn't use a different database API on the client and the server (say, sql on the server, mongo on the client), but if you did this and you wanted latency compensation, you'd have to write all of your methods twice, once against each API.

I am really excited about having sql support, but we tried really hard to defer anything that wasn't absolutely necessary for release :)

[1] DDP is the protocol that livedata speaks between the client and the server. In Meteor, the client and the server mostly keep themselves at arm's length. The client doesn't know that the server is made with Meteor, just that it speaks DDP, and vice versa.