Why not Meteor in 2020?

Planet Earth
41

I think the new shiny syndrome reason is kind of wishful thinking for those of us that love a not doing well in adoption stack. I see elixir users saying the same thing. In reality its always more than that (which you alluded to as well). So far for my shop to be convinced to use meteor its answering three issues satisfactorily ( and that means not as a meteor enthusiast but objectively comparing to what else is out there)

Why should we invest in a framework that only has one core database we don’t generally like in Mongo? (and there are TON loads of developers who feel that way)

Why should we use a framework that has an issue out of the box scaling? an unofficial solution package, to a non enthusiast of meteor, is not compelling. Scaling should be built in or have official supported solutions)

whats the unique selling point of Meteor that we NEED and can’t get from a framework that has more community resources and assistance? You alluded to Django and rails etc. Last night I installed the latest version of Meteor on my home windows desktop which seem to go fine until I attempted to create an app and ran into this error

problem is thats all I could find. First time in years I have had a problem with a well known javascript framework and couldn’t even find at least a hint to the solution. Training , people and third party support has moved away from Meteor. If you are not already invested mentally in Meteor that scares the life out of developers who couldn’t care less about shiny things. So the answers have to be VERY compelling to overcome that sense of a dying framework

4 Likes
42

@manthony so what is your go-to NodeJS framework in 2020?

1 Like
43

Node Back end - NestJS
Front end - VueJS and (recently) Sveltejs

1 Like
44

NestJS seems good, I like it. Relatively new (2017+) it looks like a thin wrapper around the already existing NodeJS pieces (express, passport etc.), little better than just using webpack with express (at least there are some standards), looks similar to FeatherJS in terms of value proposition and I find it interesting that they’re using Gulp as the build system. From the first impression, it seems a viable choice, decoupling the client from the server.

Can you do SSR with NestJS? Edit - It seems SSR is feasible since it is on top of express.

I think it could be a good alternative to Meteor backend, it doesn’t seem to cover as much as Meteor, it doesn’t have Meteor packaging system (and all the third party community packages), it’s not full-stack, and no real-time/DDP solution, no SSR out-of-box, no accounts, no hosting, and differential bundling, no default database (convention over configuration), no community forum.

Are you planning to build multiple apps (contracting development shop)? I mean most folks wouldn’t want to support multiple databases. NestJS would still have scaling issues, at the end of the day, you still need to add more machines as you hit certain traffic, both meteor and nest are using node, the only difference is that Meteor has pub/sub and Nest doesn’t and this is where most of the scaling problems happen.

Meteor seems way more opinionated than NestJS (convention over configuration), it has MongoDB, DDP, and uses WebSocket for RPC, with Blaze as default view layers, while NestJS keeps everything open and flexible, that is why you can have a hello world running example in Meteor but not in NestJS.

I still prefer Meteor simplicity, real-timeness, ecosystem, community and defaults. I think it saves way man-hours than NestJS does. But I think NestJS is a very well designed framework (better than just express + webpack) and might be a good fit for enterprises and dev shops, I think it’s more of competitor to FeatherJS (which I also like) than Meteor.

Got to love the NodeJS ecosystem, every day you discover a new framework! I would like to see NestJS port with DDP on Deno.

Thanks for sharing.

3 Likes
45

Yes not a problem with nestjs. As you stated its built on express but with fastify also as an option. Its pretty well architectured with modularity as a feature. It has Graphql and prisma support as well. so generally not a tight lock in.

However its nowhere as easy/fast to work with as Meteor. Knowledge of Angular is NOT required but it clearly is designed along angular’s mindset and conventions. I still check up on Meteor because we really could do with speedier development time on some of our MVPs

Yes we build multiple apps so its not a matter for us of multiple databases per app. Most developers I know don’t want and don’t see the need to invest in mongo on a per project basis. They can’t think of any thing mongo can do that postgres can’t but see many areas where they think postgres is clearly more suited. So faced with just mongo in a framework as a first class citizen they say - no thanks

Heres the thing with that though. I don’t know of many enterprises and growing businesess that don’t want flexibility down the line. When you first build an app sure - speed of development is a big issue. With success not so much. with money coming in you can afford to build infrastructure that can adapt and grow with the technology. It seems to me that any company looking to make its money from hosting would need to be backing a stack that could inherently scale, grow and adapt. .

those aren’t sweet spots for Meteor as it is now and from what I read even the scaling that is possible in Meteor is more because of unofficial third parties.

I guess what also is puzzling me is I can’t get a sense of what Meteor wants itself to be - a build tool? A prototype tool? for mainline business? Theres been so many twists and turrns and reverses its hard to see the goal and thats affecting marketing because the only real selling point I hear is reactive out of the box which instantly reminds people - scaling issues out of the box.

