Why should we use Meteor?

community
1

Hello everyone,
we have been using MeteorJS successfully in our projects for several years now. Recently, we have noticed that Meteor is moving further and further away from its actual features. The simple provision of reactivity was the “main feature” that made Meteor famous back then and also one of the reasons why we tried Meteor in the first place. If you look at the homepage today, you will no longer find any real animations.

“Stop fighting with frameworks and start shipping real apps” - or in short, a boring slogan that says pretty much nothing at all.

Further down you will find the information that you can also build desktop applications with Meteor. As far as I remember, the Electron implementation was never part of the core and is no longer actively maintained by the original maintainer.

Now to my original question: Why should you still use Meteor today if the special features are increasingly being neglected? What exactly is the difference to frameworks like NextJS in the future? Do we really need another framework that provides the same features as others?

2

I haven’t used Next.js, but here’s a summary via phind.com (possibly containing hallucinations) that may contribute to the conversation.

==========
https://www.phind.com/search?cache=bws4lsxruurvmoao9v30x8ja

Prompt: “What are the benefits to a back-end developer of choosing Meteor.js vs Next. js?”

Response from LLM:

Choosing between Meteor.js and Next.js for back-end development involves understanding the unique strengths and features of each framework. Here’s a breakdown of the benefits of choosing either:

Meteor.js

  • Full-Stack Framework: Meteor.js is a full-stack JavaScript platform that simplifies the development of web and mobile applications. It integrates front-end and back-end development, making it easier to build complete applications with a single language, JavaScript [1].
  • Real-Time Data: Meteor.js is designed for real-time applications. It provides a simple way to add real-time functionality to your app, allowing for instant updates and communication between the server and clients [1].
  • Simplified Development: Meteor.js offers a simplified development process with a built-in package system that includes everything you need to build modern web applications, including a database, a web server, and a front-end framework (Blaze, React, Vue, or Angular) [1].
  • Built-in Accounts System: It includes a built-in accounts system that handles user authentication and authorization, making it easier to manage user access to your application [1].

Next.js

  • Server-Side Rendering (SSR) and Static Site Generation (SSG): Next.js excels in providing server-side rendering and static site generation capabilities. This makes it ideal for building SEO-friendly websites and improving the performance of your web application [1].
  • Routing and Code Splitting: Next.js offers automatic code splitting, which means that each page only loads the JavaScript necessary for that page. It also includes a file-based routing system that is straightforward and easy to use [1].
  • API Routes: It allows you to build your API directly into your Next.js application, simplifying the development of full-stack applications. You can create server-side API routes and client-side API routes with ease [1].
  • Performance Optimizations: Next.js includes several performance optimizations out of the box, such as automatic static optimization and incremental static regeneration, which can significantly improve the loading times of your web applications [1].

Conclusion

The choice between Meteor.js and Next.js depends on the specific needs of your project. If you’re looking for a full-stack solution that simplifies the development process and includes real-time features, Meteor.js might be the better choice. On the other hand, if your focus is on building fast, SEO-friendly web applications with server-side rendering, Next.js could be more suitable. It’s important to consider the architecture of your application, the performance requirements, and the development team’s familiarity with the technologies when making your decision.

2 Likes
3

I agree that Meteor really should focus on its specific strengths, instead of trying to compete with the big boys in everything. To me, Meteor is best suited for projects which can be described as apps instead of websites. Pub/sub is a big part of that. And this also happens to be something that is rather difficult for other frameworks to copy.

13 Likes
4

Well said! That could be a strong positioning for marketing purposes.

3 Likes
5

The simple provision of reactivity was the “main feature” that made Meteor famous back then and also one of the reasons why we tried Meteor in the first place.

I straight up don’t get it. What makes you think “reactivity” is no longer present? Have you run into any issues while upgrading to 3.0?

If you straight up don’t think Meteor is good enough anymore, that’s fine. Move along buddy. It’s best for you and us, why should we convince you otherwise? Unless you’ve a specific use case that used to be solved by Meteor but not anymore.

2 Likes
6

I agree that this sound like stolen from a bumper sticker in Texas … and the whole website is like made by a blind person with half a hand …

Anyway, did you try NextJS with Svelte or Vue … probably not :)).
If you used NextJS can you do a small comparison such as getting a simple object from Mongo to the client view, for a user …

My comparison here: Meteor:

  1. add accounts-base. Add Passwordless, (SimplSchema and Collections2)
  2. Create a collection.
  3. Write a Method on the server
  4. Call the method from a client.
    Done.

