haha, thanks and cheers mate
yea, people are working on it. Make a Blaze Components interface that can also transpile to react. We donât need to wait around for MDG for anything. Blaze Components by @mitar basically is the interface, plus a few tweaks. And @timbrandin is already working on tools to transpile Blaze as it is. I outlined the plan in depth above. But here it is again:
Weâll have our own extremely thin wrapper over React that modifies React ever so slightly so you call: this.props('key') instead of this.props.key (Blaze Components will share the same interface)âthat way the same code in Blaze can call a reactive function under the hood; and in React, the former simply calls the latter under the hood. And obviously, thatâs just one example of the things that must be done, but it exemplifies the idea.
Thatâs my proposal at least, and Iâm currently working on it (along with a matching Flux clone [based on Alt] that can similarly work with either underlying renderer). Any ideas are welcome; Iâll share my work when when I have some.
I appreciate the work you are clearly putting in, and I hope you find some way to make it financially viable for you to maintain your solution so people can depend on it long term. So donât get me wrong but the first word in your response should not have been yes.
This thread was started by @mitar and in my opinion his original post was not primarily about finding practical solutions for keeping Blaze moving forward (clearly he wrote Blaze components without MDG). It was primarily about the erosion of trust by effectively dropping development of a core piece of their tech stack. That trust has now been eroded even further because the community has raised the concern but hasnât been able to get any official response on it for over 16 days. At this point I think whitehouse.gov needs less attention on a topic to get an official response from the fricken president than we need to get a official response from MDG.
10 Likes
I wholeheartedly agree with mitar. I myself was attracted to Meteor because it claimed to be a platform where all the pieces to build things were there, rather than being another Frankenstein project assembled from multiple open source projects. Iâll be the first to leave if MDG loses its vision.
2 Likes
@arnpham as somebody building and maintaining a Blaze production app I share your frustration. However, I am hopeful about Meteor embracing more external technologies (react, npm, webpack, etc.)
The JS world is changing at a dizzying pace, and as an individual it feels impossible to keep up with all the new technologies as they roll out in rapid succession. MDG is a well-funded, insanely smart group whose full-time job it is to stay on top of the changes and curate them all into a convenient, performant, reliable, and coherent platform.
Meteor 1.0/1.1 shows that they have great taste. 1.2 shows that they are adapting to the shifting landscape (perhaps not quickly enough). All of itâfrom Blaze to DDP to Galaxyâshows that they they have the muscle to go deep and build out any piece they need to in order to uphold their vision.
If 1.3 and beyond can thread the needle of incorporating new technologies without leaving existing users completely in the cold, I think it will be a real achievement. In that light it doesnât surprise me that MDG is taking their time to figure out thoughtful response.
3 Likes
I guess I donât see the problem with having more choice in view layers. Could you elaborate more on this? I feel like iâm missing a valid viewpoint.
My outlook is that having 2 view libraries to choose from means youâll have more packages in atmosphere. One might be for Blaze UIâs and another might be for React UIs.
For the packages that do things other than views⌠for example a Router, the package author just needs to de-couple the view from what theyâre doing. FlowRouter and simple:rest are a great examples of decoupled packages!
The next version of Autoforms could do this too by building the core that is ignorant to the kind of UI then create two adapters for each view library. Then you end up with modular packages like autoform-core, autoform-adapter-react, autoform-adapter-blaze.
To make the user experience better provide a wrapper package like autoform-react and autoform-blaze to make installing these easier (as it could require many sub packages).
I honestly think the choice of view layers will strengthen the community by forcing developers to think modular and build composable packages going forward.
4 Likes
I love where youâre going with this. Meteor packages will need to decouple themselves away from the presentation layer. It is clear that Meteor is moving towards a âpick your own presentation layerâ paradigm. If the community doesnât abstract packages from their presentation logic, then we will be drawing lines between sets of packages that we can and canât use.
For autoform, @aldeed has already said that React support is not on the roadmap. He doesnât seem to convinced that people will stick with React. Fortunately, since collection2 and simpleschema are cleanly abstracted from the presentation layer, and the majority of autoform is Blaze templates, it could be easily ported to React (with enough time and resources). But then youâd also have to port all the autoform add-ons written in Blaze.
2 Likes
Also once we get SQL support weâll have a similar issue with persistence layers. A popular pattern to solve this is the Repository pattern. So for example if a package wanted to add a âPostâ then the package could just use Repo.insert('post', {title: 'foo'}) and then an adapter layer could handle what an âinsertâ is in the DB youâre using (like Mongo, Rethink, Postgres,).
Iâm working on a ârails-likeâ opinionated library (of several small packages) for doing a REST API in Meteor and it has a similar concept of repositories.
1 Like
I actually think itâs pretty likely a lot of people will stick with React, but autoform is currently tightly coupled with Blaze so Iâd rather see a new package for the React version of autoform. And also I would not rule out something else springing up unexpectedly and displacing React. It is still the wild west of UI components.
7 Likes
Why youâre looking to React only? How about upcoming Angular2?
React, React, React⌠Why only React?
I just played with Angular2 a few weeks ago and I feel that we will have another portion of hype when new Angular will be production ready. Also for me to move to Angular2 from Blaze looks as much easier solution than to move into React. Itâs actually closer to what Blaze2 was supposed to be, isnât it? @Urigo, whatâs your opinion about that?
Why you donât care about your early adopters?
Many people who started with meteor year or two ago have already their apps up and running. There are many very popular packages e.g. autoform made by @aldeed which will not have React/Angular2 etc. support, so to move there from Blaze will be huge job.
Blaze is easy
@sashko, @dgreensp I think you should agree that to start with Blaze is much easier that with React. It also requires less code as well. So blaze is just awesome to start. And if somebody wants to add one or a few React components, Meteor already supports that.
So why to deprecate it?
There was many reasons already told and I feel that anyway for now main reason is that MDG at the moment donât have enough resources to work on it. 20M wasnât given to them for thank you, investors are actually waiting for return on investment, so concentration on Galaxy is totally understandable. I just donât think that to go easy(?) way and deprecate Blaze instead of make it better is right solution.
I do have some experience with React. I use it in one medium size Django project. I also used to play with React in a few small Meteor apps and thinking about React in new bigger one. But the main reason is not because I love React. Sure, React is good piece of software, I just donât like their approach and Blaze feels more natural for me.
What I miss in Blaze:
- State. In our team we even had to implement our own state solution (using reactive vars and stuff).
-
Arguments to templates. We really needed them for our components and had to cheat putting data into
@contextand passing arguments directly into template data context:+myComponent context=event arg1="abc" arg2="some_arg". Each template then starting with{{#with context}}. Not so elegant solution
- OO style component model. Yes, itâs something @mitar is trying to add into Blaze with his BlazeComponents, but to have this out of the box would be really awesome.
I like @slava position on this topic:
I still find Blaze to be much faster to write code in. I do think though, Blaze has too many weird concepts that were mixed together due to the legacy to Handlebars.
It is important to remember that Meteor had many UI front-ends: LiveTemplates, LiveUI, Spark, Blaze. At first, they were a more âdynamicâ use of Handlebars library. Since then, Blaze was completely rewritten and there is nothing left from Handlebars other than the weird syntax and semantics: dynamic and overriding data context, no arguments to templates, no OO component model, weird interactions with the this variable in Template helpers, that leads to yet another thing Template.current() which exists only because the data context access is borrowed from Handlebars.
I think Blaze2, if it happens, would need to be cleaned up and be backwards incompatible. I would be excited for a better components model and a more structured way to interact with the scoped variables.
Source: https://crater.io/posts/biSDc8kgfvqqFMa4M/ama-with-slava-kim-august-18th-at-1pm-edt-10am-pdt
For me, if 3 things I mentioned earlier will be solved, Blaze becomes default solution for any size of Meteor projects. And if Blaze additionally would support event handlers directly in template (as React and Angular2 do) that would be totally awesome.
P.S. I really like that MDG made big effort of separating core from blaze and now we can choose what to use Blaze, React or Angular.
2 Likes
This is really interesting. I would be curious to see if you gave both React and Blaze to a developer who has never used either⌠which would be harder to use. IMHO the one youâre most comfortable with is always easier.
The reason this stuck a chord was that iâve not worked in Blaze for the last 8 months and I recently made a small chatroom app in Blaze and I awkwardly fumbled around trying to get data into it and to get a reactive quark working. This is mostly because iâve been using React 5 days a week and have been thinking about the UI in a different way.
Just an observation. Perhaps Blaze isnât really âthatâ easy once you get past the hello world stuff?
4 Likes
State. In our team we even had to implement our own state solution (using reactive vars and stuff).
Arguments to templates. We really needed them for our components and had to cheat putting data into @context and passing arguments directly into template data context: +myComponent context=event arg1=âabcâ arg2=âsome_argâ. Each template then starting with {{#with context}}. Not so elegant solution
OO style component model. Yes, itâs something @mitar is trying to add into
I really think youâve pretty much described the core advantages/features of React right there. Just sayinâ
10 Likes
Well, you may not have to make a new package. I think âSideburns,â which is now called âBlaze Reactâ will impress:
Iâve been doin a lot of work on it along with @timbrandin, and things are looking good.
There are a lot of similarities between Blaze and React where it counts. And the path to resolving the differences is requiring less hacks than you would think. In addition, itâs gonna fit even more nicely with @mitar 's âBlaze Componentâ package (which is what people should have been using instead of Blaze for a long time nowâside note: the conversation really should be Blaze Components vs React).
Anyway, anyone who would like to contribute, email me at james@faceyspacey.com. we need as much help as possible to get it done quickly, as itâs a side project for both of us (obviously).
2 Likes
I havenât tried sideburns, but Iâm aware of it. But the issue is not so much the handlebars template syntax as it is the component scope. I havenât researched enough yet to be sure, but I think a bunch of the things that autoform does with dynamically inheriting and examining parent scope will break down if react is managing the component scope. Maybe it will take less work than I think, in which case great.
What scope are we talking about? Just data âscopeâ or âinstance scopeâ? are you using just Template.parentData(level) or have your rolled your own solution to make an unofficial Template.parentInstance(level)?
It is. Hereâs an example of a Template.parentData(level) method in React:
Basically when the props of a parent component change, the entire child component is re-rendered as well, which means that if you have access to the parent component passed down via a prop, you can simply get the parentâs props, i.e:
<MyComponent parent={this} />
var MyComponent = React.createClass({
parentData: function(level) {
var parentData = this.props;
for(var i = 0; i < level && parentData.parent; i++) {
parentData = parentData.parent.props;
}
return parentData;
},
render: function() {
return <div>{this.parentData(1).count}</div>;
}
});
The âheuristicsâ donât seem to be so fine-grained that it will figure out whether it needs to re-render a child component based on whether it passed down one of the props being accessed. So in the above example you wonât end up with the parent componentâs count property having changed, but the child component still rendering the old value because it doesnât know to update itself since it wasnât passed count as a property. It doesnât need it to be passed to itself to get a chance to re-render. And that seems to be the same story all the way up the chain.
However Iâm still wary there could be edge case instances Iâm missing. If anyone would be willing to point them out it would be awesome.
FINAL NOTE: thereâs also a âcontextâ feature React offers thatâs lesser known, but that they plan to expand upon:
hereâs a quick example:
http://jsfiddle.net/Ljpd0d0m
So that behaves a lot more like how context is passed down naturally in Blaze. In short, thereâs a lot more similarities between React and Blaze than you might think. And thereâs lots of ways to hook into React. I get the feeling that a lot of different view frameworks will end up using React under the hood, given it opens the doors to React Native and likely what will be the largest reactive component ecosystem of them allâŚClojurescriptâs Om already transpiles to React. You can use React in combination with Cycle.js, which is basically the purest functional reactive approach in plain javascript (i.e. without having to switch to a transpile-to-javascript language like Elm, Om, etc). So all these guys are using or able to use React as their renderer. While there is an order of magnitude more similarities with their already-functional approach and Reactâthey can basically just render all components functionally as âdumbâ componentsâI think with the various features such as âcontextsâ and ultimately what might be a less strict system under the hood than you might think, it will be possible for even Blaze to partake, and perhaps more importantly @mitarâs Blaze Components, which together will give Meteor/Blaze developers everything they are lusting after that React provides.
2 Likes
Very well put. Trust, reliability and incremental steps for the installed base make the product stronger.
2 Likes
For us it is: Consistency, predictability, trust, security, ease of use across multiple platforms
2 Likes
You are doing this already. Many of the tutorials and answers are already written for Angluar and React. It is already freezing 
2 Likes
I canât believe I was naive enough, one year ago, to choose Meteor and Blaze for my startup.
Now my application is so large and connected to Blaze through dependencies, I cannot upgrade to whatever UI tech is the flavor at the moment.
Blaze it seems now will never be upgraded/enhanced. And amazingly on something so important as the front end to our applications, MDG will not provide official guidance.
Now Iâm stuck without Blaze upgrades/enhancements, stuck with what appears to be a dead end tech, and stuck with dead packages in some cases. This is a mess for the ones that actually have larger running production applications.
We trusted MDG; we trusted them to make the right technology choices and at least enhance/support it for a while. Some, like myself, have invested countless hours on Blaze, Iâm sure others have too. Iâve bet my small company on Meteor and Blaze, and now we find (through anecdotal evidence) that Blaze is abandon-ware.
What was so awful about Blaze tech to make MDG turn it into abandon-ware? Why not continue investing Blaze tech as a hedge as something MDG can control? Does MDG not care about the needs and expectations of the users of their tech?
And what if Angular2 walks all over React when it arrives?
5 Likes