Thank you! Yes, the train is speeding up again 
Appreciate the thoughtful response here. Love hearing about people’s experience using Meteor.
@jkuester’s answer made mine almost redundant, but I would like to insist on the most amazing parts of it:
- Zero-config bundling.
- Fully stack real-time + reactive. One of the best value propositions in my view and still without serious competition out there. In the age of IoT, Meteor must capitalise on this core strength. Perhaps some examples with the likes of Pusher, PubNub, perhaps combined with storing data in somehting like TimescaleDB (also a good opportunity to show that one needs not be married to MongoDB for everything).
- Out-of-the box accounts package.
- Truly pluggable and extendable via packages. NPM, while convenient and widely used, cannot extend a meteor app in a way the Atmosphere packages do. Perhaps the packages should not be marketed anymore as such, as people see them as a failed competitor to NPM, but named something like, say, “custom bundler modules”, “Meteor extensions”, etc. Webpack has something called plugins (admittedly fulfilling a different role), so the packages could be regarded as Meteor plugins.
- Last but not least: as a result of the above, Meteor helps to quickly build from prototype to product on a shoestring. Testimonials and interviews from owners/developers of successful products (be they even internal) are key.
3 Likes
Super helpful, thank you very much. Agreed on the testimonials/interview side, it’s something we’re working on .
Thanks again!
Just to add my two cents, it’s pretty much just agreeing with the prevailing sentiment here. But just wanted affirm the above reasons why Meteor is great.
I’ve been using Meteor as my exclusive development environment since the summer of 2013 when our startup decided to use it to build our product.
I’d say the greatest selling point of Meteor has always been it’s clarity in getting from 0 to prototype. The pieces which make things straightforward and clear are:
- The Build tool
- Meteor Accounts
- The docs and guides
- The learning tools (such as discover meteor and the level up tuts videos)
Over the years I’ve moved to using React and Apollo GraphQL for my new projects. Keeping up with the latest technologies has also been a strong selling point for me.
I have always used Galaxy because of how easy it is to use Meteor Deploy and I always wanted to support Meteor so that development would continue; and with the new plans, i’ll use it for even more projects. Having a free sandbox as we had in the past would be nice, but I also understand if that is not financially viable.
Finally, the things that I believe would help to communicate the value of Meteor. Would be to update the guide and docs, and to add more official support for Apollo. I think this is the easiest way to communicate the flexibility of Meteor on the data side, to show that you can use any database you prefer. I also think an updating of the Meteor accounts with React components, and an official Apollo version, would be a big step in really leaning into one of Meteors best features, it’s easy to use out of the box accounts feature.
2 Likes
Thank you! Agree with you here on the learning tools and accessibility.
Appreciate you sharing your thoughts here!
Let me preface this by saying I love Meteor, just like you. Been using it since 2014, and still do. While I fully agree with all of the great points listed above, I think from a marketing point of view it is also important to acknowledge the ways in which Meteor has gotten a bad rep over the years. As these are the things that are keeping people away, not the lack of shiny features in my opinion.
In my experience trying to convince agencies or other devs on using Meteor, these are the pushbacks I often get (directly or between the lines):
- Meteor is just a toy framework, nice for prototypes but not a solid base to build on
- Meteor is for people that are not really skilled programmers (this will only be amplified if we keep focusing on how “easy” everything is)
- Meteor doesn’t follow best practices (like not using NPM for installation, it just looks weird compared to other tools/frameworks)
- Meteor does not scale (I know we’ve beaten this to death, but it’s still a perception — and also a reason why focusing on the real time live data without acknowledging this concern I think will only backfire)
- It’s better to build it yourself (while I, as I think everyone on this forum, love the zero config and the fact that I don’t have to spend any time on bundling, deploying, devops, etc, I also think we are a rare breed among developers. A lot of devs like tweaking with this stuff, and feel that it’s the only way to get the best setup. So you will not convince those by focusing on the ‘magic’ of the zero-config setup. Maybe the solution here is to instead have detailed explanations of what the setup actually is, what choices were made and why. Like the specs section of a MacBook page; you can expand it or skip it, so people who want to can get into the nitty gritty, but they don’t have to.)
- Meteor is not secure (also a very old story, we all know the
insecureandautopublishpackages were there purposefully for ease of use and speed to get started, this decision has damaged Meteor’s image badly (comes back to the “toy framework, not for serious apps” perception). This is also why I insist we should not again focus on how “easy” and “fast” everything is, at least not without giving a lot more technical insights because it will only reinforce this existing perception). - Meteor ties you to Mongo which I’m not sure is a good database (often I have to work to sell Mongo as well, especially if other devs are more familiar with relational DBs).
- Meteor is hard to customize; it’s great as long as you’re using it as intended, but if you want to do something differently it gets really difficult
- You cannot/It’s difficult to host Meteor where you want (like in your own Docker container)
- Meteor requires you to buy in to their whole stack (this could be fixed by a “Make it your own” section on the website: choose your fav front end framework, Postgres instead of Mongo, connect a custom backend to DDP, … — by the way, there are a lot of the people doing very cool stuff like this here on the forums
. A cool way to reinforce this could be with cases; “Read why Company swapped X for Y to support use case Z”)
Also, I think it’s good to realize that the speed and ease of use apply to us in part, because we are used and familiar with the framework and its ins and outs. For newcomers, there will be a learning curve, likely making it less fast and easy to get started than what they’d normally use. Most devs probably also already have a set of tools they take from project to project (components, packages, Webpack configs, …), which already gives them a similar dev experience.
Please don’t hate me :), I am genuinely writing this to help, not to attack Meteor. It is also just based on my experiences, so it might not be representative. But do keep in mind, and I’ve said this elsewhere, that here in the forums is quite a bit of Survivorship Bias. Of course we are all convinced by Meteor’s features and benefits, but this is about convincing people who are not on the train yet, and everyone that left to come back.
13 Likes
Certainly don’t hate you! Quite the opposite in fact – this is very valuable. Really appreciate this. Lots of food for thought about ways we can improve and bring more people to Meteor!
Thank you again!
2 Likes
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.
3 Likes
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.
8 Likes
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.
6 Likes
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.
6 Likes
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
7 Likes
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.
12 Likes
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!
1 Like
Thank you so much! Looking forward to working together
1 Like
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.
4 Likes
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