Let me tell you about my crazy experience with Meteor.
The year: 2015. I had just graduated from Dev Bootcamp in NYC and was desperately searching for my first engineering job. I came across a job posting on Craigslist for a startup that sounded promising. It was one of the few interviews I could even get. They told me next to nothing about the job, and literally nothing about the product, except that it would be built with Meteor.
The whole interview process was the weirdest I’ve ever been in. The two founders brought in four candidates (myself included) into a single conference room and told us they were going to hire two of us. They then went on and on for an hour telling us about how successful and genius they were, and that they were going to be building something 10 times more successful than Facebook. The whole interview was essentially a lightning round of JS trivia questions (type coercion edge cases and such). First to answer correctly got a point and so on.
Naive me, I remember building out a whole Meteor project trying to impress them. They took about three weeks to tell me that I had gotten the job and they were ready to tell me what the product was, I just had to sign an NDA, get it notarized, and hand deliver it to them.
Before I could deliver the NDA to them, they told me the terms of my offer—$13/hr at 20 hours per week. No benefits or equity, obviously. BUT, I would get 1% of any profits.
Making minimum wage in NYC with no potential for upside gain was not in the cards for me, but it did drive me to learn about Meteor—a technology I wasted about two months with before abandoning because no one in their right mind was using it.
Ha looks like I dodged a bullet. I graduated Dev Bootcamp SF in 2014 and one of the few interviews I could get was a shop that claimed to be "Meteor Pioneers", their entire stack was Meteor. They ended up ghosting me in the final round and I ended up landing a job at a python shop.
It’s probably neglectable anyway. There were a lot of attempts to build FB competing products in that timeframe, I remember running into some simila job posts which of course I ignored. It was like a social media gold rush. Most of them were bases on a technical solution without much business foresight.
Feeling like a rockstar while developing. Impressing the colleagues and clients with how amazing functionality I could produce in so little time.
Then the absolute horror of production traffic hitting the system and everything grinding to a halt. If I remember correctly, the resources required by their reactive data model scaled up significantly both with read connection count and write activity. And I could not do a damn thing about it without a complete rewrite. First and only real case in my career where I simply could not solve the problem, not even a small part of the problem.
Oh, and it also let me experience running Mongo as primary data source. A lot of experience gained courtesy of meteor.js, for sure, but I'd prefer it to stay in rear view mirror for sure.
I ran into the same situation multiple time and was never able to find a solution besides throwing more money at servers. That might be due to my own lack of knowledge about running servers and performance optimization as I was (and still am) a front-end person first and foremost.
This is perhaps one of the most misunderstood and misused quotes I know of. It doesn't mean what people think it means, yet I hear it misapplied at least a few times every year.
(The quote has to be understood in its original context. It isn't really about performance as such, but about maintaining degrees of freedom and development flexibility until you understand the problem you are solving and can commit)
I've been on the other end of that story quite a few times - being the person having to point out that "this isn't going to work even for normal loads", and having people argue that caring about performance is "premature optimization". And then see them crash and burn because of the arrogance of not testing their assumptions before betting the farm on them.
I think the path of least conflict is usually to encourage people to develop quick benchmarks and test their assumptions and then ask questions about how they plan to address any problems that identify themselves. If people are receptive another useful piece of advice is that they shouldn't be afraid of just starting over if it is really early in the project.
It wasn't that bad? Me and another guy made a non-profit platform with Meteor that got Hacker News front page traffic; we spun up like two instances to handle it I think. I wonder how much production traffic you were handling?
I don't remember the specifics, it was around the 1.0 release of meteor, so... eight years ago? But the core concept was sports betting dashboard, live updating the odds. So updates were coming in thick and fast, hundreds of betting positions would change every couple seconds as bookies would try to boost their margins during games in progress.
In testing it was beautiful. With simulated updates on local machine, instant updates. Instant. Everyone's happy. Deployed to the server, and connected to the data firehose? Feedback is still okay, with just the clients employees and us browsing every now and then. Slightly slower, but hey it's on a remote server now, that's got to be the issue.
Went live, client ran the advertising campaign, and users flocked. Thing is, they flocked all during the same time, when the games were on. And updates were coming fastest while the games were on. Both of those things multiplied together to firmly peg server CPUs at 100%. Clients were also not thrilled about throwing more and more boxes at it to try to stop the bleeding. Resource consumption was going up geometrically with user count, something I hadn't seen before with any technology stack.
All in all, it taught me there is no such thing as free lunch. You pay somewhere - worse developer experience, more resource requirements, development costs and time. No such thing as a silver bullet.
Also, keeping data in sync without transactions in a Mongo cluster provided endless educational entertainment. We needed to process incoming payment confirmations from the bank, and update the "credits" balance of users. Entirely too often one of those would fail, especially under load. I hear it's gotten better, but I still refuse to treat Mongo as anything but a non-authorative cache since then.
Not my experience. And interacting in the HN comments tells me others do too. Can you point to a current example of an “HN aggregator bot”? I’m assuming you see them often?
I prefer simple tools for just this reason. I never used Meteor (for fear of what you describe), but I’ve used plenty of 3rd party libs / tools that I was told “do 90% of what we need; just wrap it and do the remaining 10%”. The 90% was usually the easy part, but often had flaws that were a nuisance to (or impossible) work around. Or they’d stop getting maintained and decay over the years.
Would be interested in peoples thoughts on what realistic read/write pressure is a good level to test at, to feel confident in real-world performance... [ if not HN level dos'ing ]
I’m not sure whether I’m understanding those numbers correctly, but servers are expected to deal with many more zeroes than that. 10 writes/seconds reads like a meme.
Ten writes per second is abysmal, considering that even consumer NVMe SSDs have several hundreds of thousands of random write IOPS.
At the end of the day though, what matters is whether or not your application scales appropriately for your expected workload.
If your expected workload is ten writes per second, then trying to get every single bit of performance out of the hardware is probably not time well spent. If you're having to handle thousands of writes per second and you're getting ten writes per second per server, then it's probably worthwhile to look into what's causing that number to be so low.
You can horizontally scale Mongo via sharding and you can horizontally scale meteor pubsub with redis and related libraries as of like 2015. Depending on when, you had a lot of options. :P
100% agree with this post. I also co-authored a book about Meteor[1] and, to me, it's really the "framework that got away." Modern React/Redux/JSX/Next/etc. completely sucks compared to how awesome and seamless Meteor felt when it first came out. Surprised you didn't mention anything about RPCs. Having methods that can run on either the front end or the back end with basically zero boilerplate was an incredible idea which unfortunately never really got traction. A few comments:
I think that HTML over the wire is still pretty context-specific. There's even modern cases where I think it makes sense to just render whatever blob you get over the wire.
I don't think that "Database Everywhere" deserves a thumbs down. It's an insanely useful prototyping tool, genuinely useful when trying to replicate reactivity, not to mention extremely performant for all that work it actually did (it sort of "hacked" this by hooking into Mongo's oplog). Meteor's mistake was, imo, mainly deciding to do this with MongoDB instead of a SQL variant.
I think I'd probably give "Embrace the Ecosystem" a shrug. The modern-day "Ecosystem" is a mess. To start a project, you need tsc, but wait not that version of tsc, and you also need React, but now you need Webpack. And also a CSS plugin, but also a SASS plugin. Oh, an SVG plugin too. But now you have a conflict. Have fun. I actually prefered using Meteor's more limited ecosystem where everything just worked out of the box.
Also no mention of CoffeeScript (which was heavily pushed); that deserves at least two thumbs down.
Agree with all your points, think it's a bit subjective, but yeah... I loved how if I wanted to install my meteor project on a new machine it was just a couple of commands and everything including the database was ready to go. Contrast to these days, where you have 15 microservices, a dozen docker containers, ten million npm packages... :)
Basically it was a huge trade off: a 100% batteries included product that worked very well together because it was all made by the same people, Vs. the npm "bring your own whatever and wire it all up" approach. There are big pros and cons to both.
I think the comparisons to Rails are interesting, but actually not entirely fair either. Rails will always be primarily a back-end framework, no matter how much stuff is bolted on to its highly opinionated (of course) front-end toolchain.
Meteor was full-stack from the ground-up. In fact, Meteor was just "stack".
Meteor RPCs look cool, I've only started to see this elsewhere in frameworks like Solid.js. Was Meteor the first web framework to do this kind of seamless backend calls from the frontend?
It was certainly the first big framework to do it. The phrase at the time was "isomorphic javascript" - i.e. javascript that could run the same on server and client.
While today I might re-use _some_ code, like helpers or TypeScript types for API responses, by and large I feel like that dream is unrealized and probably a never great dream in the first place. In practice there just weren't a ton of wins from doing so, as there were not many cases where you needed the same code in frontend and backend.
This is not at all what RPCs were. And plenty of frameworks use "isomorphic javascript" (i.e. Javascript on both the front-end and the backend) -- Next, Nuxt, and many others.
Thank you for the correction, apologize if I muddied the waters. I didn't use meteor and only saw it from a distance. I do however use Next/nuxt/etc, and you're right that SSR/SG is a good counter-example to my point. I will say that outside of SSR/SG, isomorphic javascript isn't used that much in my experience. But it is a great counter-point for sure.
Wow Sacha Greif, a name I haven't seen in a long time!
Thank you for the good memories, I know every thing and everyone you talked about in this post. BTW, back in the days I created 2 very popular Atmosphere packages
I wish Meteor succeeded in becoming more mainstream, and the MDG didn't abandon it so quickly to go after the new shiny tool that was GraphQL
Nowadays, there is still no equivalent framework in the JS world in terms of productivity
Author wrote a very successful book on the Meteor framework, happens to be an amazing designer, was a fixture in the Meteor community, and yet manages to be completely clear-eyed about the lifecycle of this pioneering effort. Maybe the best postmortem I’ve ever read.
That's very kind of you to say! Personally I would love to read something on this topic by members of the original Meteor team. Although I was a "fixture" in the community, I was also an outsider compared to actual MDG staff, so my understanding of the actual situation on the ground was always a bit one-sided…
I still maintain a product with a few $100K/year revenue written in meteor. We long ago ditched the backed/DB layer but the frontend has aged fairly well. It is still fast and responsive. I will never create another product in meteor but I don't regret using meteor for that product. Coffee script on the other hand.... :P
I built a project that supported my PhD in Meteor.
My memory of it is that Meteor is fantastic, but Mongo is a nightmare.
I spent hours carefully designing my database so I didn't need joins and adding indexing, but it never ran as fast as unoptimised MySQL, and had vastly less functionality.
Mongo was literally all hype - I find it impossible to imagine the use case. A salutary lesson in how rubbish the latest fashionable thing can be.
Real-time by default for everything is really a fun way to write web apps. A little bit inspired by Meteor we've build Thin Backend, which provides a real-time API for querying data and writing to a postgres database. If you're interested, check it out at https://thin.dev/ or check the demo video https://www.youtube.com/watch?v=-jj19fpkd2c
Most of my startup was built on top of Meteor back in 2016-2018. Although I wouldn’t make that choice again, the productivity and “wow factor” we could do with so little always impressed our customers.
The coolest thing about the text is seeing what the original Meteor team is doing nowadays. They went to build companies like Apollo and Chromatic and found new tech like Vue.JS and Storybook.
Overall, I feel Meteor was too ahead of its time - being early and being wrong are the same thing in our world. Nonetheless, if you build a great team filled with passioned people, you eventually find your “thing”. Its just a matter of time, effort and iteration.
Being too ahead of its time reminds me of Google Wave, a similar "reactive" application that was just too much, too soon; performance wasn't good enough.
Wow, Sacha! 10 years already. Meteor was one of the first Javascript frameworks which gave me joy. Maybe the closest to that today is Imba. Realtime all the time was performance heavy for sure but so much fun. I recently saw https://liveblocks.io/ which is trying to do realtime primitives for the current wave. Discover Meteor was one of the first "modern" programming framework books I bought and I still remember the book built around an example, something which was missing from a lot of books in that era. Modern JS is a complicated mess. I would love to go back to that era where people were trying to do magical things with one api call. Hooks in React is more complicated than a whole library from that era. That is not a good thing. In 10 years we should have had far more higher level tools. Wish you all the best. Meteor gave me a lot of joy. Maybe I will try building something with it again to see where it's at.
Too long ago, I had written a lunch-planner as a joke to mock how much time we were losing by discussing what to eat at the office (and it even was used in a non-sarcastic way, to my own amazement), and I used meteor because it just worked.
Unfortunately I don't, it should be however easy to start by cloning and running meteor (npm i -g meteor, to install) in the directory. At least that was the case 2 years ago, not sure if it's still working.
Meteor came out before async-await was a thing for Node. Meteor solved the callback hell with fibers. However fibers introduced concurrency bugs. A fiber has pre-emption points when doing IO. If some other code then changes some state then it can be dangerous because of data races.
A friend of mine got stuck on a bug where sometimes he got a different value than he expected and after a walkthrough I showed him what happened. So Meteor is not really friendly to beginners if you have the bad luck to provoke a data race.
This is the main weakness of Meteor. I was not surprised that MDG pivoted to Apollo.
My friend is still happy with Meteor, because I told him where to look for concurrency problems.
I enjoyed Meteor. Is there anything else out there right now that works as smoothly. Just install meteor and it installs a local copy of mongodb. Not a fan of mongo per-se, rather I'm a fan that meteor didn't require me to install it at a system level but instead installed it locally in the project at the version correct for that release of meteor. IIRC it even installed its own copy of node at a certain version. Loved it!
When I look into other frameworks today they all seem lacking. They expect me to setup the backend "how I want it" and then write my own glue. (and of course make all my own mistakes). Where as meteor, "it just worked" out of the box
I honestly think the best comparable stack now is Phoenix in Elixir with LiveView, especially if you're drawn to the realtime web aspect. And probably hosted on Fly.io where you can get a push-button start with database included (Postgres or SQLite). Great developer productivity, wonderful small community that manages to move together, rock solid, high performance for IO, little to no magic, you can take it from hobby horse to the major races. Excellently designed with both developer and application growth in mind, by which I partly mean that more advanced areas tend to be tucked away (but by no means hidden) until you feel you need them.
That said there's more to learn than with Meteor and there aren't Elixir devs growing under the steps of every apartment building like with JS.
Meteor was first ever magic web technology I've ever used. The fetching from backend that you wouldn't even see in developer tools, one code base for frontend backend, straight forward cli, developer selection between jquery/react/angular, kadira, build-in simple cordova
Never ever have I seen such a rich product that had everything and was easy to learn - back then their todo tutorial took less then 1 hour, after you had fully working todo app.
Yet too much magic was not what developers wanted, during the process you felt like loosing control over the processes you don't understand nor have access too.
Compering this to building a standard app back then with REST API, and backbone/angular/react frontend seems like saving tons of time, yet developers decided on the latter in most of the cases.
> It soon became clear that the community was splitting into two camps: those who appreciated Meteor’s clear value proposition of simplifying web development by providing an all-in-one environment, and those who wanted more openness towards the npm ecosystem to avoid being left behind by the rest of the webdev community.
That seems to be a case. Also lack of people that wanted to use this in production and cost of developers.
My last app in meteor was written in 2017, after hitting success everything died, even after adding 10x more CPU and RAM. Problem was that Mongo/Magic was sending too much data, multiplying this by few thousands users caused killing node.js server in seconds. Using Kadira profiling and 2 nights of coding problem was solved and app was running fine, both web and mobile (meteor cordova). Client was happy, same with users - it was success. After investor came in, they decided it must be rewritten, because at that time, there were only 2 or 3 companies in Poland that knew that technology - investor decided its a bottleneck - whole thing was rewritten to Java Spring and Angular (or something similar).
Used to churn out so many side-projects on meteor. My first application was a chat application, that our teams ended up using on several projects (this was before slack).
I remember that the effortless hosting they had setup was a dream. Still have never got that feeling again from any project.
Meteor community is the best OpenSource community I have ever worked with. Unfortunately, the framework couldn't reach it's goals & we had to move on into other things :(
There still isn't an APM for the Node ecosystem as good as what Kadira did so economically and easy to set up.
My startup interacted with everyone in the Meteor ecosystem. Positive selection because the technology was so good compared to everything else at the time. But recruiting was horrible, getting support from community investors was horrible, getting support from MDG was horrible.
The problem was, how did a Meteor consumer align with Matt and Geoff's goals? What were those goals, exactly? I'm sure people who worked at MDG felt the same way. They were too young to articulate it at the time. My company didn't align with their goals. Did anyone's?
It's a microcosm of Y Combinator's serious, persistent cultural flaws. The Meteor technology wasn't perilously flawed, that's a red herring. They know how to write useful web frameworks. But I didn't live in San Francisco - let alone Sri Lanka - and I had no desire to volunteer at the Burning Man airport or drink rare cases of beer or cavort with people who lose elections. Those were their most visible goals!
Like Jesus fucking Christ, a reply to an e-mail we sent to Matt or Geoff would be nice. We used and promoted your (Matt's) thing - we were first class evangelists with a fast growing product. But it seemed there was a missing cultural alignment. Too bad.
How did Kadira have better relationships with Meteor customers than MDG did? This guy whom I'm commenting on answered emails and made phone calls.
And maybe this is why React is big. Their goals were: find people to work at Facebook. Great, crystal clear. You knew what the deal was. Punchline to every conversation: "Oh, thanks for contributing to React, this is good, do you want to work here?" They didn't give a fuck if you met their overarching theory of affirmative action for libertarians or whatever. They just want good developers.
You could use their thing, and if you wanted to get to know them, that's what it was. Kubernetes? They (Google, Amazon, Microsoft) want you to pay for their cloud services. Clear as day. You contribute to it? Their deal is to copy it and sell it. They're not going to hire you. Fine.
These sound like business transactions. That's great. I didn't see a business relationship with MDG. They cared about other shit that didn't matter. It made developing for the platform as an evangelist suck.
Definitely agree here. It was a great community. I ended up hitting a point where Meteor just didn’t fit performance profile I was looking for and at the time fairly inflexible for which type of DB could be utilized.
I made a few Atmosphere packages back in the day, some of them had a good # of users.
Aggregate database queries using Meteor (at least as of 1.0) would create an immense amount of backend overhead if you queried through minimongo. And the overhead was incurred as long as a user was on that page because of how the reactivity worked. I tried making a PR to optimize this but apparently it wasn't comprehensive enough. I kept checking for years but no one attempted to fix this. Before you get nostalgic for Meteor, issues like that were awful.
Meteor (and RethinkDB) were just* pub/sub you had almost no control over. Was fun playing around with, though!
* (also, being able to automatically add accounts and authentication was great)
That's not a Meteor issue. Running aggregations on fact tables at runtime is slow. On top of that, being a document store, mongo is not the best at aggregations. Then instead of using mongo you use minimogo (DB implemented in JS). Then you rerun that query all the time. Of course it'll be slow/expensive. :)
I started my post-PhD career as a one-man-band "full-stack" shop on the back of meteor. I remember developing prototypes overnight between client meetings and blow minds with a fully functioning product deployed and functional before they even finished describing it to me.
I reluctantly moved on to a larger project where Meteor just didn't make sense and it just seemed to fall apart in the rear-view mirror.
I have such fond memories of using the CLI to scaffold a new project that came with built in auth, UI components, and a simple, sane project structure, then deploy it with a single command...bliss.
Man, Meteor was such a game changer, and I attribute that largely to the group of people who were part of the initial team. Outside of the founders, you had people like Emily Stark, Slava Kim, Alice Yu join the core group. After leaving Meteor, a lot of them went to work at Google and other prominent companies.
I mean, the project had everything. Exceptional people, great funding, and the framework itself provided superb user experience. I haven't been in the loop for many years, but I might have to put together a weekend project for nostalgias sake.
The general sentiment from the rest of the JS community when meteor was announced was - great, but why are they ignoring us? The original version of Meteor seemed to use its own tech for everything - I think it may have even had its own module system? Suffice to say it was a decade ago so my memory is hazy.
I still remember how hyped about Meteor me and my team were when it first came out. We built some PoCs and tested some really interesting concepts that were super easy to build in Meteor.
I insisted on staying away from it when building our main service, which had very high data throughput and near realtime requirements. I was very happy about this decision when we had to run away from Mongo due to some atrocious performance issues.
Anyway, some of the concepts and ideas that we prototyped in Meteor, we replicated in our stack (Redis pub/sub + websockets + jQuery) with a lot more work but with zero performance problems. We would have probably not came up with such concepts and ideas without having the chance to build them in Meteor in the first place.
The one company I know using Meteor at scale (Qualia) runs each tenant in their own pod with their own DB etc. Pretty cool way to scale and not have one customer take down the platform. But when one customer gets big... :)
10 years of Meteor... Well thanks, now I feel old. I haven't personally used Meteor but I remember looking into it seriously few times.
If anyone wants to explore an open-source Meteor project in the wild, a kickstarted project named Pixel Art Academy[1] comes to my mind. Looking through the repo[2] takes me back to CoffeeScript days.
Is there anything today that really chases that original, beautiful vision of Meteor: To be a platform that would allow ordinary smart people who are NOT programmers to develop real, solid, fully capable web applications?
I haven't looked at all the low-code/no-code offerings out there, but most of them seem very limited compared to Meteor, either because they intentionally limit scope to make the building easier, or because they rely on heavy SaaS backends and such, rather than Meteor's easy deployabilty to any old server.
> To say nothing of up-and-coming front-end frameworks like Marko, Qwik, and Solid, which are all about giving you better control over rendering and being more efficient.
Curious is the omission of Svelte, which ranks pretty high in some statistics from the author's own project:
Really cool seeing so many others experience Meteor as their web dev "gateway" drug, and cool seeing that others also hit the same stumbling blocks as I did and (somewhat reluctantly) had to learn to distance from Meteor, almost as a crutch.
Thanksfully new tools like Supabase and Deta provide a somewhat similar developer experience to Meteor, but it hasn't been the same!
Remembering good old times starting learn Meteor 8-9 years ago. I was looking for a silver bullet back then. My path was like Meteor->Angular->Ionic then I end up with React. I am not looking for a bullet anymore, I am happy with the light saber since then;)
The year: 2015. I had just graduated from Dev Bootcamp in NYC and was desperately searching for my first engineering job. I came across a job posting on Craigslist for a startup that sounded promising. It was one of the few interviews I could even get. They told me next to nothing about the job, and literally nothing about the product, except that it would be built with Meteor.
The whole interview process was the weirdest I’ve ever been in. The two founders brought in four candidates (myself included) into a single conference room and told us they were going to hire two of us. They then went on and on for an hour telling us about how successful and genius they were, and that they were going to be building something 10 times more successful than Facebook. The whole interview was essentially a lightning round of JS trivia questions (type coercion edge cases and such). First to answer correctly got a point and so on.
Naive me, I remember building out a whole Meteor project trying to impress them. They took about three weeks to tell me that I had gotten the job and they were ready to tell me what the product was, I just had to sign an NDA, get it notarized, and hand deliver it to them.
Before I could deliver the NDA to them, they told me the terms of my offer—$13/hr at 20 hours per week. No benefits or equity, obviously. BUT, I would get 1% of any profits.
Making minimum wage in NYC with no potential for upside gain was not in the cards for me, but it did drive me to learn about Meteor—a technology I wasted about two months with before abandoning because no one in their right mind was using it.