Why would anyone want to contribute to Meteor? There is literally no roadmap, almost no communication between the dev team and community (except @sashko of course, he is the true forum hero).
Meteor was a magic framework, super fast to start with and create apps, with it’s ecosystem and ideas. During the last year, everything was changed - view engine abandoned, routers (any alive now?), new build tool (slow and lacking lots of features), package system changed, all meteor demos are dead, es6 & no global stuff, apollo is coming to replace ddp, most of the community packages are abandoned, etc.
It will never be the same it was, even most faithful devs are starting new projects w/o it. You can wear pink glasses and pretend that you don’t see this, but MDG has lost its interest for Meteor.
If Apollo will be an easy drop-in package for any framework, I’m not sure why anyone will need Meteor.
So I am not accused of trolling, I’ll answer this succinctly. You do raise good points (which are often raised from community)
Things did change, and many developers are using other frameworks. I see it as a settling of things. The hype has been replaced with good business judgment. MDG is divesting and it’s up to the community to take over (if it wants). Imagine if GraphQL works well, how complete the platform will be.
Routers? Plenty around, and they are mature (FlowRouter is working well with no bugs whatsoever, at least for us). KadiraHQ seems to have disappeared and left behind a nasty trail of unmaintained repos (this alone is a good reason not to use their platform).
Meteor still serves a very good niche. And I think GraphQL (reactive!) will be a game-changer for the platform.
Finally, most Atmosphere packages are NPM wrappers. We really need very few packages for such a mature core. In fact, many of those packages were to get around pub/sub issues (e.g. reactive pubs, simpleSchema etc.)
Case in point: we needed to generate server-side thumbnails for images on S3, it took us 30 mins with sharp to do it, all NPM stuff.
But what would a Meteor 2.0 even look like? I mean we already have es6 modules and npm support by now. Apollo integration, which is said to be livedata 2.0 is coming soon too. So if only the rebuild speed can be improved substantially, what would be left for a bc-breaking Meteor 2.0?
Here is my opinion on your question. I think you’re question and mindset are bias toward negativity. While a lot of the stuff you stated are true, and has been stated many times in this form already, but it’s a partial and negative biased view of reality.
MDG is encouraging people to contribute to the source code and they’ve been putting effort to make it easier to contribute meanwhile they’re also investing in future technologies that would benefit the community.
Core packages are mature and work, they get the job done. People in the community come and go, other people will step in.
Why would people want contribute to Meteor? because it’s still by the far the fastest and simplest way to get real-time reactive project delivered , and there are plenty of functional re-usable code out there… also because there are people who already built successful businesses on it, furthermore Apollo looks exciting and in my opinion it’ll extend the platform.
Therefore I think it would a much better conversation if instead of only highlighting the negatives…to also acknowledge MDG effort in encouraging and supporting people who wants to contribute, or provide a specific issue, or help by contributing, or provide a practical solution to those who enjoy the framework and would like to see it growing. Personally I think Meteor set the bar for developer experience really high, and I’ll evaluate future frameworks from those standards.
I think @SkinnyGeek1010 proposal to move into 2.0 with Apollo integration and moving toward npm,
After a half a year of django, koa and react+redux development I’m coming back into Meteor code to add some features into my old app (which I started more that year ago). And yes, it feels that ‘modern’ Meteor changed so much (and will change event more with adding apollo) that it feels like completely new framework.
I haven’t read the whole thread so apologies if this has already been mentioned:
Psychologically, the split between v1.x and v2.x has implications I don’t like. It basically says that Meteor Classic is a dead end which I think would be presumptuous and unfortunate given community efforts to take things like Blaze the next level.
I also can see barely any resemblance between Meteor Classic and what I’m seeing proposed as Meteor 2.0. Meteor 2.0 should start out fresh with a new name.
So, am I missing something? Meteor is so much more than data on the wire.
Apollo looks like it’s going to be great, but what about authentication, server-side methods, or sending email? Meteor makes all of this seamless and intuitive. Graphql will solve the problem of being locked-in to MongoDB, and will allow me to use the same query language with my non-Meteor projects, but I do not in any way see it as a complete replacement of the Meteor ecosystem.
As @moretti mentioned, many will still have need for a server.
I will also add the following, many of us contributors to meteor are using the ‘classic’ version, so by discarding us you are ignoring a large pool of developers who can add value. As well, we are interested (I speak for my organization) in integrating with future initiatives such as Apollo. So you want this developer pool on board, MDG has clearly signalled dependence on the community.
In short, buyer beware, you may not like what you get at the end. Write your code in es6, old vanilla js, just make sure not to exclude valuable contributors (who may be a big guarantor of the future of this platform).
Naming is hard, but why not use (sub)names instead of major version jumps? Meteor Classic 1.4.x can go 2+, Meteor Edge can start in alpha, etc. There could be X more Meteor-based stacks. Which means ‘classic’ and ‘edge’ are probably both too generic and specific, as it could apply to several stacks. Retaining the Meteor moniker could be useful, but then there has to be some meaningful extent of Meteor-specifics? What constitutes meaningful? Using the Meteor build tool? The Meteor API?
I feel what mz explained is what Meteor is in need of the most right now.
Also, as one of the other members stated, many users make assumptions simply because of a lack of information. If people don’t know what’s going on, it’s pretty natural that they think the worst. A lot of members here don’t really know where the situation stands (including myself, and I check these forums regularly).
With so many other things deprecated, or being updated, backwards compatibility being there but not knowing for how long, but may still be around in the future? Not knowing what’s going to happen w/ packages, or having any idea on how many breaking changes there may be & extra work needed to migrate to newer versions. It’s pretty scary to not know what’s going on with all this.
As you can see, many people are still worried about Meteor being replaced. This goes to show 2 things - 1) how little people know of the current situation, and 2) that the atmosphere is not one that gives users a “content” feeling that they are “safe” using Meteor.
I feel that is truly what needs to be worked on, for the Meteor developers sake. We need to know what to expect when these version updates drop - especially the ones that are deprecating old systems (such as pub/sub, or packages, etc), what exactly we’re in for.
Without knowing that, could anyone truly say it would be better to put together a “Classic” Meteor project or not? If there’s too many breaking changes, then yes, classic may be a better option. But if the community is worrying about something that won’t even happen, it would put a lot of users at ease.
This is also a big factor in whether people think of Meteor as a “toy” or not. If it’s nice to use, but not realistic to use in a “real project” as it’s going to be changed or deprecated in the future, it’s not going to be taken seriously.
Then think of all the users who come here intrigued by Meteor and know nothing about it. It’s not a good look if even the developers of live Meteor projects are not sure of it’s future.
Even myself - I’ve heard bits & pieces which help me relax a bit, but I would be lying if I didn’t still have that bit of worry in the back of my mind about what might happen in the future.
Ideally, I should be “excited” for the future of Meteor! I should be looking forward to all the new updates, features, & improvements. But really, it scares me far more than I am excited. Myself (and others on the forum here) have questioned whether it will actually be an improvement for our projects at all?
I believe that’s indicative of a big problem, a very big problem, that is likely affecting many other members of the community as well.
Which is a shame, because Meteor’s an awesome platform to work with. But that’s being overshadowed by all these other issues. Handling those issues through communication presents an amazing marketing opportunity for MDG, and would be best for the future of Meteor in the long run. Both current developers could be happy & have their worries eased, and new users could see how awesome Meteor is to use, with both sides excited for the future.
That’s direly needed imo. A little under a year ago it seemed the forums/voices of the community took a large turn towards negativity. Now it seems to be turning back in to positivity, but very slowly. I hope to see this speed back up, and for myself to be 100% comfortable with the situation of using Meteor for our jobs software platform going in to the future.
I would also like to note that, it’s been discussed earlier in this topic that the direction of Meteor changed a bit due to profitability. If Meteor wants to be profitable, what better way to ensure that then have happy developers? That ensures you retain as many current developers as possible, lets the community do the marketing for MDG (by spreading through word of mouth), and paves the road for future devs.
I tried Meteor when it first came out in 2012. I liked what I saw then, but worked for a RoR shop at the time and could not easily jump ship.
I’m back again now and can control my own destiny. My current project has a number of moving parts. IoT devices that collect data, a central user web app that manages accounts and associated uploaded IoT data, a mobile app that acts as a remote control for the IoT device, a mobile app that duplicates what the web app does, and then finally Virtual and Augmented reality clients that can grab data from an API provided via the main web app. Only the software that runs on the IoT device has been written and to some extent finalised, everything else I have kind of works but needs to be re-written from scratch.
I was going to use Django or Flask + frontend for the web app portion of my project. But I’m building the whole platform in a modular/microservices kind of way and so I’m actually not tied to Python for the other parts of the project.
So my immediate need is to build the multiuser web app that manages data and images that get pulled from the IoT devices.
This IoT hardware device is one that I have designed and built myself. It has a Flask (python) app running on it with a simple API for getting data out of the device and into ‘the cloud’. This will not change much. Also, I currently control operation of the device with a simple CLI based client that interacts with the device’s API too. This CLI client can be pip installed on any computer with internet access. Later this CLI will need to be replaced with a more user-friendly ‘remote-control’ mobile app and possibly a voice client (e.g. Alexa) using something like flask-ask. Sorry for all the detail, but I’m trying to get across the level of complexity and the differing non-web client apps I will need across my platform.
So the web app part of my platform will need to suck up the user data that gets generated on the devices themselves, by pulling data from the Flask api. The users will then have lots of other stuff they can do to manipulate and publish that data from within the web app. As data comes in from the device I’d like users to be able to see it appear in the web app in real-time. Hence why I’m looking at ‘reactive’ frameworks.
So I decided to research some of the ‘new-hotness’ frameworks like React and React Native. Whilst researching, I thought I had better check back in on Meteor again and see if it would be a good fit for some parts of my infrastructure. From what I’d seen in 2012 it seemed like a good fit for the web app portion at least. I also remember reading something about mobile app support a year or so ago.
So, on the face of it, I still like what I see with Meteor. It appeals most. But this thread has me a little worried and wondering where things are heading. Meteor 1.0, Meteor N + React, Vue.js + Asteroid, Apollo vs DDP?!?!! I’m scratching my head a little, but think I’ve caught up to the state of play.
Also, I am concerned by a lot of the negative sounding, perhaps warranted, posts I’m reading here. And this kind of rings true for me too:
That said, given my disparate needs, it sounds like Apollo could actually be a really good thing for me given that only part of my requirement is for a web app. What do you guys think? Is MDG and its suite of evolving products the right place for me to be looking?
Thaks for any insight you guys can provide. Also, it would be great to hear something more substantial from MDG ‘The Company’ regarding ongoing support for Meteor. I really want to believe
