Make Meteor great again

community
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).
5 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
21

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
22

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.

11 Likes
23

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.

3 Likes
24

Blaze needs more love

5 Likes
25

@cereal

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:

  1. Add some big feature, by adding code to many places at code
  2. 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
26

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
27

@cereal

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.

28

I really regret linking that at all, it seems to be detracting from my post. I’ll change the link.

29

@cereal

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 ?

30

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