Totally agree that’s why I keep going with Meteor, also for new projects which says something about the state of Meteor as the topic is.
Off course we encountered some more (and will so in the coming period) but those are really clear examples of things almost all people need.
Still remember the accounts-ui | Meteor API Docs package when we worked with Blaze. Genius simple. Now if you want to do it in React you need to find an external package to get it done or build forms yourself, change the routing to normals paths etc. There is real quick win in those areas. <AccountsLoginForm/> batteries included would save so much irrelevant time.
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
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:
one codebase to ship web and mobile
easily creating a great UX with Optimistic UI out of the box
the simplicity of DDP
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.
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.
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.
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.
.