31–40 of 107 posts
I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that cau…
I just couldn't get onboard with something I couldn't plug SQL into. A psql adapter never came.
I inherited a vendor-built website that was Craft CMS (a Yii framework) sitting atop a Laravel application that was integrated with Google Maps and indexed by Solr -- debugging even a minor issue could take days.
Meteor is fast and full-stack, no more knitting together 13 different frameworks. It's integrated with Apache Cordova, so you can easily port your website to mobile apps. It supports importing of node packages. Is Meteor the answer for everything? Of course not. But for a fast, data-driven app it's still great, IMHO.
The alternatives recommended in this thread so far are:
1. Firebase + React/Angular
2. Elixir/Phoenix + PostgreSQL's LISTEN/NOTIFY
3. Deepstream.io
4. Kotlin
5. .NET Core
6. Vue and Rails
If those things work for you, great, but I'm not sure they're 10x better than Meteor or that MDG is in some kind of death spiral -- it's still a viable solution for fast NodeJS apps.
I don't know a better tool for prototyping but I found it too slow even with ~1000 clients and that is on a beefy server. If, by some magic, they switch to a more modular design (maybe they already did, not following closely) and that in some way enables the use of postgres (as a 1st class citizen), I'd give it another go for something more than a prototype. Here is my humble opinion: If you aren't writing business l…
> If you want to like writing code [then names dynamically typed languages] Huh? :)
I actually like JavaScript more than many typed languages but I don't like writing a server that runs on an event loop. Again, preference.
ps. You seem to be downvoted, I tried to compensate by upvoting. It is just a tease with a smiley at the end. Relax, people.
So much hate for Meteor here, but I use it at work and it's been great for what we wanted. I inherited a vendor-built website that was Craft CMS (a Yii framework) sitting atop a Laravel application that was integrated with Google Maps and indexed by Solr -- debugging even a minor issue could take days. Meteor is fast and full-stack, no more knitting together 13 different frameworks. It's integrated with Apache Cordov…
I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that cau…
e.g. can't query with age > 10 and have it sorted by age edit: see benjaminl's comment on the wrong example
CORRECT example: can't query with age > 10 and have it sorted by total_spent
Earlier quoted context omitted.
You can use React as a front end for Meteor
That wasn't at all their point.
I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that cau…
Cloud Firestore has too many limitations on what it can't do... e.g. can't query with age > 10 and have it sorted by age edit: see benjaminl's comment on the wrong example CORRECT example: can't query with age > 10 and have it sorted by total_spent
Note that Meteor is much more than a data layer. Even though you won't find any easier system to deal with reactive data than their livequery system, I get that you don't want to be bound to Mongo or even need reactivity.
But it's also a server and build tool that has given our application:
- A stable upgrade path for almost 4 years where we could keep up with new ES features incrementally, with full backwards compatibility. In Javascript-framework land this is really unique. We've been able to keep adding features, expanding our product and building for our customers. While at the same time continuously update our codebase to the latest and greatest.
- By far the best easiest way to do code splitting (since 1.5) without any configuration or overlap in bundles. I don't know about any other tool that offers something similar. Webpack doesn't even come close in this area.
- Because they had node-fibers to get synchronous code from the start, now it's really easy to adopt to async/await.
- They have good integrations for React, Angular 1 & 2, Blaze and there are third-party integrations for Vue (haven't used that one myself)
- They're also the same people behind Apollo which people do seem to like for their data layer. And they announced Meteor will focus on full Apollo integration.
But yeah, their current data layer requires you to buy in to Mongo. And yes, there's no good separation of concerns in their data layer. And yes, the oplog tailing can't handle "facebook-scale" and I know you believe you need this. But picking this allowed our application (that needs a reactive data layer) to be delivered fast, gain customers and grow. Without Meteor, I'm pretty sure I would have ended up 2 years later with a nicer codebase and no customers.
TL;DR Have a look at their latest release (1.6), build a small application and chances are you might really like it.