Is it time to leave Meteor & MDG?

[tastemeru]

Non-professional dev opinion here:
For me important that everything just works and development goes smoothly and easy, it was as this before 1.3 version, a ton of docs on blaze and meteor and blaze as MDG product was always well suitable with meteor. But then, MDG announce deprecating of blaze and switching to react. Okay, after few month I think I understood react and love it, but still, struggle with integration. Meteor guide written with blaze in mind, react part, to be honest, using not the latest and best react way practices and you should dig the internet and collect piece by piece the information and figure out how to integrate this with the meteor.

Now it seems that meteor is unbalanced. I really wish that MDG collects all pieces together and make a great full stack framework again with react, apollo, meteor, etc. Which just works from the box without digging the solutions for this and that.

P.S. I don’t see anything better among JS frameworks to switch from meteor and I will wait until this dark age is over. I believe that meteor will be great again!

[dinos]

Today, I agree that things aren’t perfect - for example, the build tool could be faster, and it can be a bit awkward dealing with two package systems in the same app - but Meteor developers can now definitely take advantage of the overwhelming majority of cutting-edge JavaScript technology available today. Meteor is infinitely less a walled garden today than 1 year ago and more so 2 years ago, specifically because we felt it was necessary to enable the community to keep up with the breakneck speed of developments in JavaScript.

So why on earth is Apollo beeing thrown into meteor? Instead of running the the rat race of keeping up with the JS ecosystem, make meteor a part of it first.

Meteor is Node. Node is JavaScript. And when people say, they can’t use another DB than Mongo with Meteor, than they either mean “they can’t use another DB reactively with Node” - which at this point, Apollo can not do either - or don’t understand that Node.js supports all DBs since ever. There is literally no change in value proposition.

Empowering the JS Community with meteor via fine grained availability of npm packages (resembling meteor) and than targeting special areas (such as Apollo) would take down pressure on so many ends instead of stressing limited engineering power for X and Y. For example, if the (terrible) meteor build tool does not keep up to expectations, it can be switched out by something else - leaving other aspects of meteor (node) untouched, while staying compatible to npm infrastructure.

The constant change in roadmaps is really a let down. If there is a wish for growth, make sure people can do a npm install meteor and gradually adapt the system. Than Galaxy can serve as the soundboard of high performant reactive apps.

[dinos]

Man, you really need to stop your transactional thinking. Open Source is a Multi-Sided-Market.

Just like the case of Whatsapp: “We” - the “user” - do not pay money, but rather time and dedication. That in return creates value for other players, who may monetize “us”.

So your comments are not really helpful here, because the community is not the place to monetize the product, but the reason that a product can be monetized at all.

[vladimirj]

MDG claims they want to be like Microsoft’s .Net and Java of the JavaScript world right? They’ve given talks where they say this much (I can find a link if you like).

I also remember that presentation and have been wondering how’s it been going so far regarding penetration into big Enterprises.

[harisvsulaiman]

I like Apollo and the freedom it offers in terms of databases. And at the same time understand that people are frustrated that the parts publications, blaze are possibly being deprecated . js community is fast moving and we need to embrace that. When we build apps for Clients make sure you take in to account the extra work maintaining it if u depend on the is stack .

Meteor is modularising and its a good thing. Maybe in the near future there will simply be Apollo and meteor accounts. And meteor build tool might not exist. Webpack or any other might replace it.

We just need to know the future risk and plan accordingly. At the same time appreciate MDG for their hard work esp @sashko @benjamn who interacts with the community ! Awesome work guys.

[aadams]

A slight sidetrack:

We tried using MUPX which is built on top of Docker. It was great as we were learning the ropes, but then moved away when we started knowing what we are doing

I’m on Meteor 1.2.2 and use mup to deploy to an EC2 instance. When I upgrade to 1.3.5.1 and use mup, the setup passes but the deployment fails. I haven’t tried mup, but here that devs are having issues using that when moving to 1.3.

