I started with Meteor shortly after the 1.0 release. I came from the LAMP stack world so it was quiet new to me, but compare to every other solution I was trying at that time Meteor just worked with just one command install, this was super awesome especially compare to the other solutions which were more difficult to setup and even if I followed their guides it often did not work. The next thing that attracted me was the account system and data on the wire. Account system remains for me the most powerful feature of Meteor to this day (would be nice to see it updated and possibly extended).
I then grew together with Meteor. When the time came I switched to React, when I needed hosting Galaxy was there and as with Meteor it was super easy to use. Same with other improvements. I occasionally try other technologies, but compare to the ease of Meteor I find them cumbersome at best.
The pricing on Galaxy (especially once I combine it with MongoDB Atlas) is more than I would like to, but I see it as a donation to the whole ecosystem and is manageable at my size (we’ll see in the future). Currently I’m missing 2-factor authentication from Galaxy and more down the road a setup for any AWS regions (something akin to what Atlas has), ie. one deploy that then gets implemented in all regions.
Perhaps not quite the format requested, but I do have some comments on how Meteor might progress. So hopefully it’s ok to post this here in free form. In no particular order.
-
Communicate Meteor as a set of tools that can be mixed and matched, not as a “take it or leave it” monolith. Don’t want to use DDP? Sure, you don’t have to. Use Meteor as a build tool and get data via REST or Apollo. Don’t want to use Mongo? Add a package from npm and use PostgreSQL. Want to use Meteor on the server but have React Native on the client side? Sure, connect your mobile device to the server with SimpleDDP. The possibilites are there, especially once Meteor became compatible with npm, but are not very well communicated. This would go a long way to alleviate fears of vendor lock-in, or in this case, framework lock in. Maybe Meteor’s guide might have a section dedicated to examples on different ways to use Meteor.
-
Don’t over-emphasize simplicity. Like @rijk said, this implies that Meteor is not for skilled programmers. Rather communicate that Meteor provides you with sane defaults, but in most cases does not limit your options to configure things yourself if needed.
-
Don’t get too caught up in view libraries. Let React/Vue/Svelte/… duke it out by themselves and just keep Meteor open to any view library out there. I’ve said it a number of times before, but it’s worth repeating - the semi-official Vue integration for Meteor is only about 2.5k lines of code (going by memory here, I might be off by about 500 LOC). And at least for me, it gets the job done very well, though I don’t use SSR. Given this, Meteor should be open to any view library that gets enough traction to warrant some skilled dev to write those 2.5k lines. This should alleviate worries that a view library gets left behind.
-
I think an interesting possibility for Meteor to generate interest is the current rise of PWAs. PWAs might finally deliver what nothing else has before - single codebase, installable on all devices, completely circumvents all App/Play store masochism and enables true continuous delivery. But the somewhat difficult part of it is the offline capability. It would be interesting to see if somebody could come up with robust offline capability for the default Meteor setup with DDP. Caching assets and handling method calls while offline. I have not thought about it too much, and there might be technical issues stopping this. But an out of the box setup for PWAs with offline capability would be very nice.
I agree, specailly with point 4, PWA are picking up and Meteor is very well positioned to take advantage of this trend, I think it’s natural evolution of the Meteor ecosystem to embrace PWA given that Meteor premise was single code base for multiple platforms.
All that is needed to have a PWA scaffolding that brings the tech together.
P.S we are using Meteor to power a PWA app connected to Meteor server using SimpleDDP (which is really nice to work with, perhaps it an be extended to have offline support) and it’s working very well, I believe it’s the fastest way to get an app to the market, our next step is to explore the offline support.
I am still a Big fan of Meteor. I think that what there was Two major things that made Meteor gain so much adoption at the beginning:
- It was VERY simple to become a Full Stack developer. That simpler path is somewhat lost now in the documentation in favor of the most advanced developers path… It should be emphasized back! Although noting, however, that Meteor developer today CAN evolve with the platform to become more advanced, and develop more production efficient apps as they go along, using the latest and greatest in javascript technology.
- The FREE meteor.com publishing servers for testing and small projects (including mongoDB). THIS WAS REALLY GREAT!!! That was a great complement to the easy-of-use of the platform AND a great advertisement for its success. We could see literally thousands of working open-source meteor project running beautifully around. That could be brought back WITH some conditions like: being advertisible by the Meteor team, being open-source, limited-time, etc…
Meteor SHOULD be the platform of choice for the beginner ! But not only that… It does have ALL the technology and efficiency to hold the beginner into the platform . There is simply NO NEED TO LEAVE as it is possible to develop the most complex app with it and get not performance penalties anymore.
Thank you! We’ll be in touch 
I have been working with Meteor for 4 years and build and entire companies echo system around it, its a home automation product made for builders not consumers Home Otto were based in Alberta, Canada. All our own hardware fully integrated under one home account, lights locks, thermostat and camera is in development. All run with real-time meteor, adjust a light slider and it updates with sub-second changes.
Our Android/IOS app is a meteor app hosted thru galaxy, our builder tools for reading blueprints and quoting a home automation system is meteor, our internal monitoring and administration tools are meteor as well. We have tied in Alexa, slack, firebase, stripe and other 3rd party integrations.
For Zeotec I creates a lab test management app for maintaining ice rink chillers with field service tech’s, to keep them running efficiently and the hockey games going.
We build IOT systems for monitoring environments and have them report back to a dash board and reporting system all running in real-time, which is what meteor is great for.
Meteor has had its challenges some are harder to work thru than others but I think the long term gains are worth any issues the environment provides.
The good:
- Everything you need under one roof, or one command away from adding it.
- Quick to get any project up and running
- I love 1 command deploy to add new features all my users without having to do a new build to the app stores
- I have worked with relation databases for 15 years, I like the freedom NoSql and Mongo brings
Needs Work:
- I would love to see Cordova plugins for essential services get more 1st party integration (big ask)
- Storage, mongo, static hosting
- the ability to bash script update container packages, wkhtmltopdf is nearly 5 years old
For smaller projects I have started to use NodeChef which is lower cost with a database, I can host static landing pages, use s3 storage, update and add to the container. its a different beast with a more shared environment but for lesser needs works great.
right now I am working to stream a video camera to a meteor site to drive a remote drive a robot to deliver groceries, streaming is good now I just need to learn to drive
Thank you! This is interesting. Appreciate the thoughtful response here.
Hi everyone, it was a pleasure to read all those memories and experiences with Meteor, so I want to share mine as well 
I’ve started playing with Meteor around version 0.4. People at my software house Vazco.eu (cheers to @cristo @michalwanat @radekmie) loved it as well, and it gained such internal popularity and acceptance that we released our first Meteor production app soon after, using version 0.6. Back then, lots of things were rough. Still, the framework already gives us advantages over alternatives we were using back then.
For what we love Meteor then and over the years?
- Just Works™. Easy to install, runs everywhere, and for everyone without significant issues. The same was true for apps built on top of it, and it was a big deal (Docker was not a thing back then).
- Single codebase, allowing us to reuse code and business logic between frontend and backend.
- Want something? There was probably a solution for that. If not, you or someone else in the company can write it and reuse it across many apps.
- It was absurdly easy to use realtime data and updates. Even up to this day, Meteor is unmatched in this area - if you don’t believe me compare to what you have to do to set up and use GraphQL/Apollo subscriptions.
- Accounts system that it’s there and it’s great. Again, Just Works™.
- Easy to learn and to introduce new devs to it. At the same time, quite hard to master, so even more experienced devs have fun optimizing and tweaking it.
- A safe place in the JavaScript Fatigue. Remember all the fuss a few years ago? We as a company were attached so much to Meteor that all those problems were unaffecting us at all.
- A friendly and open community - lots of meetups and content.
- Galaxy - again, you can see the Just Works™ philosophy in action.
- SimpleSchema and AutoForms - we loved to build forms in declarative fashion so much, that when we dropped Blaze for React, we created uniforms.
Currently, at Vazco.eu, we have several apps running in production using Meteor. Most of them are walled-garden internal apps, but we have products like aleno.me, which is happily running on Galaxy. This is why we are glad that there is now a Galaxy roadmap and some attention. We can’t wait for the autoscaling feature
And while we didn’t start a greenfield project in Meteor for a while now, seeing the direction Meteor is heading after Tiny’s acquisition, this may change soon.
Hi @matthollingsworth! I’m late to noticing this forum post, but I’d like to invite you over to the Meteor Community Slack if you are interested to talk more about some ways we could all work together to revitalize Meteor’s reputation on the web and among various developer communities.
Before I knew this post was up, I made a pretty authentic case for what I love about Meteor, and specifically what I love about Meteor + Vue over here.
One tip I would offer is for the Meteor team / devs to reach out to leaders of other open-source communities that directly impact developers awareness and knowledge of Meteor. Front-end frameworks are where new developers learn to build things these days, and Vue stole the show for the new easiest place to START building a web app. To the millions of Vue developers, Meteor is mostly an unknown choice for a backend (this is from their perspective). I’m hoping to change this perception by helping Vue developers learn & get started with Meteor.
We’re glad to have you as support to get devs excited about Meteor again!
Thank you so much! Looking forward to working together
Hi Matt @matthollingsworth
I am 67yo and a non-coder. Classic Meteor has made complex apps accessible to an Average Joe, just like me. Hey, when Biden tells a steel worker he needs to learn to code, he is clearly referring to Meteor
Here’s my little offering…
I pipe EEGs around the planet using Arunoda’s Streams. No more Classic Meteor than that.
Happily hosted on Galaxy.
I use meteor on google servers with haproxy and hosted mongo for iot platform. Meteor is simple thats it. Though our platform has other components - mqtt, redis queues, node based event handlers, seperate analytice platfotm etc… from a mere dashboard that offers a view into operational data and interact with field devices . This JuST works!!! At the end iy ie all about decoupled architcture
I used to build with Meteor (wrote a long advocacy post in 2015), and ~5 years later, I’m semi-regretting not sticking with it. The main reasons that drove me away were: sense of abandonment, lack of support for PWAs and GraphQL, and team/community split (Apollo? Blaze vs. React?).
As others have said, it may be worth de-emphasizing “easy”, and emphasizing the serious time savings that Meteor offers. I estimate that at the start of a project, Meteor easily saves a man-month worth of coding time not spent reinventing the wheel (accounts, data sync, bundling etc.) with the “build your own car” approach.
What do others think? As long as it’s also emphasized how you can “graduate” from the initial setup (e.g. opting out of realtime data when and where it no longer make sense), I think Meteor has a winning story.
As for,
That’s true, for myself included. But I recognize there my OCD tendencies, However, when you step back and honestly ask yourself what benefits you’ve got after spending hours or days tweaking and testing and debugging your tweak, over the tried & true approach that a framework offers, the answer is often, “not much”. And it tends to be “not worth the time you’ve spent, which you could’ve spent building an actual feature”, when you ask your customers and business stakeholders, rather than your inner developer geek.
I’m totally new to Meteor and this community. I have a background in Drupal, PHP, MySQL, JS, TypeScript, Vue etc but I’m a generalist, dabbling in a lot of design/creative stuff as well. I’d honestly never heard of Meteor, or if I had I’d forgotten or written it off due to my own ignorance or just “framework overload”.
I have a largish, non-trivial app in mind and had started building a Nest backend and Nuxt TS Vue composition API frontend with MongoDB and GraphQL, I suppose because I was caught up in bleeding edge “best practice” (or my misconception of it). Then I stumbled across Svelte, saw how much faster, smaller, simpler and more rational it was than React/Vue/Angular and fell in love with it almost instantly. Then I found Meteor, I think through the new Level Up Tutorials Svelte + Meteor series, read up the docs and philosophy and I’m hooked. This Svelte + Meteor combo seems to be exactly what I’ve been looking for to achieve my goals as painlessly as possible, and Galaxy looks like a great solution for me as I don’t want to be messing about with server provisioning, config, maintenance and complex deployment. I wish Galaxy also provided MongoDB hosting as an option (even if just a convenient UI to a specialised third-party MongoDB cloud host) but it’s not a deal-breaker.
Thanks for this! I agree, we shouldn’t pushing the “easiness” of building with Meteor. What’s more important, I think, is emphasizing flexibility and efficiency.
What it’s about for me, when working for a startup, is getting to market faster. When building an MVP for a startup, there is always a limited amount of time and budget, meaning you have a limited amount of work you can put in. So, the less work you have to spend wiring up Webpack, rolling Authentication, setting up APIs, managing data, etc, the more time you have to spend on your actual product. Thus significantly improving your chances of it finding product market fit. For a business owner, this is a no-brainer, really. Even if there are concerns about ‘scaling’, it is really irrelevant if you consider that you won’t even get to that point if you spent 4 out of 8 weeks toying around with flashy tech and then come out with a crappy product. Another way to put it: when you do run into scale issues, it really is a good problem to have and you should thank Meteor for helping you get to that point.
Love this. Thank you so much.
I also used to use Meteor until about five years ago and they did a breaking upgrade and all of the turmoil started. But now I am reading this post and it sounds like everything has improved a LOT! So now I am thinking of updating my application for this New Meteor! It will be fun to learn about all these new things that have been added over this time.
Thanks for this thread. We are using Meteor for the last 2.5 years. We still love to work in meteor the same way as the first day although there have been many ups and downs in the community. We are thankful for this Framework which had allowed us to build our Agritech IoT SaaS platform Fasal (https://fasal.co) which is now one of the leading AgriTech companies in India and VC funded.
Our engineering team is also involved in active contribution and we will be contributing more and more going forward.
Answering your specific questions below -
I would love to hear from you on a few things: if you’re currently building with Meteor, why? What do you think is the key value that it’s providing, relative to other frameworks out there?
Meteor Build System, Accounts Package, Hot Code Push, DDP, and Cordova support for iOS and Android build has allowed us to remain a small and productive team. We have had 300+ releases in 1 year with 3 member team. That tells the story.
Same question for Galaxy Hosting – why are you using Galaxy? What’s the key feature, set of features or functionality that keeps you a customer?
We were using Galaxy and again was very impressed with one-click deploy and scale options and configuration management. However, because of limited AWS region support, we had to move to MUP on AWS. We are in the Mumbai region. I would definitely love to go back to Galaxy if support is available in the near future.