I have been working on a Classifieds app for a while now using Blaze.
Can I continue to use Meteor without ever having to worry about learning React.
Its already time consuming to create a webapp. I dont want to be cornered into pausing development and learning React.
i agree, and I can’t shake the feeling that this is a complete fad that will fade really quickly.
On top of that, I have the unpopular opinion that I don’t trust facebook-produced products. Most of the time they seem massively overcomplicated.
I mean, they basically completely monkey-patched and re-invented PHP to work the way they wanted it to. Why not just use Go, Node, Python, or even C++ instead of re-inventing an existing framework?
Meteor is open source and works now with Blaze (no React needed). So if you’re happy with Meteor as it is now, you’ve always got it as it is now. Blaze will work until Javascript ceases to be backwards compatible.
Yes but just know that your domain of knowledge is only in the Meteor world if youre going with Blaze
I also held this opinion. However that fad isn’t going anywhere anytime soon. If Angular2 would actually show up, there might be something to it, but until then, React is not going anywhere, no matter how much I might want it to.[quote=“corvid, post:2, topic:21846”]
On top of that, I have the unpopular opinion that I don’t trust facebook-produced products. Most of the time they seem massively overcomplicated.
[/quote]
I tend to agree with that opinion, however React is worse and has often gone down dangerous paths that has resulted in people with only backend experience jumping on various options provided by React to take shortcuts that shouldn’t be taken.
They didn’t actually change PHP that much. Mostly they fixed it (in my opinion) but yes, why not just use something that already was well engineered for making well engineered products. The answer is Zuckerberg. He is not a really strong programmer, he is a PHP hacker! So the original facebook was written entirely in PHP. Since then he’s been taking a more business seat and the company has been handed over to a couple of generations of programmers later. The PHP history is still there because they have legacy code that hasn’t been ported (for reasonably good reasons).
While I agree with this sentiment, I would like to point out that React is a natural extension of ES2015 which is the future. React is built around the idea of modules and the idea of components being each a function. Blaze is built in line with handlebars which is itself old. While there is nothing wrong with Blaze or Handlebars, the structure and syntax is already feeling long in the tooth. Moreover, one thing that Blaze suffers from is no namespacing constructs. React is inherently “namespaced” in that each component is a class to be exported and later imported. You don’t have to worry about name collisions in large applications (A problem I dealt with nearly daily).
This ignores the fact that as Meteor continues to evolve, blaze may very well be left behind. I’m fully expecting that at some point in the future Meteor is going to make a 2.0 version in which they remove a lot of BC hacks. I would hope at that point that they introduce module bound RPC (always a challenge) and that we could get real, truly encapsulated, applications!
Not ignoring that fact at all - quite the opposite.
I’m saying that “if you’re happy with Meteor as it is now, you’ve always got it as it is now”.
However, if you want to keep typing meteor update, someday (not soon, but someday) Blaze might no longer work for you.
Ah, a time.
Year ago people were asking for official react support.
Time past - we want our good old blaze back its stage.
Blaze is being taken over by the community with some real solid people behind it. Honestly, this could be great. The way MDG is going, the focus is moving to the Data layer (Apollo). At some point they can’t support so many different view layers at 100% like it was done for Blaze.
As for future Blaze development: I don’t expect we need a lot more to be added (there is ONE bug on Github last I saw, with a workaround). Because it’s a DOM-based templating theme. The DOM is not going to change anytime soon. We could add a few cool things, like Incremental / Virtual DOM.
Maybe open an issue with React asking them to put things on pause until you’re done your current project … 
People were asking for support, not a replacement… Blaze does its job well
I think React is stupid. Writing html code fragment in javascript is stupid.
Look at this stupid piece of code
var Chat = React.createClass({
render: function() {
return <div>
<div>Messages should be displayed here</div>
<form>
<input type="text" placeholder="Your message" />
<input type="submit" value="Send" />
</form>
</div>;
}
});
I’m returning html from javascript!!!
Just because this worked for facebook doesn’t mean we should make it a global standard and everyone should start using it.
We should simplify things and not complicate them. I feel things should be sequential.
Lets take designing a simple page. With Blaze approach we dont have to write any javascript in beginning. Just make a html page with mockup data and then once the page looks good you can start pub/sub stuff and attach the dynamic data {{}} part.
With react you are writing javascript from step 1.
I hope this react fad passes away soon.
Just because you don’t see the point doesn’t mean to call something stupid. I didn’t like React but I have to give it a try because my co-workers were using it in other projects and we wanted to unify software stack.
React is brilliant. What it gives me is that no more i mix components/part of the view that I shouldn’t mix with each other. React gives you ability to write simpler, smarter components that has HTML and JS in single place. So you don’t have to debug/understand logic of whole application just to get to know how very smart part of a view works.
Give it a try. I bet you will not call it stupid anymore. You can dislike React, but you can’t say its worthless.
I agree with this. Didn’t we separate view, model, and controller for a reason in the past?
I mean, the only situation in which I could see this making sense is if the components were rendered programmatically via something like WebGL or D3.
I really hate looking at HTML in controller-like code.
Agree. Blaze makes sense and is very elegant!
Did we though? We did a lot of things in the past, doesn’t mean we should never do anything else in the future. For example, in the past all websites returned only server-side rendered HTML and each click got new HTML.
I’d highly suggest that you watch Pete Hunt talking about most of the common complaints about React here. Yes, it’s 40 minutes long, it’s definitely worth it. One of the topics he covers is the JSX format you bash above, and why they believe it’s a great thing. I strongly believe in React for one reason above all others: it is the only part of our tech stack that my entire team (from design to development) has no objections to after using it for a few months.
To the original question: right now there’s no reason to think that you absolutely must learn React, so I wouldn’t worry about it too much for the moment. With that being said, one of the great things about React is that you can drop it into basically any existing app without needing a complete rewrite. If you ever were to switch over to React you could refactor one component at a time and shouldn’t be too traumatic.
The thing about learning react is, that it doesn’t require you to stop your project and read books for a couple of weeks. The API is ultra-thin. Basically if you read the getting started guide, you’re almost done.
So is blaze, it just hides it using a template layer.
Honestly, React isn’t any more complicated than blaze. If anything it’s simpler in one aspect because React isn’t reactive (a real trip with the mind let me tell you trying to explain that to someone who has been heads down in blaze for the last couple of years)
In react you throw two extra lines on that and still just emit a simple “html” page using JSX. Or if you prefer The trusted source for JavaScript packages, Meteor resources and tools | Atmosphere (not 1.3 ready yet sorry) which I use for more complex templates.
You are in blaze too, you just hide it by using a compiler which is native to meteor
I think we’re well past fad at this point.[quote=“mbochynski, post:12, topic:21846”]
Just because you don’t see the point doesn’t mean to call something stupid. I didn’t like React but I have to give it a try because my co-workers were using it in other projects and we wanted to unify software stack.
[/quote]
I had a similar introduction but am slowly “accepting” the React way. Of course I refused until I had a template solution (hence my atmosphere package)
I’m not sure I’d go to brilliant, but yes, React does a lot of things right in the modern world of proper separation of concerns.[quote=“mbochynski, post:12, topic:21846”]
Give it a try. I bet you will not call it stupid anymore. You can dislike React, but you can’t say its worthless
[/quote]
Some people will always call things like this stupid. Not because they are narrow sighted, but because these things really are stupid from their point of view and in the world they work in. I use React and it suits me well. Someone else might be better off with another option.
We did. And then we created a different separation called MVVM (Model, View, ViewModel). Then someone came along and created a Presenter/Model separation. There are lots of ways to separate concerns, React suggests a component style separation. Rather than having really deep templates covering large chunks of your renderable page, you have really deep component hierarchies which build up a DOM based on a ton of little pieces, each of which is concerned only with it’s little thing.
… like a shadow dom? Newsflash, Blaze and React are both programmatically emitting DOM. The fact that Blaze looks like pure HTML is just a veneer over what it is really doing. React syntax may be annoying to you, but it is no different. And if you want your view in a separate “layer” then you can use either my template package or stateless components which do nothing but render their given object (and thus are like 2 lines of code on top of an XML tree).
Yeah, we did. It was for a reason, and that reason remains valid. The reason is so that as a developer we’re not thinking about too many things at once and avoid risk of breaking things at the boundaries. Separating view, model, and controller created boundaries where the seams were well defined, and then within that boundary developers only had to remember the contents of the boundary and the seam, not also how the other layers would use the results. Only that the results adhere to a contract.
React just uses different boundaries. Those boundaries are the components. There is usually still a separate model, but controller and view gave way to higher order and lower order components. Higher order components would have special logic and generally don’t emit any DOM themselves, instead emitting lower order components. Those would take the input data from the higher order component (in a parent/child relationship) and emit DOM to show that data. Events then would usually be passed up to the higher order components to handle them. In a sense, higher order components become the controller.
I learned React on a Saturday. I built and released my template compiler on that Sunday. I started using it on Monday and 3 weeks later had it in production. In short, this is 100% accurate! The documentation is simple and relatively straightforward. It just does one thing and focuses on that one thing and tries to do it really well. I would say that it does it well, I’m still debating if it’s really well!
Honestly I wouldn’t be stressed about this particular scenario happening any time soon.
I believe it won’t happen