Meteor Roadmap questions

core
1

Hi, when I set out to prototype, I always think of Meteor as a back-end. Back when Meteor was run by MDG, I used Meteor for several clients and projects.

It was great, but MDG definitely wanted a walled-garden for their cloud platform. Unfortunately, many of the essential packages in that ecosystem were “community” packages, so the ecosystem dragged when the community didn’t update/improve them over time. MDG went off to create Apollo, and I eventually left in search of other tools.

For example, Quasar, is an amazing front-end development tool, which I now use for digital mockups and front-ends. Unfortunately, I have no idea on how to make Quasar and Meteor work together.

Here’s a Quasar + Meteor template, but it doesn’t build. The glue package hasn’t been updated in 4 years (except by a dependencies bot).

I get that Meteor’s build tool created Blaze front-ends, and now can do Vue, React, Svelte, etc. But the Vue ecosystem keeps evolving past what Meteor offers, so I keep looking to Meteor then turning away disappointed.

I looked at the Roadmap and adding Capacitor is on the list.

Quasar can create SPA, PWA + offline w/ SSR, Cordova, Capacitor, Electron, and Browser extensions. There are Vue alternatives to Quasar. React is a whole other ecosystem.

We’re still building front-ends separate from web back-ends - MDG had $20 million(?) in VC funding to create a tool that did both, and couldn’t keep up with both.

My honest question is this: Given what’s available from other open-source projects, is improving Meteor’s build tool still relevant for building front-ends?

Why can’t I import a Meteor CORE client npm package into my Quasar project and get all the data services I want out of Meteor? Or, import a custom npm package built by the Meteor build tool.

I don’t want a community glue package, because they become unmaintained and it is frankly just easier to make a REST API than to try to understand and maintain a random 4 year old glue package. I experienced this with some unmaintained Vue integration packages.

Is there a simple integration path using core maintained modules I’m missing?

Are these questions and thoughts relevant to the future of Meteor?

Thanks for reading!

9 Likes
2

I’ve been advocating this path for some time as well.

Doubling down on the backend/devOps and let the developers bring their own front-end with any build tool. This will bring a lot of flexibility and value to developers while narrowing down the scope of the Meteor code base.

Meteor Core = Galaxy + APM + node backend + support packages backend packages (file upload, authentication, payment, cron jobs etc.) + Meteor client SDK

That is also how I’ve been coding the apps, using CRA, one code base for all clients, since 5 years ago.

I mean all is needed to hook a client to a backend is npm i meteor-client and then call few methods. The client can be deployed on static host and the backend on Galaxy. This is how I’ve been using Meteor with CRA and it’s working perfectly.

3 Likes
3

If Meteor decided to provide official SDKs for other platforms it could place itself as an alternative to Firebase, Supabase & Appwrite. It has the potential of becoming a serious candidate for MBaaS.

These mentioned solutions have gained traction in recent years, They are able to attract mobile devs (flutter, ios, RN) with the promise of a seamless experience & avoid writing business logic for multiple times. I’ve personally started using & prefer Firebase if I just have to build a mobile app.

Supabase (JS) & Appwrite (PHP) both have started as a Firebase alternative. ATM the main USP of these platforms is that it’s giving you a fully-fladge accounting system out of the box. This is also sort of available in meteor just meteor but lacks official SDK support for other platforms. One advantage with meteor could be that people won’t feel that they are being vendor-locked like they feel with Firebase & Supabase.

1 Like
4

@alawi, LOL, I was SUPER EXCITED when I read your post thinking I’d missed something.

Then I looked for the documentation on meteor.com and didn’t see anything, then at the project on npmjs.org, and it’s 6 years old, with one contributor. Which is THE EXACT SAME SITUATION :slight_smile:

Why isn’t it documented on Meteor.com and part of the core packages?

Meteor was already open source. Meteor already had Galaxy. Meteor was hot then stopped being relevant for reasons. What’s actually changed in direction of the project?

1 Like
5

Apollo GraphQL happened. And in a sense it is what this thread talks about. You bring your own front-end, build system, heck you can even choose the backend and then the Apollo handles the data transportation.

2 Likes
6

@storyteller I tried Apollo and GraphQL, and they would fit well in enterprise environments with heterogeneous systems. But they don’t do 2-way real-time data transport like Meteor, and they add a lot in complexity. Apollo was a smart move for MDG - they dumped their dedicated open source community and went for enterprise $$$.

Meteor was great for rapid prototyping and real-time dashboards and projects that didn’t need $800k/year in developers.

I’m wondering if anything changed in the direction of Meteor.

Is there any long-term opportunity for Meteor in web dev open source?

Or is it still trying to be a VC-funded walled garden?

1 Like
7

Question is what you want. I personally use Meteor so I alcan create apps fast but host the Backend on our own infrastructure.

I also dont want to fiddle with the whole authentication on our API. Use this.userId in methods and go.

Also no fiddling with build tools. Just no. All productivity killers.

I admit there could be improvements to easier separate backend and client but apart from that and getting rid of fibers I currently see no demand for meteor to drastically change.

11 Likes
8

After SSR(which I don’t use because I prefer prerendering), dynamic imports, 2FA (which I could implement myself) I think the only thing missing in 2022 is Node 16 but that is ok as long as 2014 is well supported.

I am trying to understand what this discussion is about, what objective and punctual problems or limitations other encounter. I find no limitation today in developing Meteor projects for millions of users, global, compliant, sharded etc.

If we talk speed of delivery, supportability, cost of production I guess it is hard to beat Meteor. I might be looking at Meteor from a too productivity oriented angle and this is why I feel Meteor is so great.

