Wow. Amazing statement.
I already tried to say that many times but I wasn’t able to put in this amazing way.
Thank you for these words 
This thread was probably started to collect bad things about Meteor but in the end I think it’s reinforcing what people here already know: Meteor is great to build businesses online 
I’m having problems for the first time ever
I love Meteor but this is major pain for a few of my apps
Well, you know, the reason I use Meteor is to avoid these kind of situations, and that’s the promise a vendor-supported framework.
Not trying to cast stones, but genuinely asking what have you done to fix those problems? I mean you could raise some PRs and try to fix the problems for yourself, maybe commission a dev to work on those issues, or even support meteor-developers. FYI, e-Potek/@florianbienefelt sponsored @zodern to work on Meteor build tool at some point so maybe you can do the same.
Again, I’m not trying to beat on you but this is kind of learned helplessness not only that but we do have agency and great potential to take matters into our own hands and actually do something.
Well you know, the reason I use Meteor is because as a vertically integrated framework, and it promises you to take care of certain things. If Cordova or Electron are featured on the web site, I expect them to work.
I contribute in other ways, such as promoting Meteor’s use, deploying apps on it, writing packages, etc, but also, I’m essentially a customer of the product and should not be under obligation to fix broken parts. I have tried to pay some developers to fix it, and to open tickets, but no luck.
Again, I’m not trying to beat on you but this is kind of learned helplessness not only that but we do have agency and great potential to take matters into our own hands and actually do something.
Agree but also - there needs to be more pressure on MDG/Tiny to commit more to Meteor. It looks like they acquired Meteor just to milk the Galaxy profits at this point.
If Cordova or Electron are featured on the web site, I expect them to work.
I don’t think Electron is listed on their website, it’s an OSS project. it wasn’t started by MDG and thus you’re not entitled to support from them. Sorry. 
I contribute in other ways, such as promoting Meteor’s use, deploying apps on it, writing packages, etc, but also, I’m essentially a customer of the product and should not be under obligation to fix broken parts. I have tried to pay some developers to fix it, and to open tickets, but no luck.
I appreciate your work and like I was saying I wasn’t trying to put you down so please don’t get defensive.
Yeah, you’re helping and I greatly appreciate it but how does this ways of helping relate to our current problems?? I must assert you’re not a conventional consumer nor this is a conventional product. This is an OSS product. You’ve to put some work in, at least that’s how I see it. You’ve not paid a dime for it so you need to get your perspective aligned.
Agree but also - there needs to be more pressure on MDG/Tiny to commit more to Meteor. It looks like they acquired Meteor just to milk the Galaxy profits at this point.
YiKeS! I kinda saw that comment forthcoming before I started conversing with you. I already waged enough wars with MDG/Tiny so don’t make me bring out the pitchfork 
.
Finally, I reached this state of complacency nirvana where I don’t blame MDG/Tiny anymore not because they’re bad or good but they’re a for profit company so they do what they do but we do us. And that’s not to say they’re doing bad either, I think the post-Filipe leadership is waaaaayyy better. Keep in mind, they’ve their hands busy with 3.0 and they’re doing terrific job so who knows maybe they will take meteor-desktop under their wing once they’re done but for now we have to hold our end of the bargain.
It looks like it was taken down - I guess that is better
Well, you have to realize, there to be a certain level of frustration for me to escalate into making the comments I am making. The intensity is to signal to the team that, like many, I am considering moving off the platform.
If you look at Supabase… it’s very close to the Meteor… look at how advanced it’s become in a shorter time period, how much money it raised, etc.
Lots of interesting answers here. When using Nextjs you have to set up the DB, auth, APIs, there’s tons you have to do that’s not working on features that deliver value to your users. But what about Rails? It promises many of the same benefits, is robust and has a very large and mature community, it lets you create mobile apps with Turbo Native (and they have Strada in the pipeline).
What makes you choose Meteor over Rails?
Mainly the speed of simply using JavaScript throughout the codebase. If I knew Ruby inside and out then I might use Rails, hard to say.
I also like:
I haven’t looked at Rails in a while but it seemed to me that it was more challenging to create a great, reactive UX with the server in control of nearly everything. Maybe Turbolinks solves that.
I think the front-end clients should not be the focus on the core team. Probably just sdk + backend and hosting platform (galaxy) and third party integrations with different clients (vite, Cordova, electron, capacitors) could be maintained by the community.
I personally decoupled backend from frontend, created a meteor client SDK and used it for backend/hosting. This is how Firebase, and Supabase works except that Meteor backend is more flexible.
Open source the client SDK plz I’ve always thought Meteor should have that kind of thing
Maybe it shouldn’t be in there but with Meteor’s proprietary tech stack, it’s very hard to integrate them… maybe I’m wrong here though.
I was planning to do so but the source code is rough and tailored.
But I took a lot of inspiration from firebase, I’m actually surprised community didn’t end up with something like that. We can just plug the client sdk to any front-end and call it a day.
Meteor client SDK basically handles the socket connection, auth/session, detect version change, and call methods/pubsub among few other helpers. It is plain JS and can be plugged into any platform. And it can also plug to bay backend supports websockets, so goes both ways, for example I got a POC running with back-end using Deno and the same MongoDB.
Open sourcing the SDK, seems like a good point which wasn’t brought up in Seeking Community Input: Meteor.js Roadmap cc @hschmaiske
FYI, Next has a ton of examples that you can use as inspiration or starting point with create-next-app --example: https://github.com/vercel/next.js/tree/canary/examples
By the way, I see people saying you need to configure tons of things but that’s really not true. I don’t mind a but I have the feeling many people in here are discarding “other frameworks” without having actually worked with them. Putting blinders on serves this community no good in the end.
We actually tried with multiple frameworks and ran into many dependency things which just did not work out smooth.
This is how we think about it: With Meteor we install it and can start working on the features that matter for the users.
Everyone should just write more PRs.
Just for the sake of real world examples: We are now in 2 weeks building a project management like system and it just works. Is it optimal, high performant etc? No for sure not but the business is already running on it adding real-world value.
We had 2-3 really slow pages so there we focussed on some optimization. The rest is just fine to work with.
Already has loads of features and integrates with existing bookkeeping software for example.
There is great power in Meteor and also a lot to win on boilerplate work for those kinds of projects to make it even a one week job. That’s where I see much easy value-add for Meteor to increase its current state to an even better one with a low investment on development resources.
I see a lot of improvements in the real back-end technology of Meteor being worked on which is great. If a little bit of that time and energy gets focussed into developer experience a lot is to be gained.
Meteor is great and possibly the number one rapid development tool to create highly professional MVPs within an extremely short timespan.
Sadly the genesis of the project was seemingly lost long ago and now everything else is kinda poorly executed and paywalled. It’s a real oxymoron.
An example of where the state of Meteor could really use an uplift without much complicated development: End to end testing.
There is a blog on it:
Which contains lots of older information, if you start implementing it you run into the fact that plugins in Cypress are deprecated now and that there are other ways to do the things.
Those kind of functionalities would greatly benefit from an up-to-date start method which is opinionated so you can just run an “install” command and you would have access to end-to-end testing. All details important specifically for Meteor are already listed but it’s a static blog - not code.
Ran into many issues with loading the mocks for the tests. Paths which are not setup properly. Typescript plugins needed to be installed. All to the things you don’t have when working with Meteor pieces. Spent hours on technical work instead of adding value.
I’ve been using meteor for quite a long time, but recently I’ve had to stop advocating for it in my companies because policies dictate that we are OBE Node 14. I still use it in all my personal projects, and when ever I do I’m constantly reminded how refreshing it is to not have to setup all the “things” I’d have to do in my company to start a new project.
Issues like running on Windows, locked into Node14, and having two package management systems can make it tough for new users to pick up. Without a deep understanding of how Meteor operates it can be frustrating for new users once they get past some of the tutorials. I’ve had a hard time even explaining how meteor operates to other very experienced developers…who ultimately just say “that’s too complicated” and we go another route.
So, my 2 cents, if you’ve stuck around and been using Meteor for a long time you are likely always going to see its power and potential. If you’re new-ish, Meteor may seem like a joke compared to other frameworks. If you’re brand-new, and looking to adopt Meteor (especially if advocating it for professional use), I’d say put a pin in it until after it doesn’t need its own Node14 to run. Not saying 3.0 is going to solve everything, but at least your security / compliance team won’t leave the room laughing at you.
