I have asked number of developers on twitch about their thoughts on Meteor, their response has been mostly, “The core team left to work on Apollo” it’s like the project is abandoned, other thing is they criticize Mongodb a lot , “lack of relationships” will bite you down the line.
Their opinions of meteor is based on out of date information and lack of knowledge of how Mongodb works.
I’ve used Parcel to bundle an admin-style app built with with Webix (side note: Webix is another tool from the “amazing productivity” category; orders of magnitude faster to build admins interfaces with it than with anything else I’ve tried, and highly declarative no-BS code - search for anything in the top right at https://snippet.webix.com/, e.g. “side bar”); too bad they suck at marketing and open sourcing). Hot reloading was great, and that’s where the comparison between Parcel and Meteor stops, since Meteor offers so much more. I haven’t seen Meteor’s hot reload in years so I can’t make an informed comparison.
Gatsby’s hot reloading works the same way, preserving scroll position and component state. Very convenient indeed.
For me it would be “official” PWA support, though according to the last blog post, that’s coming.
Exactly. Sadly, lots of uninformed opinions and popularity bias (though not entirely unwarranted, given the risk of libraries falling out of maintenance) in the JS ecosystem.
We have one production system (built in 2016/2017) that’s full Meteor and Blaze, including mongodb, pub/sub, accounts, and everything. And it works great, getting to ~100k users / month and still doing fine with a single EC2 node as an app server.
For our latest project however, I’m just using Meteor as a build tool, and use React with a REST API provided by feathersJS connected to a postgresql backend. It’s a great build tool, but leaving the comfy confines of the Meteor environment reminds me just how many problems Meteor solved years ago that the JS community is still grappling with today.
It’s 2020 and I’m still dealing with rolling my own accounts system. And reading tons of blog posts and articles about how to manage data access with a redux store and a REST API leaves me wishing for the simple pub/sub mechanism of Meteor that automatically provides local caching, expiration, record merging, sync, and optimized network transfers without a single line of extra code.
I have a serious case of javascript fatigue, and it’s annoying to see all these shiny new toys that everyone keeps talking about while basic functionality like accounts systems and data management are considered too unsexy for frameworks to focus on. Leaving complex data management optimization, or account security best practices, as an “exercise for the user” while touting a few tenths of a second reduction in time-to-paint benchmarks seems ass-backward to me.
So why am I not using Meteor fully? For me, it comes down to the ability to build a team. In 2016 / 2017, it was fairly easy to find JS developers who were experienced with Meteor. Now, it’s extremely difficult. Even previous developers that we worked with, when we get back in touch with them about working on new stuff, tell us they haven’t touched Meteor projects in years and have moved on to other frameworks. I’m scared to start a new project with Meteor and then be unable to find developers. Meteor is different enough (especially with the way pub/sub and reactivity works) that it takes developers, even ones comfortable with JS, at least a few months to really grok how pub/sub is different than REST APIs. While I’m willing to train new developers, I can’t be sure they’ll actually become good Meteor developers and unlearn the principles of the other frameworks they know.
That’s my biggest reason for “why not meteor in 2020” 
But to that, I’d add maybe a controversial idea: 90% of websites these days don’t need Meteor or even much of javascript. Before Meteor, I used Ruby on Rails to create static sites. And again, it’s amusing when people write React/node.js SPAs that are actually pretty basic static websites. Even many “advanced” websites are often primarily a static website with a few interactive bits that can be easily managed in a couple of limited scripts and AJAX calls.
In fact, for my current site, I wrote my prototype in Rails, because it’s an even better ecosystem, with well maintained gems for just about every problem you have, and only recently rewrote it in React when we better understood the features our early users needed, and decided that interactive and dynamic features were truly necessary and made an SPA worth the hassle.
So perhaps Meteor is stuck in an anti-sweet spot: those who chase shiny new features without regard to utility seem to hop to the latest greatest thing. And those who want a well-engineered full stack solution with a robust ecosystem choose Rails / Django / Java / etc and other older technologies for the 90% of projects that are little more than CRUD frontends to a big database. Meteor is stuck in the middle: not shiny and new enough (any more) to attract early adopters and momentum chasers; not old and established enough (yet) to attract the stable and boring developers.
The good news is that, IMHO, every framework goes through this transition. I think as long as the meteor ecosystem continues to grow, focusing on solving real problems that people have, then it’ll soon cross that valley and be seen as a stable, solid choice by the vast majority of developers that prefer to live a little further away from the bleeding edge.
Rebuild it from scratch in TypeScript on top of Deno, rebrand it “Spaceball” or something, and problem solved! 
@dandv I agree, although I’d prefer PlutoJS over Spaceball ;), it would be great for the Meteor community to experiment with Deno and attract the early adopters because it is a technology worth investing in, not just another hyped JS framework, and I think the Meteor community has a lot to offer on that front, as I explained here.
However, I’d suggest to ignore the momentum/hype chasers, they will spend their entire career chasing with nothing to show, and they are not worth the effort.
@mraju thanks for sharing your thoughts, great read.
Love your post @mraju, hope Tiny is reading this as well (@matthollingsworth), as this seems to be mainly a marketing problem. I agree anno 2020 there is still a space for Meteor (provided it continues to evolve), we just need to lose this image:
I’ve listed some other misconceptions I often encounter in the field here: Introduction, and favour to ask the community! - #19 by rijk
This. Even without accounts, when I’m working in projects that don’t have a Meteor backend and I have to do API requests back and forth to fetch and update data, managing that data in component state manually, feels like going back in time for me. “Ass-backward” is the perfect word 
While I agree that Meteor doesn’t need to change, it works fine, we also should acknowledge that the bar in the industry keeps getting raised. Proper, Parcel/Next speed HMR is more than a ‘shiny new feature’, in my opinion this is now table stakes and Meteor needs to keep up.
That said, implementing this would not only get Meteor back to the bleeding edge of dev experience on all fronts, but could also help shake this “Meteor is no longer maintained” image. So it might even be double bang for your buck
This Webix thing looks very interesting, I didn’t know about it. It even has an open source built-in Meteor real-time pub/sub integration! thanks for the reference.
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
Node Back end - NestJS
Front end - VueJS and (recently) Sveltejs
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.
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?
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.
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:
--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:
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.
I think there are two things that cause the perception of lack of progress, and I think @filipenevola has been addressing both of them.
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.
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.
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”.
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.
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.
