Is it time to leave Meteor & MDG?

Planet Earth
22

I think the fact that MDG is pivoting shows that they won’t die. If they continued on with Blaze and Pub/Sub subscriptions they would have made a great system for beginners and small apps… not medium businesses and enterprises

IMHO the best value add from MDG is to create a great abstraction over things.


  • If you compare Apollo server vs GraphQL.js, Apollo is far easier and more convenient to use.

  • Authentication can be hard and tricky to implement securely. MDG has made a great abstraction over that to provide a fairly seamless experience across quite a few authentication schemes. This also includes a password reset setup which emails out a reset link as well as binds a route to handle it.

  • Sending emails has been very easy. Their email package has worked out rather nicely

  • Fibers on the server has made my life easier for years. Today async await is just finally becoming an alternative, though it’s still not quite as nice as fibers.

  • Sending proper JSON responses takes some time and simple-rest provides a really really nice API to create JSON endpoints in a few lines of code (though not directly from MDG).

  • Deploys in vanilla Node are still non trivial. If you pay it you can meteor deploy in a few seconds and be up an running with no hassle. Their rates are comparable to other providers with similar services/conveniences. This is a huge win.


Historically there were some other great abstractions that… well… didn’t really work great. They work good but not exceptional for a lot of use cases.

I think in time we’ll see more abstractions over things like Redux and others to hide away the boilerplate (like Apollo does for GraphQL). I was hoping MDG would release an abstraction like create-react-app first but I understand the importance of backwards compatibility with tooling. I would expect them to have something similar in time (they know the build tool currently is not ideal).

IMHO Blaze was a great idea that didn’t really scale well (codebase wise) with global everything. Once you try to cover the last 20% the Blaze gets very complex and convoluted. Very few teams with large apps with multiple team members are glowingly happy. It becomes a game of whack-a-mole and don’t touch that piece or the whole app may break.

Publish/Subscribe works fairly well with simple resources and simple templates but once you layer on 10 more packages that start abusing the subscriptions it quickly becomes an issue with a decent load of concurrent users. Typically it just costs a lot more monthly, most of us don’t hit a bottleneck where horizontal scaling doesn’t work. I’ve worked on a lot of apps to speed up slow data responses. Cutting out pub/sub usually yields an order of magnitude or more of speed… just by cutting them out and switching to Meteor methods… which are almost 1:1 to a GraphQL mutation.



What’s nice is that if Blaze and Pub/Sub work for a project, we can still use it :slight_smile: I honestly think a community fork that is geared towards prototyping and beginners would be amazing. We could simplify Blaze to be as simple as it was in 2012, make more things automagic like autopublish since these apps (on this fork) are not geared towards heavy prod use.

31 Likes
23

I hope you don’t take offence, but i think your post and its title are downright counterproductive. Leave… what?

Pick anything that makes your job easier. Meteor and React today, jQuery, AJAX and REST tomorrow, Seneca and AMPQ the day after tomorrow. Next week come back and build something with Meteor and Blaze because, well, your next week’s job pertains to it. Or, to an extent, mash them all together to build services with different capabilities in your next distributed app. That’s how it works.

This is not a marriage, with MDG having signed a pre-nuptial contract with each one of us. You like what you get, you use it. No one leaves anything, unless the plan is to learn and know the one and only framework of a lifetime.

It is the way you write and structure your code and its components (modules, packages, services) that will make it future proof, not a particular framework being frozen.

Meteor is one of the smartest, if not THE smartest, paradigm to have surfaced from the huge and stormy JS world. Even at the most basic level, like HTTP calls, or Mongo queries, try a little bit anything that’s on npmjs.com and then you’ll se how quickly it gets hairy.

Apologies for the long rant, and again, I’m hoping that you don’t take offence. I think it is time that we, as a community, stop whining.

Rest assured, good code never dies.

22 Likes
24

OK my question would be what value does new meteor with Apollo bring over other nodejs stacks and frameworks? What is its wow factor? What is its uniqueness? You want more javascript developers - how are you going to “sell” them? (also you will need to sell again to your loyal customers after big changes) Why don’t they just use react, relay etc? How are you going to monetize it when there is such a strong competition of other free tools? If you can’t monetize even if meteor stack is better people might choose something else simply because of for example that it’s guaranteed that facebook will continue to support its tools without going out of business.
I think you are handling transition very well and I don’t really know if this pivot is a good or a bad thing but those are the questions I have about it. I believe “old” meteor could had all those answers and that’s why it got traction.

1 Like
25

