You might re-read his @aadams post, as it is very well-thought I think. You are missing the time-factor I think, writing around bugs today is something different as being confronted with it tomorrow, when packages update or expose, and so on.
1 Like
I’m just simply pointing out the fact that he is complaining about being forced to change his code to get performance improvements and bug fixes… Which implies he has performance issues and bugs now. If he doesn’t, this argument becomes a moot-point, he can continue running the code he has now, as-is, with no issues.
The change to “Blaze 2” or whatever they call it I’m sure will be the most minimal change that MDG can make it, whilst still retaining all of the benefits of utilizing React as the underlying view-model.
I just see this argument as making a mountain out of a molehill, and I say that as someone who has invested a massive amount of time in creating a Meteor application that is currently released, being used by customers and was (until v. recently) entirely written in Blaze.
4 Likes
I’m in the exact same situation, and I think many are. However I do trust MDG to make the transition as smooth as possible.
1 Like
How about a tutorial on mixing Blaze & React? (And best practices around it?) Is there something like this out there?
My Blaze UI could use some performance improvements for a certain (sub) template, what would be the best approach to rewrite that?
1 Like
In my opinion, this is a straw-man argument:
Lets just say I have no issues with Blaze 1 right now, as is (to wipe away the point you made based on assumption).
The second sentence in my original post alone is enough to cause what I believe is a serious encumbrance on my bottom line:
The following is what I would consider ad hominem comments:
I’d like to keep the discussion civil.
It is intellectually dishonest to brush off an individual’s reaction to a situation as unacceptable because it is not the same reaction that you would have:
I’d say this is an appeal to questionable authority:
Further, as to your statement about the migration from Blaze 1 to React:
I’d just like to point you back to my original post:
In sum, my conclusion:
I believe we, the Meteor developer community, has been given False Alternatives, either stay with Blaze 1 or Migrate to React (or Blaze 2). There exists an alternative that seems unconsidered by MDG, I believe to the great detriment of the existing Meteor developer community:
Namely keeping Blaze 1 around for the long term in support of their existing Meteor developer based. And in so doing maintaining, bug fixing, and possibly ever-so-slightly enhancing Blaze 1.
The result I believe will allow MDG’s Meteor developers time to breathe, adapt, adjust, and migrate to new technologies as MDG too adapts to its changing environment.
4 Likes
To exemplify these points:
…and to hopefully address these:
… please watch this excellent video: https://www.youtube.com/watch?v=BF58ZJ1ZQxY
It shows how you could refactor parts of your UI code to ReactJs components. And having done that myself for a project, I can tell you it’s as realistic as it looks in the video.
That’s the power of UI components as an architectural pattern, and React’s implementation in particular. Component-oriented UI is not a new idea, but it’s React’s implementation that’s making all the difference (not that it’s unique to React anymore, other libraries are picking the good ideas and possibly improving them too).
That aside, I fail to understand why do you feel that you have to rewrite all of your current application whenever Blaze2 is out in whatever form? Do you expect Blaze1 and all the packages used by your code, the versions used today to be precise, to suddenly stop working for you, the day Blaze2 is released? I think such a catastrophic event is very very unlikely.
Or are you just somehow managing to delight your customers by somehow hiding “painful bugs” in Blaze1? And want MDG and package maintainers to fix them for you, no matter how long it takes, as long as you have to do nothing more than upgrade Meteor and those packages? If so, then please don’t single out Meteor; most free software/frameworks would not meet your expectations! 
Don’t mind the sarcastic nature of my comments. I don’t wanna make light of your concerns, but do urge you to re-evaluating the whole reasoning behind such pessimistic forecast you presented for your business situation, only because of this direction Meteor would be taking w.r.t. Blaze2 !?
1 Like
Sorry, with all due respect, I think I’ve made myself clear in prior posts: (1) (2)
This is a Red Herring.
1 Like
Quite frankly, I’m not sure why I am bothering with this discussion anymore as it’s obvious that you simply cannot be reasoned with @aadams, but for the sake of completeness:
This is exactly my point. @aadams you DON’T need to rewrite your entire application right this second and you certainly don’t the moment Blaze 2 is released. You do it step-by-step as and when things need changing anyway. Like those bugs of features that your customers care about… Want to add something to the (for example) customer-list? Take the opportunity to convert it into a React component and add the features you require then. If doing it bit-by-bit like this is too much work as each “bit” is too large, then it sounds like your code is poorly structured, so in all honesty you should completely re-organise the codebase anyway.
Your argument revolves around MDG spending a hell of a lot of time and effort maintaining Blaze 1, fixing bugs, optimizing, etc. When in reality, a) It’s clear that they don’t want to (we all know how great code is when the devs don’t care!) and b) what they are saying is that it will never be as performant and never be as well componentized as React.
Why can’t we stop trying to turbo-charge an Austin Allegro, and just leave it to the big boys at Facebook (& Google), who have a clear interest in maintaining it, large investment in it’s success and a HUGE amount of resources to throw at the problem?
3 Likes
So I’m now unreasonable because I disagree with you…
If I may, I’ll like to point you to a quote in my original post; I’ve added the concept of time to my quote in brackets to overlay your thought with mine:
Here, your point does not take away from my original thought.
Here I’ve replaced the words “opportunity”, “work”, and “re-organise” (in that order) with: “extra time”:
This “extra time” is called by another name, a time consuming refactor to React. Which again, even over time, is a yet another head-wind to my startup. The extra time spent on this refactor could use to service my clients and directly impacts my bottom line.
Another ad hominem attack:
Why such visceral to others that have a different opinion or question MDG’s line of thinking?
If you read my orignial post, this is not about the technical merits of React over Blaze 1. This is about the business value Blaze 1 provides to me and many others. This is about the commitment MDG made to the Meteor community when they chose to integrate Blaze 1 into Meteor. This is about trust.
4 Likes
It’s interesting to see how difficult technical engineers it find to understand business arguments.
It’s like you do not understand that MDG might even stop this discussion between React and Blaze, by adopting, for example FlowRouter or Cordova or Test-suite or any other eco-system splitter as core. The geeks look astonished, and ask “what on earth has the router choice to do with the view layer!!!”. The answer being… nothing of course (technical)… and everything of course (business). Why? A corporation needs a roadmap and consistency in a compact eco -system to survive…
If you need a little bit of technology practice to feel at home, please let me give an example: Today we tried to cut and paste some StackOverflow code in the app, while using React and all we found was Blade stuff and incompatible plugins. and it took us longer to get it working… .who is paying for that ?
Really guys… dont talk technical please if the issue is not about technology… If you like corporations to pay your bills, please give them what they need or they will flock away: security, consistency, predictability a uniform eco-system. .
3 Likes
Agreed. Don’t care what the “view layer” is. Pick one and stick to it forever. Accept downsides. Don’t lose conviction. A good dictator beats a democracy. Good is subjective. But that is okay.
2 Likes
It’s simple then, don’t refactor it. Don’t change it. Continue using Blaze as it is. You clearly think it’s better than the alternative being offered, so what’s the issue? A huge portion of the Meteor community is already making the switch to React as a view layer, because they want to. Are you saying that we should physically stop them from choosing which view layer to use!? If not, then you’ve already lost your point about the Meteor ecosystem becoming fragmented, Stack Overflow answers being for the “wrong” view layer, etc. It’s already happened.
Also to put this in perspective:
No. of questions on Stack Overflow tagged with:
- react - 7677
- meteor-blaze - 580
Oh please. Trust? Can you point out to me where MDG has ever stated that Blaze was a long-term solution that they would endeavour to maintain, bug fix and support? Nope? Didn’t think so. So what trust has been broken exactly? Google offered something called Google Wave, they dropped it, because they realised that others had done the same thing in a better way… Did they “break my trust” 
… er… no. Has Facebook &/or Google done the same thing Blaze does in a better way? Yes.
And who the hell are you to tell me that I don’t run my business, that I am not in charge of the entire development team and that I am not responsible at the end of the day for the development costs, etc.? Just because you only care about the “business” arguments, please don’t generalise and assume that the rest of the people here having a technical discussion aren’t business minded as well.
Also you don’t seem to get my point here, what I was saying was that if your code can’t easily be ported over, then you probably have bigger problems.
2 Likes
I for one am NOT advocating for this.
Technical merits asside:
As a small business owner, I’d like the Blaze 1 API to have longer runway before putting it out to pasture in favor of React, support in the form of bugs fixes, and maybe an enhancement or two.
Many Meteor, developers and their clients, businesses and lively hoods, depend on this technology lasting longer than it has.
If I may speak for some at least, we as Meteor developers and business people need more time to transition to React, we need more support time for Blaze 1, we need clean and clear upgrade pathways, and we need support documentation on the transition.
Speaking for myself now, I for one would pay for a Blaze 1 support plan in a heart beat.
As MDG is a business that cares about potential/future customers, this should be considered the cost of doing business after all.
2 Likes
The key point is that Meteor as a Platform is not a goal anymore. Meteor is becoming an accessory or a tool of other eco-system. That is completely opposite to its initial goal: a coherent eco-system from database to app development. Tight database integration was breakout, view layer was breakout, router was breakout, package system was breakout, long time vision was based on fashion technologies. What is the road ahead, you bet. What I see is another Windows 8 Lite.
For me, it’s interesting to see repeated appeals to divorce technical aspects from “business arguments”, when that business itself (product? service?) is tightly coupled with technology 
Why are you assuming that people supporting, or not opposing, the announced move on Blaze2 in this thread (which, btw, is about the direction for Blaze and view layer) don’t want routing to be in the core of Meteor? Ever considered the possibility that good technical reasons should be part of the factors driving business strategy?
Just someone trying to politely bridge a gap in the discussion, as I assumed all people here basically share the same interests. If MDG does not see a coherent ecosystem as top-priority, then that is their right. At least it is clear and each person in the community can decide if they need to move on or bite this bullet and the ones to come.
By making wild assumptions about who we all are, and that you are somehow not one of us, someone special? That seems really polite to me.
Of course you are right. At the end of the day it is all connected. Still, hair-splitting the ecosystem is costly in many ways and should be taken into account when deciding on technology, I think. And that’s why I understand @aadams The incompatibilities and emotions that I see arising in this community are a lot bigger than I saw in others… and many of them failed… so well… let’s hope the posse stays together
I saw @aadams using business arguments and some people, responding technically. I assumed nothing and did not even had you in mind specifically, so apologize if you feel insulted.
To clarify a bit more the concerns: take a look at this example: Does Meteor has offical ways to handle with translation like i18n in Ruby on Rails?
Well, I meant that I read your posts and still could not understand your line of reasoning. You make presumptions, and contradictory statements…
How do you know that’s gonna happen for sure, for all packages you’re using? Are you concerned about packages you’re using today, or packages that people might have built in the future for Blaze 1 if it existed? Even if the packages you use today were to migrate later, couldn’t you just continue using the same versions that you know work today?
I haven’t seen any popular library/framework not releasing major api-breaking versions just because some businesses think they “can’t afford” (or don’t want) to “put in the effort” to upgrade. Even the paid commercial ones don’t stop making progress, or deprecating outdated ideas/APIs. MDG articulated their reasons why they feel Blaze2 should be built with a particular approach. You want them to not go ahead with it, because your assumed “necessary” upgrade would presumably affect your “bottom line”?! Of course staying up-to-date needs effort and hence money, but you spend it only if there’s a justifiable ROI (valid “business argument”?)
On one hand you say you’re willing to pay for Blaze1, and on the other hand you’re worried about the “drag on your bottom line” caused by refactoring to a version that no one has yet strongly suggested to be a bad technical decision (the line of argument, though flawed IMO, only being: it seems unwise in “business sense”). Instead of opposing the evolution of the view layer in a way that the founders find appropriate, why not spend the same money to refactor and stay up-to-date? Or fix the “abandonware”? Or maybe even keep Blaze1 alive in a way that makes sense to you. If it’s indeed true that “many others are in the same boat”, get them together and collectively sponsor the maintenance of a fork in a way that makes sense to you! Your money/effort, your roadmap!
If you were genuinely looking for solutions, you’d have already seen merit in many comments here why it wouldn’t necessarily be as bad as you “think”. If nothing else, you’d have at least tried to explore them to address the concerns which “put your business in a precarious situation”. I replied with the assumption that you’re looking for views to (in)validate your concerns and/or find solutions. But…
…seems you’re more interested in imagining and labeling logical fallacies in others’ views! 