Using Blaze for RadGrad (http://radgrad.org). In no big hurry to switch. It’s really easy to bring new developers up to speed with Blaze.
1 Like
We are using Vue in a new project, so no Blaze at all on this new codebase.
I’m not opposed to doing a complete rewrite in Blaze. Quick question, what (if any) package are you using for forms? Wondering if there is something comparable to Autoform. In any case, thanks so much for sharing your experience with me!
To everyone choosing Blaze going forward: I agree that it’s a wonderful framework for building things quickly, but once things get complex and performance really matters it’s a tough sell. Mitar wrote some benchmarks here: https://github.com/mitar/meteor-web-rendering-framework-benchmark
Using Blaze and sticking with it for the foreseeable future because we already have a large code-base that uses it.
Also because that code-base is a bit spaghetti and it would be difficult to transition without stopping all feature development for a while…
1 Like
We will probably do the same in the near future. Any tips or insights you can share?
Sure. There are quite some challenges there.
One big issue is the router. Only FlowRouter supports both Blaze and React equally. But it will force you to use Blaze / BlazeLayout as the leading template engine and wrap all React components in Blaze. This results in multiple React roots which is neither performant nor does it play well with global (Redux) state management. More on this here: Which Router are you using for a mixed Blaze and React app? I’d say the best option would be to migrate to ReactRouter completely. But this would mean a lot of refactoring (and thus additional work) in the Blaze code.
Another (smaller) issue is internationalisation. tap:i18n doesn’t work with React, so I am using universe:i18n instead and ended up with two different i18n solutions in one single app. It works, but won’t allow you to share i18n strings across both worlds. My apps are also based on a lot of (local) Atmosphere packages that are shared across multiple apps. Here I had to learn that in the most recent recent versions of Meteor (which you definitely want for React) tap:i18n just doesn’t work anymore if you use it in a package that uses the ecmascript package, too. So I had to refactor all my packages and put all i18n related stuff in separate packages that do not reference ecmascript. Once you know this, it’s pretty easy to handle. But it took me some grey hairs to figure it out.
My conclusion is: The “soft migration” strategy MDG promotes in their guides doesn’t work well if your app is a bit more complex than just a simple demo. If I wouldn’t have a quite large code-base already, I would definitely try to go for React-only instead.
3 Likes
I’ve done a lot of C++ and a bit of Ada for the last seven or so years. About three months ago I thought why not have a look into that new front-end stuff (young) people talk so much about these days 
I am with React now because it made sense to pick something where there’s one language that will work in the data tier, the business logic tier as well as the presentation tier.
For the styling I think I’ll give styled components a shoot as it seem logical to do so when you want to have JavaScript everywhere.
1 Like
Our app is actually quite big. Will definitely consider what you say here.
True devs looking to ship will choose Blaze. All else is hype. It’s all just javascript. What gets from point A to point B fastest for front end is most important. Front-end code should not be “eternal”.
4 Likes
It may not be worth porting a large existing project from Blaze to another framework, but for a new project I would not say it’s just hype to choose Vue or React. They are more than 10x faster, requiring less optimization, and have many more useful features, which are very well tested and thought-through due to their big communities, and recieve frequent updates.
There are also tons of components, UI frameworks and other packages available for them, which are also more likely to be well maintained than Blaze packages.
In the long term, Blaze is sinking ship, and you’re better off building your skills in a more popular and lively framework.
3 Likes
BTW. whats about Angluar? I’m really interessted if someone used it or not and whats your opinion about it even for non meteor projects.
Speed of React/Vue is overrated. What projects are actually hitting rendering performance cap? Return trip from server is more likely to impact performance. Can React do optimistic UI out of the box? Blaze is still heavily used (as per this poll) and it isn’t backed by a billion dollar company like Facebook, so clearly it has more “ROI” given industry support/input.
It’s all just javascript.
2 Likes
Optimistic UI is not a feature of Blaze, but of Minimongo, so if you use subscriptions and common code methods you get it no matter what UI framework you use.
The performance difference is most noticable on mobile. And freezing the client feels much worse than waiting to load data. Performance is also just one point, there are also many features. For example, real JS instead of “Mustache language” and lots of other stuff.
Blaze may be popular in the Meteor community, but that is just a drop in in the ocean compared to the rest of the JS world. It’s only upside is it’s integration with Tracker, which is a bit of an inconvenience when using other frameworks, although fairly easily solvable.
Not saying all projects already built on Blaze must switch, but I think it’s unnecessary to start something new with it.
react is the closest thing to being “the” UI-framework. A UI should just be a function of your app’s state. And react reflects that perfectly with its simple api.
being able to build native uis with react (-native) is also a big plus.
1 Like
I’ve found Blaze easy to get up and running with quickly, but that it doesn’t scale with complexity as well as React, which is maybe a bit harder to get up and running with (because, IMHO, of a learning curve that you wouldn’t have if bad habits weren’t instilled in us in the first place by tool ecosystems like that of jQuery). Of course, once you know React, there’s no downside - it’s just as fast to get up and running as Blaze, and it scales better (and actually, I find it easier to reason through it). I’m not sure why any of that would be hype.
I haven’t played with vue.js, but it looks like a more flexible React - basically somewhere between the completely freeform jQuery type coding, and the much more constrained React way of doing things.
2 Likes
Bit sad to see Ember with 0 votes but that’s expected on a Meteor site. IMO it has a lot of really neat features but isn’t considered ‘cool’ so no one talks about it.
I’m currently using Blaze since it is the one that goes with Meteor as default. It’s very simple, easy to understand, easy to build on it. If my apps have the need to go to another framework, I might use React since the Licence became a “regular” one.
I am using Angular 2/Ionic to provide the CMS for Ionic Mobile Apps. The latest one involved human 3D body using three.js.
I successfully used single repository to host the code for the following parts of my hybrid mobile app:
- Ionic mobile app using ionic cli
- PWA version of the same app served from meteor public folder
- Meteor CMS client side
- Meteor server side for the CMS, the mobile app and the PWA app using meteor cli
- More than 10,000 lines of shared code between all of the previous
And all my code is in Typescript.
Thanks mainly goes to angular-meteor.com.
And frankly, I don’t think I will ever work using React as happy as I am working now using Angular.
The killer feature for me is that, Angular templates are in normal html with extra templating instructions, which is compatible with the work flow in the company I am working at.
Currently, the designer do the graphics, and the mark up coder (some times he is also the designer) converts it to HTML/CSS/Angular/Ionic templates, and I work on the server/client side coding and on integrating everything.
My work on the server/client side normally goes in parallel with mark up coding, and the mark up coder is doing his work on the same repository I am working at. The mark up coder is an artistic guy who can express his ideas with HTML/CSS/Angular/Ionic templates including some little knowledge in Typescript, so he will manage transitions between pages, and he also going to style everything, including the status bar.
We tried to make him work on React, but it was a headache.
Also, until the React community embrace Typescript, I will not bother my self with this IMHO stupid Flow library (regardless if it is more sound than Typescript or not).
1 Like
wow, more Vue than angular. I wonder how representative this is of JS in general. The high number of blaze is of course because this is a meteor forum.
Vue for all new projects (and some of our old projects that we transitioned). We still have one project using Blaze, which due to the size of the app will likely continue doing so until/if we ever do a major design overhaul.
We love Vue since it brings speed and simple componentization (like React) but the markup is just HTML with additional attributes which makes it simpler for our front-end devs who are often working on non-app projects (Wordpress sites, static HTML sites, emails, etc).
1 Like