Make Meteor great again

community
1

About me:

  • I started using Meteor with Meteor version 0.5 more than 10 years ago.
  • I felt in love of the MDG promise of Meteor 1.0 (for me it was the new Ruby on Rails)
  • I was the french meteor ambassador with 35+ events organised in Paris (biggest non english speaking community)
  • I made great products and companies thanks to Meteor ($10M ARR in 4 years)

For me,

Meteor 1.0 was a fantastic opinionated framework.
Then MDG had to make money pressed by the VC.
So MDG want to Meteor 2.0 and try to please everybody (try to please everybody and you’ll please nobody) splitting Meteor in pieces and make all peaces replaceable and loose all the power of the opinionated framework.
MDG moved to React and sold their shredded baby.

Here are my unpopular advices to make Meteor working that nobody will agree ^^

  • Having a unique official place for the community to talk and share (this forum)
  • Having all officially maintained packages the same name (mcp:i18n mcp:roles, …)
  • Go back to the Meteor 1.0 promise aka. opinionated framework (one language, one db, one network protocol, one client rendering)
  • Choose a unique niche for the marketing and the communication where Meteor is a game changer (for example: Creating B2B SaaS projects)

In other words:

  • remove old things
  • doing less things
  • focus on one thing
  • communicate about this one thing
7 Likes
2

I’m for this general direction. As for the additional packages like roles and i18n, I think those would be moved to core if there is a decision to move towards more opinionated framework.
The biggest problem is that the box of the opinionated framework has already been destroyed and you have a very vocal minory that wants it that way and it makes certain sense. I think on this going forward we should have a strong default (opinionated) way. For the future technical upgrades it is good to make it more modular, but we should strongly make it clear that if you don’t go with the default then you are on your own. Where this is going to be the most annoying will be the selection of the front-end library. Right now the two top choice are React and Blaze. Blaze is IMHO not in a good space and probably not optimal depending on where Meteor decides to go. React is moving away from its promise and I think in few versions you will need to use Next or Remix only with it in order to access half of its functionality. From what I have tested so far Solid might be a great replacement, but they also are starting to build out their ecosystem and might follow the React route (though maybe if we jump in we might sway them, one Meteor user is on their Ecosystem Team).
But all this comes from the main direction. I’m working towards the SaaS project starter option and I think having everything to be able to quickly start a SaaS project with Meteor is a good direction. In general I think doubling down on stuff around user accounts is the best way. Just look at how many SaaS there are for user authentication and authorization.

Those are my initial 2 cents on this.

3 Likes
3

Since I really don’t know well React, what was the initial promise of React and what it becomes now?

4

Regarding the view layer, it makes very little sense to couple Meteor with any view library specifically. The API surface is small enough that Meteor can succesfully stay agnostic and just work with whatever view library people want. React, Vue, Svelte, whatever. On top of that, if Meteor would choose Vite as its bundler, such integrations would become even easier and less workto maintain.

4 Likes
5

It makes ALL the difference to couple with one render.

Imagine if Accounts UI had to support react, vue, blaze…

Having ONE db, ONE render, ONE protocol make possible some high level package easily maintainable that handle everything.

3 Likes
6

For me at least, it was SPA front-end that is great with real-time (which is why MDG originally wanted Blaze 2 to be pretty much React). Since then it has moved more towards server rendering and server components and in general what I would describe as doing everything, except user actions, on the server. Honestly for that I can go back to PHP.
Solid seem to work a bit better with Meteor API from what I have seen and hope to explore in more detail soon.

1 Like
7

@acemtp I am trying to understand your … opinions.
Could you please try to express them with application to your own experience such as:

  • I can no longer write great code
  • I cannot fetch data from DB
  • I cannot host my apps.
  • I cannot write my posts because there are multiple communication channels…
  • Because Meteor is not opinionated I can no longer be an ambasador and organize events.
  • I cannot accept Meteor is at V3 10 years later when I love Meteor 1.
  • I don’t have the knowledge to write a UI for accounts with React and I want other people to write it for me.
  • I want 1 render because … I want 1 render. I tried to write “some high level package easily maintainable that handle everything” but could not because there are TWO dbs, more than ONE render and 1 and a half protocols…

I am really trying to understand your opinions but I think I fail.

1 Like
8

Agreed. Sadly I fear that everyone is so opinionated about their front-end that since we already left the paradigm it will be impossible to go back. Vulcan went in that direction, I think, and didn’t get much of a traction. Still I think it is worth a try. Not as a mandate, but as a default where you can go outside of the default, but then you are on your own. In this case providing your own UI setup. Another painful discussion is what styling system to use. In React we can have TailwindCSS vs styled-components, etc.
If we look up at the original Blaze UI packages for accounts there was the base unstyled and then the styled package which provided CSS.

That all said, I think the best approach might be to do something like Solid Start:

Create or designate official templates that the core project will revolve around.

9

This post is not for me.

I’m fine, I use Meteor 3 but in the Meteor 1 way, I had great success and I (almost) never post here, I do my own business without bothering other people and it’s fine.

