Is it time to leave Meteor & MDG?

I think UserAccounts is one of the important meteor features

2 Likes

Pfffff, passport does it too and its better in some cases)

1 Like

Brilliant post mate, the entire post.

Love this paragraph:

I have a business to build with software that works on Meteor-classic. It’s really hard for me to attempt to rewrite my app in React/Apollo. It will cost me time and money. But I hear it will be more maintainable, more scaleable, easier to reason about. I don’t know about you-all, but I have what amounts to a large application at this point: it’s a dream to maintain and reason about. I don’t know about scaleable, I don’t think I’ve really pushed the limits, because my clients never have more than 100 concurrent users.

But at the same time, I don’t want to be stuck at version 1.2 or 1.3 forever. Yet since MDG is going to replacing Meteor-classic with the Facebook stack, an upgrade path is a path to React/Apollo, and therefore for me a path to a rewrite.

Now that the deployment story has broken down after 1.3, with mup and mupx broken for the most part, even my so far small attempts to move to the newer versions of Meteor in oder to prepare for a future React/Apollo upgrade have been stymied for now.

MDG if you’re listening, and you want legacy/classic users of Meteor to migrate to Apollo, please help fix the deployment story as mup is broken and therefore I cannot move to 1.3 (and I can’t use mupx aka docker containers because of my file system requirements).


UPDATE:

I got 1.3.5.1 working with meteor-up-classic. The project basically picks up where meteor-up version 0.11.3 stopped – adds support for Meteor 1.3 – and no docker!

4 Likes

reading all these kind of threads, reminds me that lately I have only one big questionmark (that feels recurring in this thread as well), which might help prevent confusion for a lot of people… it is, “what is Meteor today”. As in, what should we ‘forget’ about the past what it was and what should we know what it will be in the future.

3 Likes

Perhaps much of this is legacy talk, so for those coming into Meteor now, theres not going to be much difference. Even Telescope is now a “React and Meteor app platform”. This means that your path is clearer than if you had a meteor app to maintain or now rewrite.

I also don’t understand the need for condescension towards velistar above:
-ad hominem is a logical fallacy

  • it’s neither persuasive nor productive
  • if his guesstimate includes FB aquihire and platform termination among ‘failure’ outcomes, it’s not so contentious. We are all aware of the stakes VC money spins on
1 Like

In was a real fan of meteor untill I found feathers.js. Finally an open source and modular alternative to meteor that builds really fast and is eazy to learn. It works on express and other popular technologies so its really nice! You should try it and maybe be saved from the meteor storm thats gonna give you a lot of headake

4 Likes

It’s super hard for me to say Flex is good code - it was written in AS1, ported to AS2, then badly ported to AS3 in a way that never matched any of the AS3 best practices, now it’s even cross compiled to JS - it was bloated and slow, and hard to deal with.

Flash was Okay, but had a TON of technical debt, it’s scripting engine is based on a fork of Mozilla’s Spidermonkey, a fork that Mozilla doesn’t have a hand in (because the JS community largely dumped ES4 on which AS3 is based), and as a result has none of the most important optimizations from the last few years, and so has fallen way behind the other JS engines, and was mostly private source and proprietary (much of it licensed to Adobe from obscure third party sources). I loved Flash back in the day (my name was in the Flash Pro about box as a top beta tester in one of the CS versions), and I have a lot of respect for what the engineers at Adobe tried to do, but it died for a reason.

1 Like

My opinions that choosing Javascript frameworks should be the students’ choice/preference and should be self-taught/online courses. I don’t recommend MeteorJS to be taught in schools where they can’t risk learning full stack framework when the frontend technology change year by year, will there be a new frameworks pop up?

MeteorJS is overly complicate and lack of communications was surface some time ago, indeed, without a proper working modules and plugins, it’s an expensive to maintain and time-consuming to debug problem during productions.

Why not teach FP, OO and POP using Swift 3? We have a great time communicating on the development with the Apple team and developers from all walk of life are extremely valuable and improve language clarity year by year better than sticking to Javascript.

Functional programming with Protocol Oriented Programming is a valuable and easy to master than Scala and Ruby On Rails.

Web framework similar to Laravel :heart:

Building Pokedex, :heart: it!

Well, we know a few high profile developers never posted Adobe Flex anymore, switching to any languages that supported functional programming. This paradigm helps a lot for every projects reduce complexity. Mediator patterns in Flex is crazy complicated, that not the way developers should write.

  1. In software, the ability to change, adapt and innovate is critical
  2. Since the core parts of the stack apollo is designed to address are abstracted away from the meteor developer, as long as a clear migration path is provided for those who have bought in to the current ecosystem is provided – it should be a good thing*
  3. I’m not excited that the view portion of the stack is so sharded – blaze is great, react is where the community wants to go, angular2 is what I want to use – But a path to getting there is not clear, as it renders a lot of the current atmosphere based packages useless
  4. Javascript (the community) in of itself changes every six months, so I’m just not surprised

I’m happy that MDG is moving to the future but the communication of their endgame kinda sucks

  • I put a star by this one, because I hope the MDG realizes that not a lot of “full stack” meteor developers have operations experience, so managing a graphql/relay server/stack is not easy

I don’t think so.

The product is still improving. It is well funded and has great individuals working on it.

5 Likes

:fireworks:

Break things and move fast.

I think MeteorJS is moving fast, and also actively & positively embracing the ecosystem, integrating with webpack, react (native), npm & many other very great tools.

Meteor is evolving towards the right direction and in a fast pace with a community of high talents, I believe Meteor has a bright future.

5 Likes

Reading this thread just repeatedly reminds me of this:

http://www.cad-comic.com/cad/20151030

8 Likes

I’ve been an avid reader of that webcomic since I think 2008? It’s a video game centric comic which does all sorts of one offs about things that pertain to gamers. This one was done late last year, after there seemed to be one “gate” after another in rapid succession. Since then I’ve just kept this particular strip around because it’s relevant so freaking often!

1 Like

for everybody’s convenience.

7 Likes

OMG Yes, so much this! Thank you for “fixing” it!

1 Like

3 posts were split to a new topic: Feathers for data fetching

Hey @kaiyes I looked up feathers js that you had written in the comic. And I just watched this on feathers js, very cool.

This makes it more clear why MDG is now pivoting.

1 Like

I read on crater.io that the pace of MDG’s dev has been slowing down significantly. Is it true that the project is down to one MDG team member focusing on the product and for 1.5 that focus is 100% Apollo?

It would almost be worth it to leave Meteor just to be free from debates about leaving Meteor.

10 Likes