What's wrong with React, and how MDG can fix it IMHO

core
81

Hey @dinos now I have to take offense to you calling @jimmack1963 a troll. It’s clear to me that his intention was protective of @awatson1978, whether or not she needed it. So why call him a troll?

By the way, to keep this reply relevant, I have a feeling browsers will soon start to add multi-core support as we start to develop JS more functionally. I mean, it’s not a stretch to think that if V8 can do so many optimizations and JIT compiling, it won’t be long before they can optimize a single page app to use multiple cores, right? The details of all this is above my pay grade, but I hope it’ll come soon.

82

@hwillson you did great job but Blaze syntax isn’t best possible and I surprised that you spend you time by doing something closer to Blaze Components but with React on bottom, not Blaze + Tracker + Spacebars (BlazeComponents way)?

83

Those qualifiers did not come out of nowhere. Awatson herself implied props and mount are examples of the “decline in professionalism” of APIs and that Facebook the most used web app in the world is a poor example of professional software development. Apparently only things like healthcare and finance count as “professional”. The profane adjective is warranted considering the links posted to urban dictionary.

Women do face plenty of legitimate issues in tech, but stretching to turn an issue like this into an example of one is not doing the movement any favors.

2 Likes
84

I wish I could take the credit! @timbrandin is the mastermind behind Blaze React so he’s the best person to answer your question.

1 Like
85

I’m curious as to Trackers role in React. Will it ever see true integration, or will I have to buy into Redux to rerender components correctly? I love implicit reactivity, and really want Tracker to work 100% outside of Blaze…

2 Likes
86

@SkinnyGeek1010 @dinos

Thank your for your extended answer und schöne Grüße aus Köln zurück :wink:

1 Like
87

@vonwao Whoa, whoa, buddy – that’s a bold claim!

I love Blaze thanks to:

  • its extremely intuitive APIs.
  • it’s “just HTML” with some template tags, and thanks to those tags being reactive, you get implicit reactivity and can code fluently in a completely natural way, without having to think about stuff like componentWillUpdate.
  • the fact that I can achieve basically everything with its lifecycle methods, event system, and helpers.
  • that I can make Blaze template act like really reusable components if I want to, thanks to features like passing data contexts, scoped reactivity with ReactiveVar/Dict, template.subscribe(), and Template.instance().
  • its concept of sub-components with {{ > component }}.

I’ve been checking out React (with Redux) and Vue.js for a while, and I honestly cannot see the upside of using React instead of Blaze, except for a performance increase and potentially server side rendering. I’d love to be enlightened though!

Many of people’s arguments for React can be achieved in Blaze as well, if you organize your template code into components, which means

  • think of how you pass data around – should the component be “dumb or smart”? Should it know about its dependencies and create subscriptions, or should it receive everything from an outer scope?
  • think of the internal state of each component – are you causing side effects?
  • think of what code that should reside in the component – is there too much of it in there?

I think we have all the tools we need in Meteor to create just as great UI components as in any React setup. All the mucking around with Redux stores and reducers just seems too abstract for me.

9 Likes
88

I agree with @johanbrook on this one.

I have built a rather large application on Blaze. I use smart file and variable naming, and considered organization to keep things maintainable.

I use Blaze components that built myself (without a package) and they work great. I can make a change to a component and the change propagates to all my forms.

I’m super productive as well. I can get a feature from concept to go in no time. When my clients have an issue, I know where to look even before opening Atom (the editor).

I’m dreading the new direction Meteor is being dragged. :no_mouth:

2 Likes
89

Ok, well you are free to use the tool that suits you best.

You proved my point, “extremely intuitive API… just HTML”, means it’s very friendly for beginners. React is a little less friendly for beginners, because it’s not necessarily targeted to beginners, it’s targeted to professional developers. Just like if you use a “professional” construction tool it will not be as user friendly as a consumer product. The same arguments was once made about Unix: http://arstechnica.com/civis/viewtopic.php?f=20&t=912937

Tracker and blaze components have problems, reactivity is not predictable, React has one-way flow and so it’s easier to understand and virtual DOM so it’s higher performance.

I’m talking about complex UIs with many components and subcomponents. That’s where blaze will hit it’s limits and React will help you most.

But you have to make the choice for yourself.

Also I agree that Redux is too complicated, I’m hoping Meteor or someone will come up with a better solution.

1 Like
90

Well, I’m all for progressive tech like JSX, but at the end of the day, it’s a technology invented by a company – not a world wide standard, like HTML. I think it’s too early to separate “newbs” and “pros” just by their knowledge of React/JSX.

Tracker and blaze components have problems, reactivity is not predictable, React has one-way flow and so it’s easier to understand

These things I’ve got problems understanding. Just like @aadams above, we’ve put in some time organizing our (I would say pretty large) Meteor app into well-defined components, and that’s been working out great for us. No one of my or my co-workers have had problems with “bidirectional data flows” or “unpredictable reactivity” after moving away from Session when that went out of fashion.

I’m talking about complex UIs with many components and subcomponents. That’s where blaze will hit it’s limits and React will help you most.

Yes, as I said, I’ve been building a pretty complex Meteor app with a load of subcomponents. Limits as in organizational limit, or performance limit?

I just don’t think one should be so quick to jump on the React bandwagon and drink the kool-aid. Add support for it in Meteor: totally. Throw away everything and buy into the Facebook stack: not so sure. I remember when every smart web person thought Backbone was the most awesome thing… :wink:

I think there are a lot of great insights and opinions in this thread, by @aadams, @faceyspacey, and @mweststrate : Next steps on Blaze and the view layer (around post 465 and down).

3 Likes
91