If you were a good JS programmer, Meteor is plain easy to adopt and it is very easy to join a Meteor project with only JS experience. On the other hand if you were a taxi driver and wanted to get into programming, Meteor is one of the easiest to learn, great community, multiple examples and in a year, as a single developer you can deliver to Web and 2 mobile platforms. You can write any API you can imagine for the Meteor server and you can produce an almost server only bundle.

When I say “the community did not maintain the package” I tend to forget that I am also community and I have a professional responsibility to understand Meteor and contribute if this is where I put my investment.

8 Likes
9

That hasn’t been true for half a decade. The 2019 JavaScript developer survey says in 2016 Meteor was relevant to 60% of respondents.

image
image1576×798 75.2 KB

Meteor wasn’t even included in the 2021 survey.

Think and do what you want.

The only thing interesting to me about the past is identifying opportunities possible in the future.

I have wanted Meteor to take open-source seriously, with a front-end in-core data-client, since 2016.

1 Like
10

I don’t think this is a failing of the Meteor functionality, as much as people have made their opinions based on earlier versions of Meteor. Before it had NPM/react support/dynamic imports/ and no solutions to scaling issues/etc. Deployment at times was annoying, and Galaxy was seen as expensive, but that’s improved as well. The biggest issues Meteor had are long gone. But people already wrote it off and likely don’t know the status of how things work now.

This is something a change in advertising or rebranding could solve. As I do think Meteor is an amazing tool. Most recently, I find it great to work with Vue, only complaint being that Vue 3 wasn’t yet supported when I started my project (I don’t know if that has changed). I’d argue that it’s easily one of the top ways to use Vue.

In general as a Meteor user, the primary place I think could be improved is I hope the top packages could be officially integrated in to Meteor. I see in the roadmap that this is being looked at for Redis Oplog and that would be great. Grapher I think is a huge improvement (and would likely win many over who are reluctant to try to try Meteor for relational issues) and it’d be great to see package like those integrates as well. The community has done a good job in most cases, but packages like these would be very powerful to integrate at Meteor’s core, and to be able to use them without worry of not being maintained would solve any issues I have with Meteor.

2 Likes
11

I have released a new version of Grapher recently. More and redis-oplog are on the way, but currently my time is limited to work on this, so I’m dependent on other people’s making the PRs.

4 Likes
12

This was identified as the main problem several years ago. Despite efforts by the new owner and team, it still has fallen short (for many reasons).

13

What is “not true”? Having worked on a Meteor app for the last 6 years, as well as many other frameworks over that time, I’m still in 100% agreement with @paulishca. The merits of Meteor that he outlines are still true.

Those JS surveys are a great indicator of contemporary hype and buzz. That Meteor doesn’t appear there has a ton to do with marketing and social media (dev.to included), not true business utility.

5 Likes
14

it was suggested by sasha to remove it after further decline in popularity, see this thread Well ... interesting Meteor numbers in the State of JS - #96 by waldgeist

1 Like
15

Great to hear. The Meteor community has done some wonderful things, I just think it’d be better for all if they were officially recognized as a part of Meteor. After all, if the developers took the time to create a strong Meteor package, they’re already donating a large amount of their work and time to the better of Meteor.

I remember when reading through the Grapher thread, it sounded like much of the reason cultofcoders moved on from Meteor was a failing of this. It’d be great for the future if the Meteor team would be quick to try to hold on to developers willing to put in work. This seems to be one approach Meteor has failed to utilize for many years, even going back to the authors of some of the earliest Meteor packages - a focus on keeping developers here, rather than stopping them from moving on (or having to move on).

Now may be a time to not only focus on stopping developers from moving on, but maybe try to bring developers back. Especially those who tried it 5+ years ago and wrote it off. If they only knew not only what a basic Meteor tutorial looked like, but also had an idea of what working with Meteor was like when utilizing the most popular packages, how to properly utilize scalability, it’s strengths for those who develop in React/Vue/etc, and that it plays nicely with NPM nowadays. As those were most of the negative publicity I saw Meteor getting - aside from NoSQL complaints. But there’s solutions to SQL nowadays, and Grapher can help make Mongo relational, so that issue is in a much better place nowadays as well.

16

I very much disagree with this. To keep Meteor maintainable, secure and free of excessive technical debt, it is necessary to keep Meteor core as small and lean as possible. Meteor has a functioning data layer with methods and pub/sub. It is quite simple and works well for the majority of cases. And keeping things simple and maintainable in the long run is much more important than solving edge cases. Right now the main task for Meteor core developers should be to quickly start solving the fibers and async/await issue. Anything that can reasonably be used as a community maintained package, should remain a community maintained package. Especially packages such as Grapher that are likely used by only a small percentage of Meteor developers.

I think the community packages repo is a very good idea. Not officially in Meteor core, but gathered in a central place and receiving some basic maintenance. A good compromise.

9 Likes
17

I keep reading this. What exactly (in short) are the issues? I and probably a lot more developers have Meteor apps running perfect for years.

The only issues I have are some, very irregular errors with sockjs:
Screenshot 2022-04-06 at 14.38.15

18

Fibers + NodeJS 16 !== LOVE

3 Likes
19

Thanks Paul, I’m not on Node 16 (not even on 14) hence I didn’t experience such problems

20

The issue is that currently Meteor relies on fibers extensively in core code and newer versions of node, starting with node 16, do not support fibers any more. Yes, right now, node 14 is in maintenance mode and works with meteor. But in April 2023 node will drop support for version 14. Sticking to an unmaintained node version is not an option. So there’s a year to make meteor work with node 16. That’s a major task and there’s no time to lose.

4 Likes