MDG has already shown with its actions where it is moving. If you have not noticed it than you have buried your head in sand.

  1. They are not committed to blaze as they were before and that is a goods decision because frankly they cannot compete with React and Angular for developers mindshare. If you are gung-ho on blaze than they have kept it alive and asked the community to take it forward. It is counter productive for them as a business to invest in blaze when there are many important things to work on. If you are interested in working with blaze help with its development.

  2. They have to develop a new data layer to support other databases. That is the reason for Apollo.

  3. If you think you can develop an application better with NodeJS, Apollo and React than go ahead. Nobody is stopping you and actually you should if it fits with your vision better. You should always use best tools for your scenario.

  4. They have to move closer to mainstream JavaScript ecosystem because the pace of change in JavaScript ecosystem is too fast. If they don’t align themselves with it they will be left too far behind.

4 Likes
26

Have you heard of Flash, Flex, CakePHP, I can think of 10 more.

It’s not about choosing the right tech but really understanding the vaule of Meteor + React over Node + React + Apollo

Another example is the mean stack which takes a bunch of components to do the same thing that meteor does.

27

Again it’s not about what’s better but really understanding the vaule of Meteor + React over Node + React + Apollo

Especially if you need to use Apollo anyways to connect to a different DB for example will my stack now be meteor + Apollo + react?

28

From a developer perspective and a personal business perspective I’m completely for the move to npm, focus on Apollo stack and several changing moves. To me, blaze was a simple stepping stone to pick up meteor when I first discovered it. Personally I run React now, but both at the same time could have been hard.
Only thing I’m a bit annoyed with sometimes is that every new version feels like Python 2.7 vs 3.x.
It kinda works, but it kinda doesn’t. Always a breaking change. I’d rather stay on a solid version for a while(Although I really needed 1.3 because reasons!!). But I think I’ll skip 1.4 until 1.5 is stable. But please, do convince me otherwise someone!

I like the fact that you’re slicing things up and modularizing the entire framework. Making each bit less dependant on the others. However, I don’t see it from your perspective. I’m loving it, but you’re doing the complete opposite of a lot of other software tools/framework companies. You’re making it easier to leave you by not locking in. Which is a fresh, but unexpected tactic. I’m just wondering why? To focus more on core things and have a smaller codebase to maintain? Was your main goal Apollo all this time and not really meteor? Is meteor simply an unusual stepping stone to running a large hosting company? I can see the move for getting new devs, as it’s becoming easier to convert an app to meteor. But I really don’t see the long game retention!

1 Like
29

Since when has Flash been “good code”? :stuck_out_tongue:
A more security flawed framework has probably never existed in the history of computing. Besides maybe the PDF format…

4 Likes
30

The value of Meteor over vanilla Node Is simple. You don’t need to configure webpack or gulp or grunt. You get reactivity with Tracker or DPP. Later Apollo will also be included. All the build, packaging and deployment is handled by Meteor.

Now if you can do the above without Meteor than good for you. Go with plain vanilla JS.

4 Likes
31

The only thing really annoying about Meteor, is that using Meteor is still a take or leave decision because it’s not on npm without a path of incremental adoption.

Meteor is too big, too slow and too hard to integrate in existing workflows. If it stays like that much longer, we have a problem.

The long stated goal of bringing meteor to npm was recently delayed again to make meteor even larger by integrating the young Apollo project. Though I love Apollo, I think stated roadmap priorities got pretty screwed by now…

6 Likes
32

Let’s define Meteor ?
Is it the technology stack Blaze + Tracker + minimongo + pub/sub + mongo ? We all now ALL those technologies are gonna be deprecated in the not so far future.
Or is it just a build tool, designed to drive users toward MDG proprietary solutions ?

I have nothing against better/newer techs, but i don’t want to rewrite all my code every year because MDG is chasing the next tech which they think will bring them more (with deeper pockets) users.

33

Really? As far as I know, all software they make is open source.

You are not forced to update anything. You can just keep using the old stack if that’s what you want. I hear you think; yes, but security updates. Well… it’s open source, you can apply them yourself. Trust the community to do this, or pay someone so they can do this for you.

I don’t understand where all this hate is coming from. We have a wonderful stack called Meteor, and they make it for free. Or at least; I’ve never been charged for anything I use.

3 Likes
34

Thanks for being clear on that. I think there’s should be more openness on what being a VC-backed company changes because it would make some conversations easier with having everyone on the same page.
More precisely, can you share how this change things for feature prioritization ? I think earlier in this thread @dinos gave the example of how the move to npm has been delayed by Apollo which sounds like a good case where company growth has been prioritized over current userbase need (some might disagree :slight_smile: )

