Moving forward with meduim size blaze application


#1

Hi,

Sorry if this is a repetition, but I am still kinda lost here. I have a medium size application built with Blaze.
The way I see it is that Blaze is moving towards being deprecated/not supported by MDG and Apollo is written from the ground up to replace mini-mongo and the whole thing.
Now, I am not sure what to do. I was finalizing the app and suddenly it seems I should re-write the whole thing with React/Apollo. I don’t think it is a good idea to rely on technologies that are the way of replacement and the cost of re-writing is high enough that I could probably re-write it in something more mature/stable.
Honestly, I believe the changes that MDG is doing are too revolutionary for Meteor’s good. It should probably have been named Meteor 2 with a much longer transition period. And meanwhile fix/enhance the current stack’s issues making our lives easier.


#2

Well, yes that does suck for you. But truth being told, chances are with a Blaze app as it grows bigger you would probably have to re-write everything sooner than you’d think anyway because Blaze apps are just not very easy to maintain. That said, I think there are some community packages that make Blaze more future proof. Also, seems like people are going to contribute to the future of Blaze in a separate repo and Mini Mongo is here to stay, just probably not as highly maintained anymore.


#3

I’m not sure re-writing simply for stack replacement is something I’d go for. What are the odds of a refactor sometime within the next 6 months - 1 year anyway?


#4

The application is at milestone 1 stage so we expect a lot of development in the next couple of months. That is why I am concerned about the best way forward. Mixing blaze and react maybe? Any tutorials? Do I need to migrate?


#5

I would keep it the way it is right now.

You can always re-write it at a later time when you have a clearer picture about the way Meteor is heading. But I agree with your sentiment in that it is very annoying how the Meteor community jumps from technology to technology on a whim.

But hey, that’s web development/software development in general. You are always learning and always trying to adapt. It wouldn’t be fun if there wasn’t something new and exciting to learn and utilize.


#6

Well, yeah, I understand that they would be maintained by the community… but usually that the main maintainers leave means a dying project


#7

Qualia maintains a very large web application written in Blaze, and we have not found it slow or difficult to maintain. You have to establish strong patterns, but it can work pretty well. Here is a link to a talk that I gave at Meteor Night https://www.youtube.com/watch?v=Iguedyg2cOI


#8

We’ve deployed 2 enterprise Meteor / Blaze apps so far (with more on the way); for the first we used Blaze Components, and for the second we used ViewModel. They have proven to be a pleasure to maintain and enhance, especially the Blaze / ViewModel combo.

I personally wouldn’t recommend rewriting your app if those are your only reasons. Blaze may not be the current star of the show, but it’s still being maintained and while there are certainly many improvements to be made, it works pretty well in its current state. Blaze may eventually die, but it’s unlikely to happen soon. Given the effort you already put in, if it’s working well for you now, and knowing that tons of other people have used it successfully, it’s probably better to continue using it and wait until community support is drying up before jumping ship.

Apollo will be here eventually, but it’ll also be an opt-in experience. Minimongo will still be there, and if you like you can incrementally shift to Apollo as you make updates to your app…


#9

I Thanks for the feedback. Any recommendations about new functionalities to add? Should I write the new stuff in React? Any tutorials on the best way forward?


#10

I loved your talk, do you have any more information or examples about using Template functions instead of helpers? I think this may solve some issues i’m having.


#11

I briefly described our Blaze patterns here Meteor Guide: Blaze


#12

We have developed a large classroom application with Meteor that is being deployed in many schools in the US (we were even approached by Google to launch it with them in Europe). We use Blaze exclusively as we need real-time reactivity.

We used Semantic-UI and created our own templates for Lists, Menu, Footer, Steps etc.
We found it a breeze and it works super well. I don’t see us migrating from Blaze anytime soon as it gives us the ability to launch new features in no time.

Also, the tap-i18n package is amazing, you can change UI language reactively!

We use ReactiveVars that we attach to the template and it works great (this.field.get() and this.field.set(value))