Sign of Meteor in trouble: Workpop left Meteor (comes with 10 great tips how to leave Meteor behind)

[satya]

Seems that Workpop, one of the more famous and first Meteor-in-production companies (and contributors), has ditched Meteor.

Unfortunately another sign of Meteor being in trouble

However, one of their devs wrote a very interesting article how to leave Meteor behind. Definitely worth a look. I also think he has good points about Meteor lock-in and why they decided to move on.

This does makes you wonder if Meteor is nothing more than a rapid prototyping lean startup tool suitable for light-weight sites / apps.

[hwillson]

@satya

This does makes you wonder if Meteor is nothing more than a rapid prototyping lean startup tool suitable for light-weight sites / apps.

… that helped Workpop secure $7.9 million in funding …

[a.com]

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?

[diaconutheodor]

@a.com

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.

^ 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

[XTA]

@satya

This does makes you wonder if Meteor is nothing more than a rapid prototyping lean startup tool suitable for light-weight sites / apps.

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.

[abhiaiyer]

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.

[abhiaiyer]

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

[a.com]

I’d love to see more on this one:

4. Replace Minimongo/Tracker/ReactiveVar/Session

I haven’t been able to fully get into meteor with redux/MobX… not enough good resources atm

[skirunman]

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.

[abhiaiyer]

Thats awesome! Great thoughts!

Honestly if we had started our app in Meteor 1.2 and beyond things would be A LOT different!

[vigorwebsolutions]

Did I miss the sticky that requires us to use this to come up with forum post titles?

[a.com]

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.

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?

[skirunman]

Yeh, pretty much, but the apps don’t necessarily have to point to the same DB. This is a good overview.

[ramez]

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.

[sashko]

Now maintenance is an issue, we need to solve this. MDG are dragging their feet on community involvement.

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?

[thea]

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?

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.

[AndreasGalster]

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.

[ramez]

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).

[skirunman]

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.

[thea]

@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.