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).
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.
