After seeing the first, extremely slick demo of meteor, I was, as I believe a lot of people were, extremely excited to see where the project would go. Then came the funding, and some twelve or sixteen months of development, and I finally decided to dive in.<p>I really wanted to like it. I was predisposed to do so.<p>But from the very beginning, I was confronted with something I consider a deal breaker. While I am wary and generally disinclined toward the increasingly popular pattern of curl an installation script and pipe into sh, in this case it is not only skeptical, it is downright ludicrous. Why would I, nay anyone, want to install an npm package this way? Should not the installation instructions simply be `npm install -g meteor`? And what if I need to work on multiple meteor projects with different versions? Surely there is support for adding it to your package.json file, but why is this not the primary means of installation and well documented?<p>Maybe I am being overly sensitive to these issues, but it really baffled me that the very foundation upon which a meteor project is predicated would be contradictory to the typical node workflow. I will probably try meteor to spike out a project at some point in time, but I do not foresee myself using it extensively in the near future.
Congrats to the MDG team on having 1.0 within reach, and thanks for releasing an amazing platform.<p>Meteor is one of those platforms that you should try. I could give you a menu of features, but the productivity boost from Meteor is one of those things you really should experience. The productivity boost is very real and its quantifiable.<p>An experienced developer can get a very good feel for Meteor over a single weekend:
1. Buy the book: <a href="http://www.discovermeteor.com" rel="nofollow">http://www.discovermeteor.com</a> (the book is $39...I did not purchase the other packages)
2. Spend a weekend doing nothing but coding<p>Come Monday morning you'll know what Meteor is about.<p>PS: I am not part of MDG, and I have nothing to do with the book (other than having bought a copy).
Earlier this year, I did an experiment: I implemented the design for a reasonably simple rich web app using two different stacks: Clojure on the server Clojurescript for the client, and the other being Meteor.<p>I have lots of Clojure experience but little Javascript experience. Still, the Meteor implementation took me half as long and had more features. That was a surprising result for me.
If you're curious about Meteor, I recently wrote a short introduction to it from the point of view of front-end JS developers: <a href="https://www.discovermeteor.com/2013/09/17/meteor-for-front-end-engineers/" rel="nofollow">https://www.discovermeteor.com/2013/09/17/meteor-for-front-e...</a>
I made a meteor app and it was one of the best experiences I've ever had making a web application. Even though what I made was fairly basic, the ease of creating a real-time application was amazing.
Thanks for posting this. Great overview of what to look forward to. As someone writing an app in production based on 0.6.5, should I plan on any big "rewrites" as the framework approaches 1.0? A better question might be, what will be backwards compatible and what will I have to scrap? It sounds like packages are the one area I should be the most careful with...
I've read through the documentation twice (once when it was released and again a week ago) and reviewed the basic demos. Meteor's front end structure seems like it's missing something. It has a data layer and a view / template layer but nothing else. No routing, controllers, etc.<p>Is there a good demo / tutorial that integrates these missing components, either from meteorite libs or well known projects like Angular or Backbone?
I've been using Meteor since its release and its been great at making apps at maximum velocity.<p>You mentioned that some people are already scaling Meteor across multiple servers.
Looking at it, round robin load balancing won't work given requests to a server seem to be stateful.
How is that being done as of now? Do you guys have any guidance on how to do that?
I'm very impressed by the technology behind Meteor, I just wish it weren't quite so "opinionated". It relies on standard parts of the node/js web stack, it would be great to have a stand-alone library that supported DDP for front-ends and servers of the developer's choosing.