Would using viewmodel make it easier or more difficult to migrate to React in future than if viewmodel was not used?
Iâd say it would make things easier - for example in React you call actions very similar way as in Viewmodel:
React:
<button onClick={this.myAwesomeAction} />
Viewmodel:
<button b="click:myAwesomeAction" />
or even:
<button on="click:myAwesomeAction" />
when you want to use the original javascript click event for some reason.
Thereâs also Viewmodel for React in the development right now, which will be a very easy way to switch to React from Blaze.
1 Like
Hereâs my advice: Keep using Blaze but when anybody asks, tell them youâre using React. This serves 2 purposes:
-
Youâll keep getting awesome things done quickly with Blaze, and wonât get sidetracked by the âWhat, youâre using Blaze??? OMG - you should really use React!!!â never-ending discussions.
-
This is an awesome way to really mess with anyone new starting on your team (hazing ritual).
17 Likes
kind of agree - be careful investing time and energy into react (or any other technology), the JS community switches so quickly that itâs only worth the effort of using React if it genuinely will improve you or your teams productivity (disregarding marketing yourself as a developer)
blaze is actually pretty good
For myself I went with AngularJS instead of React for my app. However, if youâre learning best to do something new than go deep dive into a single technology too much especially in UI land where technology stacks can change every few years. Even AngularJS will look vastly different from a few years ago when Angular 2 comes out.
Personally I chose AngularJS at the moment because of the Dependency Injection, modules, and other things I was used to on the server side and it allows it on the server side.
My only issue with angular-meteor is it seems like a second class citizen in the Meteor ecosystem. The examples on the main site use deprecated methods already.
I also had some minor annoyances when using things like blaze-with-angular, more like I gave up after a while and just re-implemented some blaze templates as Angular instead.
Overall though, because I can do Angular on the server side is the main sell for me, because I can develop in one âframeworkâ on both ends.
ReactJS and Blaze from what I can tell are both UI frameworks. Whereas AngularJS with Meteor via angular-server makes coding a bit more awesome with Meteor.
1 Like
Yes, be careful investing time and energy into a framework used by Facebook, Netflix, AirBnB, Instagram, and many other $1B+ companies. It might disappear overnight!
Instead, you should use this other framework thatâs not actively maintained anymore and only used by a comparatively tiny part of the JavaScript ecosystem. This definitely sounds like the safest option! 
7 Likes
I get your point- but you could have said almost exactly this about Angular 1.x 18 months ago. Iâve watched companies pour literally millions into re-writing apps on Angular 1.x because âAngular is the future and itâs backed by Googleâ, now the same people that championed Angular are banging the React drum (or Angular 2.0)- but the end result for the business is exactly the same.
If your app is going to stick around for more than a few years (admittedly thatâs not always the goal), consideration should be given to future engineers. The devs who understand the benefits that React brings right now are well above average, but sooner or later those engineers will move onto newer things and maintenance will fall to below average engineers, who wonât be able to just pick up React v0.14.4 in a week and be productive.
And for a beginner you donât really have to âlearnâ blaze, IMO the cognitive load of React is higher and thatâs not something beginners can abstract away immediately, my hypothesis is that a beginner would be more productive with blaze than react out of the box.
6 Likes
Thatâs true. Billion-dollar companies can afford to discard whatever they have for something new that they think looks better. They could probably afford to have their apps rewritten with whatever supposedly great framework is out at the time on an annual basis.
5 Likes
I like how much faith you have in blazeâŚhavenât peeked in on the battle in a while but itâs encouraging
1 Like
Now that Blaze has been split out into itâs own project (for real this time), I would love to see some kind of roadmap outlining its future plans. There has been a lot of discussion lately about getting the community more involved with projects like Blaze, and splitting Blaze out on its own is definitely a great step. Iâd love to see some discussion around the next steps though, especially with regards to what âfuture Blazeâ will look like, and how we can help out. Some form of concrete plan of attack would be awesome. I know MDG has @mitar spear heading up the new Blaze effort from the community side, but I donât think he can do it alone (actually, itâs @mitar - maybe he can 
).
EDIT: Just to add, I know the open issues serve as a roadmap of sorts, but something a little more structured and concrete could really help build anticipation, and get people excited about Blaze again.
1 Like
I can tell you how I see it from my point of view. I think the first step is to get Blaze to be available as a NPM module. And split also dependencies into separate repositories/NPM packages.
Then having working testing. And some stand-alone documentation page. So first we should have basic project infrastructure.
After that I think it should mostly depend on the community, what would they like to make pull requests for.
As a matter of fact, I do not think I will have much time to work on Blaze myself. I made Blaze Components work pretty well for me and I think that Blaze should mostly now be in maintenance mode, fixing some long standing issues, but should be kept backwards compatible. On the other hand, if there are some backwards compatible changes needed to make new stuff on top of Blaze work, that would also be OK from my point of view. If community would like, we could try to get Blaze Components to be Blaze 2 or something, a new version, but I personally will not be pushing for that. It does not feel right.
I think one interesting next step would be server-side rendering. I tried to play a bit with that and it seems to work well.
One thing I would like to see for Blaze (especially with components) is some type of gallery. Something like I made for Blaze Components: http://components-explorer.meteorapp.com/ (Site is going down all the time, since I migrated it to Galaxy, 
) So a more visual way to navigate Blaze packages.
3 Likes
How about adding virtual DOM to Blaze? There was talk of Ember (which is based on handlebars) implementing it. Maybe we could âborrowâ it.
But I do agree that SSR would be great for many applications.