Apollo as i understood it was to be an integral part of Meteor . That made sense because in my understanding it gave multiple databases and solved in built scaling issues tied to DDP (maybe I was wrong). For a hosting business model a stack you would stay on even after success was and is critical. Now I hear just as much about meteor being just a build tool as full stack.

I guess to put it short I don’t know after all these years what Meteor’s real identity is.

Agreed in regard to simplicity and development hours. I don’t think the argument can be made for community and ecosystem (unless you meant tight integration). the thing is - if I have to move off meteor once I my app is successful - what good does that do for galaxy? So shouldn’t I be going for what MDG was going for - another solution like apollo tight integrated and at core - ala vulcanjs?

3 Likes
46

My opinions on what needs to change in 2020 is largely in line with the roadmap. The problem is that people like to see updates, they like to see improvement and movement. And since the roadmap was released in Jan2020 there seems to be a ton of ??? around some of the most needed features still.

Treeshaking status -
HMR status -
Better PWA tools status -

It seems like the effort around these things is pretty quiet. While I know there is some great work being done by talented individuals, it not hard to see that things like NextJS are constantly shipping huge improvements.

11 Likes
47

Before diving in to all this, I’m just going to say, I still find a LOT of value in Meteor - as is. It’s got a ton of stuff that the other platforms don’t have, or are hard to set up and require a lot of maintenance.

Meteor has so much going for it, it’s just sort of obfuscated. Even during that period when it had the outward appearance of being abandoned (which the new Tiny team has been dutifully correcting), it made huge progress. Look at all the features that shipped during that time: perfect code splitting, modern bundles, constantly updated node.js, cordova, babel, the addition of typescript, and tons of other stuff I’m forgetting.

If I had my way, I’d focus on a central reorg of the way the app’s internals are organized, and maybe work on some splashy marquee features:

  • Separate the build system in to it’s own project similar to the way React Native does it with Metro (and maybe some other parts too). (It’s entirely possible this doesn’t make any actual sense, given the tight integration between build system and server. But it’d be nice to be able to use Meteor almost like a CRA alternative for non-Meteor backend projects more easily.)
    • Part of this could involve a more formal interface between the various parts - which could lead to opportunities to make things more pluggable - imagine if the node.js tier was as pluggable as the front end.
  • Deliver a first-class service worker (hopefully, one built with the extracted build system! That’s not strictly necessary, a statically generated service worker is possible).
  • (Begrudgingly) Provide HMR (hot module replacement) or at least some sort of support for the upcoming react fast-refresh. HMR is a splashy feature that people think they want (and maybe is necessary for tighter integration with platforms like React Native) - but is also problematic in a lot of ways. I end up disabling that half the time on projects that can support it. But people want it, and it sets a minimum bar in that way, from a product perspective.
    • Alternatively, or in addition to - continue to make improvements on rapid client refreshes when working on local dev. Maybe for example, there is a way to disable server builds for files linked by SSR during development, without having to comment out the entire SSR system (this is pretty easy if your SSR code is in a standalone file, but it can cause workflow side effects, like constantly being in your way when committing to git, etc.). We now have --exclude-archs to avoid recompiling legacy bundles, or cordova bundles, etc, but it’d be nice if we could target specific aspects of a build, rather than the entire arch in some cases (like SSR).

Other nice to haves, but not essential features:

  • Better command line output. I’m thinking webpack dashboard type stuff
  • Maybe some tools for generating PWA assets, similar to how Cordova works
  • Better integration options for NativeScript based platforms and React Native (we’re getting there - at least there’s a guide now!). My main goal with the idea of breaking out the build system is to make it more generally useful, but also to make it clearer how we might add extensibility for these types of additional build targets.
  • Tighter, more performance focused integration for Cursors with React, as I’ve mentioned elsewhere (some of us are already working on this, maybe we’ll get somewhere some day).
  • I once thought that GraphGL/Apollo should be more tightly integrated, but I kind of like Meteor’s system. We could maybe use some higher level abstractions on Meteor’s pub/sub, with data over methods. I’ve got a pretty good base for that that I build for PixStori - I just need to work out the live subscription strategy (I’m actually doing that now for a hobby chat project, might even open source that). The idea is to make it all more compatible with SSR out of the box, providing pagination by default, and make it more scalable than going through pub/sub for everything.
  • There was once thought of moving everything to npm. I still like the idea, even if we would have to extend package.json, and/or ship source code, as other projects like svelte are doing. (Or we could jump to deno and support git hosted projects instead - npm can load from git end points)