But for the first time, I would like to share my view and opinion on what I would love to see in Meteor. I follow this project for more than 10 years, I saw the original team philosophy, how the project evolved, how they struggled to create a strong community and make Meteor a profitable company, how other techno like React or GraphQL took the lead, how they move to some other techno and so on.

So with this knowledge + all I learned from my startup + trends of the JS communities, I’m pretty sure that those changes I wrote could be a game changer for Meteor even if I know it’ll never happen.

I don’t try to convince anybody, perhaps I’m just sad to see all the potential of my beloved framework not converted into what it deserves.

4 Likes
10

Yes, you fail :frowning:
This is not about Meteor not accepting Meteor 3, because Meteor 1 was better due to technical reasons.
The core argument is that due to loosening of opinionated approach of Meteor which strictly outlined how things are build and allowed for packages like accounts-ui which allowed to build stuff really quickly including the UI part where you could just insert a template into your code and didn’t have to worry much about the functionality further. Other issues there with that, but that is not the point here.
Now you have to build all of the UI yourself, which slows you down and having to cater to more front-ends, build tools, etc. spreads the core development team thin among other issues. It also means that any packages will only deal with the Meteor code base that is still strict, so server side, general API, MongoDB and at best will end with publications and methods prepared, beyond that it is unlikely to touch anything UI related. That was obviously not the case in the past.
I don’t think we can return to that in core Meteor. Probably a specific project build on top of Meteor is needed to be as opinionated. There is Rocket.chat and there was Vulcan, but it is a tough thing to do.

3 Likes
11

Sadly, I agree with you, Sacha was a friend of mine and I followed what he did with Vulcan.

Perhaps it’s too late…

…or perhaps the JS community will never be ok with a monolithic, strong opinionated framework… but Ruby on Rails was ok with that with a great success.

When I see small projects like https://shipfa.st/ that do opinionated framework having great success too, I’m pretty confused.
It’s a paid boilerplate that just link a few existing packages and sold it to 4120 customers for $200.
I really don’t understand why Meteor could not please thousand of project creators since it’s way powerful and free as free beer and free as freedom.

4 Likes
12

The problem of opinionated frameworks and why it eventually broke down with Meteor is that there are many people that always want to change one little part for their favorite alternative or need something more specific for their business. Further on like with an advanced template there will be more disagreements. Just look on all the linting alternatives. So I think it was only a matter of time till Meteor became what it is today.
ship-fast is looking great (working on something similar myself).
Personally I’m for Meteor focusing around the accounts packages (I think that is the strongest suite) and other things for integrations that are needed for a SaaS project. Even now still Meteor allows the fastest setup with all these things compare to its competitors.

3 Likes
13

@acemtp I really admire and respect your work and the results you have accomplished. I agree with you on many aspects.

What I suspect happened is that after the original founders left, the framework and community lost its unified vision, and everyone took action on their own agenda and got fragmented.

I might be wrong, and I don’t care much about what really happened, there is a reason the rearview mirror is smaller than the windshield in a car.

Where are we going from now?

I believe your advice is 100% valid:

  • Remove old things
  • Do less things
  • Focus on one thing
  • Communicate about this one thing

We already have been doing that, but as @fredmaiaarantes said, it’s a marathon, not a sprint.

For example, we now integrate with Monti APM instead of maintaining a separate project. I myself participated in the migration at Monti APM to Meteor 3, only that took more than year.

This is more in line with my vision of a thriving entrepreneurial ecosystem that Meteor is.

While you do have some of the answers, you don’t have all of them and neither do I… and that’s why we are discussing things in the first place.

Iron sharpens iron.

I want to find a way to unify everyone’s agenda into a single direction. What I have been doing is talking, in a call, to every key contributor in the community and pick their brains, still doing that as time allows.

But discussion alone is not enough.

There needs to be a unified vision, similar to what happened during fibers removal, but towards winning and not towards simply not losing.

Right now, I can tell you the two priorities we have: TypeScript & Change Streams.

  • TypeScript is a foundational thing that we need to start using sooner rather than later, for DX and core maintainability, and will happen gradually.
  • Change Streams is a huge improvement to the data layer and the official way of doing things with Mongo, we don’t want to have another fiber level event. This can be done in the next months perhaps faster.

In the meanwhile there will be smaller work, but really high level changes can only occur after Change Streams is done.

It’s also worth mentioning, that Meteor 3.0 is only here because Meteor Software is still here and orchestrated all the work, and incredible professionals who I also admire and respect took part in it.

Have you considered coming back to support us in some way?

11 Likes
14

That’s probably exactly where our views diverge. I would prefer Meteor to not have any Accounts UI at all. Instead, I would like to see Meteor have just a strong set of Accounts methods with a stable API and that’s it. Everyone can easily build their own accounts related UIs on top of those tools and the Meteor team would have even less to maintain.

I do understand your goal, though. Being opinionated in many aspects has its merit. But there’s also a point of diminishing returns. And keeping Meteor UI agnostic is, in my opinion, much more valuable to the framework and its future-proofness than any gains that might be received from tightly coupling to a specific view library.

