I don’t hope so, I would really like to support MDG, but they don’t deliver anything I would need (except the framework).
Application debugging → Kadira
Hosting → Own VPS servers, each project has different specifications, even the server location plays a role. We also need to install some packages (like ffmpeg) on the servers, so Galaxy isn’t an option. Never got it why Galaxy wasn’t developed as deployment solution with additional hosting offers. This would reach much more developers/customers. Now it is a hosting solution, only satisfying some customer needs.
It’s not a possibility at this time. I’m just saying for every project it’s good to have diverse investment - I think I phrased it in an overly dramatized way. In fact we’re currently hiring new people to work on Meteor.
@sashko, that is big news. Would it be over the top for me to start a new thread here titled something like “Big News: MDG Hiring New Meteor Developers” and linking your post in this thread?
I don’t think it’s big news - we’re pretty much hiring most of the time, just like many other companies. But we’ve had more success with targeted outreach, for example people who are already active contributors or proactively reach out to us directly.
I understand of course. At the same time, very often I see people here and on Meteor-related Slack channels saying ‘we know that MDG has abandoned Meteor because they only have one single developer working on it. Almost all their developers are working on Apollo.’ This argument has carried a lot of weight with Meteor developers, convincing many that MDG is pivoting away from Meteor and plans to abandon it. It is a big contributor to the doom-and-gloom posts on this forum.
It will be very reassuring to many Meteor developers when they hear that, on the contrary, MDG is hiring new people to work on Meteor.
Most of what I’ve seen or heard in the past seems to run contrary to what you are saying. We hear things are changing, but the team needs to do X, Y, or Z first. I think many are moving on because other tech is moving faster, easier to work with the OSS team, and makes more sense in the long run to invest in smaller libs instead of bigger frameworks. I think most of MDG would agree at this point, given how much time/money/energy is spend on the OSS library Apollo… I mean, Geoff has changed his title on the GraphQL presentation to founder of Apollo.
Perhaps it might be possible to read too much into that. Geoff is founder of both MDG and Apollo. Clarification from @sashko would certainly be welcome.
@joshowens Geoff used that title at my suggestion because he was representing the Apollo project and team, our GraphQL-based project, at a GraphQL-focused conference. Also, to avoid confusion. However, he mentioned being the founder of Meteor and MDG heavily in his keynote, if you had a chance to watch it.
Most of what I’ve seen or heard in the past seems to run contrary to what you are saying. We hear things are changing, but the team needs to do X, Y, or Z first.
@sashko was referring to our outreach to potential hires, not contributors. Still worth mentioning that there are currently clear paths to get involved in the project. While this hasn’t always been the case, and the pace of change might not be what everyone might like, there’s nothing preventing anyone getting started as a contributor today, and we are hugely grateful to those who have done just that.
Meteor is possibly the farthest thing from a “small library” in the whole JavaScript ecosystem. Focusing on small libraries is a very valid approach to development, but not one that the Meteor platform is built around. I agree it’s great that Apollo is built to be more modular from the start, which we think will make it easier for people to contribute and build new components.
Parts of Meteor would definitely make good smaller libraries, and that’s something we are trying to work on when we can. But the main priority has been to preserve compatibility for people with heavy investments in Meteor in large production apps so that they can continue to get new features and performance improvements without having to port their whole codebase.
I think that has come with a cost of some thought leaders moving away from Meteor to newer and faster-moving projects that are more configurable and support some more modern features, but IMO working hard on backwards compatibility and upgrade paths is the most important and successful principle of Meteor as essentially the only full-stack batteries-included JavaScript framework available. The fact that Meteor devs can have code from 3 years ago live side-by-side with CSS modules and React in the same app without having to set up multiple build processes is, in my opinion, a monumental achievement, but understandably not something everyone needs.
Please know that this is massively appreciated by some of us in the community. I’m actually in awe of what has been achieved in this regard.
Couldn’t agree more. I’m one of the beneficiaries of this, having had a project in production with Meteor versions from 0.5.7 right through to 1.4.2.3, with no refactors required that were so big they made me give up in despair.
Tons of to @sashko’s comment above. Really nails it.
For me, I’m still so much in love with Meteor. There is simply no other framework/tech I’m this productive with from day 0, and that I haven’t outgrown. I like the stack (the “backend” and Blaze) and the ease of not having to configure a Webpack config for everything.
It would be a very sad day if the Meteor I know and love goes under. There are very smart people at MDG, and Meteor is very high tech under the hood. I appreciate their hard work every single day.
This should be pinned somewhere visible! Almost flawless backward compatibility is one of the big things that makes Meteor so special. Low learning curve comes a close second.
This framework is the most reliable tool we ever worked with. At illustreets, we are very thankful for it!
Yes stability of the system is prime importance to us as a company. We have a big production application running at various customer site and we do need a stable framework. We can work around big changes but not at an extreme case as it is really difficult for us to update customers just because underlying framework has changed.
This is may bother people who want to live with the cutting edge but with companies invested heavily in meteor and with a on premise product it would become a nightmare if the framework changes every few months. We would love that meteor moves totally to npm but not at the cost of stability.
@joshowens Sorry Josh but what you are saying can also backfire. If we invest in smaller libraries to create our own environment and if the contributors leave for new shiny things than either we maintain those libraries or go look for new ones.
Spring in Java is a huge framework which is well maintained and i would choose that before any small library. The main reason is that it is at least maintained.
I suggested small as in focus, I think you are talking small as in mind-share. I say go with the herd for many choices, React and Angular are solid examples of what I mean…
Pick things that seem like well established communities moving forward. Meteor moved slower than Webpack because they had a team of 8+ focused on many aspects of the framework. The webpack team had 2-3 people focused on 1 core piece of the stack.
While tailored integrations are super nice at the start, I am starting to think they limit you in the long term because you end up with a bunch of legacy stuff that you feel you can’t change easily.
I think the core issue is that smooth integrations let you get started fast without having to learn a lot, but then you still have to learn all of that stuff if you want to tweak something. So you end up doing about the same amount of learning but you do it later rather than up front.
I think that is something MDG has been extremely successful delivering. I really like the fact that I can just strip out core modules like jquery or blaze and install some npm stuff at will with the current meteor version.
I mean you can basically just remove all modules but ecmascript and use it as an extremely convenient build system for vue.js/redux/flow/rethinkdb/apollo or whatever crazy stack experiments.
I’ve built up a very small mvp in 3 days using insecure, autopublish and all the crazy magic packages and then seamlessly transitioned to a more advanced architecture and now we start to add graphql support to the same product.
In contrast: Tried to start up a 2 year old project I did with a grunt,bower,npm,express,loopback stack on my pc. After fixing the first 5 various exceptions I gave up. Upgrading? Impossible…
reading all @sashko’s posts in this topic (and in other topics as well ) I have the impression mdg should make him the official PR manager for the company. He’s been doing a far better job of speaking with community and explaining the latest developments at mdg than the person they are actually paying for doing that stuff (does that guy even read the forum?? )
I vote for Sashko’'s nomination!
to 
. I guess