Since Blaze is going to be community supported now, why not integrate ViewModel?

blaze
1

Nowdays the Blaze support from MDG is beginning to lack (considering they recently stated it’s up to the community to add Apollo support), as well as the tutorials aren’t quite as Blaze-friendly as they were before (they don’t really show too much of the ‘magic’ anymore), I have been wondering, why not integrate ViewModel in to Blaze by default?

Since Blaze is becoming public, could even mean that Blaze itself could be tweaked for some tighter integration with ViewModel, if users are behind this idea.

The reason I thought of this, is because when training my new employees, I noticed that ~75%+ of the problems they were having, were related to Meteor’s way of manipulating the DOM/rendering, or them trying to fiddle around with JQuery to get things working properly. Then I taught them how to integrate ViewModel, and it resolved all their problems!

The only possible issue I could think of regarding this is that it would be a slight increase in learning curve. But let’s be honest here - for the Meteor 1.3 tutorials to be truly friendly to new users (and not experienced full stack dev’s) they need to be re-written anyway (my new employees have confirmed this, they are comfortable with Meteor now but still think the current tutorials are not very useful at all) it would be just as easy to teach users how to use ViewModel from the beginning rather than Blaze alone.

I personally love the idea, I think Blaze is very underrated, and ViewModel perfectly fits the “Meteor Way” of doing things. It’s reactive just like Meteor, and ViewModel pretty much gives the best parts of Angular to any Meteor developer in a very easy to implement way, as well as a component-style architecture - all they need to know is simple HTML and they will be up and running in minutes.

I believe the overall learning curve of Meteor will be lessened as well, as new users won’t need to worry about learning separate functions for onCreated, onRendered, Helpers, etc… and users can do more “traditional” programming when working with direct variables in their view, rather than helpers. Less code, less places to make errors, less debugging - sounds perfect for new users, and most experienced users who have looked in to ViewModel understand the benefits anyway.

Blaze + ViewModel I think will have much more potential for growth in to the future, rather than Blaze alone! It’s not just quick & easy to use with a smooth learning curve, but I believe the functionality can truly compete with the other options out there in most situations.

Any thoughts on this?

5 Likes
2

@Spyridon, I agree wholeheartedly and was thinking the same thing. Either Vue or ViewModel. Not sure which. @mitar, is there a governance / leadership for Blaze project yet so we can start to brainstorm together.

Honestly, I feel Meteor is moving on and the community will start to take over, so we need to plan this well.

@a.com seemed also interested in the Blaze issues. Maybe we should have a chat channel (if one not already up).

3

There is already a slack channel for discussions about blaze (the link is on its github page)
https://blazejs.slack.com/

4

Both Blaze and ViewModel are great. But connecting them together… will it speed up further development or bring some other benefits?

5

ViewModel has similar templating with DOM-elements as Blaze. So the question is whether to continue supporting ViewModel vs Blaze and integrate into Apollo.

https://viewmodel.org/docs/examples

I don’t believe the community can support both as they are very similar and we may get fragmentation of developer time / attention. But a DOM-based templating language is important.

The other view layer is Vue.

6

Try KISS alternative :blush:

2 Likes
7

We are still waiting for Meteor 1.4 to start using the stand-alone Blaze repository. But feel free to open issues there and suggest your ideas how to move Blaze forward.

8

@Volodymyr Well I came to the idea for 2 reasons primarily. 1) ViewModel works alongside regular Blaze just fine and all the Blaze code will still work perfectly.

And 2) ViewModel basically just provides functionality that is comparable to the other highly popular view options out there. I see it more of an “improvement” to Blaze, rather than “additional features”, so I don’t see much of a reason for it to be modular as it is right now. Blaze + ViewModel I believe is a true contender to the others out there. Just Blaze alone… I like it still and it gets the job done, but I can’t honestly say it compares to the competition on Blaze alone.

Basically like a “Blaze 2.0” - and if tutorials are tweaked based around the changes, the learning curve should not be higher than Blaze alone (in many situations it could be easier to learn, not having to mess around with the DOM manually and not having to create helpers separate from your code makes it much easier - you can use straight JS to manipulate the variables reactively - which is an easier concept to put your head around imo.

The new employees I trained definitely have a much easier time with Blaze + ViewModel than they had with Blaze alone. Learning curve is easier, they come to me with much less issues than before, and their code has reduced in size by about 50%, making it overall much cleaner.

One of my employees was a java developer creating desktop apps for many years (not javascript) and is now moving more in to web development. Another bonus of ViewModel is, users such as him are MUCH more comfortable with reactive variables. Because “traditional” programmers are used to all of their variables being “reactive”. Meaning your Meteor app can function even more like a traditional client/server desktop application, rather than a typical web app.

I also believe other benefits could be added if it were integrated in to Blaze. ViewModel is pretty clean right now, but for example, some additional tweaking of scope would be beneficial. If you compare React ViewModel to Blaze ViewModel, the React code does look a bit “cleaner” imo… some tweaks to Blaze where it was built alongside ViewModel could improve this.

Just an idea, as I think the combination could have quite a bit of potential! If the discussion were on how to improve Blaze, I doubt many new features could improve it more than ViewModel does.

@ramez I do not have experience with Vue so I can not comment. I have heard good things though!

1 Like
9

Well, now I understand - better understandability, less learning curve, more adopters. Maybe Blaze 2.0 based on VieModel seems then like a good idea!

And if someone would make Blaze IDE (Blaze 3.0) similar to the one they did for Java-based Vaadin - I would really be first to sign up and pay EURxx

10

I think the #1 immediate goal for blaze should be to get it so it is platform agnostic and on NPM.

To me, this seems more important than adding new features. Being on NPM could be the difference between life and death for blaze.

Once it’s on there, then the focus of course should move to new features and functionality ASAP.

I don’t know much about blaze’s inner workings, does anyone know if an agnostic move to NPM is possible? I guess you would have to work with projects like Express to get on their list of configurable view engines? Then I guess you’d need to get a blaze-enabled router on NPM too?

1 Like
11

I agree – and if Tracker is also incorporated (or separate NPM package) it becomes an amazing MVC view layer that could be used anywhere, not just in Meteor. After all, it’s Handlebars.

1 Like
12

Wish Templates2 was more mainstream.

13

How about depreciating jQuery dependency? This should increase performance

14

For that to be viable I think it would definitely need something like VM integration then, since there would no longer be any other easy ways for DOM access/bindings.

15

Maybe we should ask @manuel what he thinks about it.

1 Like
16

after we move it to npm.

npm is the only way forward. otherwise blaze faces certain death.

17

My thoughts:

  • Blaze should stay “Blaze”. For every person who loves ViewModel (or any other library) you’ll find another one who hates it. So I think it’s better to leave Blaze as it is, fix bugs, make performance improvements, etc. but not incorporate an external library into Blaze itself.

  • jQuery is used only because Meteor comes with it. There’s nothing that forces ViewModel to use it (the react version doesn’t).

  • About the whole smart/magic/overloaded components. I’ve never understood the whole “ViewModel lets me write my components the way I want and that’s a problem”. With ViewModel you can make your components isolated islands (my preferred way), you can make it functions of the state that is either passed down or stored in a central place (like Redux), or something in between like Angular does it (the component is an island with respect to its state but logic and interactions with the external world are done via services, or mixins/shares in ViewModel).

2 Likes