I have used and enjoyed Meteor since 2013. It has had its ups and downs, but the fact of the matter is that it has from the beginning already solved problems which we are re-solving every day. A recent client job I worked on illustrates this perfectly.
For this job I was asked to build a React frontend to an already-existing RESTful API. There were a number of things I needed to figure out in order to build this.
1. Choose an HTTP library
I, like most people, use an abstraction for making HTTP requests in JS. Since I was not using jQuery in this project, I had to shoose another one. I chose SuperAgent which is wonderful for the job.
2. Build a Network Call Abstraction
This API had over forty separate endpoints, many of which had to be called in order to load data for a single page. I did not want to make http calls directly from my view components, so it was important to have an abstraction I could call which was configured specifically for each endpoint.
3. Build a CRUD abstraction
Now, my network controller took care of the network calls, but I wanted to provide an easy abstraction for making CRUD (create, read, update, delete) calls from my view components. I could have used something like Backbone models and written a custom Backbone.sync() method, but with the vast number of endpoints and combinations of calls it would be more difficult than just making my own.
4. Build a Caching System
It occurred to me while doing this that I needed a caching system as well, so the user would not have to wait for network calls with each page loaded. So, I would need to set up a way to keep track of data which had already been fetched from the server, so for each page the user would be initially shown the last set of data, then updated with the latest as soon as the network call finished.
5. Set Intervals
Some of the data needed to be kept up-to-date in real time (comments, etc.). So it was necessary to set intervals for getting updated data from the server and delivering it to the views. I also had to make sure I was cleaning up all these intervals as components were dismounted.
In the end, I spent many hours just handling data rather than focusing on the UI (you know, what the user actually sees!). It was frustrating at times, but in the end I built a product which does the trick and does it well.
Enter Meteor
Now I am done with that project and am back to working on two production apps with Meteor. As soon as I opened up my editor, I let out a satisfied sigh, knowing that I wouldn't once again have to worry about solving issues which Meteor solved long ago.
Meteor has its problems, but for many applications--even in Meteor's current state--there is nothing to compare to it. You don't need to worry about HTTP calls, network or CRUD abstractions, you don't need to worry about caching data or manually setting intervals. Those are all taken care of for me!
In Meteor I set strict publication rules on the server and subscribe to the data I want on the client. I make a few app-wide subscriptions, and then I have a number of route-level subscriptions. I then write stateless React components which are fed real-time data from Meteor (in the past I have built my own data containers, but these days I love Arunoda's react-composer package).
Problems Solved
Meteor has its problems, but it is getting better every day. There is still no solution out there like it. Nothing solves all the problems it solves and does it in such a slick and straightforward way. I do not need to keep solving these problems for myself. Instead, I can use Meteor and MiniMongo to handle HTTP calls, data caching, queries, and live updating.
Meteor does what it does and does it well. It allows me to focus on the UI, to focus on the things my clients and their users ultimately care about. That's something worth celebrating. That's a breath of fresh air in the often drab and repetitive world of software development. That's a breath of fresh Meteor.