Time for a Community Fork?

community
34

This is a great discussion! I just wanted to add some of my thoughts. We absolutely welcome forks and custom release tracks. This is one of the things that makes open source great!

As core maintainers, we have to ensure a very high bar of quality for contributions we accept into core as they will impact everyone in the community. I know this can be frustrating because it puts a lot of emphasis on having long discussions about design, making sure good tests are included and contributions are aligned around the needs of the majority of our users. I think this can give some users an us vs them feeling, like the folks inside the walls of MDG are trying to maintain dictatorial control over the project. This couldn’t be further from the truth!!

We’re actively looking for more external core contributors who share the project’s values around building solid stable software for the majority. You may have noticed @abernix’s heavy participation on the project in recent times. He does not work at MDG.

The other angle here is technical. The current architecture leans towards a central point of control. The release process can only be executed in house and there is package infrastructure that is designed to be maintained in-house. We’re doing our best to refactor the project towards a more open model (e.g moving towards npm and a light release process) to make it easier for the community to maintain and fork. Due to the complexity of the codebase, this is going to take some time so please bear with us (or help out if you love solving difficult problems!).

7 Likes
35

I also want to re-emphasize that other than transitioning from Node 0.12 to Node 4, we don’t intend to swap out any of the core components of Meteor in 1.5, 1.6, or any other version. The stuff we add is just that: additions that you can safely ignore.

In fact, probably a lot of the fatigue of people who feel like the official materials like the Guide have switched to a more complicated, module-first, choose-your-own-adventure format could probably be helped by collaborating on a new educational resource that describes the “classic” way of doing stuff, with only Blaze, “global” variables, limited NPM use, etc.

8 Likes
36

This is a relief to hear!

Thank you for brining this up! Will you be opening a clear channel for contributions and clear place to park this within the exiting resources?

1 Like
37

Open to ideas! Where would you park it?

39

Could be a good idea - we could make another copy of the guide/docs themed app, set up CI, and put it on another URL, like classic.meteor.com or something.

2 Likes
41

I was hoping these anti-MDG posts died with this post

6 Likes
42

I think people forget that MDGs business can’t be only the data layer, they also need to provide something special for it, f.e. a fullstack framework which integrates Apollo with ease - and yeah, that will be the “new” Meteor.

43

I didn’t read it as such. Was suprised to read a lot of positive vibes in this thread. Seemed to be inspiring everybody :slight_smile: Go team :slight_smile:

3 Likes
44

Let’s make meteor the best it can be, and we’ll figure out how to pay the bills.

11 Likes
45

It’s called Discover Meteor :wink:

But seriously, I feel like this “Meteor Classic” approach is the wrong solution. I’d much rather have the community focus on making the “new” Meteor simpler and easier to use than divide it between people who want simplicity, and people who want cutting-edge-ness (or whatever you might call it). What if you want both?

I feel like Webpack provides a good case study: for months all I heard about Webpack is how hard it is to set up and configure, yet @benoitt was able to create a no-config, drop-in “Meteoric” Webpack package. Personally I think this is the right path for Meteor: move towards the rest of the JS ecosystem while preserving ease of use as much as possible.

15 Likes
46

Well, my posting above wasn’t against Meteor. I just think that “Meteor 2.0” will be the framework for Apollo, so it’s only changing but not dying.

47

Oh sure - I’m just saying a big part of the Apollo strategy is monetizing the data layer directly, in addition to Galaxy for the full-stack platform angle.

48

The problem I see with this is that you just arbitrarily decided you would put some Rocket.Chat people in charge of refactoring the Accounts stuff and it never came to pass. I offered to help and never really heard back. The accounts packages are in terrible shape and can be really frustrating to work with. Things like accounts-twitter and accounts-facebook pull in Blaze still, leaving Crater with a bunch of extra/dead code we don’t use in our already out of control JS bundle.

I’ve certainly spent a lot of time building packages around Meteor accounts-base over the years and have a good bit of knowledge of it.

