Thingking about Meteor 2.0 🤔

core
61

KISS: Keep it simple, stupid. This is Meteor’s main advantage and what is severely lacking in most other frameworks. Other frameworks grow and get more complex. But if you can figure out a way to make Meteor more flexible but maintain its simplicity, you’re golden.

In my opinion, it feels like many developers that got distracted with those “shiny” things are now taking a second look at Meteor because of its simplicity. I have talked to several who have heard of Meteor and didn’t invest in it on the first go around, but they are interested in it now or are waiting for an impetus to use it. There is also a lack of understanding how simple it really is, but when you start describing all of the things Meteor does, people get excited and become very interested.

So, speaking as someone who has built products that have reached millions around the world, here is my free advice, if you REALLY want to see Meteor on top.

  1. Treat Meteor as a first class citizen. It has not been one with Apollo. Meteor docs are always the last to get updated. If you want people to believe it’s the best, treat it like it’s the best.
  2. Do something unique between Apollo and Meteor that only Meteor can do or is best at. Maybe combine the power of MiniMongo with Apollo so you can read/write to a GraphQL endpoint simply by declaring the GraphQL server in the Mongo constructor. I’m just spit balling, but point is: make it so Meteor is the best to work with while using Apollo. You will take advantage of your growing Apollo user base and “upsell” them to a tool that will make them even more productive. And make it simple enough to especially attract the early adopters who are looking to get started quickly versus those who have already chosen a framework.
  3. Revamp your case studies and testimonials to include larger, more progressive companies and use cases. People don’t want to use Meteor because Kia used it for a small project once. They want to use it because million dollar companies have been built on it. (This point wasn’t meant to pitch you my business to include in said testimonials, but we happen to be one of those companies that has raised millions with a product completely built in Meteor. You guys should really be talking to us and people like us.)

I won’t dedicate an entire point to this, but better education on the value proposition of Meteor will also help. And this really comes down to a marketing problem. I only realized how powerful Meteor was after I started using it and went through some of the examples. But there are key snippets that are really worth emphasizing right out the gate: 1) isomorphic code between server and client (then explain how the line is blurred between backend and frontend - but reinforce the security aspect), 2) everything is real time, 3) easily convert to mobile apps. There are more but try to be concise and precise as much as possible. Remember, people are coming to you because you’re supposed to be simpler than the competitors.

Would be happy to talk more about this - DM me if you would like to talk directly.

14 Likes
62

I’m in total agreement with @alawi & @michaelcbrook but particularly with both of your first points. MDG gave us something great, which we’re still really happy with, but you can’t help feeling a little abandoned. A little bit of PR effort on their part would go a long way. Maybe a commitment to giving Meteor a few developer hours a day (be it Ben or Jesse) so things keep moving. All too often things go quiet for a couple of weeks.

2 Likes
63

I must honoustly say that i’m not pleased with how MDG operates. If it does at all. All career links on the meteor.com site link to apollo. Now news has come out about the company for 2 years now. No clear roadmap besides a technical one on github. There is no mdg staff member actively making statements on the forums and the spcial media accounts are totally silent. Pull request about even the most trivial things like the guide take more then 2 weeks to even get a response… .

I’ve sent a mail to mdg in which I share my worries. This is a week ago and I have yet to receive a reply. I cant help but feeling that I’m trying to poke a dead horse here. What is going on here!

Is someone able to rech them and get a good statement from MDG? Something that takes away this feeling?

3 Likes
64

Yes, what you point out it the worst.
We all have a feeling that MDG is just ignoring meteor, even if benjamin did a great job recently ( 1.7 and 1.8 ), but we have no clue about where they are heading as a company.
Today, I would be happier to have a word that say “We will not contribute on meteor anymore” than nothing.
Because 2.0 version can also be the version maintained by the community only and not MDG.

65

Not having to think differently for Fibers would be big improvement in DX (developer experience). One may not realize it if the only Node.js code they write is in Meteor, but for those coming from non-Meteor Node.js background it’s quite a bumpy ride.

And perhaps even more importantly, the usage of other npm packages can be very problematic. See my previous comment.

A related change would be to convert the APIs to be promise based.

Removing the “unique” but incompatible feature/innovation that Fiber is, would likely make Meteor more appealing to the more “mainstream” Node.js developers. That would increase the chances of big contributions coming in from the community itself. See my earlier comment