In my opinion a good approach for Meteor would be to focus more specifically on what sets it apart (primarily strong data layer, including minimongo, pub/sub, RPCs) and for everything else rely more on industry standard tools. For example, instead of maintaining the custom built isobuild, just use Vite.

11 Likes
15

Agree with this quite heavily. To succeed (which means attracting as many dev/companies as possible) it needs 2 things.

  1. A very strong value proposition (the thing that sets it apart from everything else)
  2. Enough integration with the greater ecosystem to attract semi-seasoned developers

The web development paradigm is different now compared to when Meteor first came on the scene. Most dev’s at that point had never seen a SPA. In my college classes they were still preaching that JS was just for progressive enhancement and the majority of web companies were much smaller and less savy with their online strategies. Most of the tooling and packages we take for granted today didn’t exist. Now developers and companies have an expectation that certain things in the ecosystem can more or less be swapped out. I agree the path forward should be focused, but balanced with what is already provided by the ecosystem as a whole. Too much opinionation for Meteor in the current JS climate would mean meteor remains a niche platform with dev numbers in the few thousands which dwindles over time.

4 Likes
16

100%. @vooteles has the right idea here. Double down on what is unique to Meteor and be UI framework agnostic. The nice thing about the UI frameworks is that they are more or less converging on using signals under the hood so it will mostly come down to what syntax you vibe with.

There’s one key theme missing in this thread though — innovation. To keep its reactivity promise, Meteor must address scaling pub / sub, which I think they are working on. Beyond that, there’s an opportunity to provide essential pieces to help people build great software. I outlined several of them here:

I’m sure others have great ideas regarding how Meteor can continue to innovate. Now that Meteor 3.0 is out, there’s a big opportunity.

Happy to hear this will be a focus. Finding a way to use and scale pub / sub that doesn’t rely on tailing the oplog should be Meteor’s top priority. Relying on an undocumented MongoDB API sounds like a recipe for disaster.

I hope this doesn’t mean spending a bunch of time converting the core framework to a bunch of .ts files. I think the current approach of using JS doc for typescript support is the correct one. Over the past few years other frameworks, like Deno and Svelte, have discovered this. The creator of Svelte does a nice job of explaining why here:

Ultimately, I think there are two outcomes for typescript:

  1. It’s so useful that JS basically becomes typescript. I have my doubts but I could see something like this type annotations proposal eventually making it into JS.
  2. It fades out over time (several years from now) and people use JS and types as comments for the intellisense benefits or they really love true static typing for which I imagine there will be better solutions (possibly gleam once it matures).
3 Likes
17

Nowadays, the whole webdev is super complex and developer/companies demand totally different things from a tool. Sometimes there are “big things”, sometimes “small details” that matter to them to make a decision for or against a tool:

  • Must have a low learning curve (simple to start) but must not limit engineers in their ideas (enable to master)
  • Un/opinionated stack
  • Must/not be split into many little packages
  • Must/not be a monorepo
  • Must/not use TypeScript
  • Must do SSR plus all these ridiculous hydration pattern
  • Must do CSR
  • Must/not enforce certain design pattern or codestyle
  • Has to use a specific bundler or support “my hyped bundler”
  • Must easily integrate with tool/library/service xyz
  • Must have a full working and ready-to-deploy boilerplate for every “moneyprinter app that is currently hype”
  • Must be deployable in one-step and with as few config as possible
  • Must support “frontend xyz” plus it’s orbiting supporting libraries (without frontend xyz will either not really work or being :poop: to work with)
  • Must have a super detailed documentation of endless pages that is well written and being consumable in a few minutes
  • Must have constant up-to-date tutorials in blogs/videos/example-repos
  • countless more things that I won’t bring up here…

Coming from this premise, I’m really struggling with defining the “ideal developer profile” for Meteor in the future. I see Meteor actually fulfilling many of the above and I see rather the issue that there will basically always someone being not impressed, simply because ONE specific feature is left out/not supported/ enforced/whatever.

Concluding this, I agree with @acemtp that we need to go back to some kind of opinionated way for Meteor but I am miles away of seeing one specific stack that will satisfy many engineers needs anymore.
Maybe the sweet spot is in being “opinionated by default” as we also go with the Zero-Config paradigms of many features but being able to replace things where needed.

5 Likes
18

This summarizes what has happened recently and what needs to happen moving forward.

Many of us (most?) stuck around with the unified goal of not being left with a deprecated framework running existing projects. Now that it’s out of the way, we badly need that singular vision to move forward.

That vision will not please everyone because even this thread with supporters have different views of what meteor is/needs to be. Meteor must not cater to the needs of every developer. It might not even need to cater to the needs of many of the current developers using Meteor. What it needs to do is be clear with this unified vision and cater to the needs of those developers who are willing to ride towards this goal.

4 Likes
19

One observation - tying Meteor exclusively to any front-end is going to be trouble because they all seem to come with an expiration date. Even in this thread people are pointing out that React, the current champion, may be heading in the direction of PHP.

Tightly coupling with any given front-end could turn into a fibers-like situation.

5 Likes
20

Yes, that why I’m fine with the modular approach so that things can be changed if needed, but we will have strong defaults and if you go outside of that default opinion you are pretty much on your own.

4 Likes