Could someone put in a few words the value developer and company get when using React vs Blaze in terms of productivity or speed of development?
When using Angular vs Blaze I would put it as as “2-way binding plus Angular components and libraries”, what about React?
I think the way it is now, all those libraries have some form of solution to achieve all those values.
Blaze, Angular and React can all give you 2-way binding and components and libraries and anything any of them provides out of box, another has an “addon” for.
Reacts main advantages (some of them may be a disadvantage to your preference) are
In fact, Blaze 2-way binding is better than Angular one.
Many thanks for going to the quest of finding the difference with me, IMHO these have some architectural value but their business value is very questionable.
Pure javascript -> not possible, as you still use
I mean there is nothing there that Business Analyst would consider very important when Architect would come and tell - 'hey, let’s invest $xxxx into changing this layer of our architecture from X to React. Is there anything?
I wonder if you researched who is behind react 
Well, I have heard of them 
But it does not add much value
I have immediately recalled Fire and Motion article especially the part which talks about advice for small companies not to invest too much time in following the latest fad of MS who was architectural fashion maker at that time.
"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape.
The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft."
This write up is from 2002! By the guy who’s founded Stack Overflow in 2008 and Trello in 2011. He is a winner and where are all those guys who have chased .NET/ODBC/etc.
In fact, it’s only a performance boost in some cases. Here’s a presentation from the guy who made ag-grid (quite a high-performant javascript grid that interacts with Angular): https://www.youtube.com/watch?v=gNhPeLCBbE0. He tried a couple of different approaches to make his grid faster, and virtual dom achieved 0 performance boost in chrome. Also, browsers are getting better at working with the DOM and therefore React 15 now does more direct DOM manipulation instead of just dumping html in innerHTML.
On the other hand, it does make your flamecharts explode if you try to debug something. So the benefits of virtual DOM are small and getting smaller.
React is nice because of its component based approach, but you can do that just as well with Angular and there exist third-party packages to introduce a similar concept in Blaze.
The main advantage of React would probably be that it has quite some traction/hype, so a lot of people are making stuff that integrates with React.
Virtual DOM isn’t about performance boost - it’s about enabling you to write your UI using plain JavaScript and not having to worry about diffing data or fine-grained reactivity. Without virtual DOM something like Redux would be basically impossible, or at least extremely difficult.
So use react because everyone is using react – stupid reason to do anything. Down with react, long live react.
I remember performance being one of the talking points as to why we should migrate to react a while back.
Without virtual DOM something like Redux would be basically impossible
hmm, could you elaborate on that? I thought redux was completely ui agnostic and in fact its react bindings are just an addon.
Yeah but if you used Redux with Blaze you would need to attach a diffing algorithm because otherwise Blaze would rerender the whole page. The fact that the react binding is so simple is because of the React virtual DOM design.
The fact that React is so focused on components means you naturally tend to write your app as a set of small, reusable components instead of huge templates. I find that really helps you become more productive as your app grows in complexity, instead of the usual opposite.
If you play around with http://meta.telescopeapp.org/, nearly everything is a reusable component: UI elements, forms, modals, modal triggers, paginated lists, etc.
So especially now with tools like React Storybook and Chromatic, I think the whole componentization approach is pretty awesome for any large enterprise project.
(Also I would add that I think React is an important enough innovation that you should spend one week of your life just to learn it and give it a chance, whether you end up using it or not)
Why stupid? The ecosystem, which is usually a result of popularity, can be just as important as the design of the framework. Because react is popular you have a lot of component libraries, integrations with stuff like graphql, meteor, redux, … , debug and build tools, IDE integrations etc. You also have more people contributing to the core project which pushes the technology faster and people who will answer your questions on stackoverflow. And because it is popular you have a little bit of insurance it will not die tomorrow.
For me, that’s at least as important as the technology itself.
I’ll rewrite that to neutralize:
So use [x] because everyone is using [x] – stupid reason to do anything.
But why? Because it’s just bad practice. Technology should be used based on the situational need and what technology best fulfills that need – not based on what everyone else is using (this doesn’t mean the two (popularity and best fit) don’t intersect in cases) (i’m glad you found react is perfect for you).
We all get why MDG is switching to react – it’s in there best interests (it was a self serving move by MDG and I don’t believe ever in the average Meteor developer best interests).
But this takes nothing away from Blaze in the context of Meteor (at this point in time).
Further, I would question if react is actually better than some “other” tech at solving the general needs of most Meteor developers (again at this time) (even taking into account the rich package environment outside the Meteor world) (I think when MDG removes DDP, Tracker, et al., then Blaze might no longer be the best choice for Meteor developers).
But of course react fits the technology needs of the developers that write the Facebook application – they wrote it for their specific needs (not with Meteor developers or Meteor style applications in mind).
I’m happy you’re happy with react.
My 2 cents.
React provides great business value because you are now writing PREDICTABLE software. And with predictability comes saving money and time on stupid bugs and incomplete features. This is the thing we lack with blaze and reactivity in general. Speed of development certainly goes up as one gets more proficient as well.
The main advantages I see are:
It is also a must to take into account is that it’s the Live Apps which do matter.
Switching from one technology to another without delivering to user base is not a vital route. So, if development company first switches from Blaze to Angular, than from Angular to React, there is no instant increase in the deliverable but rather decrease. And in the world where MVPs matter (product for startups - that was original purpose of starting Meteor as legend says), advanced tricks would not matter at the starting point of writing the app.
It would be great to see some hackaton of people trying to run SaaS from the scratch using different technologies. I do not think that results would be very different in terms of time and money.
I mean that many developers do no take into account ‘opportunity cost’, i.e. relative value, not absolute of switching to any technology.