I remember MDG making some big changes in Meteor’s governance a couple of years ago. But somehow the ratio of contributors to Github stars still seems pretty low in my subjective view. Practically it’s just one person doing development work on a framework that’s arguably larger than even Rails in terms of the feature surface area.

2 Likes
66

I have said this before that MDG knows Meteor has great potentials and easy to pickup than GraphQL when integrated properly. MDG is focusing more on Apollo right now - business reasons and totally ignored releasing or even promoting community efforts aim at making Meteor Great Again. The major issue with Meteor which is Scaling has been fixed with redis-oplog, yet it took MDG awhile to finally mention it in the Guide/Docs. GraphQL is great - yeah no doubt…it still doesn’t match Meteor realtime capability. MDG should have just carve a niche for itself by continuing serious development of Meteor along with other great community contributors. Nothing is wrong with Meteor; something is definitely wrong with MDG for abandoning something this great.

4 Likes
67

Well, most of the comments here are not (only) about major functionality for the end-user but also a complain about the lack of commitment and guidance by MDG.

What I’ve contributed to Meteor so far has always been accepted with open hands, so I shew out how other frameworks got more hackable and thereby attractive for a bigger community.

Having decoupled components gives the developers a chance to hack on them without feeling that there’s something heavy going on and they first would have to understand the full framework before being confident on doing small changes to the code-base.

As much as I agree with what you mentioned here (LTS, Vue support, marketing strategies), but to keep this project suitable for future projects we need someone driven by a vision. We’re talking about the next major version …

2 Likes
68

I stand correct, both you and @gaurav7 echoed the importance of dropping fibre for future contribution and maintainability, so I guess it’s important.

Here is my attempt to consolidate a meaningful list from the discussion so far.

  • storyteller items from here.

