fullName() {
return this.firstName + this.lastName;
}
<template name="fullNameBadge">
<span class="full-name-badge">{{fullName}}</span>
</template>
But this doesn’t further your point, as there are also ways to write React code that is also hard to reason about.
We are not forced to write Blaze cod like this. One can write code that is very easy to reason about what is does, where it comes from and where it goes.
Oh sure, you can shoot yourself in the foot with whatever framework. But for me personally it seems like React encourages that modular, explicit approach out of the box, where Blaze doesn’t.
I think it’s because Blaze/Spacebars was originally based on Handlebars, which wasn’t designed as a language to build complex, data-heavy applications. IMO this attachment to handlebars concepts like data context really hurt it in the long term, even though it made initial adoption easier.
It seems like you’re asking people, “why do you like X” and then saying “well X can be bad too”. It doesn’t matter - I’m just explaining where I’m coming from.
No. I’m simply asking, why are you more productive in React, which to me means you can accomplish the same thing in less time.
And your reasons hinted at React being easier to reason about (smaller components) and maintainability (refactor, clearer where data is coming from and going to).
That’s a fine answer if you feel like in the long run you’ll be able to make up time lost during building the app.
But I just wanted to mention, in parting, that I’ve heard about things being more clear where data is coming and going before, and I just don’t understand it. I gave my examples which to me are crystal clear to reason about.
You then provide confusing examples (that no one should use by the way), and hold that up as support for a point that React is easer to reason about where the data is coming from and going to – all I’m doing now is calling foul here.
I find that I start hitting “maintainability” questions about 10 hours into building an app. So if I’m trying to make a simple demo in an hour, then sure I don’t need any structure. But as soon as it’s a real project, I start forgetting the code I wrote about 10 hours in, and then I’m already in the “long run”.
I think it’s pretty clear that Blaze has no built-in concept of argument definitions, and that data context is used all the time in Blaze. If there were some small changes in Blaze that made my preferred workflow easier, then it would be great! I’m not saying it’s a total game-changer, at the end of the day you can build the same apps with both. Literally just trying to tell you what I’m thinking.
I honestly cannot relate. I find “maintaining” a large Blaze application superbly easy to reason about and structure, and I’m about a 1.5 years into building the app. Every day I’m making adjustments, features, etc. – my clients always compliment and thank me for how fast I am. It’s a good feeling really.
(no disrespect implied)
I mean, my workflow sometimes is: I have to do a search for keywords, but then I connect the dots.
I’m sure you’re getting tired at this point, so I won’t ask you what you mean by “argument definitions”.
I used it some when starting out, removed that code for the most part.
I appreciate your candidness here. I’m glad we had this discussion, it has made me feel a little better about being on Blaze for now (although, I’m going to try out React at some point).
Hopefully we will see some Blaze enhancements (performance and otherwise) and Apollo integration come our way sooner rather than later, and then maybe I’ll feel even better.
I’m not ashamed of this - I’m forgetful, I don’t type very fast, I don’t know almost any editor hotkeys, and I don’t like to spend a lot of time setting up tools. So I really like it when a framework/language makes it so I don’t have to think very much to see what’s going on. It’s a big reason I like more verbose but “safe” code.
There’s really nothing to be ashamed of. Again, I appreciate your candidness.
I like this sentence. You know, I feel like I’ve set up my Blaze environment in such a way now that I don’t have to really think as much as I use to. If/when I need a new template/view/screen (what have you), for the a good portion of my screens now I can just cut and paste my way to at least 60% complete. Then it’s all about changing names: template, variable, collection, etc. Not all things work out like this, but things move much quicker than before.
This conversation started when @sikanx said he can will take any Blaze example and write it (better) shorter in React. Hence React is better. Honestly I don’t know now React so I can’t say.
My code can be verbose at times too. I’ve never lost my speed and productivity, and over time my code feels more and more “safe” because I use the same code in many places – its time tested. In the areas where I’m writing new code, I have the patterns down so well now that I know for the most part its going to work. When I come back to the area later, its easy for me to reason about for all the reasons we’ve mentioned.
Your time is always appreciated and enlightening.
The only way I would consider going back to Blaze is if Blaze focused on being maintainable. It’s the #1 issue i’ve had with Blaze over the years. Starting a Blaze template is easy. maintaining one with a team is painful. It’s way too easy for someone to introduce a bug from not realizing how one change will effect something else in the system. A lot of times it feels like tweaking, getting it to work, then running through the app (manually) to try and catch any issues. Add a couple of years of code rot and it’s enough to make anyone want to jump ship.
I share a lot of the same sentiment as @sashko . Writing code is easy. Maintaining code is hard.
React is far from perfect but the methodologies it embraces help make maintainable apps, and if you follow common conventions you’ll have code that much easier to change.
My first React (native) app started off using props and only passed data around this way. It was verbose to pass data around but very traceable as you would just “follow the money” so to speak, watching where the data flowed.
Then I thought I would be clever and reduce all that typing… do I ever regret that. I chose a terse flux library (when there were tons of flux options) and I had state flying in and out of the view, in stores, I skipped action creators because… typing… and I paid for it in spades later on. It became a total 
show. Sure I can figure out eventually what was going on when coming back months later… but it wasn’t fast.
I was essentially re-using a lot of the Blaze conventions with it’s hidden context, global state (like Session), and loosey goosey organization of where to put async things (making it hard to trace/find later)
Anyway my point is that when I went back to the “React way” using container components, pure views, and very minimal global state, things became really easy to work on. Also react works best if your components are very small and compose with others… this can be a lot of typing so a reactcomponent tab trigger will scaffold out a basic component with everything I need 90% of the time. This reduces the time down drastically.
Nope, wouldn’t go back to Blaze. I have 2 reasons for my decision:
But yeah, I must agree that writing JSX feels a little bit like writing old PHP scripts in 2003, without using any framework and mixing HTML/PHP/CSS in one file. The seperation of HTML, CSS and Javascript in Blaze feels more natural to me.
I was team blaze but then moved to react and I cant imagine not being able to put my css in my css with my html in my js.
I used to really prefer Blaze over React, until I discovered Vue: templates, real components, at least as fast as React, and more… Vue is getting mainstream because it has so many great features. Everyone who likes Blaze simplicity should give Vue a try.
So it sounds like you and @sashko agree that productivity (time saved) over Blaze might not be a thing after all?
I’ve heard this before, but it’s foggy to me what this means. To put more meat behind this, are you saying if you change something like a Global Session, in one place, it’s hard to reason about what the affects to the system are because one might not be able to reason about where this particular Global Session is used throughout the system?
Why isn’t a simple find command enough for me to find all the spots a global session occurs, review the code, and reason about what making a change in one spot will do to the rest of the code? Isn’t this how coding works throughout all the languages and from the very beginning? There has to be side affects in React – make a change in one place and affect another. Don’t you do a find string to find all the affected places and reason about outcomes in React too? Where’s the disconnect?
Also, is there no such concept as Globals in React? How are the majority of bugs caused in React, by not reasoning about where data comes from and where it’s going?
By the way, I very rarely use Globals in Blaze. For the things I do, and there’s only a handful, they have distinct responsibilities and naming conventions and are used in very few places in the code.
No tweaking and no code rot occurs with React?
I missed where @sashko said writing code is easy, but I think we can all get behind the sentiment that maintaining code is hard. I’m happy to report so far, maintainability has not been an issue here in Blaze land.
This is encouraging. Is React much easier to change because of being componentized or another reason?
For example, I have a template that’s just a form input field, with styling and logic within. I use this on every form, multiple times per form. When I first built the template (aka component), I found I needed to make changes more often to it. When I made a small change, instead of changing every input field of that type in all my forms in all my templates, I made a change to one spot and it propagated everywhere. That to me is an example of productivity and maintainability. Is it any different with React?
So it is possible to write React code too. I worry about not following the right path if I transition to React. I read about containers of components, and where data should be feed into. It’s taken me a while to get my good patterns and practices down that promote code maintainability in Blaze.
Just as you had initially found out what makes for a maintainable React app, so too can one find their way to a maintainable Blaze app. I don’t know, but it sounds like all things being equal React might be more maintainable, but what I’d love to see is a side by side comparison of good code written in both, rendering the same thing to the screen and talk/write through the pros and cons.
Also, for the most part I don’t use hidden context, global state, and I’m organized where I put async things – so just because something can be done, doesn’t mean it will. I’m sure there are gotchas and edge-cases in React too that make it a pain to maintain.
Glad to hear there are strong conventions and a “React way” of doing things. This is reassuring that if I decide to make the migration, there will be guidelines.
To be fair, there are ways to write Blaze that make it easy to work on as well. You have experience with both Blaze and React, me only Blaze, so I cannot make a real comparison for myself. You seem to have honorable motives, are good intentioned and competent, so I do assign your opinion some weight.
At this point it just seems the whole JavaScript community is moving to the Facebook stack, and I don’t want to fall into the trap of group think – where I’m doing things just because everyone else is. This cycle of migration from one thing to another has happened before, and therefore its reasonable to conclude it will happen again – the next time away from the Facebook stack.
Having said this, I too have recently looked into making the switch to React, but not for any of the virtues you sited. Not because of productivity or maintainability or how easy or not it is to reason about. Having a large application, I have no real issues with any of the above and my clients are very happy with my turn around speed.
I’ve looked at making the switch to React only due to MDG dropping official support and the unknowns around community involvement. I think the premise of this thread is really, if the community steps up and maintains and improves Blaze, would you return or stay with Blaze. I think for me it’s too early to tell because it’s not only how fast things “improve” but what the improvements are, what gets prioritized.
Does the community put time into making Blaze easier to reason about and maintain? Does it address performance by adding virtual or incremental DOM? Server side rendering? Will Blaze build-in a more modular, explicit approach out of the box? These are all questions yet to be answered. Until we get a clearer picture here, I can’t say for sure if I’ll stay or if I’ll go.
@aadams - Are you by chance a talk show host or television news moderator in real life? You’re certainly a pro at pushing discussions forward. I’ve been through background security clearance interviews in which I would have fallen to pieces, if you were my interviewer … 
For existing apps that already use Blaze, I’d still use Blaze until there was a clearer benefit and easier conversion path to using something else. For new projects, I wouldn’t use Blaze until it covered both of those when compared to alternatives, especially in the context of meshing with a functional (declarative, immutable) paradigm. I’m using an approach like this for new apps, to compose stateless React components, and I’m very happy with that.
Personally I agree with this statement a lot. I think the issues for me with Blaze come down to a few things:
I will also say that React virtual DOM is MUCH faster than Blaze. I will say that some of the perceived issues may have come from problems that are solved with DDP Batching, etc. Would be interesting to build a decent app and measure in browser render performance of the two…
I personally don’t think that I could get back to Blaze.
I’m having too much fun writing with React and the whole concept makes so much more sense to me. I feel like I have better control of my data, have the ability to improve performance with some of React’s inherent prototypes.
Just feels cleaner and more organized. JSX was a pain in the ass before, but now I’m just too used to it and still make the class vs. className mistakes from time to time.
React actually has a HTML to JSX converter… I really wonder why they won’t just make a plugin that lets people write normal HTML and then magically convert it.
http://magic.reactjs.net/htmltojsx.htm
I find it odd that it wraps the component in another DIV… that has odd styling implicatins
I really wonder why they won’t just make a plugin that lets people write normal HTML and then magically convert it.
That’s called ViewModel =)
You can write this:
Example({
render() {
<div class="alert" style="color: red" />
}
})
No className or style objects, you can just copy/paste the html and it works.
The one feature I wish Blaze had was a clear way to define required parameter types. Is that what you’re getting at? The meteor guide provides a way to do it, I just wonder how many people actually do it that way. https://guide.meteor.com/blaze.html#validate-data-context
Also, I wish Blaze never had implied data context, or at least made implied data context an opt-in behavior, not the default behavior.
Additionally, for better clarity, always explicitly provide a data
context to an inclusion rather than letting it inherit the context of the template where it was rendered
I think Blaze is fine and works well using a ‘Dumb Component’ style where all of a Blaze template’s parameters are explicit, and it doesn’t go looking for things. I never had a problem with performance.