Competition doesn't sleep

[metstrike]

There are similar projects trending on github right now, the two that caught my attention:

http://mantrajs.com/

https://github.com/ryanflorence/react-project

How does meatier look in comparison with them? What are its strengths/weaknesses (except a very cool name clearly). Let's get ready guys to argue in another upcoming "vi vs emacs" like war.

[fallenpeace]

Mantra is just an architecture for meteor, it doesn't solve any of the chief complaints listed in Meatier's ReadMe, since you are still limited only to the meteor platform. Although I love working with Mantra's specification, compared to the "put things anywhere" approach of default meteor.

React-project, seems more a "kickstart your traditional react project". React, Babel, webpack, testing, express(if working with node) are a few things that are pretty much installed with every react project. I dont think there's anything special about it, compared to most kickstart projects out there, but I maybe misinformed, anyones welcomed to shed light on this.

Meatier seems to want to provide a modern platform-ish alternative to what Meteor is. Realtime data, graphql, Node 5, etc, etc, It has the packages to reproduce what Meteor does, with tons more flexibility not found in the Meteor platform.

My two cents, fairly new to all of this :)

[abastardi]

Interestingly, it appears Meteor itself is planning a major overhaul that will address most of the "chief complaints" listed in the Meatier readme -- upgrading the Node.js version, ES2015 modules (and no more global namespace), full npm integration (no more Atmosphere packages), new build system (possibly based on Webpack) with code splitting, built-in testing, and a completely new reactive data layer based on GraphQL.

[bartekus]

@abastardi while that may be true, meteor seems to be training behind the curve while meatier and by extension r3stack intends to stay ahead of it. We are not interested in commercialization like the corporate fat cats at meteor. We follow Aaron Swartz mantra - knowledge for all! This is by hackers for hackers... r3stack will allow commercial entities to take advantage of our effort, but their interests are not the prerogative - the npm community and specifically javascript community is.

[abastardi]

meteor seems to be training behind the curve

I wouldn't say that about the new Apollo data layer.

We follow Aaron Swartz mantra - knowledge for all!

That's a laudable goal. One thing Meteor does fairly well in this regard is focusing on ease of use and learnability (i.e., lots of documentation and learning resources), opening itself up to a wide audience of potential creators. From their mission statement (emphasis added):

"In the face of escalating complexity, how can we simplify software engineering so that more people can do it?"

At the moment at least, Meatier appears to cater more to the technological elite, even eschewing documentation and guidance (see #22, #34, #100, #72). If the goal is knowledge for all, there are still some things to learn from Meteor.

[bartekus]

Indeed, more competition is good for everybody IMO Beside we're just starting and documentation will follow. As to the technological elite, they are the ones who make worthwhile stuff, including this so perhaps insulting them is not in a good taste or character.

... but if you find our goal of honoring Aaron Swartz 'laudable' then I'm afraid that I have nothing else to say to you.

[abastardi]

As to the technological elite, they are the ones who make worthwhile stuff, including this so perhaps insulting them is not in a good taste or character.

I think you take what I wrote the wrong way. "Technological elite" is not meant as an insult -- it just refers to those on the upper end of skill/ability in this domain. It's good to have a high level of skill, and it's perfectly appropriate to create something that caters to those with such skill. I'm excited to see what's being done with Meatier, and I appreciate the work that has been put into it.

But perhaps you can explain more what you mean by "knowlege for all" with regard to Meteor vs. Meatier. Meteor is open source and comes with lots of documentation and guidance (they are also implementing a new development model, breaking the framework into multiple repos and facilitating more community contribution/collaboration). I don't necessarily see it as withholding knowledge from the masses. If you say Meatier documentation will be forthcoming, that sounds great -- it's just not the sense one gets when viewing the various Github issues on the topic.

... but if you find our goal of honoring Aaron Swartz 'laudable' then I'm afraid that I have nothing else to say to you.

I'm not sure what you mean by that. Do you take offense? "Laudable" means "praiseworthy," so it was meant as a compliment.

I apologize if I offended you or any of those working on Meatier.

[mattkrick]

Mantra gives some much needed shape to meteor projects, but that's it. The started kit by ryan has some great stuff that we could probably learn from, but it only offers up a front end.

@abastardi My very opinionated take on the issue which you should take with a grain of salt:

Interestingly, it appears Meteor itself is planning a major overhaul that will address most of the "chief complaints" listed in the Meatier readme -- upgrading the Node.js version, ES2015 modules (and no more global namespace), full npm integration (no more Atmosphere packages), new build system (possibly based on Webpack) with code splitting, built-in testing, and a completely new reactive data layer based on GraphQL.

They've had requests to leave node 0.10.x since before v1.0. The problem is meteor is built on fibers & a fibers-enabled version of node (think await/async polyfill from 4 years ago). The most popular topic regarding the upgrade on the forum is something like "when will we get node 0.12?" ...yeah, it ain't high priority. Regarding the whole major upgrade, I'd encourage everyone to re-read the post they released a week ago. A CEO should be decisive and have a clear vision. The post included a whole bunch of "maybe" "will consider" stuff. That ain't a path forward by a company that will shape the future, that's a weather vane. Regarding the build system, they're polarizing the npm ecosystem by building a webpack-like system instead of webpack itself.

I wouldn't say that about the new Apollo data layer.

I think adding an additional invalidation server + a dependencies prop to every graphQL query complicates more than it simplifies, and again, with a non-vanilla graphQL implementation, meteor is gonna segment the npm userbase. I'm also not sure how much they looked into the relay internals... but I think they could get back on the map as a team of thought leaders if they rewrote relay the right way (it is a very difficult problem).

If I know GraphQL, that doesn't mean I know Meteor's Apollo, which is a problem when I, as a project manager, have to look at the cost of moving from (or to) Meteor. Currently, there is a difference between a "meteor developer" and a "javascript developer". While MDG took a big step forward to open itself up to the NPM ecosystem, they're taking a half step back by forcing you to eat the meteor-flavor of all these great tools. I like vanilla :smile:

[mattkrick]

Closing as there is no direct action to take, feel free to keep the discussion going!

[bartekus]

@abastardi, my bad good sir, I was very tired when I was responding and clearly I'm unable to even read properly... I mean no offense either, and I do value your option so I'll certainly will be looking at addressing some of the concerns that you have raised in the near future. It is our goal to serve the community, from hobbyist developer to seasoned elite - we try to create a solution that will span both of these extremes. Constructive criticism and PR contributions along with patience will serve all of us in the end. It can very fun and rewarding path for us of all - and one by which taking we will learn and grow our skills to a new level.

[abastardi]

@Bartekus, it's all good. Thanks for all of your work on this.

[metstrike]

To continue the discussion.

1.) There is a package that brings webpack to meteor and also mantra (supposedly eliminates the need to work with webpack config, which is very painful):

https://github.com/thereactivestack/kickstart https://thereactivestack.com/

2.) Related to issue #72: The React Project is wrapped up as a npm module. It looks like the author sees a lot of advantages in doing it that way. Quotes:

• A dependency--not a boilerplate--to make your React project a delight to develop.
• Keep the app in charge. Config lives in the app, defaults provided by the framework are imported into the app, the app is not imported into the framework.