Over the last few months I’ve been experimenting with different stacks for web/mobile development. My goal was to “break free” from depending on Meteor to get things done by becoming fluent in other technologies. However, my conclusion after this process is: Meteor is really hard to replace. So I’d like to summarize my thoughts on this to maybe help people and businesses who are facing the “should I stay or should I go” dilemma with Meteor right now.
Technologies I experimented in this period:
Firebase
Apollo + REST (Express and Koa)
Nuxt
Why Meteor is really hard to replace:
1) Accounts
We’re in 2019. Private space travels, flying cars and virtual currencies are a reality - so should we still need to struggle to create a simple user accounts system?! The amount of code necessary to get something close to Meteor’s account system up and running on any of the technologies mentioned above is overwhelming - think about all the security, back and front-end aspects involved. Things may look quite easy when you’re thinking about login/signup. But when you add email verification, reset password, enrollment links, social signup and all the hooks to the mixture… oh boy.
2) Search
I was doing quite well in Firebase until I realized it doesn’t have a full-text search mechanism. What I can achieve in 30 minutes and $0 with the awesome easy:search package on Meteor took me 3 days and $29 / month to get with Algolia + Firebase. Meteor’s pub/subs are awesome to help you filter search results the right way (optimizing performance) - and have no real peer elsewhere.
3) Mongo Integration
Meteor is by nature integrated with Mongo. You can write Mongo code almost exactly as it is in the official documentation. If you switch to Firebase’s Firestore, you will have to use their own Mongo-style syntax… which imposes a lot of restrictions (on querying / mutating) and is overall less clean and intuitive. Firestore also doesn’t have any specific Schema tool (like simpl-schema for Meteor). If you switch to REST with Mongoose, you get your powers back - but at the cost of complexity and lots of wiring around (remember, server and client are in a serious relationship in Meteor, but are not more than acquaintances in REST).
4) Comfy Back-end
In Firebase, you get a “serverless” environment where all your back-end code needs to be written in “cloud functions”. This may be an interesting approach for larger, microservice-based apps, but it imposes a structural restriction that gets quite annoying if your app has a lot going on behind the curtains. In REST, you have all the freedom you want - but at the cost of countless endpoints and plumbing operations. A simple “update this document” method in Meteor can become quite horrifying in REST if you need authentication, error handling and additional features.
Final thoughts:
Meteor may be too opinionated for projects that have really specific back-end needs and rely heavily on fine-tuning details for performance. Is this your case? If it’s not, then don’t waste time reinventing the wheel just because it looks fancier!
Meteor apps can be really fast if done correctly (controlling real-time data, optimizing methods, using a good front-end library etc.). If your app is slow (and you don’t have a million active users doing heavy stuff on it right now), there is probably room for optimization!
I believe that Meteor is the direction in which dev tech should go. Less time spent doing things that are basically the same for every project (accounts, security, routes, data plumbing) and a solid environment to host your business logic.
That’s it! Would love to hear your opinion on that
Unfortunately, I have to agree with most of these points. I’ve moved on from Meteor for more control and because Service Workers still haven’t been implemented, which breaks PWAs, but haven’t found any framework that comes close to Meteor in terms of power and ease. Vulcan came closest (Meteor + GraphQL + React).
Search - if provided by Mongo, it’s still sub-par. We’re building a crypto news aggregator and found that stemming is okay, but far from Algolia or ElasticSearch. For example, “China” doesn’t match “Chinese” . There are also various limitations that MongoDB imposes on search (can’t use $text in change streams, for example).
Mongo integration - Firestore in particular has a really peculiar set of limitations, including:
This is not a plan limitation. You can’t pay to remove it. As a workaround, you must create shards.
Backend:
A simple “update this document” method in Meteor can become quite horrifying in REST if you need authentication, error handling and additional features.
GraphQL makes that pretty easy. You write the authentication and error handling once, then resolvers can be as short and focused as an if (userIsInRole(context.uid, 'manage-team')) collection.find(...).
Final thought
If Tiny picks up Meteor after the acquisition and solves the major lingering issues, they still have a excellent chance of (re)turning it into the full-stack platform of choice for a large number of developers.
Service workers are just plain javascript files. You should be able to toss your service worker in the public directory and everything with “just work”.
I have dropped Meteor for a few years now. But sadly there is nothing that comes even slightly close to Meteor.
Hopefully the new owners will be smarter and fix the weak points of it, then do some proper marketing and they will make a real boom.
It’ll boom. I think Tiny will double down on entrepreneurs and indie hackers and provide a pathway to grow and adapt their code base as their business scale. As of now no tech platform can do that and today’s Meteor is very close to owning this role, it has the right balance between opinionation and flexibility which took years to reach, few improvements here and there is all that is needed.
Not a frequent user of Meteor but using it from time to time in my side project. I guess, improving the development experience of integrating other tech stacks(e.g. react native, apollo) could be sweet for small business developers… Don’t overwhelm the framework, just keep it updated and practical to small business.
ServiceWorkers are easy to implement, just add your sw.js in /public and register in your index – there are many reasons to switch, but I wouldn’t say this is one. We are using it with great success https://app.classroomapp.com
I am still using Meteor along with React, and I must say it has much less overhead than RN in terms of development and build. But yes thers’s downside too. I think one must access properly what they needs from what they are building then only consider using tech stack.
My experience with GQL and meteor has been amazing so far.
Really interesting post. I’m sort of on the same journey now.
I think the biggest concern for me with Meteor is the lack of an easy way to support mobile or any other service that wants to interact with my app’s data. This has lead me to looking at creating a REST or GraphQL API first and foremost. Like you said though, this is nowhere near as complete or productive as just using Meteor.
Services like Hasura or 8base are incredible for getting up and running fast and allowing a nice decoupled approach but the thought of not being able to easily integrate server side logic with my stack is offputting after years of building with Meteor
. There are also various limitations that MongoDB imposes on search (