I haven’t used it myself but the sideburns package looks like a promising bridge between the two https://github.com/timbrandin/sideburns
4 Likes
So it sounds like a lot of people really like Blaze!
I don’t have anything in particular new to say about that (a lot of things have already been said I suppose – I like it too!), but I did want to point out to @SkinnyGeek1010 et al that are talking about client side state, that there are some ideas on what will be in the relevant section of the guide here: https://github.com/meteor/guide/blob/master/outlines/data-loading.md
And we’d like to hear any thoughts about how that could be improved via PRs or here: https://github.com/meteor/guide/issues/33
There’s also a guide article about Blaze! But I don’t think people reading it will get a lot of new insights beyond what’s written above—I look forward to updating it once a bit more clarity has formed around all of this!
2 Likes
Some Meteor Developers:
-
We want MDG to double down on Blaze!
-
We don’t care for the hype around React!
-
We’ve lost trust in MDGs decision making, and tech choices after what seems to be a total abandonment of Blaze, how can we reestablish trust?
-
There are many early adopters in our group, they have significant code base on Blaze, in some cases years worth of work!
-
Every package that integrates with the Meteor client up to this point somehow touches Blaze, think of the undertaking!
-
Having one Front End Framework endorsed, supported, and worked on by MDG allows for a common denominator that applications and packages can build on!
-
We want Blaze Native!
-
Blaze is the front end to your Dev Stack for gosh sakes!
-
Blaze makes us so much more productive and any other UI framework!
-
Designers, Novelists, and People that want to get sh*t done love Blaze!
-
Blaze is a great gateway to Meteor!
-
We don’t want MDG to make Blaze dependent on a competing platform’s UI!
-
Get to work on Blaze 2.0 or give it to the community to advance!
Some React proponents:
-
React is the best thing since sliced bread!
-
Get rid of Blaze because Facebook’s React is so much better!
-
Yeah, it’s a little harder to work with, verbose, and all those extra files, but man React gives you so much more in return --> Blaze Devs: what more? We still don’t see why it’s so great? React Devs: Just trust us, it’s great.
-
Ok, if you must keep Blaze, then just rewrite it on top of React!
-
Who cares that Designers will have a harder time with React, it’s all about us anyhow!
-
While you’re gutting Blaze and replacing with React, let’s find the next chunk of Meteor to subvert
-
If we all just keep repeating how cool, new, and great our ideas are, and how dumb and backwards everyone else is no one will be able to resist!
Some in MDG (unofficially, because well… unofficially is all you get):
-
React is great, and will be supported and the best framework now and in the future, which is why we have big plans to either gut our existing UI and rebuilt it on top of React, or just let Blaze die a slow death. Get pumped! --> Blaze devs: right, but how is it the best or so great that it make sense to chunk Blaze and for us to do rewrites? How are you going to regain our trust? MDG: crickets
-
The Devs, look at al the React Devs, they must know what they’re doing… right? --> Blaze devs: OK, but I don’t see how React is so great, even after these React guys tell me why it’s so great. MDG: crickets
-
Betting our future on a competitor’s UI framework just make sense guys, come on trust us! --> Blaze devs: But how exactly does this make sense, considering what we are giving up? How can we trust your tech choices after this? MDG: crickets
-
Do you guys even realize the man hours we’ll save by letting Facebook basically build our front end framework for us! Our investors will be thrilled with the news! We’re now busy trying to figure out what else we can gut, ok guys? When we are done, you won’t even be able to tell the difference between Meteor and the Facebook stack! Blaze devs: sigh
-
This is all unofficial anyhow, so if we stop talking hopefully you guys will just go away after a while!
-
No, Facebook is NOT a silent investor in Meteor! It doesn’t matter anyhow, we planned on kicking Blaze to the curb long ago, haven’t you noticed, no new features!
-
No, we will not open up Blaze for community contributions on a wide scale! Are you kidding us already? That would undermine our choice (it’s our choice not yours) to go Full Speed on React! --> Blaze devs: Please tell us why not? We have a few guys that can really shape Blaze up we think! We need to reestablish trust in this framework we’ve invested in! MDG: crickets
-
Of course we love all our Devs that took the chance with their careers, time, and money investing in Meteor and Blaze! To be clear, we are not throwing you under the bus (officially of course). Besides, you guys will get so much more by migrating to React, and we PROMISE (unofficially) never to do this again when the next new wize-bang thing comes out! --> Blaze devs: like what more do we get, how is React so much better? MDG: crickets
9 Likes
React homepage, first example, Compiled JS.
"use strict";
var HelloMessage = React.createClass({
displayName: "HelloMessage",
render: function render() {
return React.createElement(
"div",
null,
"Hello ",
this.props.name
);
}
});
ReactDOM.render(React.createElement(HelloMessage, { name: "John" }), mountNode);
Look how ugly and verbose that is. I think it speaks for itself, no?
2 Likes
Why use the compiled JS example? Have you seen what compiled Blaze templates look like?
Template.__checkName("listsShowPage");
Template["listsShowPage"] = new Template("Template.listsShowPage", (function() {
var view = this;
return Blaze._TemplateWith(function() {
return {
todosReady: Spacebars.call(view.templateInstance().subscriptionsReady()),
list: Spacebars.call(view.lookup("list"))
};
}, function() {
return Spacebars.include(view.lookupTemplate("listsShow"));
});
}));
Yeah, good luck with that.
I’m not saying this proves anything about one being better than the other, but I don’t think it’s reasonable to start comparing the compiled forms of different template languages.
10 Likes
I explicitly shared the compiled example because, as the homepage says, JSX is optional and not required to use React.. For sake of quality discussion, we can go ahead with the non-compiled example. Per the docs, This example uses an XML-like syntax. Oh, XML. They’re really trying hard to sell this, aren’t they?
var HelloMessage = React.createClass({
render: function() {
return <div>Hello {this.props.name}</div>;
}
});
ReactDOM.render(<HelloMessage name="John" />, mountNode);
Writing HTML in JavaScript is just messy. This is only marginally better.
1 Like
This can be easily avoided by writing a simple compiler for .html files into React code, much like @timbrandin is already working on with Sideburns. It’s not actually a factor in whether or not it is a good idea to adopt React as the underlying rendering engine.
1 Like
I feel like this thread is going back and forth and in circles, with everyone (including me) saying the same stuff over and over again.
Is there some format in which we can have this discussion where we can avoid repeating ourselves? For example, a hackpad where we can group by topic, or something?
3 Likes
Fair enough. I found there some example meteor react apps out there, I’ll give it my best 100% unbiased effort and run through the tutorial, maybe make a small second app with it (sans tutorial), and share the results here.
Hackpad might be a good idea.
It’s hard to give clear answers when I’m one person trying to respond to 10 different walls of text. I don’t mind it being on the front page of the forums, but I can’t answer questions effectively in this format.
2 Likes
I tend to agree with @aadams , the community is probably not going to be satiated by answers that have the “unofficial” disclaimer attached to them. Could you imagine a white house press secretary coming out and before every press conference saying “well I can’t actually speak for the President, but let me tell you what I think.” In fairness we are still waiting for the official actionable items that were in theory coming from dicussions with @debergalis.
In my opinion a discussion driven by a community that cannot ultimately make any decisions is bound to go around in circles regardless of the medium its conducted in.
Can MDG bring the actual decisions makers into the discussion?
If you can I’d say have those decisions makers and key members of the community involved in this topic @arunoda, @mitar, @awatson1978, @msavin, @timbrandin, @aldeed work through it on a publicly viewable forum but with editing restricted to only those people.
4 Likes
To me this is almost beautiful. If I have 100,000 lines of code in my app, I can look at this component and know what it’s going to do. That alone is a game changer ! If it had propTypes I would also know what type name is and if it’s a required prop.
However in Blaze it’s not clear where your data is coming from… context? Session? Template var? Router? You have to hunt down and usually though several files. This is very terse but it comes at a cost in large apps. It’s quick to start and slow to maintain.
<template name='HelloMessage'>
Hello, {name}
</template>
The component is almost like a regular function that doesn’t have side effects. For example:
// prop.name - {String} - a persons name
// returns {String} - a greeting message using persons name
helloMessage = function(props) {
return `Hello there, ${props.name}`;
}
I can picture in my head that this will return "Hello there, Leah" if I call the function like this:
helloMesage('Leah') and if I call it 10 times i’ll always get back "Hello there, Leah".
In fact React 0.14 now has something called stateless components that take it to the next level… you can use regular functions instead of ‘classes’:
import React from 'react';
function HelloMessage(props) {
return <div>Hello {props.name}</div>;
}
7 Likes
With “community management”, its not about the free t-shirts or meet-ups but the organization showing some bit of care. Many of us are concerned about this, and it would be nice if we can get some kind of official word, even if its just “we don’t know right now because…”
12 Likes
Blaze is simply better in every way that matters to me and lot of others. In the ways React is ‘better’ according to you, to me, doesn’t make up for all I give up leaving Blaze and all the other ‘baggage’ that comes along with React.
If MDG would reverse the abandonware status when it comes to Blaze, they could address everything React brings to the table in a more intuitive and extensible way while taking advantage of Blazes obvious strengths IMO.
Agreed, it would be great to know or at least know if they are not sure about what will happen with Blaze. I’m starting a new project in a couple days, and it would be good to know whether it would be unwise to use Blaze as opposed to React. At this point, I have my preference, but it doesn’t matter to me as much which one is better, but what the future will hold for the platform. Will React going forward be the go-to for Meteor as far as support? Will Blaze disappear? Is React Native support in the plans? Any sort of solid stance on these questions or just a solid not decided yet would be great and allow for those of us who are unsure what to do a bit of extra confidence in our decisions.
1 Like
@rubenpa and @msavin I want to disagree slightly by saying that I don’t think an official “we don’t know” response is enough to make people happy. That at least needs to be followed with “but here’s our plan to figure it out”.
Most questions on here I think can be fairly easily inferred from the observations sashko has shared with the community:
A: They want to be able to be UI framework agnostic. You can pick Angular, React, Blaze, whatever and it would work just fine. Any support effort will be focused on whatever is the most popular flavor of the day.
A: No, it will stick around for as a long as people find it useful. Its increasingly unlikely that they will pursue development of a next generation Blaze. No one has any significant Blaze work anywhere on their active todo list.
A: Of course as long as A) it gains a large mindshare and B) holds that mindshare indefinitely C) it does not end up require signing up for significantly more code maintenance. They already have one foot in the pool with Cordova.
The big mess right now is the impedance miss-match between wanting Meteor to be a framework that’s built and configured for super fast, sensible, out of the box development, and one that is agnostic to libraries within the ecosystem.
One of their core principles:
Embrace the Ecosystem. Meteor is open source and integrates with existing open source tools and frameworks.
creates a lot of conflict with half the other principles. Database everywhere obviously is a giant middle finger to the idea of meteor “working” with any other open source database. Data on the wire as a principle commonly makes it harder to work with APIs. Fibers on the server makes many NPM packages misbehave or have to be wrapped.
Its nearly impossible to be a trailblazer making opinionated framework choices that often go against the grain of compatibility and simultaneously wanting to be a loosely coupled framework that is compatible with many other libraries. There is no apparent guiding light within MDG for when to go one way and when to go the other.
4 Likes
I thing MDG owes the community a clearer communication than that. All of us (individuals and corporations) that have significant investment in Blaze apps/code/knowledge made that investment because MDG gave the impression of a solid maintainer. If MDG is now going to prove itself NOT being that (by moving Blaze to “we stop development and keep it at current state until it dies by abandonment” status), any such confidence is lost.
And as I keep telling my 11-year old, confidence is a thing that is hard to build and easy to loose, and almost impossible to rebuild once lost.
For me personally I need to see a clear official statement by management, where I see two possible acceptable answers:
-
“We have heard the community feedback and will put Blaze back as a core technology to receive future development”.
-
“MDG will not invest more in Blaze but we will provide coordination and integration/test resources to allow the community to develop this part of Meteor”
The second one would be acceptable to me because I have seen plenty of intelligent answers and talented people in this thread 
! And it is also along the lines of how Qt is developed in cooperation between the Qt company and the community, which is a well proven model.
1 Like
Using the word investment when you are getting something for free from MDG’s tangible investment is quite quixotic.
When do we get to the point in the story where you explain to your 11yo that nobody owes him anything and the stuff he receives for free actually came from someone else’s bitter effort? We apparently jumped past that all to where he gives a frumpy face and stomps his feet.
3 Likes
If for-profit companies offer something for free to you, then you are the product.
3 Likes