I haven’t tried mupx, but the only success I’ve had was using vanilla docker 1.2 for mac and following these instructions.

Now I’m trying to learn about docker and deploying that to an EC2 instance – but this is a real pain and I’m not sure this is the right route for me yet.

It was so simple when everyone was using mup, and it just worked.

I’ve opened threads about this, but no one seems to have the answers (or is talking) when it comes to deployment.

All this has side tracked my upgrade efforts to 1.3 and my migration to React/Apollo. I hope the community can get the upgrade path and deployment story straight in this new NPM/Apollo era.

[ramez]

@aadams,

Meteor is now moving towards production and enterprise. I therefore expect quite a bit in the ecosystem to move in that direction. So MUP, Cluster and all that were (in my opinion) hack-like technologies. I can’t imagine real production working that way.

Deployment is a big deal. If you have a sysadmin on hand, they will likely have a deployment system setup like the one we had proposed in our Github repo (https://github.com/ramezrafla/meteor-deployment). In fact, meteor has a deploy command for Galaxy. All this is painful, I know. 99.99 uptime is indeed a challenge.

[aadams]

If you have a sysadmin on hand, they will likely have a deployment system setup like the one we had proposed in our Github repo (https://github.com/ramezrafla/meteor-deployment).

Right, I reviewed your scripts, but on a fresh EC2 instance, where’s the script to set up the environment (i.e. node, npm, fibers, etc.)?

In fact, meteor has a deploy command for Galaxy. All this is painful, I know. 99.99 uptime is indeed a challenge.

Galaxy is way too expensive for my small startup mate. I’m going the EC2 route, where I can get a hefty box for cheap. I’m on the fence when it comes to the remote mongo installations – they’re very expensive for the resources you get.

[aadams]

the community is not the place to monetize the product, but the reason that a product can be monetized at all.

Brilliant!

I’ve never heard anyone put it like this. I have a different perspective now. Thank you.

[SkinnyGeek1010]

Sometimes you have to…

[marktrang]

Thanks for the supportive words!

Keep in mind that the discussions that happen here on Forums represent only one facet of the “the Meteor community”; we also take into account direct feedback from paying customers, official consulting partners, and lots of datapoints from other channels (e.g. Github, Slack, broader JavaScript community). As a result, sometimes our decisions or strategy may not totally serve the demands voiced here. It’s not because we don’t care; it fact, it’s quite literally the opposite. We’re a fairly cerebral bunch here at MDG and make practical decisions based on a large (yet sometimes incomplete) dataset about the software market. In order for MDG the company to maximize adoption of our open source projects (Meteor & Apollo), we sometimes need to make decisions that aren’t popular among some long-time community members here on the Forums.

I’m also not totally sure the the Meteor community wants or understands how to “make sure MDG is staying profitable and healthy”; my posts on this thread are an attempt to illuminate some of the complexity of balancing our open source and commercial strategies. Specifically on Apollo, I can assure you we’ve been building monetization paths since day 1 of the open source project as we’re already generating revenue from tools and services related to Apollo/GraphQL.

[a.com]

For Apollo, the core technology is GraphQL. We think that anyone who builds stuff using GraphQL is going to need some GraphQL-specific tools to manage their app. So at the end of the day it’s not about locking people in - it’s about building great new tools that people can use to improve their workflow, because modern apps have more complicated architectural requirements.

lock-in was a poor choice of words especially in the tech community where it has a particularly negative connotation.

I meant more “attract people on their own free will to use MDG’s paid services/products”.

[hwillson]

Is it time to leave Meteor & MDG?

No, but I think it’s time to leave this thread … reading and digesting all of the great points in this thread is seriously hurting my productivity …

[alawi]

In my opinion MDG is doing the right thing.

Like any other business in a capitalist market they need to adapt, evolve and grow as the market and ecosystem evolves. They’ve sensed the risk from React.JS, GraphQL, Angular.JS, NPM, etc… and concluded that it’s difficult and more importantly unnecessary to compete with those emerging open source communities so they embraced them. And to their credit they’ve been transparent about their decisions, they’ve communicated their roadmap and they’ve kept their backward compatibility. They’ve also modularized the framework to make it easier for the community to maintain going forward. So to sum up, they need to adapt and grow their business just like any other business and that sometimes involve tough decisions and compromises since they’ve a wide user base to serve.

So what about all stuff being ‘deprecated’? well these are open source libraries, the code is available and if many people need it and depend on it, then I think a community will emerge to maintain them. I personally appreciate what MDG is doing in adapting to the ever-evolving ecosystem, brining the best of what out there so we can actually focus on our business.

So relax my friend, we’ve something that works today and open source, and there are exciting stuff on the pipeline, yes you might need to learn new stuff, yes you might need to refactor some apps, but that is the nature of JS ecosystem, the tradeoffs of being cutting edge and innovative is the necessity of constant change and learning.

Just sharing my opinion!

[vigorwebsolutions]

Haha, the conspiracy theorist in me says that MDG has been intentionally not fixing build times to increase forum activity…

[proyb2]

I have developed music using AIR and shelved the project after a year of wiring code. Not due to performance issue, it’s frustrated how Flex 3 is almost unheard in Singapore, likewise, Meteor and Apollo as well.

Adobe AIR is not a framework (runtime) and not the leading, Swift and Objective C programming language is the leading. Look at the jobs availability and iPhone has the largest market share in Singapore.

[proyb2]

Whether to leave or stay is largely depend on the community you have. It’s also makes sense at this period, lot of technology transform significantly.

Swift
Java
Python
Javascript
RubyonRails
Go
Rust
PHP
Some Javascript framework.

Whether it’s worth the investment, Java is the safest, RubyonRails, Go and Python are popular. e.g. Kickstarter stack are built on RubyonRails.

If you have a good knowledge in Meteor’s internals, you can contribute to it, that about it.

[ignl]

OK so I would summarize problem points for meteor right now like this:

1. After 4 years Meteor still feels amateurish (looking from java world perspective). They are delusional if they think they can get any big traction in enterprise against java and .net ecosystems. Documentation, support, partnerships, products, integrations, stability, legacy, the way enterprise moves and the way decisions are made etc… Lets just get real.
2. From innovation and leading they became simple followers chasing the last “best” technology. That creates uncertainty and show they are not confident in their own product. Which leads to # 3
3. “Old” Meteor seems a bit neglected and it looks like most of the things will be deprecated. And if stuff you use is deprecated then definitely you need to use something else.
4. Even for things that are added documentation is poor and it’s hard to find out how they work. I personally got stuck with ddpratelimiter (how to make a global rule for all methods?) and pollingInterval/pollingThrottle (https://github.com/meteor/docs/issues/72). But that’s probably side effect of # 3.
5. Third party meteor packages are mostly unmaintained now and any development/improvement completely stopped. That’s bad. Very bad.
6. Meteor is slowly loosing its "easy to use and productivity “features” and it’s bad because that was one of the core selling point.
7. Not solving some important problems like those f** build times. I still see posts about those infinite reloads (which is a huge issue if that is still happening). Not sure if it’s just me and my setup but stacktraces are often worthless. Pretty sure performance and scalability could use some work too.
8. Not that good tooling. I personally absolutely don’t understand why profiler was created and monetized by a third party. When it was closed ecosystem tooling was an obvious place for monetization. Meteor IDE, Meteor debugger, Meteor Profiler, Meteor deployer, Meteor load balancer, Meteor production monitor, Meteor app store for paid packages… Now there isn’t even official support on how to deploy an app on server (not on galaxy). Good luck with enterprise.
9. Lack of communication about this transition. Yes MDG kinda provided information, but that’s not enough. They need a marketing guy or maybe PR firm. I think that could possibly make a difference from “is Meteor dying?” to “I’m so pumped up for 1.5 and apollo I can’t wait”. Unless of course apollo is not what users want. I asked here on the forum about a clear explanation of what value does apollo bring over just using facebook stuff and even asked one MDG member who seemed to answering questions in one of those “meteor is dying” threads but really got no answer. So I am not sold. This is a critical moment for the framework and MDG needs to learn to sell now. Hire a marketing guy.
10. Because of some or all of those reasons the biggest problem - loss of confidence. That’s why 3rd party maintainers are leaving and all those threads are popping up.

Oh I wrote more that I thought I will So after all this - is it time to leave? IMO it’s no. If it worked for you before, it is working for you now. Framework is still moving forward and in 1.4 we have got node4 and mongo 3.2 which is nice. We can still use “old” meteor and be productive. Now let’s just wait until transition is completed and then we will see. However even if it’s not a time to leave I would also not enter right now because of all those reasons.

[lesparte]

I fully agree, especially on points 6, 9 and 10. I’m President of an academic department in digital humanities. I was the first promoter of Meteor to my colleagues. Students with no heavy background in IT need a framework easy to grasp with good documentation, sandbox, easy deployment and a great bunch of open source examples. Meteor had a lot of those when I started, less than two years ago. Quite everything is gone now, and MDG never looked really concerned about it.

Like other people here, I hope those are just turbulences. I’ll stick with meteor for one more year, but I am sadly looking at alternatives and will be really cautious recommending it to our students.

[JimmyKeesee]

Meteor needs to redouble on its current products and rethink their strategy. Apollo is a great initiative and deserves the investment. That said, Focusing too much on the future and not on the present will continue generating these types of thread and discussion in the community.

I wrote an app in meteors early days and it was a pleasure. I sat down, drew a few diagrams, read a bit of documentation on blaze, installed a few packages and in 30 minutes I was writing code that pertained directly to my needs. 3 days later I had a testable application and didn’t need to write much code that didn’t pertain to my particular application logic. Like many, I thought meteor had hit a sweet spot.

Now we are on react. I think that’s great. React is wonderful to use. a bit more boiler plate than blaze, but well worth it. Last week I sat down to write a meteor react app and let look at how that experience went.

I sketched out my app, did some reading on meteor/react integration. Then I sat down and started writing. Set up some collections, worked with both create container and tracker react to see which appealed more and picked a direction. Getting data in and out was still a piece of cake. That’s good news. Data to react seemed reactive. all good. I picked flow router and that worked well. so far so good.

Then I tried the login packages for react and they were all crap. I had to write my own. Then I looked at integrating a few custom components and had issues getting Meteor.User as a reactive source. More headaches. and a ton of other small headaches.

The point is it was a different experience this time around. I spent significantly more time writing boilerplate and components that didn’t apply to this specific case. There was no magic any more. It left me wondering why I was using meteor. Elixr or horizon would have been a better solution. At least in those cases I wouldn’t have had to deal with the headaches of React/blaze, flow, react router etc.

Meteor needs to (IMHO), Pick a direction and fully support that. that means…

If you support react and include it in your documentation, then support it. Take the time to create all of the key packages, or throw bounties out to give me user packages, form packages, etc that give us all the same experience we fell in love with the first time around. Don’t document that I need to wrap a blaze component in react. It feels like a hack. I shouldn’t have to install blaze at all. That’s the whole point of react. You react documentation shouldn’t include blaze for a new project. the current document is find for hacking a transition together, but not for a NEW react/Meteor project.

Key point is, that MDG needs to take a step back and remember why many of us fell in love with Meteor. At the end of the day it wasn’t blaze. Blaze was just easy to pick up and then we were off writing our code. Our code. COde for our app. That wasn’t the case this time around, beyond the authentication example I gave above. Just my 2 cents.