I'm considering using meteor for a small project currently on my plate at work because I really love the idea of only writing the data model once and using that in both the front and back-ends.
Absolutely. The sheer simplicity of Meteor is taking me back to the days of hacking together simple web pages with HTML, CSS, and a sprinkling of JavaScript, only now it's possible to build much more feature-rich creations. :)
David, thanks a bundle for making your book available for free online, a decision so unselfish and so revealing of who you are and how much you love Meteor.
We're a small dev shop currently researching and evaluating Meteor for an in-house HTML5/PhoneGap hybrid mobile app. What we haven't found yet is a definitive, best-practice article or guide on how to "Meteor-enable" or integrate Meteor with the front-end Javascript UI frameworks we use or plan to use (DevExpress DevExtreme, Kendo UI, Polymer, Google's Web Starter Kit).
We're thinking that there must be a clear, definitive "right way" to get these frameworks work smoothly with Meteor. We haven't found such a resource yet to guide us through, and we're still looking.
I've recently picked up meteor since the place I joined newly is using it in production. Put myself through a crash course using the discover meteor book. Any new resources on how to learn Meteor are much appreciated so just wanted to say thank you for this. It's awesome that you picked one of the simpler examples that still cover the core principles of Meteor. The pattern in which the book is written along with the recommendations to read it once without coding and read it again this time coding is great.
The only quibble I can find with the book is that since you've said, experience with building web apps is not necessary, I think you might want to dedicate a chapter to teaching that. I remember learning web apps for the first time, and the only time it actually clicked into place was when the whole concept of how pieces come together was shown. Nothing fancy. I learned web apps using udacity's course so that should give an idea of how simple a chapter it should be. I think it would really help given how much magic seems to be going on at any time with Meteor.
Thanks again for this. Kudos and keep up the good work
As for your suggestion, I'll have to check out that Udacity course like you suggested. My worry is that the book could become too heavy on the theory within the first few pages — I mostly want to get the reader's fingers on the keyboard as soon as humanly possible — but can see where you're coming from and will do what I can in the next few versions of the book. :)
Since you mentioned it, I wanted to highlight the Discover Meteor book as well. I went through it when they had the free access weekend a while back and found it extremely informative and helpful to the point I purchased it afterwards.
This one looks great as well from a first glance so I'm excited to check it out.
Usually refer to it as just "Meteor" but, in the form of a headline, "Meteor.js" feels a tad more descriptive. Even if someone has never heard of Meteor, they can see that it at least has something to do with JavaScript.
It doesn't matter how it feels, it matters how creators want it branded as - you need to honor their branding, casing, etc. I'm tired, for example, of seeing "Wordpress" or "memcache", when the proper name is "WordPress" and "Memcached", as an example.
Meteor has invested a lot getting the meteor.com domain, not meteorjs.com or similar cheaper alternatives.
It really does matter. People who don't pay attention to these details, don't pay attention to other details as well. It's not rally hard to honor the author's work and the way they want it named. It's a form of respect.
It's an exciting time to be in software :)