I just don’t get this @vonwao, I have many templates with 50 or more Blaze components. On these same templates I have many level deep #if statements. I have conditional, multi-level validation on these components. On these same pages I have bar charts. Maybe 10 subscriptions, pulling in data from many different collections, time subscriptions, count subscriptions, joins. I have many calculations and logic too inside the helpers. These pages seem as complex as anything I did in C# and F# when I use using .Net using webforms and winforms. These pages are as complex as anything I’ve seen using the MEAN stack. This works, it seems relatively fast (I can’t compare to React), and I’ve have NO issue debugging or fixing bugs fast.

What walls did I hit using Blaze? What great doors will open for me using React over Blaze?

I don’t understand how you can generalize as much as you have. It almost seems like you’ve not really used Blaze in much depth.

1 Like
92

You’re contradicting yourself. You said react is only supposed to take 8hrs to learn and some basic concepts…now it’s meant for professional developers? There’s a big difference there.

1 Like
93

I totally agree with this. Blaze gets a bad rap from the lack of guidance and structure. As much as I dislike FBs saying of they aim to have the developer ‘fall into the pit of success’… they do so much more than Blaze. It feels like you get a shovel, flashlight, and a map and you’ll need good luck or experience to not make a mess.

Much like jQuery actually… you can write a mess but i’ve also seen some really nice SPAs written in just jQuery. However, they had lots of structure (Backbone has made me a better programmer comes to mind).

On a side note, everyone one in JS had been making messes with their UI with jQuery and then Backbone came along and created a paradigm shift in how we made UI. This was 10x better than most jQuery apps.

Anyway, I feel like that ship has sailed and there isn’t much time left to change Blaze so that devs fall into the pit of success.

With Iron Routers reactive routes and Session some legacy apps I made feel like playing whack-a-mole when maintaining it. Newer Blaze apps are much easier to maintain after adopting better patterns, making it more declarative and dropping Iron Router and Session.

I do hope that Blaze will be something that can be used for several more years, I would hate to see it just drop out of the ecosystem.

I’ve been checking out React (with Redux) and Vue.js for a while, and I honestly cannot see the upside of using React instead of Blaze, except for a performance increase and potentially server side rendering. I’d love to be enlightened though!

I think React is one of those things that looks horrible from glancing at docs or tinkering with for a few mins. You almost have to build an entire crud app with it to really appreciate the different way of thinking. Redux is 10x more so… almost impossible to grok from looking at readmes or even tutorials. I think Redux also makes more sense once you hit the edges of building a React app without flux and can then appreciate what it does.

I do wish Redux didn’t have all the ‘extras’. At it’s core it’s just a pattern like:

user clicks button
   |
   V
even handler gathers data from UI 
and calls dispatch( buttonClicked(data) )
   |
   V
buttonClicked function prepares data and 
does dirty work (send db reqs) and then
returns object which is returned in dispatch call above
   |
   V
a 'reducer' function takes old state and new object from above and
merges them together, returns what the new state should look like
   |
   V
UI layer listens to specific keys and updates if they change

That being said I still think Blaze is a great UI layer. It’s more important that users like your app and that you’re productive so you spend less time debugging and more time working on the real featues.

Here are some ‘patterns’ that were pre-react that helped me build better Blaze apps:

https://github.com/AdamBrodzinski/react-ive-meteor/blob/master/both/actions/post_actions.jsx
https://github.com/AdamBrodzinski/react-ive-meteor/blob/master/both/domains/feed_domain.jsx

The key is to decouple the UI and make things predictable for your future self and team.

5 Likes
94

I think if you do not like React and its quirks you can use Angular. It is nicely supported within meteor and has a bigger community than React. So if you do not like React there is Angular and lastly Blaze isn’t dead. There are projects that help you with Blaze like Blaze components etc.

I think people are just overreacting on the thread. React is not the end game of web programming. It has introduced a new way of thinking in web apps and many people appreciate and like it. If you do not like it there are tons of very popular frameworks present to suite your needs.

2 Likes
95

Jsx will only take 8 hours to learn. A simple react component with a simple render method.

1 Like
96

I guess you haven’t hit enough edge cases. It’s not about how many templates or if statements, it’s about the complexity, coupling between components, reactivity loops. Because react is one-way data flow you don’t have reactivity loops.

2 Likes
97

also it is really important how many people works on one app :wink: With Blaze and big app it is hell :smiley: but of course it can be done.

98

This sounds so matter of fact. Are you saying there are situations on the UI in which Blaze simply cannot be used? If that’s what you’re saying, I’d love to hear these edge cases know about.

I believe firmly that Blaze can do everything React can, but I can do it faster with Blaze.

If you read what I wrote, I have interdependencies between components – very complex ones that are multi-level deep. Every component on the page is tied in reactively. I’m just not hitting the walls you speak of – will you start being more specific if you can? And conversely, can you be specific what React will give me tangibly over Blaze? :grinning:

4 Likes
99

This is a great point @juliancwirko. I believe that I might not have any issues with a large Blaze application because I’m the one that built it. If I brought other on and had to on-board them, I might have a harder time of it than with React. I simply do not know because I’ve never used React.

1 Like
100

It’s seems to me that the reason devs are having trouble putting into words the specific benefit of React over Blaze is because it isn’t a technical matter…It’s a disciplinary matter regarding how data is structured in one’s app.

You can essentially achieve a “one-way” data flow in Blaze if you’re carefully organizing your components. React just makes it that way by default.

and @vonwao in regards to your 8hr remark…would you hire someone with only 8 hours of experience with React? No. Then why argue that is all the time needed to learn React properly? Talk about edge cases…React may not be the most complex technology on the web but when the discussion becomes about “how easy it is to learn” something, then it becomes completely subjective based on people’s learning environments and capabilities. Everyone is different.

6 Likes