Or “Crater” which is the thing a Meteor is destined to create.
All,
I honestly think this kind of conversation is hurtful. Meteor has progressed well and I don’t see much breaking change. We haven’t yet put imports everywhere and all is still working super.
I had a conversation with @thea from MDG (great one actually) and will shortly post the minutes (been busy at work).
Short summary (my wording): we should stop complaining and start doing! The plan is for the community to take on more work for Meteor so that MDG can focus on Apollo. We have a great base to start from.
In terms of all those stale packages, I am suggesting that we filter key ones out and make sure they are maintained (especially all those NPM wrappers), and then many of them can become optional in the meteor github repo.
As we all have daytime jobs too, community work will inherently be slower - and that’s ok. Something bugs - PR it!
Edit: I am not saying MDG is dropping Meteor, I am saying it’s a lot of work. We should be active members of the platform.
3 Likes
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.
3 Likes
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.
1 Like
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.
5 Likes
Really? Who? I think they’re still here!
I don’t start new projects in Meteor. All of my new stuff has an Elixir backend with a static React frontend. 
5 Likes
Using the same, nice combo 
2 Likes
Off-topic: what’s sharp?
Sharp is an optimized Image manipulation library. The authors claim 4x vs imagemagick.
They have a solid API backing it up. Really cool work.
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 think 2.0 could:
- drop old (5 rules based) file structure and use only ES6 imports
- have tide integration with Apollo and GraphQL should be recommended way for data (not DDP + Minimongo)
- be install-able via npm and even could drop atmosphere support (or it should be deprecated)
- have build-in server side rendering
- webpack as build tool (?)
3 Likes
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.
1 Like
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.
5 Likes
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).
Time to close this thread now?
4 Likes
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.
4 Likes