ā¦ that helped Workpop secure $7.9 million in funding ā¦ 
Sign of Meteor in trouble: Workpop left Meteor (comes with 10 great tips how to leave Meteor behind)
4 Likes
I guess it depends what exactly you are planning to doā¦ if you have truly unlimited funding and time-- then yeah donāt choose meteor. But Workpop and Buffer seemed to make it REALLY far into their companyās life before being on meteor turned into a ārealā problem (I use quotes because developers seem to have different opinions on what a real problem is than business folks). The reality is most startups fail because their business or organizational skills suck, not because they chose java instead of node or react instead of angular.
It also depends on how fast you are in the current node ecosystem VS meteor. If youāve been building vanilla node/react apps for the last two years and never touched meteorā¦ well there isnāt much of a reason to learn it. If youāre a meteor ninja and you need to get an app out for the least amount of time and money possible, go with meteor.
But not choosing meteor because your startup may outgrow it come the year 2020 (assuming you make it that long) is not logical, imho. That kind of thinking is premature optimization on steroids and will leave your startup with an unfinished product and no more runway (i.e. money). 95% of startups take 3-4 years to really ramp up to where being on meteor MIGHT be a problem.
At the same time, meteor is definitely trending downward pretty fast. Still, it seems like if youāre using React with meteorā¦ is there that much to switch out? Some Meteor.startup stuff? Some pubs/methods for http calls? Some atmosphere packages that wrapped npm packages for their original npm packages?
4 Likes
^ So true
I have never seen something so easy to learn as Meteor. Weāre onboarding people who were clueless about Meteor & React and after 3 weeks they are ready to be put on a project I simply cannot ask for more, Meteor is in my opinion the easiest thing to learn.
Regarding, scalability, Classcraft has 10k concurrent users and 2M code-base. There didnāt seem to be a problem for them for scaling, ofcourse they had to use some non-traditional ways to do some stuff, added caching etc, leave some reactive parts behind. But they did it. If they would have rewritten their whole code-base, they would not have a chance.
I personally can bootstrap an application MVP within 40 hours, using this stack:
- Meteor 1.4.2.3
- Grapher as the collection relation manager and fetching layer
- React as the view layer
- RedisOplog as the reactivity backbone
9 Likes
No, Meteor is just missing some features bigger sites would need. This features are already requested for a long time (code splitting / different entry points). And to be honest: Most of the suggestions in the blog posting are already the way how you should Meteor use. React instead of Blaze, NPM packages instead of Atmosphere and so on.
Completely moving off Meteor is impossible at this point given 3+ years on the framework. Though it is true it does not have the features a bigger site needs at crucial times of performance and revenue.
We are indeed going to move off the platform but it wonāt happen overnight. Rewriting the app would be a huge mistake so think of it as ārepurposingā the Meteor server. The Meteor front end client for sure is dying and Iām personally going to dispose of it.
Now mind you, the Meteor world was different in 0.6 land till now. And a lot of you had the fortune of picking Meteor up in better times. But can you think of all the crud you would have if you followed the platform this whole time?
Spark to Blaze <- costly migration
New atmosphere packages
Package based architecture <- biggest mistake if you knew where Meteor was headed.
Only Blaze was available
No NPM
So a legacy code base is gonna have a lot of these annoyances. So please donāt think itās simple to do this by removing things here and there. The āMeteorā way is not the JS community way.
Global variables are not a thing. Nor is loading 10mb of JS to a client on a mobile device. Yet all still happen in our Meteor codebase.
Iāll keep you folks updated on how this goes.
Also rather than be negative and speculate if Meteorās in trouble. Why donāt you take the perspective of someone building an App at scale and see if my tips make sense for someone opting out of the platform.
Again not opting out cause we hate Meteor. Meteor is dope.
She could be mrs.right, but sheās not mrs. right now
1 Like
Iād love to see more on this one:
- Replace Minimongo/Tracker/ReactiveVar/Session
I havenāt been able to fully get into meteor with redux/MobXā¦ not enough good resources atm
Interesting blog post, even if I think the title is a bit link baity 
Here are our thoughts on your 10 points. We started with Meteor 1.1 with Blaze, but have moved to Meteor 1.4 with React and a complete ES2015 āimports designā that allows us to build multiple Meteor apps from the same code base.
1 - Replace Meteor Packages with NPM Modules
Agreed: besides core Meteor and MDG packages we only use the following 3rd party Atmosphere packages and they can all be replaced by us in the future quite easily except for simple-schema. Good news is there is a new NPM version of simple-schema we will move to in the near future.
aldeed:simple-schema
edgee:slingshot
ground:db@2.0.0-rc.6
okgrow:analytics
practicalmeteor:mocha
raix:push
universe:collection
2 - Get off Iron Router
Agreed: we moved to React Router from Iron Router.
3 - Remove Blaze ASAP
Agreed: we did major rewrite of our entire UI from Blaze/Meteoric to React/Material-UI. Very happy with the results.
4 - Replace Minimongo/Tracker/ReactiveVar/Session
Disagree a bit with this one.
Minimongo/Tracker works great for us as we only use pub/sub and reactive state where it is really needed. We use ReactiveVar in just a a couple of places to hold some global state that needs to be reactive, such as if a user is offline. We donāt use Session.
If you are going in all in for GraphQL/Apollo then Iād agree to that using Apollo client to manage state would be a good idea, but we are happy with our current data system and donāt see a compelling reason to make the move at this time.
5 - Microservice Feature Development
Agreed: we already run 2 āmicroserviceā Meteor apps, one is a data sync server and the other is a chatbot. Modern web/node apps should be designed this way anyway.
6 - Get on Apollo
Maybe, but not necessary today.
Our data system built using simple-schema, pub/sub and Meteor validated methods works great for us because we donāt overuse or abuse it. Having accounts/users built-in and using the same data system is great. Now with @diaconutheodorās new RedisOplog and Grapher packages we feel confident staying with this solution in the near future as we scale.
GraphQL/Apollo does not provide enough benefit in the medium term for us to completely rewrite the core of our application.
7 - Replace Kadira with another performance Monitoring Tool
Agreed: we deploy on Meteor Galaxy so have some simple monitoring included. We instrument our app with both analytics events and Winston NPM for logging. We have used New Relic in the past and may fire it up in the future. Your suggestions for error tracking packages is good.
8 - Mount an Express Server on your App
Donāt need. We donāt need server side routes except for our REST API and we use simple-rest package for that.
9 - Create a different Entry Point
Agreed: incremental loading/code splitting is the one big missing feature for us. This webpack based solution looks interesting, but we also need to get all of Meteor moved to NPM. Finally, I thought I saw a new proof of concept someone had done using Meteorās build tools, but I canāt find the link now. Anyone?
10 - Peak your head in other communities
Agreed: as an engineer you should be monitoring what is happening in the greater JS world, just donāt get bit by JS fatigue 
Iāll add one more point:
11 - We still like Meteorās build system slightly more than webpack, especially with the latest performance gains.
11 Likes
Thats awesome! Great thoughts!
Honestly if we had started our app in Meteor 1.2 and beyond things would be A LOT different!
1 Like
what exactly is a microservice? Is this the new term for splitting your app into separate apps, hosted on different servers, but pointing to the same DB?
Yeh, pretty much, but the apps donāt necessarily have to point to the same DB. This is a good overview.
I posted an answer to the article on Medium, I didnāt like the article for this reason, the starting premise is faulty:
āWhat I do know is our ambitions of where we want to take our platform are growing faster than the frameworkās offering every release.ā
WTH does that mean?! Why do you need to correlate ambition with framework release? And what is your ambition? What is missing? I got used to BS, but this is more than my tolerance level 
Second, they replaced Meteor with a dozen other packages to build their own framework. Thatās what I call real risk! What if one is not maintained, or does not get appropriate security review? Who will handle API changes?
I hate saying this, but there is a reason people (especially governments, security conscious organizations like banks) use Microsoft or IBM. So they donāt have to worry about all this. Meteor provides a single complete and secure code base. And man, is it well-coded!
Now maintenance is an issue, we need to solve this. And MDG are dragging their feet on community involvement. We are toying internally with setting up a fund to finance Meteor with other companies so that we are not dependent on a single entity.
I keep hearing this - what does this mean? Issues are triaged and PRs are being merged more diligently than literally any time in the history of the platform. Itās easier right now to get involved in Meteor than it has ever been. What kind of involvement are you looking for? What does maintenance mean to you?
4 Likes
Seconded. @ramez I updated the (fantastic) thread you kicked off about community involvement with a big effort on our part to clarify the project structure and give concrete steps to getting involved with the project, and received almost no response from people who had previously indicated their interest. If you feel that wasnāt the direction you wanted, it would be great to respond to that post with your concerns.
Also, Iām calling out that this thread is veering off-topic from its initial subject. Want to avoid these threads that are a big venting pile-on and donāt focus on solving particular issues in the framework.
3 Likes
Are there examples how to build Meteor microservices? Iāve been interested in this for a while, Iām not sure if you can or should build microservices via Meteor or if you should just use node or something else to build your microservices.
Thanks @sashko and @thea for weighing in. First, a major milestone is the NPM conversion. I understand itās secondary to build times (as per prior post), but many of us feel this is make-it-or-break it moment for Meteor. Second, (official) Apollo integration would also go a long way as it would bring it all together for MDG and us. I do sympathize that itās a lot of work, but thatās what Meteor needs to stay alive. Third Atmosphere, where is it going? We get messages that it will get deprecated then news stops. Do you think people will keep creating packages if you tell them you are dropping the package manager?
Itās often all about perceptions. I saw a post go by where people were doing the math so see how many people are working on Meteor, and that picture alone was scary (of course, we need to remember that Meteor is mature). Do you expect new devs to start with Meteor with such a picture?
Now in terms of community involvement, while I do appreciate the effort, I havenāt seen an uptick in involvement by my peers. I am guessing because itās still complicated. Iāll go back and check. It took a long time to get things going, so I got distracted by other work. I honestly believe the way to go is to literally hand off portions to the community. We had a list of people interested in things. Empower them!
Now in terms of the fund, I think it could be an idea! If we set bounties to fix things.
And finally, I honestly think a big part of this is perceptions. How come we are not hearing from @gschmidt that he still cares about the platform, why no news updates on the future? Last time he came around was to tell us he is dropping Blaze in favor of React, then he minced his words. All we see is a roadmap on GH that says āwe are converting to NPM and then moving onā (thatās what I read, and likely others too).
1 Like
Not that I know of, but you can think of it just like building a straight node.js app except you are using Meteor as the build tool. That is basically what we have done. Using Meteor to build the app not only allows us to share business logic code across apps, but also streamlines our automated build/deploy process to Galaxy.
@ramez we do need to update the roadmap more regularly - currently organizing an effort around that with @sashko.
Thereās a bit of a paradox weāve been running into where the community both wants more information about the long-term direction of the project and to have a shorter cycle between communication and actual product development. This is particularly true with initiatives as complex as transitioning to npm, where weāre working through a living and changing set of dependencies, along with changing internal priorities. Weāre still finding that balance, but always plan to communicate when we have any concrete plans.
Though he may be over-represented in GitHub stats, Ben is hardly alone in giving deep thought into how to best serve Meteorās current and future users. Working out these complexities is something the entire team is involved in, particularly as products like Apollo Optics and Galaxy are built on Meteor.
We also canāt force people to contribute to Meteor, but we can and have made it very clear how to get started in Contributing.md, and will continue to work closely with anyone who expresses interest in getting involved, as well as better surfacing good opportunities to contribute.
With that, Iām closing this thread. If anyone would like to create separate topics to discuss any of the particular issues brought up here, you are welcome to do so. Please keep them focused, friendly, and easy to navigate for those who use this forum as a resource.
6 Likes