Pattern and development approach

My question is simple. Soon I found this is an old issue, so I searched and read a relevant post to understand better.

In “Meteor way”, is it not so meaningful to embrace MVC way in framework level?
(by easy optional choice, and providing some good guidelines)

Meteor seems like using template modular approach(This is just my expression, I’m not sure if this is right) - template and it’s js,
and each js is acting like controller in template level.

You know controllers, how about employing controllers in the conceptual level division. (i.e. PersonController, CarController)
I know there are answers like “Meteor doesn’t force you into one design concept.” or "it’s up to you."
But is the reconciliation between meteor way and MVC way often meaningless or hard to do? (I’m saying framework level provision.)
Why should we take it for granted to forget about the benefits of MVC so easily?
As an opinionated framework, why is it not acceptable to embrace MVC?; Even at least optional way.
(Sorry to use too many “why”.)

FYI, a relevant post and comments:

Meteor follows the MV* pattern with self updating views that “react” to model changes.

It’s up to you to plug in controllers or view models, or whatever middleware you want to use to interact with the models.

Meteor is MV* What does that mean?

Model - Meteor provides a mongodb based model for use. It’s a reactively updated model which has some nice workflow elements built right in.
View - Meteor provides us a view in the Spacebars/Blaze template system. It’s more of the MVC style view but it does have it’s own events system.
(*) - Meteor waits for you to tack on the rest. It doesn’t provide out of the box either consistent view model bindings or controller based routing.
So it’s up to you to put in your code for the *. You can use Iron:router or flow router to accomplish most of an MVC pattern.

Meteor really is MV* because it provides the M and the V but not the *.

Meteor doesn’t force you into one design concept.

Meteor doesn’t implement the whole of any pattern but puts you in a place where the last piece is easy enough to implement.

It’s easier to think of Meteor in terms of Meteor than in terms of design patterns that other frameworks have used. MDG is very big on not telling you HOW to use their framework and as a result it leaves a lot open.

I really don’t know why we have a compulsion to classify everything.

When I am working in RoR, the MVC pattern is quite clear. It’s part of the methodology of the framework.

If you’re less interested in MVC, than in a consistent approach, you could take a look at viewmodel, which provides a nice MVVM wrapper on top of React (or Blaze).

1 Like

Thank you. Please excuse my poor Engish.
I understand we could apply MVVC, React.js-like ways, but for now, I’m satisfied so much with Meteor’s reactivity support.
(As Dan Dascalescu said, “The client and the server communicate data updates seamlessly and automatically, without you having to write any boilerplate data sync code.”)

This was my first motivation and question: Meteor’s reactivity support is so good, and I’m familiar with MVC in web development, so how about if Meteor is shipped with a “Meteor way + MVC together” option?
(To amplify further, I’m from Spring/java background, and recently I recalled how Hapi.js was a decent and familiar framework for web development.
I imagined Meteor’s reactivity + Hapi’s good features(including MVC) would be great only if it is possible and realizable.)

Viewmodel works reactively with Meteor. It was developed for Meteor, and @manuel (the creator) is super-helpful.

Thank you. But it seems not easy to understand how this could be related to Controller issue.(I don’t know in detail but…got it. MVVC…, not MVC) It looks like React way and so demanding to learn.

That’s why I said:

I think everyone who’s used ViewModel has said the exact opposite. However, if you’re not comfortable with React, look at ViewModel for Blaze. It’s still not MVC, but it may be better for your needs.

1 Like

Thank you. I mistook MVVM for MVVC…anyway seems I need to understand viewmodel more in detail. I thought adding controllers would be an easy task. (I found an example using controller.js but it was almost empty. Seems it is not so easy as I thought.) Now I understand the gist VM plays a role like C.

1 Like

When using VM I think it will do you good if you don’t over analyze it in terms of MV-whatever. At the core it’s just a very simple concept: you have a component defined with properties and methods and the HTML can bind to those.

Here’s an example in React but the Blaze version is functionally the same, you’d just have a separate file for the js and the html.

  name: "",
  greeting() {
    return "Hello " +;
  render() {
      <input b="value: name" /> 
      <label b="text: greeting" />

The component name is Person, it has a property name, a method greeting which depends on name, and an HTML with an input bound to the name property and a label bound to the result of the greeting method/function.

That alone will take care of 80% of your apps.


Thank you. Please excuse my poor English.
To write down my understanding, that is just similiar to a classe, and we could say that plays a role as controller. And that could have full controll over certain view part, including rendering function, hence we could also say that as VM.
It is not hard to understand in concept and,

  1. I expected a normal controller as we know, but VM is recommended. I think I could take this for granted, presumably as it is a more advanced result in modern web frameworks.
  2. Html or jsx code in rendering function(React way): this is why I hesitate to try. I’m worrying that could make code complex and even hard to maintain. (I’m not sure but isn’t it a common issue in React way?)

Anyway I have a good understand now. I need to try to employ VMs but think it still would be not as easy as using plain controllers if I have to apply them completely in the project.