Hacker News new | comments | show | ask | jobs | submit login

Hey everyone! The four of us have been working very hard on this for the last six months, and we're excited to finally take the wraps off. Can't wait to hear what you think!

We've got a lot more stuff coming over the next few months, and if there are particular things you'd like us to do/prioritize, I'd love to hear about them!

This looks fantastic. I genuinely got giddy watching the screencast!

If I were to use Meteor for a partially closed source app earning around $1000 per month, how much could I expect to pay you? From the FAQ:

> If the GPL doesn't work for your project, get in touch (contact@meteor.com) and we will write you a commercial license to your specifications.

I love everything about Meteor so far, except for this.

This is no way to answer such an important question that most potential users will have - let's face it, there's a lot of people who will want to use this for open source, but a lot more who will want to use this for commercial apps. To ensure Meteor's wide-spread acceptance, you need to clearly answer this question on FAQ page, and not with "we need to have a conversation".

A great many things are sold this way, and it is sometimes unavoidable. Commercial projects tend to have a wide range of requirements from a licensing point of view so if they spent time drawing up a full commercial license they would end up having to rearrange half or more of it for the first commercial client that came along anyway. They could spend time drawing up many license templates (world wide, X,000 users, X server, ...) and pricing plans with many combinations of support and development agreements to try cover the bases - or they could spend more time coding.

Their preference is that the library be used under the GPL. That is their choice and it is a fair enough choice. But they also acknowledge that some entities can't accept that for one reason or another, and are willing to be flexible. Very flexible: instead of saying "this is our commercial license, deal with it" they have said "tell us what you need, and we'll see what we can do".

Fair enough - if that's their choice, that's totally understandable. But my point is - if they wish to make it a wide-spread popular platform for web development, this is not the way to go about it. An MIT license like Rails would be a much better choice.

How is your application distributed? If it's a web app that you run on your own servers, GPL doesn't apply to you (only AGPL would).

That part of the GPL faq refers to server side code, not client side code. Client side code very clearly gets distributed to third parties.

Ugh, I didn't even consider that a (partly) client side framework would have been GPL. Unless they come out with a very clear, simple and friendly commercial license it pretty much kills meteor for all practical purposes.

(To be clear, it's not that I begrudge the author's their right to license it how they want. I simply think frameworks like this are too central and important to have any uncertainty about licensing associated with them.)

Well, no one has mentioned anything about the awesome domain yet, so I guess I'll have to -- meteor.com -- great domain guys :)

I was wondering how they scored that one too.

Meteor is a horrible name for a programming language. Meteor's crash and burn! lol.

Fairly certain that they're playing off of [Comet](http://en.wikipedia.org/wiki/Comet_(programming))

Actually, they tend to burn up in the atmosphere :)

Impressive! I was blown away by the fact that you don't need callbacks and events for the DB operations. Can't wait to dig in the code and see how you guys managed to make that work :)

great launch - most of the stuff that was out there just didn't do it for me. I've done lots of app development before and the new JS frameworks were pale in comparision.

You guys have done a great job at making a true reactive system that doesn't burden the developer with complex binding/event systems. I also like how you guys have avoided the persistent store impedance mismatch :-)

overall, i'm excited to try this out. great work.

"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 :)

Is anybody paying you to work on this full-time?

Judging from the "About Us" page, it sounds like these guys are "financially independent" enough already...

yeah... the "people" section makes me feel very unaccomplished :-(

They must have a good amount of money to have that URL.

I haven't been this impressed since DHH showed off Rails in 2004.

Mind blowing. Feels very desktop-ey for a web application. The included deploy to cloud options are a huge plus!

Things seem to go in cycles in computing (and life in general). We had a solid model for developing single user applications, then we dropped that in favor of multi-user (web) applications. Now it's going full circle and we get the nice rapid development tools again. I wonder what the next cycle will look like.

Looks very interesting ... This or something like it seems like the obvious "other shoe" for nodejs.

Are you guys in Boston?

We visit a lot, but we all live in the Bay area these days.

This looks awesome! Nice work guys.

Does this work with something like Plates or Weld.js, or does it replace them, or does it shun that approach altogether?

Bravo! The earth has been waiting for this. ;)

Simply WOW...I'm really blown seeing the screencast...keep up the great work!

looks amazing..hope to see this take the position of Rails!

Can you relax server side requirement a little bit ? Lots of people, including me, want to run such app on google app enigne which do not support node.js yet.

It's been built using Node.js. How on earth are they supposed to 'relax' their dependance on it?

I think he was hopeful that the same benefits could be achieved with a different server-side runtime. It's a long-shot, but with good socket-sync and something like the client-side MongoDB adapter, Rails could come pretty close.

We got pretty comfortable with the commodities the Rails environment provides, so it's understandable some people would rather just add another layer (Backbone/Spine) and avoid the paradigm shift.

The advantages of attacking new problems with a new toolkit can sometimes appear less beneficial, because swapping out the current mega-stack for something slimmer inevitably leads to reduction in features (ie.: You end up making another `view` in place of a collection partial. Mailer, gems/middle-wares, etc..)

That said, despite getting pretty comfortable with Rails/Backbone|Spine, I'm in the pragmatic camp, looking forward to tackling a few side-projects with Meteor.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact