0 voters
In light of the new Blaze website and roadmap, I’m curious how many people would switch back to it if significant improvements were made.
EDIT: the votes have not been encouraging in terms of people returning to the Blaze camp… however, I think that’s because of a lack of concrete examples of how Blaze would be improved.
As I expanded the complexity and features of my application, managing the event life cycle became a new challenge. With react everything happens when it’s supposed to without having to initialize listeners onRender.
A strong separation between front end, and backend even so far as having a redux store which represents the front end’s version of the Db, creates a philosophical difference that aids in component/module/plugin design.
Loved blaze when angular1 was the favored strategy.
Still love Blaze for teaching Meteor.
i’m surprised at the number of people still using blaze!
Check out these stats:
# Package downloads in past Month
meteor-base. - ~31,000 downloads
blaze-html-templates - ~30,000 downloads
react - 309 downloads
angular - 400 downloads
I do think we (the people in Space Dojo) are in a bit of an “altered dimension.”
Haha not at all. Nobody (or at least nobody should) uses React from the meteor package server. If you want real numbers you have to go to npm.
There is a high of 100k downloads per day and its been pretty consistently above 75k downloads per day since earlier this year. Blaze isn’t even in the game. Given your use of the above stats it makes me wonder if you’ve even used React at all? 
i think your numbers are skewed.
blaze-html-templates comes pre-installed with meteor when i do meteor create. one of the first commands i run is to remove it. also, angular and react downloads from atmosphere are borderline useless as of 1.3 because we’ve had access to npm!
react:
85,502 downloads in the last day
431,667 downloads in the last week
2,019,514 downloads in the last month
angular:
22,578 downloads in the last day
111,471 downloads in the last week
510,798 downloads in the last month
angular2:
2,148 downloads in the last day
11,660 downloads in the last week
56,874 downloads in the last month
You guys are posting numbers of the entire eco-system. Of course, the Node ecosystem is larger than Meteor. However, IIRC, Meteor pre-1.3 did not have impressive downloads for React/Angular.
To confirm this, the React package has around 30k downloads, while Blaze has 500k. Blaze has an additional 1.5 million downloads before the package name was changed.
pre-1.3 is was a hack to get react working in the first place. react was also still pretty young pre-1.3 and there weren’t as many people using it. AND it wasn’t officially endorsed by the meteor team.
if you want to compare apples to apples, you have to look at handlebars v. react/angular:
184,852 downloads in the last day
948,958 downloads in the last week
4,244,607 downloads in the last month
clearly handlebars is about double the react numbers, but it’s also been around for 6 years. react is a different thing and is geared toward state management which is why it’s such a good fit with meteor.
What affiliation do you have with Space Dojo?
I’m CTO - Chief Trolling Officer.
Still - cannot compare React to Blaze in the world of Meteor. I’m betting Blaze is beating it hard in terms of adoption.
Moreso, the power of React is in the tooling around it - Webpack, Redux, etc. With Meteor, you’re not really getting all those benefits, at least yet.
Given the choice between the two when starting new projects… I’m definately encountering teams that are choosing Blaze over React because of team composition, skill level, etc. So it seems like there’s a fairly clear refactor-path from Blaze to React; and new projects will continue using Blaze to get off the ground before they do a performance optimization/refactor.
If this continues to be the case, I’d like to see Blaze get rewritten using Virtual DOM.
I think the advantage for Blaze here is how closely aligned it is to Web Standards, and I hope it continues to do so. There is someone who is trying out to implement Incremental DOM with Blaze. Incremental DOM, in Google’s words, “significantly reduces memory allocation and GC thrashing for incremental updates to the DOM tree therefore increasing performance significantly in some cases.”
I feel like this thread has veered far off topic. The poll is great, but I don’t think comparing different stats is really helpful.
Let’s get back to the original idea - what would Blaze need to become to join the next generation of UI frameworks?
That graph was done by a React groupie with a fantasy. The code you write with React is as much “JavaScript” as CoffeeScript or any other language that compiles to the JS that browsers actually understand.
You still have to transpile what you write and the output has some vague resemblance to what you actually wrote. Babel’s output is so removed from your code it might as well have started with Scala.
The fantasy is that one day browsers will catch up and you’ll be able to turn off the transpilers. That would only work if JavaScript became fixed like it did for so many years in the aughts. Yes, I know it wasn’t exactly fixed but due to IE6 it was fixed in practice. JavaScript will continue to evolve so React code will fall under “Transpiled Languages” for the foreseeable future.
btw, no I wouldn’t go back. I will not rewrite my current apps but new ones will use React (with ViewModel of course). I haven’t decided on the stack yet, probably Horizon.
Lazy/progressive loading and SSR.
That’s a limitation of Meteor’s build system, not Blaze.
I thiiiiink Blaze has the right stuff to support SSR - at least, AFAIK there’s a way to convert HTMLJS to an HTML string.
It would be really cool to have principled SSR for Blaze, Apollo is also well-optimized for SSR so it could be a good match.
(this may not be the right spot for this) Will you please explain the relationship between the build system and lazy/progressive loading?
Modern build systems include something called a “module bundler”. Meteor’s bundles all of your code into one big blob, which is great for apps that can deal with loading all of the code up front. Some build systems, like Webpack, let you configure the tool to build several smaller blobs, which can be good for apps that need a very fast initial load time.
So there isn’t anything in Blaze that requires all of the templates to be loaded up front - that’s just how Meteor compiles your code.