Next:

  1. Implement an authentication solution and manage token rotation, saving to DB etc.
  2. Add Mongoose or build your own Mongo API
  3. Create the Mongoose env: connection, schema, model.
  4. Create a route with an API endpoint to support authenticated calls.
  5. Create a fetching method and wire it through the authentication system to pass the right headers.
  6. Very good luck with implementing reactivity with Mongoose and monitoring your entire environment in all relevant points.

NextJS would take 5x the time you need in Meteor…with Blaze, React, Vue or Svelte … or Vanilla JS and HTML … with coffee-script.

The main functional difference between the two is that Meteor delivers a bundle, perfect for apps (e.g. like you open your Insta again and again and …) while NextJS is optimized to stream the code, perfectly optimized for things like e-commerce - a lot of new users.
SSR and SSG: do you want to take the burden of tens of thousands of clients and do the rendering for them … your cost. Do you want to diseminate the cost to all your users and let them render their own thing … lower costs for you. However, with Meteor you can also do SSR.

I think you really need to understand the differences to see that Meteor not only offers a far better DX but also a far better time to market on 3 different platforms with 5 different frontends.

Now, create a simple react meteor app and … forget pub/sub and Methods. Start writing your code as per the NextJS documentation. Create a route, do a fetch from that API endpoint etc … it all works.

If you go in a Ferrari showroom and ask this question, why should I buy a Ferrari … all salesmen will tell you that you are not qualified to buy a Ferrari.

Anyway … I agree the Meteor website is terrible. Feels like one day, a blind man with half a hand …

6 Likes
7

As someone who seriously considered replacing our usage of Meteor for one of the “modern” stacks (Next, Nuxt, SvelteKit, etc), I basically gave up and stuck with Meteor (well, and Hono - I’ll get back to that).

I think the main differentiators are that a lot of things are provided to you almost out of the box, apart from writing the frontend part. And to be honest, that’s something that used to be more achievable when Blaze was the de facto solution for Meteor frontends.

Auth is a big one. Setting up Auth with Meteor is a lot easier than with other solutions. Lucia Auth might be technically superior, but it’s evolved quite rapidly and I honestly need to review all of said changes to know how it works now. Meteor auth, for better or worse, still works roughly the same ways, with its SHA’d and bcrypted passwords and its localstorage saved tokens :sweat_smile: Other frameworks can otherwise be downright hostile towards setting up a darn auth solution, like it’s one of the most vital parts of your application but the framework avoids the topic, or has some weirdness with cookies and SSR+Hydration. Those frameworks are still good, but they’re focusing on different problems, often optimising frontend delivery and performance. Meteor’s happy to let you deliver an SPA and assume your SEO is being addressed some other way.

Pub/sub is another. TanStack Query is pretty good, but Meteor pub/sub and minimongo really covers a lot of use cases at once. Yes, Oplog trailing is not ideal for performance, and it gets complicated in production because you might want to bring in Redis Oplog and now you have two databases to provision and pay for. But, the pieces are all there for you, and not quite as hard to find as they would be if they were just strewn across NPM by maintainers who don’t even know each other exist.

Meteor’s check library was basically Zod before Zod was cool, and now Zod’s much more advanced than Check plus Simpl(e)Schema(2) because of the sheer community effort to evolve it, but again, that’s another component provided in an otherwise chaotic JS ecosystem.

The only other stack I would recommend that you can pretty much start with right out of the gate for things like MVPs (that might live longer than you expect) would be Adonis, as long as you commit to using the server rendered pages + something like HTMX.

Adonis basically took inspiration from Laravel and went “you know what? Let’s implement everything ourselves that you might need for an app”.

Or, do a hodgepodge app with Hono and all the cool stuff, and just add what you need as you need it. Or maybe embrace (extend extinguish :sweat_smile:) Microsoft’s ASP framework, it’s more complicated but it more or less comes with everything.

Speaking of Hono, that’s a major one we’re adopting simply because it’s like a modernised Express that can be adapted for serverless, Node, CloudFlare etc. And the creator & other contributors seem really dedicated to building out an ecosystem for it, eg with Zod and OpenAPI integration. It’s ambitious but pragmatic and like Meteor I like the idea of everything being thought out so I don’t have to reinvent the wheel, which is not so valuable to the company :wink:

8 Likes
8

Hey,
thanks for your reply. I know about the differences between Meteor and NextJS, we use both in production (with React).

I‘ve started the topic to discuss about the features that make Meteor „unique“. Over the last years you could read several times, that „reactivity“ isn‘t really needed and Meteor shouldn’t focus on it. And in this topic it was also mentioned again (publish-composite and redis-oplog are not needed anymore, use GraphQL).

