If you ask a developer what moments he enjoys most, 9 out of 10 times he’ll say, “It’s when the stuff works!”. As we move forward into our public beta, it’s like seeing our baby walk up from crawling. The zipBoard (www.zipboard.co) team is really excited, and now that we can finally take a deep breath of satisfaction, we decided to share our experience with using Meteor. A neutral opinion, based on our experience with building a commercial application with Meteor.
The Happy Story
Let me start by saying that we absolutely loved coding with Meteor. Out of the box, Meteor offered us a fully reactive front-end, with an asynchronous back-end. Reactivity on the front-end meant that we had to write significantly less code. All client-side updates were automatically managed, so our event handlers were thin, and were primarily intended for database updates. Meteor, as it’s built on top of NodeJS, makes it asynchronous, and gave us outstanding gains in performance. Coming from a world of php apps, these out-of-the-box gains in performance were very useful and impressive.
Second, my belief about Meteor is that it’s exceptionally simple to learn, and the ramp-up time for a person familiar with coding is about four hours. Why four hours? Because every person on the zipBoard team has been able to complete the getting started tutorial (Meteor) for Meteor in half a day, and jump right into coding. In my opinion, Meteor code-flow is intuitively structured, and it’s all javascript, both on the client and on the server, which makes it very easy to debug and extend code. I must mention our experience with an extJS project, written with a php back-end last year, and trust me, it was a total nightmare to understand the existing code pool and write enhancements.
I must also credit the availability of spacebars in Meteor. Spacebars made it easier for us to write simple logic inside the HTML itself, thereby reducing our javascript code substantially. And at last, we found Minimongo to be an ingenious concept in Meteor. Minimongo allowed us to publish our non-sensitive data to the client, and run queries on the client itself. We believe, till date, that this makes our application faster, and reduces some bits of load on our host server.
But no story is complete without some tough moments, is it?
=> Deployment - Quite honestly, all of us were in absolute love with Meteor till the time we were testing it only on localhost. Our toughest moment, or let’s say, the day when our love for Meteor took the first blow was when we planned to deploy it on a web server.
Among the most popular PAAS that support Meteor applications, there were Modulus and DigitialOcean. We created sample deployments on both Modulus and DO. With modulus, we found it to be extremely black-boxed. Modulus offered us a tool that packaged the application and deployed it on their servers. However, we had external dependencies, and external resources that we found to be extremely difficult to manage with Modulus.
So, now on to DO. The step-by-step (How To Deploy a Meteor.js Application on Ubuntu 14.04 with Nginx | DigitalOcean) guide provided by DO simply did not work; we improvised, made changes/updates and were able to deploy a few times. However, the process was not consistent, and not very reliable. In the end, our only hope was provided by Arunoda, and his MUP tool. Thankfully, this worked for us every time, and provided a stable deployment process. But, once again, we are now bound-to-the-grave to an external deployment tool, and like any developer, we are not fans of this hard-bound dependency.
My recommendation to this fellow Meteor community is to budget enough time for solving the deployment puzzle, if you are doing anything out of the ordinary. We were using external assets, and external HTML link-ups outside the application, so it took us an unexpected amount of time (almost 1/3rd of our total dev time) to get it all working in production.
=> CFS - The CFS package provides a filesystem for MeteorJS apps, and is among the most popular packages on atmosphere. This is a must-use package if your application is doing anything with upload/download of files and/or folders. For zipBoard, we upload zip files, and unzip them on the server to display them inside the application.
Once again, the CFS package was quick to get started and implement. However, when it came production time, and we got down to writing the ‘user-delight’ features, like ‘cancel a download while the file is uploading’, or ‘show a more reactive upload-progress bar’, there was nothing available. We were able to hack our way through (http://blog.zipboard.co/2015/11/23/cfs-tips-and-tricks-for-meteorjs/), and get these options to work. But, it would be seriously nice to see this package mature up more before apps can use it in production. My suggestion would be for MDG to pick it up, and make it a part of core 
It would be super helpful!
Ah, and let me mention our biggest challenge! There is still no way to find out if a file has completely uploaded, and available on the server: kept us awake a couple of nights to write our own custom implementations and get this to work.
=> So what else is there? - Well, there isn’t much you can say about an almost perfect technology. 
A few other minor things though: once we got into production, we noticed that some of our helpers were running all over the place. It did not have any impact on the application as such, but still, I would like to understand the exact work-flow of helper functions. In some cases, we noticed that some our helpers ran three to four times, however, we could not figure out why.
Lastly, as we completed our application, we noticed that we ended up using a lot of NodeJS packages for parsing XML files, zipping/unzipping files, and file structure manipulation. The ecosystem around the technology sustains it in the long run, so it would be nice to see some dedicated effort from MDG to develop its package ecosystem.
Once again, we love Meteor, and will strongly stay behind it. Check out zipBoard (www.zipboard.co), and it will convince you that Meteor can be used to produce brilliant applications.
-Pranab@zipBoard
(orignally posted on blog.zipboard.co)