As per @SkinnyGeek1010’s comment, this is complete nonsense. You can add any blaze component into React with about 10 lines of code. It’s this “scare-mongering” nonsense thats being thrown around that’s making people make snap decisions.
I think it’s important to decide what Meteor is.
Is it an ecosystem that removes the friction of making realtime single page apps?
or
Is it an ecosystem where you just assemble legos and one that surrounds you in a cocoon so that you don’t have to look outside into the ‘real world’ of the JavaScript community and perhaps take a weekend to learn something new?
I think Meteor was “sold” more like the latter, really. Remember what they used to call “Meteor Platform” and “Meteor Distribution”? It went along the lines of “a set of packages tested and designed to work well together…”. The distribution included both the back end and the view layer. React and Angular were not even part of it. So I don’t think many people can say they came to Meteor because of it being open to all the JS world. I think it was the opposite. I knew what I signed up for when I started putting time and resources to learn Meteor.
I know a lot of people have a negative connotation about Meteor being closed and not being in the “real world” Javascript. We envy the world, the world doesn’t envy what we have. Maybe they’re right.
1 Like
I am very unhappy with this move. Though I can understand that React has reached a momentum that Blaze might not be able to achieve, I’m getting more and more the impression that investing in Meteor in effect means that you have to completely re-write your apps once a year (or so) – which is completely counterproductive from a business perspective.
Not everyone wants to be at the “cutting edge”, just for cutting edge’s sake. Though I clearly see the benefits of React’s component approach (and yes, I am missing this a lot in Blaze), constantly re-writting my app to hang around with the “cool kids” is not an option to me. I want to focus on business value rather than on having the latest technology stack.
And from that perspective, Meteor used to be the place to go, because of its simplicity and super-fast “from prototyping to production” cycle. But now I’m faced with a lot of community fragmentation (which will eventually lead to a lot of incompatible packages) and much more complexity.
It looks like if Meteor is becoming more and more a stack “from developers, for developers” rather than a stack for a quick time-to-market - which Blaze supports very well due to its proximity to HTML, which makes it quite easy to board new developers or designers.
Besides this, I expect that Facebook and Google will develop their own full-stack solutions based on React and Angular, so if Meteor is dropping one of its core USPs (which Blaze and its simplicity is, at least to my point of view), it will sooner or later become obsolete.
Maybe you will manage to keep Blaze’s simplicity on top of React, but I am not very optimistic that this will be possible - the approaches are too different. I really hope you will prove me wrong…
23 Likes
Like I mentioned before, everybody talks of “opening Meteor to the whole JS community”, add this, add that… But no one seems to care about the documentation and making it all actually work together. Who’s gonna write the documentation for all this stuff? Which package is gonna work with which package? These are practical questions.
Writing documentation is a lot easier said than done. Or we can just forget and let others figure it out. If that’s the case, we’re back at square one and Meteor web development will becomes neither fun nor accessible.
3 Likes
The whole point of the “Blaze templates over React” is to bring the ease of use of templates to work with a well thought-out component system of React. What approaches do you see to be different exactly? Why do you think it is not possible? Are those concrete technical matters?
1 Like
Hi Evan, correct me If I’m wrong, but this template layer on top of React is just going to be for those who want to transition from Blaze, right? Should I just jump into pure JSX for my new projects?
What do you recommend going forward? I’ll take whatever solution MDG recommends from now because my primary concerns (and I think of many other too) is what will have better support and resources, in terms of integration and documentation.
Thanks!
2 Likes
@evanyou
Thank you for this reply. The way you have composed this post, is an announcement worthy response for developers and people investing in Meteor as a serious project. I believe this should’ve been the official answer from MDG. If done like this, I sincerely believe that there would be a whole less drama. I do not see an issue when it comes to migrating for improvement. I see issues in the field of solution lifecycle and existing production apps. And this response has clarified the things I really care to know about.
10 Likes
Is this something that may be incorporated in the near future? Hoping to start a new React Native project by the end of the year, and would much rather have it directly within a Meteor app. Would you say this is something worth waiting for or should I just go the DDP route?
I don’t think we’ll have a seamless react native integration by the end of the year.
4 Likes
If you are open to trying pure JSX, then yes, I’d say start using React now is a smart move.
8 Likes
I don’t want to be picky, but when can we expect an official blog post on this matter?
1 Like
Is “Blaze templates over React” going to be maintained in the long run or is it going to be a one time deal? (so that old projects can still run and new ones are pushed to React)
4 Likes
@sashko Do you think we could somehow document react alternatives to blaze packages? At least that way we can see where the holes in meteor react components are vs blaze. I’m all for moving to react right now but there aren’t always alternatives, look at autoform for example… managing large forms without it is unthinkable but I don’t see an alternative for react that can validate on both the client and the server as conveniently.
10 Likes
Evan, this is a great answer! I was waiting for such. Small apps or prototypes or MVP projects might use Blaze, and this is cool, but big, production apps need to use React (with or without ‘pseudo’ templating system, whatever, as long as it will not break React) and this is reality. Mentions of modules, npm and Webpack… this is good - I trust MDG 
Just wanted to say it 
4 Likes
When reading this thread I got a clear feeling, that the community is not ready for a hard decision. Because it is also not an essential problem of meteor… spark/blaze/react/angular/polymer… there are too much and this is good. people should choose what they like… it’s an individual thing.
In my opinion, meteor has some other issues which should be on top of the agenda like: Multi-DB Support, robust scalability API over cluster networks, instances isolation and so on.
About the view layer:
React is still really new for the meteor community. Most of the people did’t tried it yet. Most of the apps are running blaze. I personally like react. But it’s wrong to shift complete to react right now, because this dynamics makes the community nervous.
8 Likes
Oh man, I have a lot of thoughts on this. I wrote like a page and a half and deleted it to put this summary:
I want the toys the other kids have, and I want it to be easy. That’s what drew me to Meteor. Now I’m using webpack:webpack because I need code splitting - and I love the flexibility from the work MDG put in to their build system that allows that. I wish that all of these features I wanted just worked and I didn’t need to think about it, though.
Blaze worked well because it was part of the entire Meteor ecosystem. I think Meteor would do well with a router as part of core that handled SSR, module support, and easy to configure code splitting. I like the idea of MDG making easy to use APIs on top of existing technology to accomplish that goal.
2 Likes
A long time ago unobtrusive javascript was a thing that people cared about. JSX is not that in my opinion. JSX gets messy and hard to read.
2 Likes
I think part of this is because, back then we just had “JavaScript sprinkes” that spiced up the page. Now we’re creating the view with JS and things are more complex than ever.
I think poorly written JSX is very hard to read. When starting out (myself included) most people don’t abstract enough and end up with a giant mess.
Instead, using several composed components helps reduce complexity and it also breaks them out into separate files. In programming terms, think 2 liner functions instead of 40 liner functions. By reducing line count you make things more clear.
A lot of time you shouldn’t need a JSX component to be more than 20 lines of code. Abstracting away bootstrap classes into one liners is a start! e.g.:
<Input label="Email address:" name="email1" />
<Input label="Password:" type="password" name="pass2" />
is way more readable than:
<div class="form-group">
<label for="email1">Email address:</label>
<input type="text" class="form-control" id="email1">
<span class="err-msg"></span>
</div>
<div class="form-group">
<label for="pass2">Password:</label>
<input type="password" class="form-control" id="pass2">
<span class="err-msg"></span>
</div>
6 Likes
Fair enough but from another perspective, isn’t Meteor relying on atmosphere and atmosphere packages relying on blaze actually a problem, partially closing meteor off from the larger JavaScript community?
3 Likes
The second snippet is a W3C standard. It’s longer but IMHO it’s more readable to everyone who is familiar with HTML.
With this discussion about React and Angular, doesn’t anyone think that W3C standards are important anymore? I’m not convinced with React, it’s just not seem to be contributing to an “open web”. We like HTML5 and ES6 because those things bring everybody forward. It’s not perfect, and it takes time. But standards are a beautiful thing.
What about web components? Anyway, I’m just venting here…
You seem to have a lot of experience with React so I’d like to ask a truly honest question: Do you think something else will start to replace React in 12 months?
thanks for the input!
2 Likes