There are also things I’d like to see - more open ways to debug problems like memory leaks which only occur in production builds on Galaxy, and things like that. There are some things in the build pipeline that might need adjusting sooner rather than later. I’m adding more and more npm packages to the recompile list of late, for example. I’m not sure there’s a better way to deal with this than what I have set up (which would make a good Medium article - I’ll get on that, it’s kind of important for some things), but it’s becoming an issue.

8 Likes
48

I think there are two things that cause the perception of lack of progress, and I think @filipenevola has been addressing both of them.

  1. Some documentation has fallen out of date, and some entire awesome features haven’t had any at all - until recently! There’s been a ton of work going on to bring the documentation up to date.
  2. There hasn’t a been a huge number of announcements about what all is in what state of release. There is now a regular release newsletter, which is a start. We probably need to somehow promote that better, maybe by mirroring those each with a Medium/blog post.
2 Likes
49

I hear your point and indeed the identity of Meteor changed a lot with the years, after all Meteor has been around and backward compatible since 2012 (not just 2017) an achievement in the JS land.

I think the new website capture what Meteor does pretty well, it says:

“Build Javascript Applications Faster with Meteor”

I think it a solid description, I’d say it’s the fastest and easiest way to get Javascript web and mobile apps without sacrificing too much control, it has just the right defaults to get you going.

Meteor is opinionated enough to get you started quickly (as opposed to NestJS for example) and flexible enough to get you to production (you can see some of the example production app here), and then you’ve the Galaxy to eliminate the need for DevOps (although you can host it elsewhere since it is just a Node process). But I worked in large and small companies, I understand the resistance of developers in larger teams to use something highly opinionated, developers, like flexibility (and trendy tech), some might be more familiar with SQL and have a preference for it, so they won’t like a framework that forces them to use Mongo, NoSQL is relatively new and most developers are more familiar with SQL, and if your developer is more productive in SQL, then yes, I’d give them the tool they’re comfortable with. I see it as a spectrum, you’ve things like Firebase at one end where you’ve no control at all, Meteor somewhere in the middle, NestJS is more flexible, Feather is even more flexible and then you’ve Express.

image
image903×211 11.6 KB

But the fact is, Meteor is more productive than NestJS, it’ll save you man-hours (with accounts, real-time pub/sub, hosting, and sensible defaults) however you’ve to agree and stick with its initial choices (especially MongoDB), if you can’t and want the flexibility, then perhaps NestJS, Feather or just plain Express would be a better choice, I personally would go with just plain express, passport, webpack, if I want total flexibility, I don’t see much value in either Nest or Feather at this point, why coupling myself with another new JS framework (2017) with little to add and that could be abandoned (it seems to be maintained by only one developer)? I don’t see much value in NestJS relative to plain express/passport/webpack really, I personally would never use it, we’ve webpack/express and Meteor projects and we’ll explore Deno, I don’t see where NestJS would fit, it is the same reason why FeatherJS didn’t grow, they offer very little to plain express/webpack.

WIth regards to scaling, like I said, if you remove pub/sub then you are dealing with scaling Node sockets, no different than express. With pub/sub you need to scale horizontally quickly to minimize the hit on the CPU (or use something like RedisOplog), again it is solvable and can be optimized with scale. NestJS is not giving you any scaling advantage, in fact, it is offering your nothing for real-time pub/sub or hosting, therefore for me, NestJS is a also a no-go tech.

1 Like
50

There is already an awesome package (that requires some additional work) that does this, “Grapher”. It will be interesting to capitalize that work and try to use it to create some type of queries that can run over methods and over publications just by setting a flag like reactive: true. I use grapher for all my projects now and its an awesome package to get this performance (scaling) improvements by just setting that flag, among many other things.

A pattern like this shouldnt be that difficult to implement and might be a good selling point. “Reactive where you need it” as opposed to “Reactive everywhere”.

2 Likes
51

Not sure, but probably the advantage is that handling http request’s is much less expensive that handling websocket connections for every user. Can’t say exactly how much less expensive, but for some people that small (or big) optimizations might be important.

Having some tests and charts to compare the requests per second (for methods vs http requests) would be something interesting to have for comparison. I saw one chart in a GH issue once, but it was not comparing http to websockets but current WS implementation to uWS.

1 Like
52

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.

3 Likes
53

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.

4 Likes
54

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

3 Likes
55

Definitely Meteor in 2020 and beyond!!! :comet: @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. :heart::rocket:

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.

6 Likes
56

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.

Unless I’m missing something.

6 Likes
57

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…

2 Likes
58

Lock in was referring to this from alawi

“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 .

4 Likes
59

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 :slight_smile:.

1 Like
60

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.

Seriously, “constructive” is the key word here.

8 Likes