Thoughts on Meteor from someone new to it

I recently introduced someone to Meteor. Passing along the salient points. Maybe it can be useful for marketing and tightening up the docs / tutorials / demos.

Here’s their original line of thinking:

what matters to me the most is the speed of development, if a tool allows me to be faster with a good enough result than i’ll pick the faster tool everyday

until now i have not seen any fullstack js framework that allows me to generate a complete crud + auth with two commands, now yeah i can generate that and call the api but why? now i have a bunch of glue code i need to write, why not just have the interactivity baked in… someone srsly needs to make a rails for react, the closest thing to that is inertia… but even with that there still things missing like pubsub & real time features, but i think the reason why no one does is because each new react adds so many new things that shift the entire way we do web apps from class components to functional components to RSCs & server actions

Here are their thoughts after initially checking out Meteor:

Thanks for the suggestion, I checked out the demo ToDo app on their site, and honestly, it didn’t click with me at all. I’m also not a fan of MongoDB as a default choice. The demo didn’t really showcase the kind of structure or capabilities I’m looking for.

Funny enough, this actually reinforces the point I made earlier, in the JavaScript ecosystem, there are rarely solid defaults. Instead, you get endless fragmented libraries and frameworks that all try to solve the same problems slightly differently, constantly reinventing the wheel.

It’s kind of hilarious that their demo includes a deployment section, but nothing on data validation or schemas. I get that MongoDB is schema-less by design, but that’s not ideal for most apps. In reality, most data is relational and benefits from a strict schema. You can find mentions of Zod and other validation libraries if you dig deep enough in the docs, but it’s not front and center. And still, no real mention of Postgres or MySQL.

And clustering, how does that framework handle it? I’m not interested in relying on their Galaxy hosting platform.

7 Likes

Very interesting. I agree with the initial observation, I find it interesting that when they were presented with something that does what they complained it wasn’t good enough for them.
Part is probably the fault of the demo. Another I find that the complaint is that it doesn’t use their favorite technology. This I think is one of the issue of the fragmentation. Similarly how they mentioned the issues with React versions, but at the same time I wonder how they would look at the demo if it was in Blaze. I reckon that an additional complaint would be that it is not in React. That much to my initial observations and larger issues. I suspect that this would be a common feedback.

Now what can we learn from this? First we have two specific issues:

  1. Data validation and schemas
    If it doesn’t already, then we should at least add check to the demo. More detailed section on this might be nice.
    We have now an ongoing discussion on RPC and method improvements. I believe this needs to be decided soon and allow to include custom validation like Zod to satisfy people who like to roll their own validation (so much about fragmentation, but devs are going to dev).

  2. I don’t like MongoDB, give me Postgres or MySQL
    Nothing we can do in the short term. There is vlasky:mysql and other projects that solve this issue, but if we start adding additional databases the project will become unmaintainable. More education on this will probably help a bit.

  1. Deployments
    MUP might need some love and propagation. Beyond that, as a Galaxy user, I don’t know much. A quick side note, we should really emphasize that it is good open source citizenship/usage to use the official hostings of the projects they use, especially for commercial projects. Still, I have heard that there might be a solution that could be build and put on AWS Marketplace to essentially allow people run their own Galaxy like thing that would handle the scaling and so on. I don’t know the details, but that will be something for the team to look into to see if they can offer that as an additional revenue stream and deployment option for those who want to run things on their own.
1 Like

Sounds like they want Adonis JS. Has its own first party ORM, validation, routing, etc. More traditional backend-frontend split (but can still use their server templating language, or maybe Inertia).

MongoDB is often a complete no-go for some devs. I think more devs have stronger opinions about SQL (or the lack thereof) than frontend framework preference :sweat_smile:

1 Like

I think a lot of new devs coming from more opinionated frameworks (like Rails or even Laravel) feel that JS ecosystems can be overwhelming because of how much you have to piece together yourself. Meteor tries to reduce that friction, but maybe the demo app isn’t the best example of what it can do in a real-world app with stricter needs, like validation, schema enforcement, or SQL-based persistence.

4 Likes