Thingking about Meteor 2.0 šŸ¤”

core
55

Just my ideas and cents in here - and stories of things I saw in other parts of the programming world. It picks up quite something from the current roadmap, but defines some ideas for the long run:

That @cloudspider pointed out that people think that Meteor is an island in my opinion could and should be focussed on in the switch to an NPM package.

I still remember this from my PHP days when Symfony2 came out and revolutionized the community by embracing the idea of bundling your code into packages (and sharing it via composer) and make it all modular. Despite of being a complete rewrite of their earlier system, they also managed to get away from being a big monolithic project to being rather a community with tons of small projects, each fulfilling a small part but doing it perfect - and they took this idea (and a lot others) from the Linux eco-system.

In fact, they ended up with a structure that rather reminded of LEGO, which made the community very flexible and open. Other systems quickly started realizing the potential and kicked in and made use of these packages (https://symfony.com/projects).

I see that the community on JavaScript is quite different from the PHP world and also at a different state.
But seeing Meteor being quite monolithic and creating wrappers (and I do not mean those created to support Fibers), which even go beyond by getting up to a new major version having breaking changes but still keeping e.g. their old naming convention (yes, Iā€™m talking about you mongo) is quite a blocker.

Please donā€™t misunderstand me here. I want to give out a huge thanks for those keeping the Meteor platform in such a good backwards-compatible state. At the same time I donā€™t know if this is the right way to go in the future because it adds a new stone of stumbling - and you canā€™t move as fast as the original package does. On the one side we agree that we should keep the packages updated, on the other side we donā€™t want the breaking changes they introduce, which brings a huge burden and slows down the development (in my opinion).

I know that the mongo package isnā€™t trivial - specially because we also need to make it work on the client-side (where only a subset is supported) - and this only is a sharing of my impression.

And this is exactly where the thought of Linux comes into play. Any distribution of Linux decides which program to update when and some setup-scripts just need an update when updating the packages.

I would LOVE if a version 2.0 of Meteor would:

  1. Drops Fibers - which removes the necessity of creating a wrapper for a package to make it look ā€œfit for the environmentā€ (which in itself would qualify to call it a 2.0 from a developers perspective)
  2. Have the courage to remain upstream with other packages and break when things should break (up for discussion and personal taste ā€¦)
  3. Be more modular by publishing more npm packages, embrace the usage of them
  4. Take a look at other commonly used libs and define interfaces. Let the main meteor-stack (Symfony called it the standard-distribution) use the previously used package but let the users build a bridge for other libraries which then easily could become the new standard by replacing the self-maintained package with it.

If some of you have worked with PHP and a Symfony project before, you donā€™t feel bound by anything but you have the impression that everything is so modular that you can just take out the package responsible for the task and write a bridge which makes your favorite package compatible with it.

Pretty long ā€¦ but I hope you get the point :slight_smile:

56

How does those changes improve the development experience? Iā€™ve been using Meteor for some time now and I canā€™t see how those 4 items will add any value to the end user? say Iā€™m new dev using Meteor how does those items improve my experience?

Also, where would the development resources come from? sounds like a huge refactoring effort and Iā€™ve not seen any PR coming out of this thread aside from the Vue guide/tutorial (thanks Chris :slight_smile: !), is this something that you or someone in this thread have the knowledge/time to help with? The project has been modernizing for some time now, but JS language and ecosystem changed radically in 2015 and this is a heavy and specialized code base to refactor. Yet huge progress has been made by decoupling the view layer, support ES6, dynamic imports, improving build time, serving modern bundles, and support for node modules.

Personally Iā€™m happy with where Meteor is now, my minimum requirement is that it stays up to date with node LTS & mongo, Github issues resolved, new JS syntax supported and the build time doesnā€™t regress (or ideally improve), essentially Meteor LTS. Also little marketing is always good, it deserves it since there is still nothing in the ecosystem currently match what Meteor is offering as far as I can see, other frameworks seem to try challenge a piece of the stack leaving developers to glue and maintain the rest. Also, itā€™s worth noting that Meteor packaging system is really unique and itā€™s enabling architecture styles that currently seem unachievable (or at least without a lot of effort) in a typical webpack setup.

So to sum up, for Meteor 2.0 I vote for (1) An official Meteor LTS statement from MDG (to counter all those 2015 FUD posts and increase consumer trust/confidence) and (2) Tutorial/guide for Vue coupled with little marketing.

13 Likes
57

Support for Blaze, React and Angular is awesome. Blaze is so simple to use and lowers the barrier to entry for a lot of developers.

3 Likes
58

Iā€™d +1 your post over and over if I could

2 Likes
59

+100!

On (2), and because this does rely on his work, maybe we could rekindle @akryum enthusiasm on Meteor Vue? Couldnā€™t be bad for Vue itself, could it?

1 Like
60

I want to be able to make an Apple Watch app

just kidding

Things that are bothering me today:

HTTP.call() is still using callbacks. You have to wrap it as a promise to use it with async / await.

Things that would make me go crazy in love:

I think Meteor was spot on with the cross-platform focus. So with that being said:

  • Right to repair is officially legal as of next week. Jailbreak a tesla and be the first platform to allow people to build tesla apps

  • Make it easy for people to build apps for Alexa and also IOT

  • Cross-platform deployment. Not having to use third party tools to deploy onto cloud hosting (seriously deployment kind of sucks still). Meteor deploy AWS. Meteor deploy digitalOcean. Meteor deploy Zeit. Letā€™s get it. I mean come on.

  • can you build clients / servers for Magic Leap apps?

3 Likes
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