When I first worked with Meteor, I was very excited by its full-stack(ness). Meteor allowed remote data to be reactive. It bundled MongoDB and has something called optimistic updates. The framework updated the client immediately, then batched updates to the server and if something went wrong with the server, switch back to the server provided value. For any geeky programmer, this feature gave goose bumps.
Over time, I realised that Meteor had its own flaws. Optimistic updates, though nice, surprised the user when the value changes from old to new and then back to old. Other than this, there were several quirky things, which did not go well.
Meteor communicated with the server via DDP protocol. DDP protocol allowed for real-time communication. But, it also was a problem because we moved away from writing the de-facto standard HTTP APIs. If mobile apps were to be written in React native, the mobile apps wanted a HTTP API service.
Yes, Meteor allows to develop for web and mobile with the same code base. But the mobile app is based out of Cordova. Cordova apps never had the native feel because it runs on the WebView component of the platform. Animations don’t work well with Cordova. So, those apps developed using Meteor is almost a waste.
Finally, I fell in love with React. I learned React with Meteor. But over time, I realised React is a much more powerful UI library. React works well with Webpack. Webpack provides features like – live reloading, hot reloading and code-splitting. Using Webpack also gives me an opportunity to work with Redux, my favorite state management library for React.
In most projects, my web UI platform is built with react, webpack, react-router and redux. This gives me freedom to choose the API – Firebase, Express or Scala. And the database – PostGreSQL, MySQL, etc.