Like Brajt said, it would be optimal to have one, but giving people two options up front is better than leaving them to experience the pain, search for answers, and then have to make a decision later on.
We could enumerate the most common problems areas when using view layers, and then @mitar and I can submit PR’s where we explain how each package deals with each situation.
How about the following to start with:
Creating components
Reusing components
Communication between components
Event handling
State handling
Again, these could be in a section called “Packages that compliment Blaze” (or something to that tone).
I do think it would be a true disservice, if you don’t tell developers upfront there are simpler alternatives to do more complex stuff with available packages. Actually the guide already recommends packages for other layers like simple-schema for data. Then why not the view layer?
Learning / comparing by example is always the best way to learn. When new developers jump to Meteor by learning the TODO example, they are naturally exposed to those exciting new features (reactivity without effort etc…) that distract them to ignore or assume real world apps will be equally easy, until their app requirement become complex enough to hit walls. That’s exactly the start of my journey reaching VM. We all want to focus on business logic, which is mainly view layer centric, instead of lower level stuff, that’s why Meteor hits, isn’t it? Then why not make new comers’ lives even more easier, without going through all the painful routes? or worst, leaving Blaze or Meteor…
It would be great if the guide could provide sample apps with more real world requirements, in different versions using pure Blaze, VM or others packages. The idea is like: https://viewmodel.meteor.com/#comparison , but in full app. Just let developers decide which approach they prefer. For VM I work most with, @manuel already has great demo apps like the contact management, though I wish the app could make use of other packages like Astronomy for validation and easy-search for search etc…
Personally, I think React is over-rated in Meteor (probably mostly the forum community) because most haven’t really tried or even aware of the existence of VM …
Yeah, when you start to need more Sessions, Reactive-X etc… either you end up in VM or leave Blaze, even Meteor. It’s all for the sake of Meteor developers (thus MDG) if the official guide could eliminate the unnecessary painful journey of solution searching.
I’d be happy to sharing my toy projects, but probably most new developers prefers to see raw JS/HTML other than jade and livescript that I personally prefer. Maybe @sashko could consider inviting and listing different versions of the predefined demo apps alone side the official one. Then I’d be very happy to help make VM version in jade/livescript to show case the simplicity etc…
I have some perspective on this as someone who started into Meteor seriously mid-December. The Guide has been completely invaluable, it’s been my bible and it’s especially important at the moment as examples from even a few months ago would now be considered out of date.
For us as experienced developers looking to take on a new platform, a “blessed” approach is really important to us (Microsoft do that really well, it’s usually pretty clear that the recommended starting path is).
The other thing that’s worth a thousand words is a great demo. From a corporate/enterprise of view the Todo app is a great starting point, but a demo with a dashboard and a few dull screens showing how to edit records and do the dull business of parent and child relationships (invoices and invoice lines etc) and lookups would be invaluable. Rather than just bemoan the lack of that though, I’m actually working on writing one in 1.3 React, I’ll send @sashko a link to the repo when it’s working and you can have a look and see if there’s anything worth using.
One other thought (because I know MDG are sitting round twiddling their thumbs for a lack of things to do at the moment); a boilerplate project that includes all of the guide recommended packages would be really good too. It would be great to be able to type meteor create --guide-boilerplate --blaze my-project-name or something like that and be up and running on the happy path.
Yeah, often I feel that people leave to React to get some features at the cost of more code than Blaze while manuel:viewmodel gives them many of the same with less code than pure Blaze.
This would be impossible to maintain for us. We can at most maintain 1 or 2 example apps, unless there is someone literally working full time on example apps (which won’t be the top priority even if we would hire such a person).
This is one place I would really encourage some work from the community - if you make an example app that uses view model but follows all of the recommendations from the guide (not necessarily in code, but at least in spirit) I’d be happy to figure out a way to promote it.
Spot on! This is the reason we haven’t published a forms article in the Guide yet - we don’t have a testing ground for the kind of app that needs really complicated form functionality. It would be great to have a new example app for this.
Yeah this is certainly something we want to do once the guide is more complete for Meteor 1.3, if you want to help with that it would be awesome. First we need to get the testing and app structure/modules articles into the guide for 1.3.
Sure that’s understandable. Recently I did quite some private Meteor mentoring for which I always ask the guys to use VM. Shall let you know when I come up with the VM version of the Todo example.
Would MDG maintain the simple-todos (or a new version at the same scale) in the current tutorial of www.meteor.com? It is the right bite-size for new comers. The Todos app in the Guide introduces too many concepts, seems not a right app candidate to start with for comparing view layers.
I appreciate this is a frustrating situation. For context the stated reason we haven’t looked to recommend one or the other is partly due to the lack of clarity around direction with Blaze / React / React in Blaze: https://github.com/meteor/guide/issues/8#issuecomment-167917156
It’s outside of the guide’s goals to provide more than one recommendation; however I think in this case, like the end-to-end testing case, there are a few competing options that have their merits so it could make sense to at least mention them all. But we probably would need to recommend something, unless the whole section is a “other options” section…
Since then things have progressed in other ways a bit so this kind of fell off the radar.
As you probably know we split Blaze off into it’s own repo and we’re hoping it’s development can be more parallel to that of core, and community driven. As such we’ve given @mitar commit rights to that repo and hopefully post 1.3 he and others in the community like yourself can continue Blaze in the sort of direction that you’ve taken it with BC and VM.
We want to focus on getting 1.3 out but I know that @martijnwalraven has been thinking about figuring out how to properly separate the release process of Blaze from that of core and he’ll probably focus on that right after 1.3 is released. Our aim would be that Blaze could be on its own release schedule and not held up by core changes.
Part of that effort will eventually be for the same Blaze maintainers to take over the guide article as well. Again, I’d rather focus on getting 1.3 out the door and then think about this afterwards but that’s the current direction of our thoughts on that subject.
Looks you can’t grow wrong with Blaze Components or ViewModel. The thing you can’t do is continue building an app without one of these opinions. You will spend cycles arguing what’s right rather than conforming to a common understanding. My team did this and we just chose react. So this will happen to everyone else! I like BC vs view model but I still think both APIs are too big! IMHO
