Let’s find out via voting
Let’s find out via voting
You forgot to include the option: “Hell NO”
It would have been “Hell NO”, indeed!
Yes, and it’s hard.
But in the end, i find the code to be more testable.
Valid point. Curious though, had you had a very complex UI, say, 400 - 500 templates in about 300 components (that work really well), would you still do it?
I currently have 4 apps… all on blaze… There should be a possibility to vote “No” 4 times
Do you rewrite your Blaze based app?
Yes … using Blaze. I’m working on projects using both Blaze and React, and find myself refactoring a lot of my Blaze work to leverage some of the popular React ecosystem approaches, like the container/presentational component approach (mentioned in the Guide as Smart components). If Blaze is working well then a rewrite is likely less important than building new features, but leveraging a smart component type of approach in Blaze has certainly helped with component re-usability.
My project is 70k loc, and working well.
But i had no test, and i don’t believe Meteor “classic” has a future (no need to comment on that).
So i’m rewriting it React/Redux style using TDD, it’s hard, long, i don’t add new features, but i’m fairly confindent that the new code is better (once new bugs has been fixed…)
Yeah, really no need for comments on that 70k LOC is quite a bit of work. Ours is twice that and counting. No chance I’m moving it to a new framework or combo any time soon
Personally, I’m finding React to be 20% to 30% more efficient and effective in terms of sprint velocity. Given time, that will compound in a big way.
However, I’m also seeing a slight tendency for React to be too complex for some of the developers we were able to bring onto projects with Blaze. We work with a lot of radiology technologists, nurses, physician assistants, PHD researchers, medical doctors, etc. About 80% of them could pick up Blaze; whereas only about 50% of them seem to be able to grok React.
So it’s excluding some participants in the name of performance. However, because of isomorphic/universal codebase, we need fewer team members to ship to multiple platforms.
So, on balance, yeah… happy with the decision to rewrite, even if it’s going to take 3 to 6 months. Also happy that we waited a year or so for it to become stable, and we’re able to go directly to Material UI and React-D3.
I did not even update my project for import statements yet… so no.
Although if you go from Blaze > ViewModel, then refactoring for React (using the new React ViewModel) is an extremely easy process in comparison.
Oh wow, so that’s the time for rewriting. I could publish 3 meteor app within that period. Thanks for sharing @awatson1978.
I rewrote Telescope from Blaze to React, it took me ~2 months altogether with a lot of refactoring. I think to answer the question of whether you should rewrite your app or not, we have to distinguish between “bad” Blaze code (Iron Router, router-level subscriptions, old code, etc.) and “good” Blaze code (Flow Router, components, etc.).
If you have bad Blaze code you should rewrite it anyway just for maintainability’s sake. And if you have good Blaze code, moving to React would probably be relatively easy since you already have a React-like structure. So in both cases my answer is “yes”!
Here’s a good read on one of the main reasons FB created React - https://speakerdeck.com/vjeux/react-css-in-js.
I started to look into RiotJS but haven’t touched Meteor in months due to the continuing mess. It’s also not just about React vs. Blaze - it’s about everything else as well.
Now, Reactjs is not best solution for reactive scene. Blaze has convergence feature for project, being simple, clear model.