After carefully studying Meteor for weeks now, trying to find that right development approach, I believe that Meteor is following the MVVM pattern, in contrary to MVC (that is followed by Rails). I found many sites and documents that contradict one another - such as multitude of MVC in a variety of regions or the non-wikipedia MVCVM for example. It matches when I take a look on how I would create something in Meteor (and it makes perfect sense).
Yet, I do not find an official reference on the Meteor website. Did I miss it or is it following something entirely else? Because it isn’t obvious, someone from a Rails background like me would most likely look for the typical MVC approach and could get confused. I firmly think I am on the right track, a good confirmation that I’m right - or solid arguments that I’m wrong - would allow me to venture forward. And might help someone to understand Meteor just that extra little bit better.
In a sense Meteor is somewhere between MVC and MVVM. MVC is a cyclical pattern specifically employed in early web and desktop UIs where updates happen at the controller then populate to the model and then to the view.
MVVM is an amorphic pattern in which updates happen somehow in the model or view and are passed back and forth through the view model.
Meteor is basically one way MVVM. Updates in the model populate through to the view by way of helpers and data contexts. This is essentially the point of Blaze helpers - to build the view model though it’s not called that. Meteor doesn’t have binding in the other direction because in a highly decoupled asynchronous environment, getting that right is very difficult and time consuming and they haven’t dedicated the time (and may never) to it. However, you can always use events to simulate the binding the other way by updating the model on appropriate updates. So utilizing the MVVM pattern is an option, you just have to implement the bindings from the view to the view model.
Of course add a router and some additional service layers and you can go full on into the MVC direction as well and utilize the reactive nature of Meteor to make MVC extremely responsive. The choice is really up to you.
To be more precise, 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. I will say that the MVC pattern works well with web applications while the MVVM pattern (or the MVP pattern) works well with native (or Cordova) applications.
Now we’re talking semantics. Whatever you want to call it, meteor doesn’t work like other libraries and frameworks clearly associated with mvvm (Silverlight, WPF, Knockout, Angular, Aurelia, etc.)
Meteor is, out of the box, as half way there as any other piece of technology with one way data binding. If you see the proposal for Blaze 2, it wants the template instances to behave like view models. And of course, like with other libraries, you can fake having a view model in different ways.
To be more precise, Meteor follows the MV* pattern with self updating views that “react” to model changes.
I found a fanfiction pattern, called Resource-View-Presenter - one of the reasons of it thought up is that Meteor isn’t truly MVVM or MVC, in which I can relate. Thank you for the good explanation why Meteor isn’t true MVVM (the 2 way data binding part). Is the MV* pattern you are talking about, something I can read more about, or is it something like Resource-View-Presenter?
Now we’re talking semantics. Whatever you want to call it, meteor doesn’t work like other libraries and frameworks clearly associated with mvvm (Silverlight, WPF, Knockout, Angular, Aurelia, etc.)
The point is indeed clearly. A design pattern follows certain rules. Too be honest, the Wikipedia page about MVVM isn’t really informative in this regard; I didn’t find there that a 2-way databinding is one of its key factors that distinguishes it from other patterns.
From what I can tell, the cached and synchronized data, accessed by isomorphic JavaScript is the model area. The HTML templates are the View area. The helpers and events, separated from the HTML, feel like the Controller, but are so tightly with the View and acts as well on client and serverside, they feel like a View-Model.
The view model is an abstraction of the view that exposes public properties and commands. Instead of the controller of the MVC pattern, or the presenter of the MVP pattern, MVVM has a binder. In the view model, this binder mediates communication between the view and the data binder. ( Wikipedia )
Does the MDG has a typical pattern how they would describe as practice when developing Meteor applications?
You’re using terms so loosely that anything can be construed as MVVM. Let’s go to Microsoft (the ones who came up with MVVM) to see what they have to say about it.
The view model in the MVVM pattern encapsulates the presentation logic and data for the view. It has no direct reference to the view or any knowledge about the view’s specific implementation or type. The view model implements properties and commands to which the view can data bind and notifies the view of any state changes through change notification events. The properties and commands that the view model provides define the functionality to be offered by the UI, but the view determines how that functionality is to be rendered.
When it comes to Meteor (Blaze to be more specific) the only part of that definition that holds true is “encapsulates the presentation logic and data for the view”. It doesn’t provide commands or two way binding (see diagram).
On the other hand that definition applies very well to other libraries and frameworks (Silverlight, WPF, Knockout, Angular, Aurelia, Volt, Vue, ViewModel, etc.)
Let’s go to Microsoft (the ones who came up with MVVM) to see what they have to say about it.
It’s a common misconception to associate ownership of a pattern to the developers of the pattern. Microsoft was developing a new UI framework for their desktop environment and needed a new paradigm to work with it as MVC just wasn’t cutting it for them. Enter MVVM. It was simply put their way of separating concepts. They don’t own it however.
So let’s drill down into what specifically makes the MVVM pattern in the larger world of actual use.
Model - An authority on all the data and business logic. This would typically be held only on the server in web based MVVM operations.
ViewModel - An authority on UX (user experience). This model contains all of the data to be displayed as well as all of the behaviors to be used. In WPF (Microsoft’s framework that prompted the invention of MVVM) this is broken down into databindings (both one and two way) and commands. In other frameworks this can be simply implemented as data that can be displayed/manipulated and functions. In some uses, one way data binding is exactly how it should be done. This is the cornerstone of MVVM and is the inspiration behind rx.js knockout and many others. Originally written for WPF it has certainly evolved as a paradigm past that.
View - An authority on how the UI should look. It provides interaction points wired to “commands” on the view model and it displays data from the view model. It contains no logic of it’s own except that which is used solely to convey meaning.
MVC on the other hand is a more linear pattern
Model - Again the authority on all things data and business logic. Again typically contained Server side. Again typically needing translation to get to the view.
Controller - Behavior. Requests to do something hit the controller which interacts with the model and then selects a model and view to display. Could be the same model and view as before with just the updates or could be a whole new model and view.
View - Again provides only UI. However now it is closely bound to the model and has the logic contained within it for all UX behavior.
So where does that really leave meteor?
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. You can use events and reactive variables to accomplish an MVVM pattern though the view and view model are more closely bound than you would in the traditional MVVM pattern.
Conclusion:
Patterns are loose guides not hard fast rules. Cornerstones of patterns are generally in the name.
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. The flipside of that is of course that it leaves a lot not implemented by them. That is partially why the package system has become so popular.
Holy straw man Batman, nobody said anything about owning a pattern!
I mentioned Microsoft because they came up with MVVM so it’s fair to say they know a thing or two about it.
As for the pattern “evolving”, if it evolves past the point of being recognizable as how it was described at the beginning then it’s something else (MVVM 2.0 maybe). Right now it’s recognizable as Microsoft described it 10 years ago in a whole bunch of libraries and frameworks.
Holy straw man Batman, nobody said anything about owning a pattern!
And this is my queue to check and see how forceful I was. I get a little touchy when I hear people reference any major corporation and use THEIR documentaiton on a pattern instead of looking to the larger community. Is that right? no, not really. The rest of my post however was meant to simply articulate the various patterns being discussed and how they compare and not at all meant to hammer on the idea of Microsoft owning a pattern.
As for the pattern “evolving”, if it evolves past the point of being recognizable as how it was described at the beginning then it’s something else (MVVM 2.0 maybe). Right now it’s recognizable as Microsoft described it 10 years ago in a whole bunch of libraries and frameworks.
I would disagree. Even Microsoft’s idea went through a lot of evolution. Moreover a pattern isn’t a standard. There is a big difference between say HTML4 vs HTML5 and MVVM of 10 years ago and MVVM of today. The pattern itself doesn’t have a standard and should evolve as use cases evolve. The two way databinding was and remains one of the use cases, but restricting the pattern definition to that logically eliminates real use cases. Not every application which is leveraging mvvm is going to do so with bidirectional data bindings. A very valid structure is to use single direction data bindings to show the data and commands to update or modify the data.
I’d like to ask, out of curiosity, does it matter?
I mean I read up about MVP (Model View Presenter) when I was doing a winforms project back yonders and so I had server DB, soap API(model), client model cache, presenters (business logic) and user controls (views)
Did some asp.net MVC, server DB with EF, had a data layer API(model) that my Controllers(logic) were accessing to create the cshtml (view) files statically before serving to the client with some ajax behaviour
Did some angular/firebase side project that had a firebase API that I was syncing with my angular frontend as a service (model) and then used directives, controllers for logic (controller) and directives/html as view
Now doing some meteor project with a backend in mongo with attached helpers/hooks (model) that is synced to minimongo which is just a cached and synced (model) that I use with template helpers/route controllers/hooks to do business (logic) and then displayed with html (view).
Isn’t this why Angular sold themselves as a MV* framework as well? I don’t see how labeling frameworks as MVP, MVC, MVVM, MV* makes any difference to the way in which we develop. Nowadays I don’t pay much attention to the MV* pattern. More focused on how the technology I’m working with does what it does, be it one way, two way or three way binding, no binding?, full client data representation (minimongo), fully synced db (firebase), build your own model (cshtml Model var).
Can someone provide a concrete example as to how working with a MVC mindset differs from a MVVM one when working with meteor? Is this what you guys are talking about?
Good point - I agree completely. I understand what the “Meteor way” is; how to write it, comprehend it, reason about it, etc. Does it really matter which “M” it is (other than Meteor)?
Not trolling - I really don’t know why we have a compulsion to classify everything. The time I would have to spend understanding all the various methodologies around how the data gets from the backend to the browser and back would be better spent doing “real” work.
I have to disagree here.
The point of patterns is to bring code organization that is kown to work, preventing new developers to try to reinvent the wheel or to loose time exploring ways that are known not to work.
The problem here with Meteor is that it doesn’t seems to fit into patterns that we know about.
We can declare like you that we don’t care about patterns and that we just use the technology, but we end up with the actual “pattern” of Meteor development which is to work with global Session variables, and direct database access through template helpers. This is great for rapid development of small to medium apps, but can become quite limiting once your app is reaching a certain size thresold.
I fear that at this moment, we don’t have any true pattern for developing big apps with meteor.
I fear even more that the framework/technology makes it quite impossible to apply best practices (= decoupled code) and then those patterns won’t ever come.
I sincerely hope i’m wrong.
Can someone provide a concrete example as to how working with a MVC mindset differs from a MVVM one when working with meteor? Is this what you guys are talking about?
Playing with Meteor doesn’t require any pattern at all. You can simply dive in and do what you must. And this is fine! I, and I suppose some others, like patterns - especially when it comes with frameworks and adopting them. When I am working in RoR, the MVC pattern is quite clear. It’s part of the methodology of the framework. You generate models, controllers and views. Even in this, you are quite “free”. Working in collaboration, now here is a different story - style, preferences and experience differ among team members. Having a pattern that contributes to work flows is quite effective. Patterns are also great when it comes to composite design. I don’t mind that there is no specific pattern, however it is rare that frameworks do differ in this area compared to Meteor. Half of a pattern is not something I call a pattern - that would be labeling things as they closely resemble.
Playing with Meteor doesn’t require any pattern at all.
This is dangerous as diving in without a pattern creates chaos. I recently had the challenge of bringing order to chaos in a project where another dev didn’t “have time to follow design patterns” and it was misery. The discussion of what pattern Meteor is holds a very important place however the points made so far are that meteor really doesn’t provide the last piece. Meteor really is MV* because it provides the M and the V but not the *. There are packages that provide various other options for the * (viewmodel lets you make it MVVM, various routers let you make it MVC, You could create your own presenter concept for MVP). That doesn’t mean you don’t want to use a design pattern with Meteor but rather that Meteor doesn’t force you into one design concept.
I have written recently both an MVC and an MVVM based application in Meteor. One is a website really and utilizes meteor to make it a fun site to be at. MVC was really useful for this. One is really interactive and just about everything you do on the site has an impact on every other user. MVVM was the target design for that. In my implementation of MVVM I didn’t use the viewmodel package but instead had a load once use a thousand times piece of code that when called provided a handler that would wrap a reactive variable for a text field.
'keyup #field1': textWrapper(field1)
function textWrapper(reactiveVariable){
return function(event){
reactiveVariable.set($(event.currentTarget).val())
}
}
This gave me the binding quickly and easily into reactive variables which I could put auto runs on. So I implemented the viewmodel concept in my template’s backing js files.
Of course it is important to stick CLOSE to patterns as they provide known good ways of organizing your code. It is important to also separate your pattern pieces as much as possible.
I fear that at this moment, we don’t have any true pattern for developing big apps with meteor.
I fear even more that the framework/technology makes it quite impossible to apply best practices (= decoupled code) and then those patterns won’t ever come.
I sincerely hope i’m wrong.
I think you are possibly overreacting a bit here. There are several large shops using Meteor and I know I personally have written two relatively sizable applications with it. The real problem with meteor is that the package system hasn’t been really finalized so to leverage it in order to encapsulate your project (I have one application which consists of about 30 packages, each responsible for one aspect of the application) you have to use a poorly documented and not finalized system. Once we get more package control and less global namespace pollution I think you’ll find that Meteor actually lends itself very well to existing patterns, but it leaves you to pick one. It’s that last part that causes problems. In the aforementioned frameworks (knockout, WPF, Winforms even) you are forced into one particular pattern because the framework depends on it. Meteor is a good framework in that it doesn’t depend on a pattern, but it is a bad framework in that it doesn’t depend on a pattern. Take your pick. Personally I’d rather be able to apply the right pattern for the job and still be able to leverage the amazing features that I get for free with Meteor as a framework (reactive collections, mongodb, websockets, hot code push, reactive templating just to name my favorites)