And also, what are the risk that someday Meteor gots acquired/close shops because this is what happens to a bunch of VC-backed businesses? Would we be left with an open source code that is not actively maintained? Do you have legal company constraints again that happening?

Don’t get me wrong, I’m all in favor VC backed stuff. And I think developers who make important long term choice with Meteor would be happy to have more clarity on that front, and just want to reassured there’s no reason to leave Meteor/be suspicious of where the project is going.

35

Overheard recently at a MongoDB sales conference:

Larry: Brad, I think only crazy people using databases other than Mongo would agree with MDG putting priority on Apollo integration over the move to npm.

Brad: I hear you Larry; that tiny minority of crazy non-Mongo people really, really annoys me. Oh well, another Mai Tai?

Larry + Brad: High-fives.

:slight_smile:

36

Galaxy is open source ?
Apollo optics is open source ?

You are joking, right ?

“hate” is a little bit strong.
Distrust would be more appropriate, in my case.

For how long ?

1 Like
37

@greblak, we programmed with Flash AS3 for a very long time and it was “great code”. You are probably judging from the days where people mixed AS2 and animations in the same file.

In fact, we had imports and classes long before JS did.

38

No, those services not. But you aren’t forced in any way to use them. See it as Cononical or Redhat, they make an open source product, but provide extra services so they can make a living to.

No I’m not. We don’t pay for Meteor as the platform. I’m not talking about services like Galaxy. Somehow people expect life time support but are not willing to pay for it.

39

So what part of “designed to drive users toward MDG proprietary solutions” don’t you agree with ?

Where have i talked about my willingness to pay or not pay for it ?
I regret that the framework i came for and which i liked will probably be abandonned in the future to be replaced by something else. MDG owe me nothing. But now contrary of what you said, i have to rewrite my whole app to something else, if i don’t want it be stuck with an abandoned framework. And it won’t be a tech depending on MDG.

1 Like
40

The example you and @dinos raise is a good one and can be simply explained by the fact that we are a small company and not immune to resource tradeoffs/prioritizations that occur in any organization that builds software. Sometimes the decisions we make aren’t universally popular or even immediately useful as we don’t solely exist to build open source features for current Meteor users. Deciphering the constantly evolving world of software (esp JavaScript) alongside a multitude of other datapoints is what goes into our decisions; we read the market and build products so that we can continue to grow as a company and expand the Meteor community. Prioritizing Apollo directly addresses arguably the single biggest objection to Meteor today - the lack of SQL support. We’ve heard this objection daily for years from both current users who can only use Meteor for prototyping (but never production) and from users/companies who reject Meteor outright. It’s not surprising that the current community may not care or get value from Apollo if you’re able to use Mongo exclusively. But in order to really grow the size of the Meteor community, we as MDG need to address objections to Meteor to continually attract new developers that currently aren’t in this Forum. In the long run, the more developers that we can attract will make the open source project stronger; this also happens to align with our long-term company growth goals too (e.g. commercial revenue). I’d argue that because we’re a VC-backed company, our decisionmaking will be always be easier to predict as we’ll almost always behave in a way that aligns to future growth (open source adoption + commercial success). If these goals and outcomes make you suspicious, you have a number of options as others like @illustreets and @suhaila have listed. Again, reaction/adoption by current Meteor users is just one of many important datapoints that we consider when making decisions about where to allocate our limited engineering resources.

re: risk of MDG begin acquired or shutting down, yes it’s always a possibility in the world of startups - open source or not. Like all open source projects, there’s rarely any “legal” guarantee of continued maintenance other than the project still being available (and probably worked on) in the community regardless of the state of MDG the company. Even if there were commercial agreements in place (e.g. long-term open source support contracts), the continuation of those services are usually determined by the acquiring company.

14 Likes
41

I wish we had the magical foresight that you imply! :slight_smile:

When MDG was founded, we never could have predicted the direction and rate of evolution in the software market and especially the JavaScript community. I’m glad you appreciate some of our decisions to modularize the framework as it reflects both a pragmatic view of where we think app dev is going plus a lot of work (esp by @benjamn) on our end to allow current developers to opt-in gradually. But I can assure you that although the MDG team has a lot of experience building distributed data systems, Apollo & GraphQL were not part of the MDG strategy in 2012. Like many of you on this Forum, we too are a small company; we make decisions with limited resources/information and try to quickly improve/iterate along the way.

1 Like