I have a background of Drupal 5,6,7, as well as C++ desktop application development. I used to write PHP custom modules for Drupal. My experience with PHP goes back to 1999.
I started using Meteor since Meteor 1.0 was released, was blown away by its power and simplicity, and find it to be a great framework for building apps, even when building more complex apps.
But I am confused as to why its not more popular. Any ideas?
Well, yes, one can develop wonderful things with Meteor, on a developer machine, quick and safe.
But if you want to let it out into the real world, you have to pay a lot or become rocket engineer, or rent one. Deploying is not really easy.
Perhaps - that did have me stumped for a while, but I realize now that its no more difficult than deploying any other Node.js app, as far as I can see. I now have 4 meteor apps running on a webserver in my basement.
@dpatte I guess one of the main problems is the hard dependency on MongoDB. Yeah, you can use MySQL with some third party packages, but there is no guarantee that they will be maintained in the future. So if you have a serious project with a lot of customer data and relations, you may run into trouble when you use Meteor. MongoDB has no support for real relations and transactions, and for a lot of projects both are a prerequisites. Apollo will solve this issue, but we have to wait until it gets “official” integrated into Meteor.
Dependency on Mongo and non-Webpack build system, especially with kinda-legacy Atmosphere packages.
But saying it’s not popular is way too much. It’s got more Github stars than any other Node-based framework, even Express.
Seems like it’s doing okay. 
Good question. I say it’s because too few people are sharing their Meteor success stories.
More people need to showcase their Meteor-based solutions and stories of success at technical conferences and developer meetups and events - especially those that concern NodeJS, MongoDB, MySQL, Databases, IoT and WebApps in general.
Last year, I submitted a proposal to give a talk at the Percona Live 2017 Conference that was recently held in April in Santa Clara, California. My talk planned to detail how my business Delivery Command uses Meteor with MySQL and what we’ve learned from the experience. Unfortunately, my proposal was not selected and I did not go. I will try again next time.
To the MDG - Percona Live is THE conference you need to be at! All the big players are there and lots of people pay attention to what goes on there.
Last year, I also experienced the indignity of attending a local Sydney Meteor meetup where one of the scheduled speakers gave a talk on how to move away from Meteor. It was depressing, it brought the mood of the audience down. I felt disgusted and knew something had to be done.
I immediately gave an off-the-cuff talk telling the people how Meteor had greatly improved our business’s productivity and improved our financial fortune and how using Meteor with MySQL made it much easier to gradually ease off our legacy PHP solutions. I said it was going to be a 5-minute talk, but it ended up going for almost 20 minutes including Q&A. The mood of the audience immediately lifted.
I think the build tools are a big reason. We’re refactoring a legacy app right now, came in 2 months ago, it’s 1 1/2 years old, solely depending on Meteor packages. One of our developers has roughly 5-10 minutes of built time! (Meteor 1.4.2 didn’t help much). One of our apps got faster, to roughly 30 seconds after migrating most things to NPM, still pretty slow though.
That’s why I moved to Webpack / Node for my latest app, where backend reloads in 1 second and frontend reloads in 2-3 seconds.
Overall understanding that Meteor is no past the packages era and you can easily use NPM hasn’t reached everyone. For many people (even my own co-worker), they don’t realize that Meteor is pretty much just a Node/Webpack app without the setup.
Use Webpack with Meteor simply by adding packages (meteor-webpack 1.0 is out!) looks interesting in this regard. Strange why MDG did not make an effort to integrate Webpack. It was in their possible plans long time ago.
More precisely like Node + Database Configurator + Tracker + custom replacement of Webpack?
Well yea I guess but then … It depends. Connecting to a DB is really not that hard and if you use Apollo now, you’ll use almost 1:1 the same setup on node vs meteor. So honestly the only difference I see these days in Node vs Meteor is Node requires more setup initially for both the app and the servers (but not as much as people always complain about, frankly after a few days you’re done with most of it for a majority of the rest of your life ;)!)
It’s hard to judge how popular Meteor actually is (although as @awatson1978 pointed out, it seems to be popular enough on github). One of Meteor’s sweet spots is custom apps, and those aren’t necessarily seen outside the organization. We’ve moved most of our custom app development to Meteor from PHP, but none of that is public.
I have nothing to base this on, but I expect we’ll start to see more Meteor stuff coming out soon. Meteor 1.3 is just over a year old, and I think for many that was a watershed release, with moves to get closer to the general NPM ecosystem. With time for people to start twigging on this and experimenting a bit, deciding to use it for the next project, dev time…I wouldn’t be surprised if we started to see more Meteor projects hitting release soon.
MongoDB isn’t appropriate for all projects, so being tied to it means that you’re already limited to a subset. Apollo should make a big difference.
There has been quite a bit of churn. It’s to be expected in new projects (and Meteor is still relatively young. 1.0 was…about 2 1/2 years ago?) If we had anticipated some of the changes between 1.0 and 1.3, we probably would have held off moving so much of our development until things settled down. I don’t regret the decision, but when you have to deliver to a schedule and budget, you need stability. As things settle, I think we’ll see more people jumping on it.
There are still pain points around deployment. Build tools were one reason why we went with Meteor over Node + Express + whatever. Moving from PHP, the node world is a very different beast, and ease of set up and building were more than welcome. Deployment, not so much, and not everyone who is experimenting is going to set up on Galaxy. More likely they’ll grab a DO droplet and take it for a test drive. If that has too many bumps for someone entirely new to node apps, they’ll try out the next shiny thing instead. (Even just good entry level documentation would be a boon.)
TLDR; there are a few actual drawbacks, but Meteor is young and I think we’ll see more growth. Expect that there’s a fair bit of behind-closed-doors projects in it.
Agreed on all of that. The DDP protocol gives lower volume sites really amazing functionality that can’t be found elsewhere. That lower volume requires more underwriting and resources per user, so it’s ideal for established businesses with external revenue sources. Lots of projects behind closed doors.
DDP is a tough call. It’s a huge selling point, but it’s also a huge drawback. Many teams and applications benefit from a more traditional AJAX style of data management with REST interfaces. I think it was important for Meteor to build out the DDP infrastructure to get to where it currently is; but I’ve also come around to the thinking that REST/HTTP support isn’t going anywhere, despite websocket snazziness.
Pulling JsonRoutes and OAuth Server support into core would be a major step in aligning the stack with what much of the rest of the industry expects. And it would create an option for more stateless architectures, eliminating the need for sticky sessions and nginx proxies. That would go a long way towards broader adoption.
The DDP vs REST issue has come up in a half-dozen projects; and as much as I love DDP, I’ve resigned myself to providing first-class REST endpoint support, OAuth support, and stateless architectures on most of my projects nowdays.
I thought it was popular already. Only few times that I mentioned Meteor my interlocutor didn’t know about it 
Frankly, not hip enough for the hipsters anymore.
DDP was one of the things that got my attention. It certainly makes for cool demos. The project we just launched uses pub/sub and has all the reactivity and…it’s not actually needed anywhere.
Starting again, I’d take a hard look at using REST. Along the way we built some utilities in plain node with React and Express and a REST interface, and I think data management was actually easier. That plus automatically getting a REST API that you can hook into with anything would have made building some of those utilities easier, too.
On the other hand, that was also an education in how much you get free, out of the box, with Meteor. /shrug.
In this particular case, volume is low enough that it doesn’t matter much perfomance-wise, and dealing with the few annoyances that come with it wasn’t onerous (I might feel different if we had to deploy to our own servers.) I can’t help feeling that - at the moment - Meteor is a nice but very particular kind of screwdriver. I do welcome what look to be moves to generalize a bit more.
As a user from the 0.3 days… in my opinion it was a summation of small things that led to a slow adoption rate (note this isn’t a bash but an observation, FWIW i’m still using Meteor for some projects):
The JS ecosystem moved so quickly in 2013 that Meteor essentially had the rug pulled out from them and a nice integration became lock in over time (script tags era to NPM on the front end era)
early misconceptions with security through the insecure packages and autopublish (nice demo, but brought on the HN hate), hard to use permissions with allow/deny
lock in with accounts system
No structure or process was prescribed when it was released and it took a lot of the “Ember CLI” or “Rails” cohesiveness away
Scaling issues with making * everything * realtime (well methods were an option but not recommended). Making everything realtime seemed nice at first but made things harder to work with over time
No large company back because of said scaling issues
vast sea of shoddy modules/plugins
Build tools became slow and suffered from lock in
most importantly no buzz/hype/
I appreciate all the comments on this thread. Its enlightening, But for me the varying comments only highlight that Meteor, like every other solution, has some weaknesses, and some strengths.
When I first started on PHP in '99 I was amazed that you could simply embed instructions (though ugly ones LOL) in a webpage and it would work. That had me hooked, and the rest is PHP history. But I felt far more amazed by reactivity, optimistic updates, and the fact I could go into airplane mode and continue working with my app, than PHP ever amazed me. 99% percent of websites have no need for further scaling than what Meteor, and simply uploading your app somewhere, easily provides.
And try to find opening for Meteor developers. Next to none. Node is in demand, React is Demand, but a full solution like Meteor which provides the benefits of both is not getting sufficient attention.
That’s what has me stumped.
To me, there really needs a way to make Meteor more apparent to the masses, people that normally just upload their site somewhere and hope for the best, or write small apps - not those that hope to have a website with 400 servers in 12 countries.
As for me, yes, I agree with awatson1978 that there are hidden users and a hidden market, writing internal custom apps, and this fact could be better highlighted by MDG in their promotion.
I believe it more to be a problem with Meteor-only devs. But you may be surprised with getting a Meteor project to work on even if you got the job as primarily Node dev.
True, but that is true with any app. So putting that aside, why isn’t this more popular as far as the app writing experience goes, not including deployment (which is actually really easy with Galaxy)?
But, actually, how popular do you want it to be? I hear people LOVING meteor all the time. Everyone I know who’s tried it, loves it. I think it already is really loved. It is very new also, and things take time to grow. Existing companies would be making bad moves to simply jump onto new technology instantly, things take time. The early settlements on Mars will be really awesome, but not everyone will want to go until things are more established, only the daring pioneers will go first, even if the whole effort is amazing.