Technology:

  • Get rid of fibers and convert all core APIs (including core packages) to be promise-based. (from here and here
  • Source maps support
  • Do something unique between Apollo and Meteor that only Meteor can do or is best at
  • More front-end agnostic, meaning no Minimongo, DDP
  • Hot module reloading and SSR
  • Improvements to listen internal events not just by hacking and wrapping some methods. (from here)

Support & Strategy

  • Official Meteor 2.0 LTS
  • Make Meteor first class citizen
  • Better communication especially form upper management

Documentation:

  • Vue Guide/Tutorial

There is a lot of good stuff in this thread, I think a good doc can be created from it. Also it’d be nice if we can have this somewhere that we can vote on.

8 Likes
69

There’s 1 full time developer on meteor/meteor from MDG. That’s not as bad as it seems, considering that React, from an organization that has maybe 10,000x the resources, only commits 4 full time developers.. It’s not like it was in the past, for sure.

I guess in light of the desired features, you should consider more carefully what it means if the project only had community contributions.

2 Likes
70

Mmm…

On the first point (fibers) here is something to consider (nice Ben Newman’s presentation, links to slides in the abstract): https://www.youtube.com/watch?v=bxaOGDqVPKw

As for DDP and Minimongo: I do understand that in some scenarios these present obstacles to scaling. However, in many others (specially on LOB enterprise apps) the benefits far outweigh any (almost non existing in these scenarios) scaling issues. And considering we don’t have to use Meteor Pub/Sub/Minimongo and DDP, we are not hindering the use of any frontend framework if those are not required.

3 Likes
71

@doctorpangloss, that was @alawi 's post, not mine (just making it clear since the double quotation is hidden and if you don’t expand it gives the wrong impression). Although there is nothing in there I disagree with :wink:

1 Like
72

Well that was happening for a long time now and basically majority of people left since 2015. There are no community left that would make meteor specific packages (and it was pretty large at one point). Meteor is now abandoned small niche project. We are now 7 weeks in a row with less than 10 commits per week (and couple of those have nice 0 commits). The single developer works on it part time only since from the beginning of the year Benjamin seems to work on Apollo too. There are some interesting PRs but they are not discussed and simply are left to be forgotten. One interesting PR is from 2016!
1.7 release was some nice new feature, but to be fair that was originally 1.6.2 which started on January and 1.8 is basically just fixing 1.7 problems.
I guess it would be best just to fork it. At least PRs could be merged then.

1 Like
73

I’m actually considering (re)-building some of the good parts of Meteor into Nuxt…

  • A similar API as what Meteor has. One static and one socket based for realtime updates and optimistic UI and a reactive storage (Revuest maybe?) including SSR support.
  • Zero config
  • A guide including Nuxt Guide additions
  • …whatever is great about Meteor atm (over time ofcourse)
74

That’s an overly negative impression which comes from the mindset that Open Source projects should always be committing or they’re abandoned. Meteor is being under development for 6 years now, it’s unrealistic to expect a commit/feature rate of the project to be similar to that under heavy construction. By your definition I’d say 90% of open source projects are just abandoned. It’s like looking at a building which is almost complete, and comparing it to a hole in the ground and saying look construction rate is not the same, that’s just absurd.

There are 2.2k views on this thread alone since it has been posted, obviously a lot of people care. Also the “The single developer” did an incredible work in bringing the system up to date, I’ve seen many projects with 10+ devs not accomplishing similar feat due to lack of skills, poor management and/or decisions. And for the packages, there has been clear push toward using NPM packages, but the community did create Redis oplog and other crucial Meteor specific packages when needed.

The biggest issue surrounding Meteor up to date are the FUD and the skewed negative opinions not being countered by PR.

8 Likes
75

If you think that the biggest meteor problem is lack of PR against negative opinions then we are looking at it completely different and the best is just to agree to disagree…

76

I feel that I need to do a lengthy one here. I’m sorry…

That’s an overly negative impression which comes from the mindset that Open Source projects should always be committing or they’re abandoned.

The javascript land is changing continuously. It’s not about being abandoned, its about it not being kept up to date with the rest of the system. Sailing upstream is awesome, but when the river starts flowing faster then your boat, it might be time to jump off and take another one. OR you start peddling. And I AM peddling, but for that I need to have peddles… Right now my pull requests arnt even being accepted. Do I really need to become the boat. fork the whole project, built my own sites around it, etc?

Meteor is being under development for 6 years now, it’s unrealistic to expect a commit/feature rate of the project to be similar to that under heavy construction. By your definition I’d say 90% of open source projects are just abandoned. It’s like looking at a building which is almost complete, and comparing it to a hole in the ground and saying look construction rate is not the same, that’s just absurd.

The biggest mistake developers and businesses make is to look at projects like this and mark it as “done”. These are projects that need continous updates, refactors, regular interactions with the community and if possible new features aswell. Ecmascript would have been swept away by now by other modern languages if it was still in its old v5 form.

I suggest you read Martin Fowlers “Refactoring” book. Its about ‘evolutionary systems’. It fits nicely on this whole topic: https://martinfowler.com/

There are 2.2k views on this thread alone since it has been posted, obviously a lot of people care. Also the “The single developer” did an incredible work in bringing the system up to date, I’ve seen many projects with 10+ devs not accomplishing similar feat due to lack of skills, poor management and/or decisions.

I totally agree with this. Meteor and some of its contributors have archieved much more then whole teams combined. Most projects also fail because of the reason you mentioned. I do feel however that its not the MDG people’s skill level. Its lack of Management, priority and Marketing that kills it atm. I totally understand their business decision though. Meteor with Galaxy is a cashcow and it will be for some time. It had its investments, but Apollo seems to be a more strategic option given its momentum.

However, Meteor is no exception. All popular frontend projects have some really bright people that could easily replace a team of 10+ devs. Evan You? Maybe Dan Abramov?

Do I agree with MDG’s decision to go full Apollo and leave the Meteor project? No! In the end it will bite MDG, because if they drop Meteor’s support, why wouldnt they do that with Apollo as soon as momentum fades when it enters the Trough of Disillusionment on the Hype Cycle?

And for the packages, there has been clear push toward using NPM packages, but the community did create Redis oplog and other crucial Meteor specific packages when needed.

You’re highlighting some of Meteor’s biggest pains here. Hence why I like this original topic. Should there be a v2? Maybe one that breaks with Meteor’s package system? What about Fibers? What about Minimongo and DDP? Would Angular 1 still be here if they didnt decide to break with its legacy stuff? Good question. Great topic to talk about with the community.

The biggest issue surrounding Meteor up to date are the FUD and the skewed negative opinions not being countered by PR.

Yes and no. Most of the things that people mention are true (harsh but true)! Meteor ‘was’ not suitable for most websites that simply required SSR and a static API. MDG ‘is’ not active on topics, pull-requests and not even social media atm.

Compare it with React, Angular, Vue, Ember, Nuxt, Next and Laravel (Laravel is I think older then Meteor and is still actively being developed, maintained and talked about). The competitors that were not even in Meteor’s water, are catching up with toolsets like Webpack that directly compete with one of Meteor’s current USPs: Hot Code Pushing and its build tool: vue-loader for example is using HMR and is really fast and easy to configure. SSR out of the box in Next and Nuxt anyone?..

MDG did so much great things. It has brought some awesome technologies on the table, but if they keep on ignoring us, it will become a dead end.

4 Likes
77

Good summary, @alawi! Some of these might not be so drastic as to necessitate a v2.0, but I agree with the list in terms of things that Meteor’s roadmap must include, for it to not only stay relevant but really attract new adopters.

78

MDG looked like taking some significant positive steps around Meteor’s project governance just before starting the work on Apollo. But then Apollo did so well and became the de-facto GraphQL client, leaving even Relay behind – must have exceeded even MDG’s expectations. I totally understand the attention and effort they are putting behind the project and the ecosystem.

I think all that we need now is for MDG to state clearly what their plans are with Meteor. Updating the roadmap with goals for 2019 would be a good way to kickstart the new year.

1 Like
79

@hluz, I’m not sure if you’re using that reference to support continuing with Fibers? Could you clarify?

My interpretation of the presentation is that Fibers helped Meteor to adopt async/await in a backward compatible way. But I don’t think Benjamin made any arguments about Fibers being worth sticking with even in future. In fact he seems to support the idea that async/await is the solution (slides: 20, 21) for coroutines not being suitable for Javascript (slides: 18, 19)

I think nobody contests the reasoning behind adopting Fibers when Meteor was first released. That was probably a great decision at that time, especially since Promise was not common and async/await were unheard of in JS-land. But I also believe Meteor faltered in not incorporating the mainstream Node.js conventions fast enough. Situation improved drastically since Meteor 1.3, but I’m afraid that Fibers is one big obstacle still remaining (and releasing Meteor as npm packages would be the other thing, but Fibers is a bigger problem imho).

Also, the problems that I alluded to in my previous comments are in fact detailed by Benjamin himself in this presentation; see slides 40-50

If some developers still find Fibers (co-routines) making sense to their projects, it could be an opt-in (just like it is for other Node.js projects, using node-fibers) – maybe Meteor could make that a tad easier through a compiler plugin/package.

2 Likes
80

Good reference, it’s my second favourite after The Mythical Man-Month :slight_smile:

I agree with that statement, I never said it’d be marked as done, but my point was the rate of development can’t be the same as when the project first start, this can be observed in all system life cycles, the amount of energy it take to bring a system from nothing to something is far greater then what it takes to maintain and evolve it.

Meteor started 6 years ago, it’s certainly passed the hype cycle, and I speculate that it’s in the middle of it’s life span. Reflecting on the web technology industry history, it takes on average 10 years for a new wave of innovation to kick-in (PHP/Java/Net – 10 years --> Ruby on Rails – 10 years --> NodeJS — 10 years -> ? ) one might argue that the rate of change might be increasing but there are constraints in adopting technology, people build businesses around them, there is natural construction speed limit, selling and maintenance periods which can’t be avoided so the 10 years mark makes sense. So I suspect the NodeJS ecosystem (and Meteor is the most mature and developed framework within the Node ecosystem) has another 5 to 6 years before it starts trending down. Nuxt, Next and create-react-app are the niche frameworks relative to Meteor now, they’re doing what Meteor did few years back with Blaze each capitalizing on the raise of view framework, SSR or some other micro-trend, but really Meteor moved first to the Node frameworks and that first mover advantage can’t be underestimated (and MDG is doing the same with Apollo now).

I agree with that statement, hence my comment for LTS support. While their push on Apollo is understandable but Meteor is a foundational tech and it’s an entry to an ecosystem yet MDG is pushing hard on Apollo and they’re allocating ex-meteor developers to Apollo which I personally not very thrilled about. But the transparency of Open Source projects is both a gift and a curse, this resource shuffling happens a lot in private companies as they invest in strategic future projects without the knowledge of the external stakeholders however in Open Source, everything is in the wild, and when the rate of commits drop, without clear communication from the leadership team, the community starts to panic and the FUD increase.

MDG seems like a company with top tech talent and little appetite for marketing or PR. I agree with your statement, it’s not just about technology it’s also about trust and communication. With that said, I really hope as a community we keep the conversation constructive and see how we can help to make Meteor 2.0 a great release :slight_smile:

5 Likes