Is that set of packages being maintained? Looking mostly lifeless atm. I also question the viability of Blaze going forward when things like React and Angular are more performant, have better tooling options, and are more widely adopted by the community at large. Useraccounts set of packages suffer from a deeper problem of relying on Iron Router and Flow Router, which aren’t being actively being maintained anymore from what I can tell.

I’ve been personally pushing clients to adopt more active and widely accepted packages from NPM like React Router, instead. Better to rip the band-aid off now and at least gain some decent performance at the same time.

2 Likes
49

They actually made a lot of progress.

Would you like to make a PR to remove the blaze dependency from Accounts? I would immediately click “merge” on that one, and we could check that task off!

5 Likes
50

Would just making it a weak dependency work? Or is it more involved than that?

51

But wasn’t a lot of their progress around trying to make it db agnostic so the postgres package could work?

Ok, will see what I can do, would love to fix this issue.

4 Likes
52

Yes, that is part of it. We would also have to look at where accounts-ui and Blaze are being used inside accounts-twitter and accounts-facebook. My guess is that the oauth config interface lives in accounts-twitter and accounts-facebook, but maybe that could be moved off to service-config-ui or some type of package?

53

I’ve moved the discussion point for this over here on an issue.

3 Likes
54

Just to add my two cents, as someone who came to Meteor from php and jQuery:

React vs. Blaze vs. Etc

Performance isn’t everything. With complexity comes maintenance. And at the end of the day, when view layer purists are focusing on squeezing every last bit of performance out of the browser, how much attention is really being paid to what’s actually being displayed? As Google will inevitably teach us time and again, content and accessibility are king.

Perhaps part of the reason I’m turned off by React is because it drives the metaphysical wedge between code and content even further. Which, interestingly enough, is a separation that seems to drive the company (and CEO) behind the technology.

I still believe in Blaze and am excited for a community-maintained package. If Meteor Classic is realized, I can’t help but think Blaze is a part of that.

Packages

While Atmosphere was originally amazing, I think the unintended consequence has been this swirling mass of packages that follows Meteor along through each release, with little curation and no way to easily identify the viability of a package. I think the sheer number of users who come to these forums with questions about IR is an indication that (especially for newbies) Atmosphere can be more a curse than a blessing. Which is unfortunate, because NPM can be a tough place to get started.

In all honesty, before working with Atmosphere packages, I found NPM frustratingly hard to understand and work with, another testament to some of what made “Classic Meteor” great.

Classic Meteor vs 1.3+

I think most of us would agree that 1.3 marked the definitive change between what we know as “Classic” Meteor and the “New” Meteor. And while I think we would also all agree that many of the changes in 1.3 (and since) have been truly beneficial to those of us developing apps for production, I also think that the concepts (and original Meteor principles) are harder to grasp as a result.

Again, in looking at the posts here, you can see Meteor newcomers debating about view layer choices for non-production apps that haven’t seen a line of code, or trying to decide if Meteor makes sense for an app they’d like to try out.

I feel like in the old days, when Meteor was more opinionated, you could just tell a newcomer to dive in and find out if they like Meteor. Now that dive comes with choices and baggage, Atmosphere vs NPM, imports, folder structure choices, build and install issues, etc. Which is fine, if you’re deciding about a long term project and js frameworks. But not so much for “Hello, world”. (Or in our case, “You’ve pressed the button 3 times.”)

I love Meteor. I don’t love it any less today than I did in 0.8. But if I didn’t know Meteor, and we met today, I’m not so sure I’d have the patience to fall in love.

What Classic Meteor Means to Me

While I look at Meteor now largely as a tool, that’s not at all what it was to me initially. Initially, it was an experience. Just like the first time you connect the circuits in science class and see the bulb light up, the first time I deployed and saw a web app that I had written, with a functioning db behind it, on an actual website – holy ****!

That is an experience.

And I feel like the community (and perhaps MDG) has lost a bit of that initial wonder and excitement, in lieu of what is ultimately a better long-term, viable, business-backed strategy.

I guess my hope is that amongst all of the new and wonderful things we can do with Meteor, the fact that it can turn a lowly jQuery hacker into a full-fledged web-app developer isn’t lost in the mix…

13 Likes
55

‘Meteor Classic’ & ‘Meteor Pro’