Should there be Meteor Frameworks?

I just saw the Khorinis Announcememt which, in my opinion, is a great step into a direction I’ve been waiting for: frameworks on the Meteor platform.

People are often asking for a good structure for Meteor apps and MDG have announced to give advise on how to structure apps. But is a structure really enough? A structure doesn’t make much sense without knowing what libraries will be used, so you won’t just share a structure but the libraries as well.
So shouldn’t we start to think of “frameworks on the Meteor platform”? There are already some boilerplate structures/ frameworks, but I think we should create more of these. Why not have Meteor frameworks like we have node frameworks? Meteor itself is great but having more standard frameworks with events, routing, models and a module/dependency system might be a good step into the future.

Please note that this just came to my mind and I’m still thinking how this makes sense, but I’d like to know your feelings about this :wink:

And as MDG are looking for a good structure (I’d say framework), what do you think about an official “Meteor framework challenge”?

2 Likes

I think it’s starting to head in that direction already, especially with Angular and React coming onto the scene, and SQL support in the future. Take the upcoming react support, for example:

Check out the posts by @SkinnyGeek1010 on React integration. He has been testing out tons of different architectures using React, Flux (and its varieties), and different elements of Meteor. Also @arunoda has been developing great routing and layout features for react (flow router and reaktor and reactlayout). If you read through the posts, you can start to see some patterns emerging. The next logical step would be to get more community feedback / involvement to push these patterns into a framework, even if it were not a strict one.

Here’s what I would want to see (for React since that’s what I use):

  1. Different architectures that are possible (diagrams and explanations. architectures need to be proven in prod)
  2. List of base packages needed to enable each architecture, and support it (maybe some specific packages only work for this framework etc)
  3. List of use cases or problems that each architecture is good at solving
  4. Tons of sample code / open source projects / docs for learning the framework and how each package enables it ( for example, how to do routing with flow router and material ui components)
  5. App structure that fits with app architecture
  6. Community support / feedback / “a place to live”

Number 6 on my list might be controversial, because you don’t want to split the Meteor community into a bunch of sub-communities based on which framework they prefer. But it might be kinda like that already. Whenever I come to the forums I sort on “React” first and read all those posts before I go to Core or anything else.

Just my 2 cents.

2 Likes