Been building apps with Meteor since '13. Never been let down by the framework. Old apps still keep working, new stuff is easier to build than ever.
I think that, like with most good Open Source Software, the question is not whether it’ll still be there in 10 years, but whether it’ll help you grow with it or it is going to leave you behind.
You will be growing with Meteor.
It’d be great to get a wrtie up on this.
In the meantime, React Static is pretty sweet too - and in some ways better than CRA.
(this is not to speak against Gatsby)
Here is the Meteor roadmap: https://github.com/meteor/meteor/blob/devel/Roadmap.md
You might also check out the feature requests to get a better idea where in the short and middle time range Meteor will be headed.
Whoa, very optimistic approach. Personally, I don’t know application built in one technology and lasts - in the same terms - for long time like 10 years (wait a second, I know - and it is called Basecamp, but I can be wrong). Every application needs to evolve. If you will choose PHP, Ruby or Python - you do not know, if it will last for such time period. You do not know how it will look in next decade. That’s why I would recommend you to think about shorter period. We don’t know, what the future will bring to us.
Because that place is full of Meteor fans (like me, @CatInBlack and others), I can’t write other words - don’t be afraid of using Meteor in long-term development. It is very mature technology, built by great developers (@benjamn and @abernix, I am looking at you!). Maybe three years ago, it wasn’t, but now - everything is in great shape. I would recommend it! Of course everything is up to you how you will prepare and develop your app, but I think - if you will follow the Guide - everything will look fine and clear. Don’t be afraid of MDG disappear - it won’t. They gained a lot of money some time ago from VC and contracts simply do not allow them to forget about their product and clients. Maybe they do not always update their blog and website, but they are alive - and I am sure, that they will for next decade (remember that they are working since 2012!).
So, follow up the MDG and move your next big project towards with Meteor’s help. You won’t be disappointed! 
I just recommended Meteor to a customer today. For me, it’s still the best all-in-one JS framework out there.
My two cents : started using Meteor in 2012, less than one year later it had become my main development tool and I would not trade it today for anything else.
Above all, Meteor helps me focusing on creativity, juste like Logic for music or Unity for 3D : easy learning curve for the first steps, and immense possibilities under the hood. The project I will release in the next coming months, a full social network with realtime collaboration features, is the most ambitious one I ever worked on - and it would definitely not have been so easy to develop in a small team without Meteor. I’m very thankful for that.
Just hoping they will seriously reconsider the case of Blaze : like it or not, its simplicity plays a major part in Meteor’s attractivity 
Hi,
What was happier with the meteor was for the simplicity of developing a complete, responsive, modern and quality code. And I did with the basics, meteor, iron and blaze. I even managed to generate the Android and IOS versions without difficulties, a plus in the framework. I do not intend to change the structure so soon, but for new projects I do not know what to actually use. For while the diversity of choices becomes good, it brings back, as someone up here said, a need to learn various other things.
In my opinion, the Meteor should have all these possibilities, but it should have some standard framework definitions, to ensure continuity for projects that use them, as this is critical to corporate projects.
This churn has be discussed so many times, and largely it’s inherited from the young and active Node.js ecosystem, had meteor not opened up to the rest of the ecosystem it’d have been an isolated framework. We might be tempted to consider things from our point of view and projects immediate needs, but those changes were necessary to keep Meteor relevant, and it’s truly remarkable engineering that it’s still backward compatible, even smaller NodeJS libraries can’t keep backward compatibility for more than year!!
I see people talk about Meteor being backwards compatible now and then and I know they try to. But they seriously broke our app more than once (even without upgrading, because the build-tool updated in the background). I appreciate the effort they put in minimizing impact, but calling Meteor backwards compatible isn’t 100% true. 1.6.1 completely broke package tests and now requires ugly workarounds. And if you still had some coffeescript in your app you better start converting that. Maybe a good thing to do, but not backwards compatible by far.
Sometimes I would rather see a 2.0 with everything cleaned-up than the required steps with every update. “Then don’t upgrade” you might say. Well, modern JS, security patches and new features are really welcome in a large code base.
TL;DR: Meteor is backwards compatible for some, not for others.
I totally agree with you @waldgeist. We are recommending Meteor to our clients and they are happily getting switched from PHP/MySQL to Meteor.
Well I had a different experience. I had a app written prior to 1.3 and was able to migrate to 1.6 without any code change, for me that’s the definition of backward compatibility.
I think there some truth to that, I do agree with you that some third party packages do break and the test package in the only major one I had issues with as well, due to coffee script update, but it was quickly patched by the community.
But I think we need to keep things in context, if you think about the transitions and pivoting Meteor has to go through since it’s inception, and the pace of evolution of the the Node JS ecosystem, then their effort is really applaudable in my opinion. I had to do way more refactoring for React code within 2 years (sometimes full components re-write) then Meteor update related refactoring in 4 years. In fact I don’t recall requiring to re-write a single line of code after an upgrade, only upgrading packages when needed, maybe I was just lucky 
TL;DR: Meteor is backwards compatible for some, not for others.
I have a app since Meteor 1.2 and I updated without problems. I creed that use correctly framework is better to update to new versions of Meteor.
Same here, almost no upgrade issues (most issues relate to third-party packages).
And … we avoid coffee like the plague 
– unless it’s a Latte or Cappuccino
We also avoid coffee.
Meteor was a very exciting technology in 2015. It was a zero-config solution for cutting edge features like reactivity, hot code push, and client side rendering. I think it grew quickly because it was extremely easy to use and pick up. Meteor was in the first Node app I ever built, and to this day I’ve never built an Express app.
First let me say this may come off as harsh or shortsighted, but this has been my experience and frustrations over the last few years, solo developing Meteor applications full-time. I greatly appreciate what MDG has done and continues to do for the JS community. After all, they were a travel app startup originally, right?
That said, MDG has made some choices that hamstringed the adoption of Meteor in my eyes:
Stopped development on Blaze, which was an extremely productive templating engine. Leaving several bugs and still recommending it in their docs.
Slowed development efforts on Meteor to focus on Apollo. For me that creates concern, if they are willing to stop development on Meteor to focus on GraphQL, whats next after GraphQL? How long until Apollo receives a similar fate? What if they decide Meteor isn’t worth the effort anymore? I’m not the only one that feels this way. msavin’s comment Does "resources are not unlimited" === "we will continue to have one developer staffed on the Meteor project"? hits home for me.
arunoda left the Meteor ecosystem to focus on React packages, abandoning the highly used Flow-Router and Fast-Render, which I had to try to maintain to keep working with the latest Meteor updates. Why are we receiving no support from MDG for Meteor’s most popular router? The documentation even suggests using Flow-Router. This contributes to the sense of abandonment. How can you have a JS WebApp framework that doesn’t include a router? And I know it’s “optional”, but this is why newcomers are confused as hell coming to Meteor in 2018. It feels like 80% of a framework where you have to figure out what the other 20% is and how to incorporate it.
Bought Kadira and open sourced it but didn’t provide any instructions on how to use it. This could have been an opportunity to earn some developer favor and help mitigate the sense of abandonment. But they put effort into incorporating it into their paid hosting service and let the community try to figure out how to deploy Kadira on their own.
There is no longer a clear path for newcomers to feel that “Meteor productivity” we are familiar with. Do they use React, Blaze or Vue? The docs recommend one router, but should they use React Router instead? Do they use Apollo? If so, how the hell do they setup reactivity? I thought Meteor had reactivity built in? Not if you use Apollo? Well why is everyone using Apollo then? Because you can make it work with subscriptions. How do they cluster the GraphQL subscription server in production? It’s an endless pit of questions now. Meteor used to be an “opinionated” framework and that helped adoption by somewhat enforcing best practices or at least suggesting the components that should be used. Don’t get me wrong, opening Meteor up to work with other renderers and data layers has been fantastic for the future of the platform. But now we’re left directionless trying to put together the pieces.
Meteor went from “it just works” to “it might work if I can figure out what components to use in 2018 based on out of date documentation, forum posts, and changes to cutting edge technologies”.
I would really like to see MDG use their expertise, experience and opinions to put forward a recommendation for components to use in Meteor, and maybe some best practice documentation. Smart defaults (Blaze, Flow Router) that are still maintained would be a great start. It’s great that Meteor is opening its doors to support components from the greater JS community, but I would still love to have guidance from them as far as best practices, pitfall warnings, etc. goes. It’s almost like Meteor needs separate documentation for the React and Vue sub-ecosystems and related components.
The most painful of all is that we can all see what Meteor is capable of, and it’s slow growth is painful. I don’t give a shit about GraphQL. I am sick of switching rendering libraries/database layers/routers every 2 years. I have nothing to gain from Apollo except maybe my collection code becomes twice as verbose. What we had worked well and allowed developers to be highly productive. Now it feels like we can’t have confidence in anything we do. Should we use Meteor’s data layer in 2018 or use Apollo? Will the current data layer be abandoned like Blaze? What happens to Meteor if benjamn is hit by a bus?
Anyone still developing on Meteor has fallen in love with the platform. We don’t want to go anywhere else. We want to feel like MDG has our back. It’s true that in 2018, Meteor is stronger than ever before. You can even use Blaze and ignore all of the changes. But when you read about Meteor, you’re going to see a lot of opinions, frustrations, excitement, and confusion all at once.
Well-written and well-said. I echo your feelings.
I just wanted to add the following: @arunoda leaving was because he couldn’t monetize his platform. Not out of exasperation. And we do use APM in production (https://github.com/lmachens/meteor-apm-server) and it works great out of the box. The code went through major cleaning and is being contributed to.
Here is the challenge: how do you make money off meteor? Our case: we use Elastic Beanstalk now (migrating from DO servers), we host our DB, and use redis-oplog. It’s all super easy infrastructure and well-maintained (well, super easy if you have expertise in-house). So we don’t use Galaxy. We can scale up and grow without paying a cent to MDG.
The only way forward, I believe is for the community to take it over or contribute heavily until then.
While I understand and empathize with your sentiment, since I had to refactor a large Blaze app myself and passed through the 2015 pivoting phase. However I honestly think these are moot points which has been discussed so many times on this forum. Personally, I’m more satisfied with the Meteor now then prior 2015 specifically because it catered more for advanced use cases, opened up to Node and allowed using different view layers (along with their community maintained routers). Also I enjoy the work being done on positioning Meteor as a competitive build tool.
They did and it’s called Meteor Guide, and it would be great if more people contribute to it.
I also understand MDG business decisions, a lot of solo developers/entrepreneurs point fingers at MDG for pursuing revenue models and targeting complex use cases and enterprises ( Galaxy, Apollo, and Optics for complex APIs) and not scaling the dev team on Meteor open source, or maintaining all pieces of the stack, yet one has to wonder how MDG is suppose to pay for those dedicated and highly specialized Meteor developers if many entrepreneurs are aggressively and understandably seek cutting cost everywhere until they’re profitable after which they don’t give credit to Meteor, deploy on Galaxy or move to something else!
Qualia is a good exception here. Hats down.
I agree. I was simply telling the story of why so many people got frustrated with Meteor in the last few years. Those of us that are left are pretty much over it.
I think bickering about their business decisions is useless, they’e made it clear we aren’t going to influence their behavior at this point. The Meteor community DOES suffer for it though.
Yes I agree, I acknowledge the frustration and I was one of them.
Exactly, Meteor followed the hype cycle by the book. Notice two things:
Thus my point earlier that it’s in much better shape today then where it was two years ago and those who are not seeing that are missing out the opportunity to build something great.
First I would really thx for all you feedback and messages.
Whatever you will say, Meteor is dead, dying, or in agony, one of the best point of this conversation is this conversation itself.
20k visits and many comments can confirms in conviction that Meteor is no dead.
There are still many people who love it, who take care of it and want to make Meteor the best technology (again).
I truly believe that is gonna be true. We are amazing community, we can do everything together.
I also believe that MDG are working on new features in Meteor, and they will take care of Blaze again.
I hope they managers will do more to popularize this technology, not only using community.