my humble opinion is that Blaze is better for medium projects if there’s a good Project Manager, because React lacks the separation of concerns.
If I need every designer to know JS and react on top of HTML, then I need to pay people more. With blaze I can design the UI, then make it works.
I would hire someone with 0 hours of experience in React, if they have experience with Javascript, are smart enough and willing to learn a few new concepts. You can fix not knowing something with a few hours and a little patience, but you can’t fix stubborn or stupid. And most people are actually stubborn, they want to stay within their comfort zone and don’t like any change.
It’s not JSX or React that is difficult to learn; it’s the entire React ecosystem. There is an awful lot of churn and uncertainty. Best practices seem to change daily and it really feels that no one “knows” how to write an app with React. Debates about functional reactivity vs side ways data loading, ui state vs domain state, the dozens of libraries. Not to mention the several ways to integrate these flows with Meteor.
It’s figuring out how to go about writing the thing rather than just writing the thing.
It’s not React per se that is difficult; it is everything else around it. This isn’t a criticism by any means, just an observation.
Yes, I hear your point.
So at this point, I wouldn’t recommend jumping on any bandwagon (redux/flux/relay), but you can still use dip your toes in the react world pretty easily, you can even use it side by side with Blaze.
If you decide React is something you like, gradual refactoring is the way to go: you can create some new react components, drop them in your blaze app (or viceversa).
This is the case for me. I only had a small team of 3 and the most difficult thing was determining what would happen when, for example changing a Session variable. It’s fairly obvious that it would change what you’re looking at but some other part of the UI could depend on it that you don’t know about. The tricky bugs come from edge cases and race conditions since most will make sure the app works by giving it a ‘run though’… except it doesn’t always work.
React doesn’t solve this directly, rather it has a very strict way of dealing with how the UI updates and gets data. Something like Redux goes even further with de-coupling and a more strict data flow (for better or worse).
Blaze/Meteor could have this but it would take a ‘standard’ or framework on top of Meteor to do this… as there isn’t a strict way to do anything. The loosey goosey feel is great if you’re just hacking on an app but the more time you’ve been away from it or the more team members the more difficult it is (albeit very doable-useable).
I haven’t had the chance to drop into very many Meteor and React apps of others but the ones I have it’s easier to know what’s going on when there are strict rules… otherwise you’ll need ack or grep to get out of the fog.
Just my 0.02 though.
It’s not JSX or React that is difficult to learn; it’s the entire React ecosystem. There is an awful lot of churn and uncertainty. Best practices seem to change daily and it really feels that no one “knows” how to write an app with React.
This is def. an issue and a burden to consider. Although I feel that JavaScript SPAs in general are churning a lot lately. I didn’t fully empathize with this until learning Elxir and was it was very comforting to just have ‘one way’ to build an app, (as in file structure at least). Though I feel this is true of most serverside langs/frameworks as things haven’t changed much in 2 years.
Absolutely. I agree. In fact, that is what I am (attempting) to do now. I found “vanilla” React and JSX to be really nice and straight forward once I started playing around with it.
But even then, there is still that uncertainty of how to get React to work with Meteor in an optimal way. Off the top of my head, I can think of three different ways sans Flux: GetMeteorData, tracker-react, and komposer. So even if you decide to ignore Flux/Redux/Relay, you still have several solutions to investigate and pick from.
I don’t blame anyone for being hesitant about this topic.
This is def. an issue and a burden to consider. Although I feel that JavaScript SPAs in general are churning a lot lately. I didn’t fully empathize with this until learning Elxir and was it was very comforting to just have ‘one way’ to build an app, (as in file structure at least). Though I feel this is true of most serverside langs/frameworks as things haven’t changed much in 2 years.
I miss the ‘one way’, too!
The javascript churn is fun to read about and study… but it makes me so hesitant and inefficient. I’m always second guessing myself and wondering if their are better ways. It’s wreaking havoc on my self esteem, man!
ignorance is bliss 
Haha… Gives a whole new meaning to DOM object.
I have to strongly disagree with the core concept of your complaint here. I’m using React in production and the ability to compartmentalize and objectify the visual and functional aspects of my components into a single file makes it far easier for me to write, debug and reuse my code.
I suggest that you listen to this great talk from Pete Hunt, where he addresses these issues directly: https://www.youtube.com/watch?v=DgVS-zXgMTk
Really agree. With React (and I guess Blaze to an extent if you’re hardcore disciplined) my brother and I can work on entirely different areas without overlapping each other.
It takes some getting used to for sure, but once you grok it it makes sense. Just split your UI into boxes those boxes are components. It will take you some time to feel out what should and should not be a component though. And unfortunately there isn’t a tutorial for that, it’s something you just have to learn on your own by making mistakes and learning from your mistakes.
gotta love to work with your brother!!!
but do you create UI from zero, or have you ever ported a commercial HTML theme to React?
When I read someone saying two cannot work on the same project using Blaze at the same time, it makes me wonder if they’ve ever used Blaze before. It’s simply not true you even have to be disciplined for two to work on a project with Blaze at the same time. It’s so easy to pull off, I’m just dumbfounded anyone would say otherwise.
I’ve never used a commercial theme with React, no. I imagine it’s a huge pain.
But then again even when using a commercial theme in many Rails apps, it was still a pain. So I think that’s just par for the course for themes in general and not really a reflection on React.
I feel like converting an HTML snippet to JSX isn’t so bad - you just paste it in, replace class with className and you’re like 90% of the way there. You get extra benefits from splitting it up into reusable components, but that’s not required - you don’t have to do it if you don’t want to.
what about jquery events? and all the libraries that relies on jquery?
What do you do about them in Blaze?
I’ve almost wrote a 400 pages book simply by annotating what I did with several commercial themes. Heaps and heaps of tricks up my sleeve.
I really wish MDG could find a way to port commercial themes to meteor… Bad looking apps are useless apps, and theme forest has been a key tool to reduce time to market for many startups …
Anyhow Blaze is jquery friendly. React not so much.
That would waste so much time. It’s akin to saying I wish WPF themes were ported to Meteor. It’s comparing apples and velociraptors.
Do you know theme forest sells html themes? angular themes?