If we take a look, MDG (previous owner) never fixed the issues you had with the oplog, so the core solution isn’t really usable for production apps (just try to delete a huge amount of documents and your Meteor app will crash). Then came redis-oplog, which was developed by a community member. It instantly fixed most of the issues without any big configuration. And to be honest, setting up Redis is probably easier than setting up a replica set. But this important fix has never been implemented to the core, and reactivity is one of the “advertised” big features Meteor offers. Same for publish-composite, which is needed in nearly every applications that works with reactive data (f.e. in a chat, where you have so send the message docs including some user information, so you have to publish from multiply collections).

I know that the team has currently a lot of work with Meteor 3, and I’m pretty happy to see that we finally can upgrade to Node 20 and remove Fibers. But what will happen after that? Does Meteor/Tiny have plans to finally fix the issues you have with the oplog, or is it still a thing that doesn’t need much attention? Will we be able to develop desktop applications (Electron) like advertised on the homepage?

I love Meteor and we use it on a lot of projects. My concern is simply that in the end people will forget why Meteor is used by so many people. In addition to the great account system, the simple development environment and the ability to develop apps for multiple platforms, there are also features such as reactivity that are needed in a modern web app, even if perhaps only to a small extent.

2 Likes
9

Without saying much, I let others speak by experience

https://twitter.com/danielberg_/status/1763341446143234462?t=DdYyYvZDB-zMfxztOqFLNw&s=19

2 Likes
10

I want to share my opinion on this subject. As someone who uses Next, Nest, React, Vue and Svelte, I must say frankly that none of them can beat Meteor.js and Blaze.

I say this as someone who uses Meteor.js’ reactivity features. Otherwise, I’m sorry, Meteor.js does not do anything different from other frameworks.

If you use redis-oplog, collection hooks, blaze, and tabular packages, you can develop products at lightning speed. It is truly incredible to get a data-grid structure that has both a backend and a frontend, like tabular, with one package. Moreover, this product can serve thousands of instant users through a simple server.

Mup and MontiAPM are solutions that we cannot easily find elsewhere.

Even Uniform cannot do exactly what Autoform does. Still, it’s a nice solution for react.js. I wish Tabular had an alternative written in react.js. It is not difficult to do it using Devexpress, but it is not ready-made. If you want speed and scalability, Meteor.js can do this wonderfully when used correctly.

Coming to the real issue shared here, I think it is necessary to correct the website to indicate the real features that make Meteor.js special and ensure that the momentum achieved with version 3 spreads to the entire ecosystem. A framework where Reactivity is this easy and can scale so easily with one package is truly like magic.

4 Likes
11

I’ve been using Meteor since 2012. I have not yet seen signs of it abandoning its core strengths. The bulk of the negative discourse has always come from developers who simply needed a slightly more dynamic way of building websites. If you want to build the next Photoshop / Google Maps / Figma - that is, complex online apps - especially on a tight budget and with a small team, you are still out of luck without Meteor in 2024.

7 Likes
12

This particular thing has been answered there so I won’t go into this here (though redis-oplog is not mentioned there in that connection).

What will happen after Meteor 3. Well there is the official roadmap where you can have a glimpse. For the concern with oplog, there is a plan to move to Change Streams and much more. You can also look on the numerous PRs in Meteor repository which many will most likely land in Meteor 3.1 (I submitted a PR for a new small feature for accounts just today, for example).
The slowdown is that the Meteor Software is focusing on Meteor 3 upgrade, which is not an easy thing (and for obvious reason until that is done adding new things is a bad idea). Honestly in the community we are not ready with many packages. Part of the reason on the other thread for me was that if people can migrate off some of the packages that landed in my lap and I don’t have to worry about maintaining them and point to something better (be it newer packages/API - like is the case with Picker, new approach to the problem), then I can deprecate the package and have more time to focus on other packages.
Many thanks to all who contributed PRs towards this effort!

6 Likes
13

If you make a non meteor app, once you build up through MVP stages to production and years of refinement, you’re going to just wind up with “meteor” but fragile and worse. Why bother gluing code together when you can have it all from the beginning?

4 Likes
14

Exactly that. Unfortunately, it is not supported well if you go beyond a web-browser. I think that’s something the Meteor team is completely missing out.

15

That is exactly what we think at Quave.

For websites:

  • we use Next.js when SEO is really important

  • we use Vite + React when it’s very simple and SEO is not important. Like a simple website that people will access because of a link

4 Likes
16

Well said, totally agree to that

2 Likes