This is true, but I think its minor. NodeJS is good enough for handling a large number of open socket connections. However, it does make scaling meteor a bit more expensive (it needs more server RAM) if you hit very a large number of concurrent users, for that, I’d switch to GraphQL or Rest over DDP for the hot pages (and remove DDP accounts) since those protocols are stateless. One thing to keep in mind though, that sockets once established are faster than Rest/GraphQL (since the packets size are smaller), you can see this advantage in infinite scroll for example.
I personally think all real-time by default was not the best Meteor design decision, I think it should have been opt-in and Meteor accounts should have been done over Rest, but it is what it is now.
However, we derive benefits from having stateful bi-directional socket (over-the-air update, simple RPC, faster response, pub/sub) so the tradeoff is worth it. So you’ve to evaluate your use case and pick the best tool for the job.
There are ways to convert to REST pretty quickly (thinking of simple:rest in particular). I’ve often thought that if I ever hit scale issues (so far I haven’t), I’d try that, maybe convert my one paginated package (which 95% of my queries run through) to use REST end points - maybe put a front-end cache in between my running server and the client, etc. Or just use redis. There seems to be no shortage of ways to scale Meteor.
From scratch yes. I don’t think anyone is denying that. but don’t oversell things because with a lot of frameworks you need not start from scratch. I rarely have to start from scratch with Nestjs. To be honest lightning speed of development is always relative to knowledge. Nice to have some framework level built in tools sometime though. However lets be clear here. You asked me what my present go to stack was. I took that as an aside not as a turn in the subject of this discussion. After all I am here and I wouldn’t be if I thought nestjs was the answer to everything. I don’t think ANY tech is. lets not turn this into a Meteor vs Nestjs discussion. If I answer some of your points thats where it would go and I am not here for that. I never volunteered Nestjs as superior or inferior oreven brought up it up until asked.
Unfortunately ( or perhaps fortunately) thats not the way the world works. You don’t need to stick with anything. You can rewrite (and only app flops never get rewritten) and leave (which does Galaxy no good). Technology moves on which was my point and if we are honest whats happened to Meteor to a large degree. With new ownership I see a hope from most to have a new resurgence . I don’t think that kind of binary thinking really helps. we are talking technology here. the idea that its a positive thing to be locked in doesn’t make a lot of sense unless the thing you are locked into is so ideal and near perfect there’s no issue.
Still, don’t really accept your premise of “especially mongo” or no fast development speed benefits . As if that’s the only way forward. Curious as to what you think of Vulcanjs. Yes Meteor as a build tool (and I believe for things like accounts) but no not married and forever bound to Mongo for all the rest. As for Nosql being relatively young. Thats a bit of a reach. Anything in tech for over a decade can’t make claim to being new in anyway.
On the whole other stuff on nestjs (hosting , real time etc), like I said won’t get into it. You are wrong but nestjs was never the subject of this thread or my initial post. My point on scaling always referred to third party packages such as diaconutheodor’s great work and to that being brought in in an official way. Like it or not The framework architecture creates a scaling issue so solutions either should be built in or officially promoted and taught. In my discussion with diaconutheodor a good while back The numbers looked much better but we’ll just disagree that express has nothing to offer in its whole ecosystem that gives it an advantage. I don’t think that would need a rebuttal even if this were a discussion about nestjs
Definitely Meteor in 2020 and beyond!!! @dandv you really gave a nice summary of why Meteor is still really amazing!! Meteor + Vue for me is a dream come true, and I can see reasons why people want their front-end (view layer) of choice to integrate with Meteor.
Building a new app is the dream with Meteor and it’s so much easier to maintain than any other option too.
Great additions @alawi and @jkuester … I think any Meteor app can meet the PWA criteria. And to have a stack that is all open-source, should really never be undervalued, it’s the key to longevity & a strong eco-system of devs.
I really like this idea of Meteor devs cross-pollinating with other devcommunitiess as I think it will bring a lot of the right kind of attention to Meteor.
I don’t see much locking me in to Meteor, except convenience. Most of my code is portable React code. On the server side, my methods could easily be ported to any other transport framework. My SSR code is a light abstraction on connect.js, and could easily be ported to Express.js or anything else. I’m a bit locked in to Mongo, but even there, I could rework most of my queries to use any Mongo driver directly - I just lose convenience.
In fact, I could literally replace each of these aspects within Meteor to start - replace the build system with webpack (but why?), replace Meteor collections with Mongo directly - I’ve seen some folks swear by that - or better, replace it with Apollo, in Meteor. I can even run Express.js along side or on top of connect.js (I think). In fact, one of the Apollo package does exactly that. I could replace Meteor’s accounts system with account-js. After each thing has been ported away, I could replace the entire build chain.
I just don’t see a reason to do that. The problematic parts people reference in Meteor when it comes to scaling all have workarounds, and models we can use to scale them - or you can just use Meteor’s underlying node.js system directly, and not use the parts you don’t like. It’s so modular that way. It’s like ejecting, without ejecting.
I’ll also say, Meteor’s back compat is a god send. I’ve not worked with any other platform (except maybe WordPress, which has, er, other problems…) that makes it as easy to stay up to date. I was surprised to learn how hard it is to stay evergreen on so many other platforms…
“however you’ve to agree and stick with its initial choices especially mongo” .
So yeah reworking isn’t sticking with the initial choices. Nothing is a total lock in unless you move to an entirely different language (then the rewrite is close to 100%).
Mongo only is a deal breaker for a ton load of developers in regard to a ton load of apps. Thats a fact. Might work well for your apps but - key point to remember -
You are not in the why not use Meteor in 2020 group. After all you are using it. Frankly I am not even in that group. I think i can perhaps still sees things because I am not as locked in as some of you - so I have a semi outside perspective. So you either have to kiss goodbye ever reaching a large block of developers out there that have limited use for Mongo or take on the task of convincing them otherwise. Good luck with that Tiny.
Those would be workable choices for a framework gaining head space and adopters but not for one that has seen a rather one way consistent exodus. Mongo too was supposed to have conquered the world rendering relational databases as things of the past. it didn’t happen. Instead Mongo showed its warts in some regards (mostly expectedly relational). Still wildly popular and used a lot in node development but nobody really WANTS a framework that only offers that. I can’t think at the moment of another framework as tightly linked to one database as Meteor (regardless of reason)
SMH…After all these years of hearing and reading in this very forum that MDG was working toward multi database integrations I now come to read in this thread - “nah its not an issue whoever needed it? We are all good with mongo”. We just need to market better. Kind of boggles the mind how often this framework and its community switches lanes and directions
yeah the thing you are missing is that you are already invested in meteor so you think from that perspective. The trick is in seeing how you would view it if you weren’t. I hear and even at times give the same answers on behalf of Ruby and as far as frameworks go RoR. You can do that . Theres a workaround here for performance.shucks if you want you can create games in Ruby. alright not the exact same thing but thats an enthusiasts position not someone saying why use ruby who isn’t presently.
take the new framework Zeus. right now it only works with Maria. Out of the box its 7 times slower than Meteor and it takes about four servers to handle the same load as Meteor . It had a bit of a situation and lost half of its contributors. thing is though it has a sweet messaging system built in and comes with authentication built in and there are some hacks and workarounds that you can do to make it run faster
Interested in this fictitious new framework? I wouldn’t be. Truth is the hacks might end up making the framework incredible performant - but who will ever know since how may people are going to get that far down the avenue to find out?
Fact again - Meteor has rep for not scaling. You say it can because of redis-oplog. how do you expect a nonuser to know that? What person putting themselves out there for a new framework at their work place wants to answer the question of scaling with - “there are workarounds” (which sounds like a few steps up from hacks). I have looked into it and diaconutheodor has done a great job but - maybe i missed it but wheres the back up and support officially??
I guess we will see in another year or two whose right. real issues people want or just a matter of Tiny remarketing .
So to sum up, you never used Meteor, and you don’t (or rather your developers) don’t want to use MongoDB (which I and assume many of us here are happy with), and you worried about scaling (which several people here told you it can be solved).
Then perhaps MeteorJS is not a good fit for your shop, although my suggestion to your shop is use pure express/webpack over NestJS (NestJS doesn’t offer much value over plain express and extra layer of dependency) and perhaps give NoSQL a try.
And we are not locked in, as I said i have webpack/express projects and I can replace every layer of the Meteor stack, but I can’t justify the extra work myself since it won’t add any value to my users, I don’t have any major pain point, I derive value from the many great packages, I don’t have to worry about updating NodeJS and other dependencies, I like the Meteor community, I find most of the counter arguments against Meteor, including yours, mostly FUD so they are not very convincing and the alternative frameworks don’t have very appealing offerings, so yeah, I think I will keep using Meteorr in 2020 and beyond. I think only Deno land can offer a serious alternative.
Anyway, thanks for sharing your perspective, and good luck with NestJS, and we will hear back from you in few years .
It’s a fact that Meteor has a bad rep in this respect, but the basis of this rep is not a fact. Personally, I think it’s just unfortunate that a bunch of beginners (not saying you are!) got WebSocket superpowers on their hands and didn’t know what to do with them other than shooting their own foot.
Sorry, I mean no offence, but I think anyone complaining that Meteor doesn’t scale, well, it’s almost like they don’t really know their thing. It’s ok to not know, we are all learning. It’s also good to admit that our code / architecture skills / DevOps is lacking when that’s the case, because that’s more often the actual truth.
I understand some of your points, but hammering home the same unproven point over and over does not help towards building constructive criticism. Just don’t pub/sub everything, and use methods and I promise you will be scaling to 2K concomitant users on a couple of EC2 medium servers (depending on the number of documents and queries you send to them) and you will have room left. No Grapher, no Redis, nothing fancy needed here.
But on the other hand, if you need pub/sub (i.e. you are building a real-time game, tracker apps, whatevs), good luck with other frameworks. It is then when you go back to learning: WebSockets, Mongo internals (yeah, show me a commercially solid alternative to Oplog), and understand what pub/sub does and what you need to do to scale.
Meteor scales fine. Mongo is a fantastic tech used by a huge amount of companies. I have no vested interest in sticking with Meteor other than it just works well for our needs. I understand your perspective, but after reading this whole thing, I just see a lot of unneeded aggression. If you want to use something other than Mongo, you can, just not with ddp and pubsub. If that doesn’t work for you, just move on and stop insulting people here. I don’t understand the commitment to keeping up with an internet argument for this long.
Yes the basis of the rep was a fact. Its so much a fact that some good people here addressed it. So I would say present tense that’s not as big an issue BUT in order for me to know that I had to continue to show a deep interest in meteor to know there were workarounds. My point is and was (and hasn’t been touched) that companies and shops want to see such solution as as official or integrated package. i don’t know why such a statement is either controversial or something to get defensive about.
Go back and read what I read. I at no point stated that Meteor cannot scale.
Are you really trying to claim that instant reactivity and subscription doesn’t have a scaling effect? Can you mitigate it? Why yes but to claim the rep wasn’t a rather direct result of the selling point of Meteor but just people’s ignorance is well …a little bit arrogant and uninformed itself.
No the keyword here is one that has not been used yet - fan boyism. We don’t want to hear anything else but all thats right with meter past or present EVEN IN A THREAD titled "why not meteor in 2020?
How dare I show up in such a thread and maintain issues exist that do make some decide not to use
meteor.
I guess it must be such an impossible gargantuan task that all the developers of those kinds of apps all use Meteor. I don’t disgree it s easier to get going on that with meteor. Its also harder to control it too.
Anyway I declined getting into debates about this framework against another and just cited some reasons why shops might not go with meteor. I don;t see any of you having touched any of them (as actually stated) . I’ve been very constructive for a very key reason - I’ve been around awhile and I have NEVER seen a framework in decline restore its place in mindshare by saying - everything is great and theres no good reason why we are not being used more.
A few of you in this thread is what really kill frameworks. You get so darn defensive and passive aggressive at people who are not head over fanboy heels in love you run off everyone else. Then maintainers only hear your point of view and the framework continues to die.
The issue here is the shortcomings you are listing, I (and others in the form) have been hearing them for years and they have been debunked many times. And I tried to explain, that yes there is couplings with the DB (but most of us here are happy with it), and for the scaling there are ways to optimize once you hit the scale.
Once you accept and bypass those, I think the Meteor ecosystem has alot to offer relative to the alternatives.
You are not adding new point to the discussion. You mentioned NestJS and I gave you my honest opinion about it, that I would stick to express/webpack if it comes to that. But it is a good framework and will get the job done (I mean it’s express/passport with good patterns).
Again, I wish you a good luck with your choices, this is tech and we have to pick what works best for us and get the job done. I really don’t think I can add anything anymore here, we are going in circles, and I would rather get back to my coding.
That in itself prove my point. The rationale that the whole world just hasn’t gotten that we really have solved all issues others have raised as well is not in the least bit credible. Meteor though declined is still too widely known to claim everyone else but us has just missed it. I never made any point about what most of you are happy with or not. Its immaterial. It never been about you or other present users or convincing you to use something else. Its not difficult - Its right there in the title
Why not Meteor in 2020? and then the OP asked. Whats wrong with Meteor? lol,
Crikey Mates. So no one was supposed to point out what they considered wrong or they were trying to convince you away from meteor? Get a grip. But you are right nothing new is being added to this topic at this point…Not you and not me.
I criticize aspects of meteor all the time without feeling spited in some way by it or anyone here who may disagree. This community takes critisim just fine. It’s when things are no longer constructive that’s the problem.
OK. I see. This person is just here to argue and provoke. I got no time for people like this. I’m not trying to sell this framework. Use it or don’t.
Hey @manthony it looks like you’ve been missing out on the joy of Meteor since about 2015 according to your message history, FOMO (fear of missing out) is real. I’ve been using Meteor and loving it since that time, and so have thousands of other developers.
I’m now using Meteor + Vue for 1.5 yrs and I couldn’t be happier. It’s not cool to spread FUD (Fear Uncertainty & Doubt) just as a “lurking outsider” (your words), that has no benefit to anyone. And your lurking FUD behavior could be done to any framework.
I’m working to change this FUD, so I really don’t appreciate your misinformation/FUD. The experience of the developers in this thread is pretty massive, and it sounds like you’ve never even used Meteor. We are working to make it easier for new users to get started with Meteor, so if that is your goal, we could all help out a lot more around that topic.
When you use Meteor vs other stacks, you pretty quickly realize why it is so amazing.
There is no other community I’ve seen that is more supportive than the Meteor Community. It’s also been crazy resilient over the years.
It looks like you’ve been “lurking” in the Meteor community and raised your concerns about Meteor in 2017, 2018, and now. I’m in the Vue Land Discord and talk with two core team Vue devs about Meteor + Vue and working to build a stronger connection between the two communities. Vue devs somehow felt burned and there is A LOT of FUD about Meteor in the Vue community and hopefully we’ll get this cleared up in time. One of Vue’s core team devs wrote the primary integration packages for Vue + Meteor and the integration is awesome.
Meteor is a hidden gem at this point, and the devs who discover it find a lot of joy in building & maintaining apps. Meteor will continue to grow organically, the best kind of growth, and passionate devs write the packages they need which benefits everyone in the eco-system. You can look at some of my post history if you’d like to see some of my comments to clear up old FUD.
@matthollingsworth this has been the kind of attitude that we would like to clear up in the public
@ everyone, lets chill for a second please. This has spilled over from constructive disagreement into frustration and aggression.
@manthony, you don’t need to reply to everyone. Most of your posts have been very constructive, but your frustration in later posts seems to have triggered a frustrated response from others.
The thing is, that others opinions and experiences aren’t an attack on yours.
Their experience with scaling doesn’t invalidate your experience with core functionality and external perceptions.
Unfortunately, perceptions of Meteor is a long standing sore spot for community evangelists, so you got the regular defenses of Meteor in response (ie. be careful with pub/sub, use extra packages, etc).
You don’t need to respond to every one of these, your first response was adequate in explaining that this is the objections you face when considering Meteor with your team. It’s clear in the remaining ones that you are getting further agitated that folks are getting stuck on defending the point. Chill, you don’t need to keep replying.
@ everyone
Lets not make assumptions about each other, and keep it civil. I don’t want to have to delete or edit posts. I’ve done a little of both to clean up instead of responding to the flags. I’m not handing out any silences or suspensions, since this looks like it was miscommunication and misreading instead of malice.
We all know that Meteor has a rough reputation, some deserved and some not. I think some of the improvements suggested have a lot of merit, but we are still going to have that reputation to work on as well.
As a side note, I’ve been interviewing for a new job and so I’ve gotten a few of these:
Which is fun trying to convince others that my skills are still relevant in 2020
I really hope I’m not throwing gasoline on the fire here.
I actually think @manthony’s posts, albeit pretty direct, were pretty constructive. He was not insulting anyone, just pointing out (perceived) flaws as is the topic of this post. If you are insulted by this, you should maybe read some of the stoic works. As Epictetus already observed, it’s impossible to insult a rock
This is a good point in my opinion. The discussion is not (and has never been) “does Meteor scale”, but rather: what can we do to improve this perception. Official guides + packages for the known solutions is a very constructive suggestion.
Goodness man. You should be on Reddt so I could give you some Gold. Thats EXACTLY The point I made in my very first post in this thread. Its been twisted mercilessly ever since. unofficial packages need to be brought into official status to help convince people they can trust meteor to scale. You’ve single handedly restored my faith in this forum (well almost. I see the merry band is still at it).
@manthony, I for one apologize if any of my comments aggravated you, I get your point about scaling best practices and the DB coupling, it has been echoed many times in the form, and I really don’t want this thread to turn personal.
This is very good feedback.
I’d suggest we turn this thread into something constructive. I’ve always proposed to create a scaling section within the Meteor Guide to encapsulate the best practices.
However, at risk of repeating myself, the scaling issues you alluded you are solvable, and no these are not hacks but best practices to be followed to address the challenges of scaling any system. The alternative you proposed (nestjs) doesn’t make any comparable offering, and in my perspective, offer very little to plain express/webpack or Meteor. The issue with Meteor real-time is that it is very easy to screw it up, and run into performance issues, that is why I think it should have been opt-in by design and not the default.
@manthony would you mind sharing the link of your dev shop so we can get a better idea on your perspective on the kind of services/app development your shop is creating?
I agree with you that the community can do more to address the FUD around scaling.
Some of the offending messages have been deleted, others have been edited, since the original discussion. Unless you were following it closely for the past 12 hours, you might have missed parts of it.
The constructive parts of it have been obvious.
But, because of misunderstandings, or maybe it was just the late hour in the specific timezone, @manthony’s posts were becoming more and more in a way that can easily be viewed as patronising and negative. And it all snowballed from members of the forum defending others, not from a defensive of Meteor.
Saying this so it is not assumed that it was just a case of evangelism gone awry.
.
at this point, and the devs who discover it find a lot of joy in building & maintaining apps. Meteor will continue to grow organically, the best kind of growth, and passionate devs write the packages they need which benefits everyone in the eco-system. You can look at some of my post history if you’d like to see some of my comments to clear up old FUD.
