I’ve started to invest my time in learning React, as there were suggestions in this forum that Blaze would eventually be deprecated and that React delivered a better front-end system. I have recently been made aware of the patent clauses that Facebook have included within their licensing and it is being suggested that they are incredibly inhibitive for any company that includes React in their products.
I have already used Blaze in one project and found it to be adequate for my needs. What I’m getting tired of is investing significant amounts of time in switching frameworks/products for them to change/get abandoned and for that time investment to be wasted.
Can I get a clear answer from MDG as to what the position is on React because this could be a significant blow to Meteor if the ‘preferred’ technology for UI is one that exposes products that have been developed in Meteor to legal action from Facebook?
Another great option is Angular 2, which doesn’t include such a clause and is really gaining a lot of ground! We’re working on some great materials about why Meteor and Angular 2 are a great fit.
Why not evolve Blaze? Meteor started with Blaze, then changed it, then suggested to use React and now Angular - do MDG even have a clear direction of what they want their framework to be?
Hey @tidee, we use Blaze exclusively as well and it’s working great for us. Already in commercial deployments, and it’s super easy and fast to add new features (we also use Semantic-UI).
So far it has served our purpose well. Now, we don’t do pub / sub within the templates. We use event handlers to automatically pub and sub – this very simple class: https://github.com/mrdoob/eventdispatcher.js/ is amazing. We do it at server and client level. So Blaze has all that we need.
The one place I really think it would be great to implement, is a Virtual DOM. This would give solid speed benefits (and negate much of the need for React).
@ramez I am a bit intrigued by your post. I am, like you, very happy using Blaze and Blaze components. And like you I am using some form of event based subscription management. But I created that functionality myself. It would be great to learn about how others have implemented it. Do you have anything written about how you use the eventdispatcher class?
But what need a fullstack framework in it’s core? In my early Meteor days, I had to rewrite a big part of my application, because some “popular community packages” didn’t run on multiple instances or aren’t maintained anymore (f.e meteor-streams, CollectionFS, meteor-cluster). After that, i’ve seen that the Cordova app of the site has crashed after a HCP, so I’ve lost a lot of app installations, because my store entry was full of “I only get a white screen” messages. This Cordova issue was open about a half year until it got fixed wirh 1.3.
.
For me, the most issue about react and meteor seems integrating meteor into react, because react community running forward with redux-flux stuff, and I’ve been suffering few times in this cause, when I tried to implement some modern react packages and they were built with the redux approach in the mind. It seems that every modern react app uses redux-flux for storing data and when you use meteor minimongo and react it seems like a wrong way to manage things in react.
Meteor community suggesting to use redux for the UI-states, but it looks like a half solution. I hope in the future meteor community will find some union approach for this.
@sashko, thanks a lot for your reply. You are right Blaze is not THE core competency, but it is a very solid competency (I personally believe it is core to many developers’ experience).
If you look at the postings on this forum, there is quite a bit about view layers / view frameworks. Blaze has such deep integration into many packages in the ecosystem, it makes a whole lot of difference. In fact, it hedges Meteor’s bet against UI framework volatility.
Hi @jesperwe, sure, let me write up a blog post and post here.
This approach has made development so much easier.
We just trigger events at key moments in the app lifecyle and whoever wants to listen just adds a listeners. This also makes it super easy to add new features.
So basically, if you try to seek legal action against Facebook, claiming that they somehow infringed on one of your patents, then your license to use React is revoked. How is that as horrible as people are making it out to be? Don’t be a patent troll, and you’re fine. Is anyone seriously going to try to take Facebook to court, claiming that FB stole their reactions idea, or their ad targeting algorithms?
I just don’t see an issue here. But probably none of us are qualified to make any assumptions about this, since we’re not lawyers.
Agreed. Maybe somebody at MDG could (PT or FT) be in charge of managing the Blaze branch? In other words, they could handle taking in PRs or providing some support to an outside group willing to take it over?
You may even be able to find a number of small/medium dev shops willing to fund that position with something like https://www.patreon.com/
As far as I understand the topic Meteor team is currently working together with Angular team. Meteor takes care of back-end and Angular2 takes care of front-end. What else do you need? Why is Blaze better? I would like to know because I haven’t used Blaze and React. Just a question from a new forum user.