We need to get passed that “Meteor was still a thing” attitude that I often hear 
anyone interested in making fresh tutorial sites and youtube posts?
2 Likes
Actually the issue here seems deeper then Meteor given the latest NodeJS surveys. Somehow the majority of the NodeJS ecosystem believe that it’s better to have many small packages than any opinionated framework. Also NodeJS ecosystem got dominated by front-end libraries and large cooperation stack.
I’m not really pleased by that mindset, given that node allows you to write both the client and the server in theory it should be the ideal ecosystem for the web startups and entrepreneurs, but practically it’s not, somehow developers believed that stack that worked at Facebook such as React, GraphQL, Redux and webpack are also the go-to tech for a new startup and medium size business. Both Ruby on Rails and PHP has a great framework for entrepreneurs, NodeJS has Meteor, the difference is that with RoR and PHP, the developers and the entrepreneurs wholeheartedly supported those frameworks because they know they don’t have the budget of large cooperation like facebook so they support those tools for themselves and their fellow entrepreneurs, they’re all on the same boat, yet somehow in the NodeJS developers are convinced that the facebook stack is the starting point when it’s obviously 3x the cost/time of doing it even in PHP. But Facebook is the king of the hype and the herds. I think any entrepreneur with business sense should rally behind a framework like Meteor/Vue because they simplify the process and reduce the number of decisions needed to generate value to customers.
8 Likes
Thanks everyone for the comments. I got from a different area IT and pre-made solutions are always preferred when faced with a business problem. I get it learning the new shiny toy gets you a cool job at a tech company, but I’m more interested in generating revenue than learning the next new tech stack. I know a few laravel developers who do very well for themselvs and can launch new products that can make up 5-10K a month in sales if its the right project. If it fails they shut it down and move to the next idea. All the built in tooling and deployment options make rapid development so much eaiser. I’m just not sure why in the javascript world this hasn’t caught on. Are more people interested in the tech vs the value you create?
1 Like
Then I think you’re in the right place 
1 Like
Im’ also saying this as someone who got a lot of Cisco certifications and got to the high bill rate, and one day I realized if I put that much effort into learning asterisk, php, and other open source I could have made way more $$$$ and way higher customer satisfaction with less of my time being devoted to dollars for hours and more value for the customer. This is my take away after being in tech almost 15 years.
6 Likes
I can think of few. The thing is, you approach it from a business point of view. Most developers don’t. Business means getting profit and reducing TTM (Time To Market). Software development is essentially the same, because business software is of course being built for… business right? So what is the problem? The below picture illustrates it pretty well. It originates from Martin Fowler’s book Refactoring:
As you can see it traditionally takes time for a good software system to become productive. It takes planning, hard thinking, talking, learning, discussing, and a lot of refactoring. Meteor in that sense feels counter intuitive, because a lot of that stuff has been done. Now suddenly the developer has to focus on the actual problem domain. A MVP can be profitable within just a few days with Meteor without having to boilerplate, glue, build API’s, decide on JSON structures, caching and clientside storage + reactivity. Especially when you use existing design systems like Bootstrap, Material-UI or Vuetify. I’ve built systems with Meteor that became valuable after just a few minutes of programming.
Business people love it, but developers get scared. Its simply too good to be true!
Reason 2: Meteor in context
Meteor on its own provides a huge business value. It also makes a lot of developers very happy. Development in Meteor is lovely - that is - for as long as you follow the Meteor approach to handling data, transpilation, API requests, the database and hosting it. Going against the opinionated flow of Meteor might get you in trouble - especially if you don’t have a lot of experience. Funny thing is though that Meteor simply follows some pretty good standards so there should be no reason to go against it.
In real life, software systems are part of a bigger ecosystem of tools. The simple scenario is where Meteor would work as a SAAS Dashboard where customers log in. This is where Meteor shines, but almost always there would be a need to build a simple static website that acts as the landing for prospects. I’ve worked at companies that had dozens of landing pages and just one platform. Today its less of an issue, but Meteor was not always good at static site building and things like SEO, multi-site support and had quite a bundle size (for example Minimongo is still part of the bundle).
Another example is the API. In reality, many bigger organisations have API’s all over the place. To leverage Meteor’s pub/sub system you will need a way to make requests on these API’s, bundle it and publish it in your publication. That’s why MDG came up with Apollo.
Reason 3: Meteor had its issues
What is still a big strength, but becomes less of a thing since (MDG tries to move away from it) is Atmosphere and its smart packages. While its a very powerfull way of adding isomorphic packages without having to configure anything, it is not what the javascript community wanted. NPM became defacto and therefore Meteor had to open up to NPM packages aswell. NPM support was not that pretty just a couple of years ago.
The build tool is powerful, but ‘was’ slow and had some issues. Many potential Meteor developers that tried Meteor stopped using it, because they got stuck on the build process (also in dev mode). “There is something broken, but I have no idea what”. Most of the Meteor magic happens in Meteor’s core. Good luck figuring out what went wrong if you wernt the one building or maintaining Meteor. What most people don’t get though is that the opposite is also true: “Good luck building your own flawless zero config platform using webpack”. Developers unfortunatly take a “Do it yourself” stance, since that’s how most developers became developer in the first place…
Not only that. There is the Dunning Kruger Effect - A coginitive bias that makes unexperienced developers think that building their own system would be possible within short notice and with just their own knowledge. They forget that MDG is a team of bright people, each with their own strengths and knowledge that work full-time on this platform. Good luck…
Reason 4: Blaze was the only choice for the clientside
Blaze is a very powerful view layer. Besides Vue I personally find it the best rendering framework of these days. Even better then React, simply because it works so well and intuitive. Not everyone is fan of Blaze though. To give an example: When React came in the picture, people wanted React, but couldn’t, because it wasn’t supported. Luckily it didn’t take long for MDG to realize that going against the greater JS community is not a battle they could win so they decided to make React the first class citizen of Meteor, causing a small uproar in Meteor’s community, because what about Blaze?
MDG did well here. They’ve made the right prediction and I did some very successful projects with React. I’m also very happy to see that Meteor now also supports Vue.
Reason 5: Marketing and communication
While the technical side of Meteor is briliant, there is almost no communication to the outside world on social media. The javascript community did not hear about Meteor’s adoptability that kept it bleeding edge even though there was a revolution going on in the Javascript landscape. For me as Meteor power user the transition from ES5 to ES7+ and the adoption of new concepts like reactivity HMR was flawless!
The community did not hear about Meteor’s legacy builds and Meteor’s zero config React integration, its flawless integration with Apollo and capabilities to build a simple Rest API using Webapp.
There is many more to mention, but I don’t think the platform Meteor is the issue here. Most issues are solved and its now a very stable platform. Its the Javascript community and how developers look at developing software. That’s why we need to step in. Promote Meteor, share your love, your success stories, share how Meteor helped you and don’t listen to people that laugh Meteor away simply because they didn’t try it.
23 Likes
Thank you for the thought full reply. I think you hit the nail on the head with it just being too easy and devs are left to actually think about the business.
We’ve been using Meteor to build an enterprise data platform, and we’ve raised over a mil to do it in the last year. We’ve been using Meteor almost exclusively for the last 3 years. But Meteor fits perfectly in our case. We developed a real-time database platform that’s easy enough for employees to use, they don’t need an IT team to run SQL queries or make custom interfaces for finding relevant business information. We also are using GraphQL and Apollo to connect to different database systems. I don’t personally get the anti-Meteor sentiment. There’s nothing wrong with it. It cuts down development time and costs substantially. I’m the CTO and have been developing products for 13 years. I used to work with MySQL and PHP back in the day. I could maybe understand if you don’t need real-time, or the bulk of your app needs to work with a different database other than Mongo, or if you aren’t making web apps but instead websites that need fast startup time. In those cases, Meteor isn’t great. But in my opinion, most reasons poeple give for not using it are because they want to find a reason not to use it. Want to control every aspect of your stack? Sure, use webpack, node, some weird pub/sub thing you find, express, and whatever other concoction you want to throw together yourself if you absolutely need total control over every aspect of your stack, because sure you might be as big as Facebook some day. But really? Ask yourself.
It’s a short sighted way of thinking. The cost savings alone and speed to market will more than make up for any insufficiencies in the tech (not that there are many). And you can use that money to deal with any scalability issues when they happen. But you’ll never get there if you bog yourself down in the details.
20 Likes
Agreed @michaelcbrook and congrats on your success!
Just one comment regarding the startup time, I think by leveraging SSR/Dynamic Imports you can get an initial render below 1.5 seconds, we’ve relatively large apps that loads with the data in less than 1.2 seconds, without SSR/Dynamic Imports it used to be 4 to 5s.
Also, I think the value of of a framework like Meteor extends beyond real-time. The whole philosophy behind Meteor is convention over configuration which borrows from Ruby on Rails, traditionally in every programming language and ecosystem there was a dominant framework because frameworks abstract common patterns, reduce the cost and time to market, so unless someone has a large budget, surplus of time or want to do something radically different then there is really no justification for re-inventing the wheel, it’s not just re-implementing those patterns that is costly but also maintaining them. That’s why NPM is full of abandoned open source packages, because maintaining any code beyond the hype and the fun require long-term commitment and discipline which is why I’ve tones of respect to Benjamin!
That’s why I also stated that, to me at least, it seems that the NodeJS is still not a mature ecosystem and many developers are just experimenting. All the large players (Uber, Wallmart, Netflix, Facebook etc.) created their own tech and stack. But when more entrepreneurs/SMB get into Node, this kind of churn and re-inventing of the tech will make much less business sense and will be reduced, I hope!
@michaelcbrook I’m curious what front-end library are using for your stack?
4 Likes
We’re still using Blaze to be honest. It works well. It’s easy to use. It’s still, in opinion, the easiest frontend framework to use when building in Meteor. And I’ve done my homework. React, in my opinion, is still very complicated and is difficult to maintain, especially when you have a company with multiple developers and another developer needs to work on something made by someone else. I’ve looked into Vue with a lot more interest. What I like most about Vue is it doesn’t require a build system. So this is not really a big benefit when working with Meteor, but I like the idea that I can cross pollinate code between a Meteor app and perhaps a more basic frontend website that could benefit from having reactivity, but has an unsophisticated backend and doesn’t need all that Meteor offers. But we haven’t gotten to the point of actually adopting it yet in our company. For the foreseeable future, we’re still sticking with Blaze for our core apps.
But this supports this theory I’ve had that maybe we’re seeing a lot more packages go unmaintained nowadays mostly because of the age of software. I can think of many packages on NPM and various software that is no longer maintained (kind of like Blaze) because it’s simply “done.” It doesn’t require many more improvements. There’s a growth curve to everything in life and it moves not exponentially but in the form of a sigmoid. You find this in business but also in nature. Biologically, as humans, we grow rapidly in the first dozen or so years of life, but then our growth slows. It would be unreasonable to expect technology to grow counter to the laws of nature. The way growth can continue, however, is with major innovation. We would see a “step up” in the sigmoid curve in this case. I liken this to Apple’s release of the iPhone. But every NPM package and every piece of software will not hit a major technological breakthrough, nor should they always. It’s more the exception than the rule, and it’s often the combination of apparently separate pieces of technology that induce a technological breakthrough. And that’s what our jobs, as programmers, are. I get frustrated sometimes too when a package is incomplete or not maintained, but 9 times out of 10, someone else has already forked it and made it better or made another package that fits my needs. If no one has, well then that’s my opportunity to make one and share my creation. This brings us all closer to being able to combine technologies to come up with those massive innovations. But this is largely dependent on your unique perspective of the problem and the solution maybe only you can offer. I can’t expect the computer chip manufacturer to be an expert in making phones. And there’s something to be said for specialization, which projects tend to lose sight of when they try to artificially “innovate” just to inch the curve up. There’s also the economics of it - many developers are not getting paid for their open source work. But this improves with the sharing economy. The burden of work is “distributed”, lowering the opportunity cost of each contributor. But this is why it’s important we don’t solely rely on others to do the work for us. The machine moves forward only when people contribute.
Like a lot of things in life, the progress of an ecosystem, of a technology, of a society, of a species largely depends on your answers to two questions: What am I looking to get out of this? And what am I willing to give?
12 Likes
I’ve built a few client projects with Meteor before and I’ve always loved the direction where it’s going.
With that said, the stack I’m using for my startup is Vue + Express (serverless) + Airtable. While airtable is slow and not so much a replacement for mongo, it allows everyone else to quickly enter in stuff in the DB (create lots of new content) right out of the box, and the site can pull it right in.
When we add auth, might consider using meteor again. Firebase seems unmanageable in the long run. Meteor still feels like a black box to me, even after having built several sites on it. I didn’t like how the front and backend were so tightly coupled.
With that said, I’m exploring Prisma + GraphQL at the moment. Will see how that goes!
Serverless is no-go for us since we need to have control over our backend to serve enterprises.
Airable doesn’t sound to be useful for anything serious and frankly I dread spreadsheets, there is reason why excel hell is a thing, the last thing I want to have my databases as as spreadsheet, in fact spreadsheets used to be the storage mechanism before databases got invented.
Firebase/Prisma are both backend as a service and again it’s a no-go for us due to complete lack of control over the backend, but I think those are good if you want to get get a mobile app to the market quickly, so you need to pick the right tools for the job.
That’s an architectural choice, you can just use Meteor as a backend with GraphQL or RPC end-point and build the front-end with something else.
Also I’m not sure how you’re managing so much churn of different tech stacks while serving clients!
2 Likes
For sure, there are so many variations / stacks / services it mostly comes down to personal preference.
The stack running costs $0/mo for me, and allows other people to collaborate with me (I’m the only dev on the team, everyone else is a journalist or biologist). We’re running a small project, not Airbnb. But I’m about scale it up, which is why I’m moving some aspects away from Airtable (they’ll still use it, more or less as a CMS). Btw do you know of any Airtable-esque interfaces for Mongo? There’s a reason Airtable just got a huge funding round. They make stuff fast, easy, and reliable.
For Firebase/Prisma, totally agree — what I give up in control I gain back in speed and cost (and frustration, since I’m the designer/dev on the team, and we run on a $0 budget).
Interesting using Meteor as backend. Do you run a Node server with Meteor? And Meteor does the mongodb wrangling for you? Does Meteor act like an Apollo backend (since it’s the same team) and you can just run GraphQL queries? I’m gonna look into that. There are way too many tech options out there lol. I just want something low cost, cheap, fast, for a chat-like app. It’s Firebase vs. Meteor vs. Prisma right now.
Churn of tech stacks — basically I was doing Meteor/React for a while, but that was slow to dev (ugh React) and costed money to deploy Meteor server. For my latest project I’ve moved onto a completely free low-tech stack (Vue/airtable/serverless). Basically airtable so I didn’t have to build any backend interfaces lol.
1 Like
Ah, now it makes more sense given the background and constraints you’re faced with.
Yes exactly, at least in that case you’ve control over a backend that you can build on, perhaps you can ask your biologist colleague a 1$ each to afford a 5$ droplet on digital ocean 
but yeah they won’t be able to just modify the data like a spreadsheet also if this something short-term or a POC maybe serverless make sense.
Ok so I’ve had trouble figuring out the difference between Apollo and Meteor. If I just run Meteor as purely a backend, isn’t it more or less like Apollo?
I remember super frustrated back in the day when Meteor would change/break a lot, which is what led me to look at other stacks. My relatively-simple Meteor apps would also be absolutely massive for some reason.
(As for cost, if I used Prisma, I’d have to deploy it on DO or Heroku anyway, so oh well)
Well I don’y really run Meteor that way, I’m using DDP/RPC. But one of the directions (although it’s not there yet) is to make Meteor an entry point to GraphQL using Apollo, so yeah you’ll be just using Meteor as a build tool and a server and Apollo to serve the GraphQL requests.
I’m not sure when did you use Meteor it but I think over the last 3 years it’s been stable with new features added in backward compatible way. With regards to being massive, for me it’s mostly the client code, specially with React there is a lot of code to write and libraries are changing very quickly. I’ve not changed any backend code since I start using Meteor due to an update, but with React, every few months there is a breaking change.
1 Like
Yeah it’s been more than 3 years… I’ll definitely give the latest Meteor a look.
Interesting about the direction of Meteor an entry point to GQL w/ Apollo. That’s exactly what the Prisma team is attempting, and I think it’s great both teams are going in that direction. Thanks for all your help!
2 Likes
There are a few reasons people avoid Meteor:
It does a lot out the box which is awesome for getting started, but moving away from. The defaults isn’t always easy.
For example, if you want Postgres or Mysql it’s not going to work easily out the box. Probably just better not to touch Meteor if you want to use sql for example. This applies to a lot of items.
Mdg has mostly abandoned Meteor themselves. Probably didn’t generate the revenue for they were hoping for so they have a minimal number of developers now focused on it.
Scaling is a headache. Because everything is real time out the box you have to start worrying about scaling once you hit 50 concurrent users. The full stack reactivity Meteor provides is awesome, but a huge burden at the same time and most devs would rather do without it and add real time for the one or two items that need it and not kill their servers with everything being reactive.
As for the question of getting an mvp ready in 1 or 3 weeks, a lot of people would choose the 3 week option if it gave them a more stable platform long term. Migrating away from Meteor once your project is 6 months in is not going to be fun. If it’s a question of doing things quickly and badly or a bit slower but well, a lot of the time the second option makes more sense. Especially if a project is going to take a few years. Get things right from the beginning and don’t build up a huge amount of technical debt.
Even the Mdg focus is nowadays on apollo server and client. And not meteor publications. That should really tell its own story.
Yes, it’s the same criticism being said so many times in different ways. So please allow me to give you slightly different perspective on those.
Agreed, if you don’t want MongoDB don’t use Meteor, that’s very clear.
Now here is an example of black and white thinking, MDG is either fully invested or not invested at all, but the truth, as stated by them several times, is somewhere in between. They’ve clearly stated that they’re committed to Meteor long-term and furthermore they’re using it internally however it’s very clear that they’re investing in Apollo and other tech and that’s good, it ensures the company is here for the long run and that the framework and community are mature enough to stand on their own feet.
Scaling your own cluster is headache period. But scaling socket real-time application is more challenging, I agree. But I’ve done performance testing on Meteor and bottlenecks came from MongoDD and CPU but they were solvable. On the flip side, you do have a community who managed to scale Meteor, you’ve monitoring tools and tons of content so when you start to worry about scaling like Facebook you’re not alone. And I think you managed to scale it yourself as well, but yeah it does have extra layer of complexity (real-time sockets/fibers) to worry about.
Yes, it’s desirable to have control over the entire stack, but at the same time the economical reality dictates some trade-offs. Letting go of low-level express or webpack config for quick to market and more features is a tradeoffs that make business sense.
So to summarize, the statements that it wont’ scale is simply not true but yeah you need to some effort and knowledge to scale it and if you don’t want to worry about scaling early on then go serverless or use something like Google App Engine. The other statement that’s abandoned is also not true, I mean the folks from MDG have stated several times they are committed long-term but you are right that it’s a genuine concern.
The real concern is that for people who go with express or build their own stack, underestimating the complexity, time and effort to get basic features like pub/sub, authentication going and copy the Facebook stack in the hope of having Facebook scale when they’re less then 5 people company with few months of runway.
It’s not a perfect framework and you did capture the general fear but in my opinion it’s the best of what Node has to offer and it’s the ideal framework for entrepreneurs.
5 Likes
Here is a screenshot of 1.5k actual concurrent users on a server, not many but surely more than 50. These are actual sessions simulated by puppeteer headless browsers. I ran out of test servers because they’re expensive to run since I’m opening too many chrome instances but the CPU/Memory usage is prepredicable.
4 Likes