Viewmodel is overhead? - Githubissues

Q: I think we should also start thinking about making the Viewmodel approach the standard in Meteor -- currently people are still wiring up events and templates manually. We already have a few packages in regards to viewmodels https://github.com/dalgard/meteor-viewmodel and http://viewmodel.meteor.com

A: I really disagree with the idea of making Viewmodel standard. The beautify of Meteor has always been that it doesn't make decisions for you. There are plenty of bad view model implementations (including viewmodel.meteore.com which is buggy, slow, and doesn't play nicely with blaze, doesn't "interop" as it were). There are plenty of options for what you tack onto the MV* that meteor is, and components and view models are among them. What I love about flow components (and possibly blaze components) is that I can write all the behavior in actions, and then just call the right actions from events. Now the event is just a binding. Making a specific type of view model standard tells newcomers to the platform that Meteor is MVVM not MV*

A: I'm also leery of baking any MVC assumptions into the next iteration of Blaze. One of the strengths of the component approach is that it's agnostic to one's MVC interpretation; and works equally well with client-side interpretations as it does server-side interpretations. The Blaze.View() API is bad enough, and has caused all sorts of problems and misinterpretations and headaches. And while the viewmodel package may have some good technology in it; for some of us, using it's API is like using a camera-obscura, where everything is flipped upside down. Some of us prefer to design our apps using CSS as our View, since CSS manages what gets rendered out of the ViewPort and exposes controls for all the opthamology/photonic features, such as color space, opacity, pixel density, media queries, etc. You know, the stuff that gets rendered onscreen and blasted into a user's eyeballs and that they view. In such a client-side interpretation, the dalgard:viewmodel package is misnamed rather badly, and simply a state-controller.

A: ViewModel doesn't play nice with models returned from collections. ViewModel is good for like a web form that only sends an email. If you are rendering models, perhaps to update them, you actually create more work for yourself by using ViewModel than by using your models with AutoForm. The reason is you get the data out of the form via 2 way binding, but it's only in the state of the ViewModel component. Now you still gotta pass it to your actual model. ViewModel is overhyped. It's only good for the simplest least dynamic of use cases. Any time you use real models from the database you need a slightly lower level of abstraction, but if used properly (i.e. as just described) you actually have a lot less work than if you used ViewModel.

https://meteor.hackpad.com/Proposal-for-Blaze-2-bRAxvfDzCVv#:h=Viewmodel

My actual favorites: https://github.com/themeteorites/blaze-magic-events https://github.com/peerlibrary/meteor-reactive-field + 'this' inside helpers & events

dalgard / meteor-viewmodel

Viewmodel is overhead? #27