Do you rewrite your Blaze based app?


#1

Let’s find out via voting

  • Yes
  • No

0 voters


#2

You forgot to include the option: “Hell NO”


#3

It would have been “Hell NO”, indeed!


#4

Yes, and it’s hard.
But in the end, i find the code to be more testable.


#5

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?


#6

I currently have 4 apps… all on blaze… There should be a possibility to vote “No” 4 times :slight_smile:


#7

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.


#8

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…)


#9

Yeah, really no need for comments on that :slight_smile: 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


#10
  • Using .jsx files breaks the JS/HTML/CSS separation of concerns; but as far as file count goes, with 400 templates, that probably means 800 to 1500 files. .jsx gets that fiile count back down to 400 files. And that has a real impact on workflow.
  • CSS scoping is the tightest it’s ever been. For the first time, I feel really confident that when I specify that this type of component should have a specific style, it’s not going to spill over into any other components.
  • All the components are more testable. Much fewer side effects.
  • With Material UI and React Toolbox, we have theming objects that pass through the props. This is a much more coherent strategy for theming objects.
  • React-D3 lets us use React to draw the SVG elements using D3 math libraries. For the first time, D3 graphs are not only re-usable; they’re componentizable as well.
  • There are React Native projects that are aiming to port Material UI to React Native and Web, and vice-versa. In another 6 to 12 months, I think we’re going to have a truly ubiquitous web UI layer that performs with native UI performance.

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.


#11

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.


#12

Oh wow, so that’s the time for rewriting. I could publish 3 meteor app within that period. Thanks for sharing @awatson1978.


#13

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”!


#14

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.


#15

Now, Reactjs is not best solution for reactive scene. Blaze has convergence feature for project, being simple, clear model.