This thread is proving to be very productive in gathering feedback and understanding the community’s opinions as we work on what comes next after Meteor 3.0. I agree with many of the opinions shared here, and I will ensure we discuss each with caution and kindness.
4 Likes
As a Rails developer for a last 10 years, I’m highly in favor of more opinionated defaults, including the view layer.
Rails is extraordinarily opinionated, but still modular. You can replace every single part of rails with another piece of software and it will probably work, but you increase your own workload exponentially by doing so.
Making a new Rails app these days is a cakewalk, and it’s because of those opinionated defaults that it’s so easy to start off running.
For example, if I want to take my database and change the schema. I can use rails provided migration generators and runners to do that.
In Meteor, there’s no default way to do that. Meteor is also not very popular, so finding the “popular” library is difficult. I have to scour the internet to find percolate:migrations.
Another example, let’s say I want to run some process in the background. Let’s say the user uploads a big ol text file and we want to run it through some random AI server. I don’t want to do that in the main thread, I want to spawn a background job. In rails you just pop off an ActiveJob and it handles it, no brain power required.
Meteor? I don’t even see a standard way to do this. Official documentation only references routines, and my brief google search while writing this didn’t return much.
I think ideally when I’m using a framework, I want the framework to have the answers my questions. There are things meteor does that other opinionated frameworks don’t. For example, Rails doesn’t have a default authentication method (but let’s be real, it’s devise), whereas meteor does. And I cannot stress enough just how much that default authentication method helps.
I want those defaults for everything.
Just for the record, this kind of problem can also be solved by a third party bootstrapping project. For example, a lot of people bootstrap their projects with https://bullettrain.co/, which is just additional opinions on top of rails’ opinions.
This is just an example to show that it less needs to be built into meteor, and more just needs to be the “go-to”, regardless of who is providing it. A sane set of opinionated defaults.
Just as a side note about the view layer stuff. I don’t see any reason meteor can’t provide the default views from v1 (login page, simple form etc) for whatever view layer is deemed the default (solid, svelte, whatever), while still allowing you to use whatever.
It’s exactly how rails works. If you use activerecord, you get all your migration goodies, as well as activestorage. If you use mongoid you lose all that, but you can still use mongoid. Rails was built for activerecord, so it works best with activerecord. But it doesn’t say you can’t use something else.
I think my big issue with meteor is without a set of opinionated defaults, there’s almost nothing to meteor. There’s the communication and data layer… and that’s it, basically. It’s pretty hard to sell someone on DDP when they can just use normal REST with any other set of tools.
It’s easier to sell someone on a complete web development stack, that happens to be powered by meteor’s data and communication layer.
Tertiary note: god I hate typescript. What a waste of development time that’s been for the last 5 years.
8 Likes
Amen.
You explained exactly my point.
You said that in RoR you can change all pieces if you don’t like it, but I remember at the beginning on Rails, it wasn’t the case, You were forced to use postgresql for example. It’s long time later when Rails became popular and more people working on it that they make things modular.
At the beginning, they were small so they keep things simple, with all defaults and no options so it was easier to maintain and create a robust (opinionated) stack.
2 Likes
Blaze needs more love
5 Likes
For example, what I use for my rails projects is https://jumpstartrails.com/, which just takes the rails defaults, and also adds auth, multi tenancy, payment processing, etc.
That kind of paid SaaS template means, that RoR by default does not provide enough of starting point to even get started. It seems that nowadays expectation is to have all those parts already working together, maybe even get updates to newer version of template, and just add the remaining parts, like plugin system.
So currently, RoR and Meteor are kind of same level of DIY, when not having that SaaS template.
With Meteor 3, needing to:
- create new project based on some template (like Blaze)
- add meteor:roles, write UI for managing users, check that permissions work properly
- add some cron package (like msavin:sjobs or percolate:synced-cron) for scheduled tasks
- add internationalization package like ostrio:i18n
- add some authentication packages
- for each of those packages, check are they Meteor 3 compatible
So every developer making their custom stack needs to select all the parts, and maintain the whole stack.
Development of big features usually goes this way, based on my experience:
- Add some big feature, by adding code to many places at code
- Fix some corner cases, make code to fit all other parts, so everything works together well
At some forum post was some list about packages, that are already Meteor 3 compatible, I’ll try to find link to that forum post. Alternatively, maybe that kind of list already is at Meteor 3 docs, or could be added? So that there would be the “currently existing Meteor 3 happy path” to develop with already existing Meteor 3 compatible packages?
1 Like
It’s a little disingenuous to say you need payment processing and multi tenancy just to start a project…
I was just using it an example that the third party can provide the opinions.
2 Likes
At previous comment, I did not mention payment processing and multi tenancy. My point was having some more parts already working, to get started faster.
That paid SaaS template subscription price $249 is at the same price point as DHH’s ONCE product line, that DHH designed to compete with high priced enterprise products that should be more like commodity, like their Slack competitor. That price point could be too expensive based on where someone lives, and could be cheap for those that are used to pay much more for enterprise products.
I presume, that using that kind of paid SaaS template would not have possibility to use it with FOSS software like Open Source kanban that has MIT license.
I really regret linking that at all, it seems to be detracting from my post. I’ll change the link.
I think my big issue with meteor is without a set of opinionated defaults, there’s almost nothing to meteor. There’s the communication and data layer… and that’s it, basically. It’s pretty hard to sell someone on DDP when they can just use normal REST with any other set of tools.
I think, that DDP in Meteor is used for realtime updates, by reading MongoDB changes, and updating data to all users realtime. For example, in WeKan Open Source kanban, that PubSub updates realtime, resolves any merge conflicts etc. I don’t know how REST is related to that, can REST be used for realtime? I would think, it would be more similar to some Websocket usage at RoR, like TurboLinks?
In TurboLinks is some feature, that when page is scrolled down, more content is loaded, like infinite scroll. I may have looked at some infinite scroll code previously, but anyway, what are the current ways to provide infinite scroll in Meteor 3 ?
Why I Still Love Meteor JS
I started with Meteor after PHP, jQuery, and MySQL 10 years ago. Creating my first todo list app felt like magic. No other framework matches Meteor’s simplicity.
Despite changes in the JS ecosystem, Meteor’s declarative style and features like Minimongo, pub/sub, and RPC still stand out as @vooteles pointed out. Other real-time frameworks still don’t offer the same developer experience (DX).
One of our startups products is a Chrome Extension, I needed real-time functionality. Due to age of DDP client JS libraries, I used Firebase. The popularity of Firebase and Supabase, despite a worse DX, shows Meteor is missing out.
Meteor could be the default alternative to Firebase/Supabase. Imagine importing import { Meteor } from "meteor/meteor" in any frontend and having everything—Minimongo, methods, subs, etc.—just work, with any Node.js backend supporting connections.
With Meteor V3, we’re building a new product, and I’m still amazed at how productive I am with Meteor. It’s the only stack where I feel I could code without internet access faster than anyone with internet and any LLM.
The ability to write the following code is the magic of Meteor—nothing else comes close:
// client.svelte
$m: tasks = TasksCollection.find({}).fetch()
// server
Meteor.publish('tasks', function publishTasks() {
return TasksCollection.find({ userId: this.userId });
});
So if meteor focus on anything in the future, in my humble opinion it should be on data syncing and rpc between devices. Kinda like https://zerosync.dev/ the successor to replicache.
9 Likes
For me Meteor is (or could be) so much more than a database and a data transfer layer.
2 Likes
Quick inquiry. What do you think about a “classic” boilerplate repo using a highly opinionated set of packages, ready to code an SPA in a few hours, including modern tools like tailwind but also classic meteor tools like Blaxe, all optimized and production ready.
1 Like
You can use IntersectionObserver or MutationObserver and load new content , epending on element visibility during scroll.
3 Likes
Even if it would be desirable to turn Meteor into a super opinionated every feature included out-of-the-box experience (which for me would not be a good goal), there’s another problem with that approach. Getting there would require a massive amount of developers both in the initial work and also in the maintenance that follows. And those developers need to be really good at what they do, because a very opinionated framework inherently requires those opinions and the execution thereof to be top notch. Since due to the nature of opinionated frameworks, users would be at the mercy of that execution.
Since the Meteor team is very small setting a goal like that would almost certainly spread the existing very limited reasources (too) thin and the quality would suffer. I would much prefer for Meteor team to do less, but do it really well rather than do many things with questionable quality. This is one of the main reasons I am expressing my arguments here as well. To try to encourage the Meteorteam to set a narrow focus for Meteor core and deliver high quality on it.
I hope my replies do not seem very negative or apprehensive to you. My goal here really is not to argue against your vision at all costs. Quite the contrary. A good project should be receptive to input from anyone and community members should feel free to voice their opinions. Hopefully my counter arguments do not get in the way of that! 
If there is indeed enough interest in a very opinionated version of Meteor, then I think a good option would be a community managed starter template with all the pieces put together and every once in a while updated. The burden would then fall onto the community members maintaining it and the Meteor team can focus on the core. Something like @jkuester mentioned above.
6 Likes
The more opinionated the framework is, the less work we have.
Imagine Meteor decides, ok now, we support only Typescript / React / Tailwind / Shadcn / DDP / Mongo.
It would be TONS of less things to handle. Way better than today where they have to maintain a angular compatibilty, make the pubsub and meteor reactivity compatible, make the examples, make the doc, dp the support, and so on. Then doing the same for vue all other pieces. Then support JS and TS version and all the variants.
Just look at the meteor create --help
--react Create a basic react-based app, same as default.
--vue Create a basic vue3-based app.
--svelte Create a basic svelte-based app.
--typescript Create a basic Typescript React-based app.
--blaze Create a basic blaze-based app.
--tailwind Create a basic react-based app, with tailwind configured.
--chakra-ui Create a basic react-based app, with chakra-ui configured.
--solid Create a basic solid-based app.
All those stuffs to maintain and be sure everything is working fine for each version, that is NOT my definition and simple and easy.
3 Likes
I don’t disagree that meteor should be opinionated, they should, but that opinion should be on the toughest engineering problems, not semantical ones.
2 Likes
I am a fan of your work @acemtp . I am unsure if you worked directly with Lempod in the past, but I was hired to support the product for the company that bought it. Cheers to the future of Meteor!
3 Likes
ahaha excellent. I’ve made lempod indeed.
3 Likes
I don’t believe that the choice of MongoDB as the database behind Meteor is a good choice today. If the same features could be implemented with Postgres as the database behind it, Meteor would be absolutely the perfect framework.
I think we will have a huge disagreement on that. I’m on the MongoDB train and it is perfect for my use cases.
7 Likes