[akbar501]

Congrats to the MDG team on having 1.0 within reach, and thanks for releasing an amazing platform.

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.

An experienced developer can get a very good feel for Meteor over a single weekend: 1. Buy the book: http://www.discovermeteor.com (the book is $39...I did not purchase the other packages) 2. Spend a weekend doing nothing but coding

Come Monday morning you'll know what Meteor is about.

PS: I am not part of MDG, and I have nothing to do with the book (other than having bought a copy).

[sgdesign]

Co-author of Discover Meteor here, glad you liked the book!

[Kequc]

Curious to learn about meteor but probably will end up needing an up to date book when I actually get around to programming with it. So if I purchase the $40 package, will that include updates up to maybe a year from now?

[sgdesign]

Yes, we'll update the book for free at least until Meteor reaches 1.0.

[jclos]

I insta-bought the book after hearing the Changelog episode on it. Thank you for writing it.

[puller]

When you say it is quantifiable - can you actually quantify it for us, or is this just hyperbole?

[parasj]

TL;DR: It's great for realtime apps, but not so much for the traditional web app as compared to something like RoR.

My perspective as someone who has been using it since its release. It depends on what kind of app you are building.

Coming from RoR, Meteor actually is more of a pain given that it still has edge cases that can eat developer time, especially once you dive past the initial levels of tutorials and documentation. RoR also has well established best practices and norms, unlike Meteor and perhaps Node.js as a whole. This means you will be writing a lot more boilerplate code. Meteor has some memory issues as well at times. You have to be aware of memory leaks and will frequent the profiler often, especially with large client-side applications. I've had some projects that I've worked on in Meteor hit 1GB of RAM client-side. Recent releases have been working on this, though. Live reload and hot code pushes are kind of a moot point with something like the Live Reload plugin for Sublime Text or equivalent.

For realtime applications, Meteor is a whole different beast. Realtime applications are much easier to code. I'm comparing this to making a realtime Node.js application. Meteor takes care of the boilerplate for you, pushing changes automatically to the client. It's not difficult to do something like socket.io and node.js but it is nice to have that all handled for you.

It's great for getting an application off the floor - it has a lot of that magic RoR had when it was released. Once applications get more advanced, the structure and maturity of RoR make it easier to work with. These issues are things Meteor is working on, especially in terms of stabilizing the spec/API and working on fixing the edge cases. With 1.0, it seems they are bringing some more stability to it by making it production ready. Its strengths are much more apparent in realtime applications as compared to a traditional web framework.

Edit: As compared to other node.js frameworks like Express, Meteor is much easier to work with - I probably would not go back to raw Express after Meteor. It's been moving fast to 1.0 where many of the issues I've had with it should be resolved with stability and as edge cases are resolved.

[akbar501]

Yes, we measured it. I am rounding these numbers for simplicity, but essentially, our split of developer time and KLOC follows:

# Labor and spend allocation

- 75% of engineers were on our server-side (Java) (1)

- 25% of engineers were on front-end (JavaScript/HTML/CSS)

# KLOC (2)

- 14% Java

- 54% JavaScript

- Everything else is in other (Scala, CSS, HTML, shell scripts, SQL, etc.)

From speaking with other companies, we found these ratios are within the normal range. We've seen 60% server-side to 80% server-side, but the directional finding appear to be actionable. As mentioned in Note 1 below, we excluded backend work from server-side work.

Also, and this is important, these metrics hold for our single page applications (SPA) projects. I do not have metrics for projects with a more traditional server-side only rendering...but I would guess that these finding do not hold true in such a situation.

If anyone else is willing to share their metrics I would be very interested. I'm always open to seeing the bigger picture in case there are some important facts that I have not factored into my decision making process.

# Notes

(1) This 75% is after segmenting server-side work (i.e. Java application server) from back-end processing (i.e. Kafka, Storm, Hadoop). Obviously, data processing will remain in Java, so we excluded it from our comparison.

(2) KLOC is a poor metric, but it was quick and dirty for us and provided good directional information. Also, all developers (front and back end) are good. So we did not need to adjust for quality of code (i.e. good developers have lower KLOC on average).