FR: Switch to react and react native?

[raix]

"Embrace the ecosystem" http://docs.meteor.com/#/basic/sevenprinciples

I'm really happy with Blaze but it seems React is doing the same thing, why not cooperate?

• It got an official component model
• Its fast
• It renders server-side
• It does work natively on ios and android - natively...
• Meteor core team has limited ressources

Native is one killer feature on the way: react native allowing us to write js and use the native ui components.

I've been working on several meteor mobile projects, and just recently bumped to use the official cordova implementation. Its ok, but still cordova with the inconsistencies that follows.

React native is doing something a lot of us have thought about: letting us write js and leverage the native ui. Its actually allowing faster development than regular native development (eg. not having to recompile all the time)

I know some would argue that its only for mobile, but its actually also for desktop, the Meteor build tool supports multiple platforms, this is cool!

We could wrap ios/android native code in our packages instead of trying to fix the cordova plugins all the time...

https://www.youtube.com/watch?v=7rDsRXj9-cU

Just my honest opinion, I think react fits Meteor very well, maybe have a Meteor React distribution for starters to check out popularity...

Kind regards Morten

[jhartma]

interesting thought, and definitely something I would try!

[rclai]

There is a guy that created this React.js integration package. I haven't tried it but it looks like you can actually write JSX and it hooks into the Meteor build process, which is nice.

[raix]

Theres another guy that build https://github.com/reactjs/react-meteor - I think he is on the core team now?

[rclai]

Oh wow, I guess he is. The guy that made the package I mentioned is built using the same code as Ben's.

[stubailo]

For a start, I think it would be great to have a well-maintained and useful community react plugin. Is the one you linked to good enough for people to use React as a replacement for Blaze? If not, what is it missing?

Thanks for the feature request! You might be interested in reading our feature request guidelines.

[rclai]

Can you ask @benjamn (he's in MDG right?) if this implementation is still good? It uses his code from here.

[raix]

@stubailo I've skimmed the guidelines a while back and just now - not sure if I'm missing something? - This FR is based on the:

we're not able to work on every single subproject every month

+the reference to the seven principles "Embrace the ecosystem"

+I've contributed to the hackpad Blaze2 regarding this too

I'm personally not seeking to maintain yet a package, the deep integration I would have wished for requires more than a package - making the build tool extendable is another FR.

But lets see when React native is published if its worth migrating to or if its just another Famo.us project claiming to tackle mobile.

Kind regards Morten

[rclai]

@raix he's not saying that because "you didn't understand something" he's saying that because MDG requires all employees to state that in every FR post.

[raix]

ok, so I just replied on a copy&paste / bot text - I'm too polite to ignore it, @stubailo could you guys consider:

• have a bot comment depending on the labels you set
• have a bot that sets label "feature request" if we put "[FR]" in subject (this way we can help you set the label)
• or tailing robot messages like instead:

Thanks for the feature request! You might be interested in reading our feature request guidelines.

[glasser]

Well, it's not a bot, it's copied and pasted by a human :) See https://meteor.hackpad.com/Responding-to-GitHub-Issues-SKE2u3tkSiH for how we try to deal with the issue queue.

The goal of the text is to get across the message that we appreciate the feature request and are happy to track it in our issue tracker, but that there's a giant gap between "Yes, this would be cool" and "Great, we are going to allocate limited labor resources right now to fixing it". If you have a better suggestion of text we can use to encourage people making feature requests to read the guidelines and understand the level of support we're able to provide, let me know!

[stubailo]

I've updated the text to say: "Thanks for the feature request! We welcome discussions about how to make Meteor better. If you haven't yet, check out our wiki page about feature requests on GitHub." Does that sound good to people? @raix @rclai

[raix]

@stubailo I ment adding visuals like italic and the seperation line makes it more clear that its a pasted message - some of us are getting old and senile - well, could be just me - @glasser I'm just glad you guys have the time for feature requests at all, I think its important for the community.

If it was me, ideally I would comment and set the label and have the bot add the std. text accordingly to label. (without knowing how many std. texts you have, not sure if possible at all)

Btw. I started the https://github.com/MeteorCommunity/discussions/issues to keep track of feature requests, we should prop. migrate FR from there at some point - having it for tech community discussions.

[mitar]

What about using a label for this? "Feature request" can be one label, but then "Yes, this would be cool" and "Great, we are going to allocate limited labor resources right now to fixing it" labels would also be cool. Because to me, when you make that reference to the feature request guidelines, I always wonder what exactly are you trying to say. That I missed something in the feature request? That you are confirming it? That you will start working on it? Or that community should start doing pull requests.

For example, it is unclear what you think about this idea:

• is this something MDG thinks could be done, and will do
• is this something MDG thinks could be done, but community should make a pull request, and it will be merged ASAP
• is this something MDG thinks could be done, community should make a pull request, but it will be reviewed and merged when there will be time (pull requests reviews take resources as well)
• do not even bother, MDG does not think this is a good idea for core, make a package/fork
• do not even bother, MDG does not even think this is a good idea for the package

[stubailo]

@mitar figuring out which of the five types of feature requests you listed apply to this one is in itself a lot of work.

[mitar]

:-)

[rclai]

Okay anyways, so looks like another reactjs-related package reached the atmosphere by one of MDG's guys @avital. Are you guys going to do some kind of official integration package of sorts?

[stubailo]

Right now Avi and Greenspan are building an app with react to test it out, I suspect that package is part of their effort.

[Goyapa]

@raix i agree to what you write abbout react-native.

This are some resources i think are very helpful:

React: CSS in JS – NationJS

A Deep Dive into React Native

Pros and Cons of Facebook's React vs. Web Components (Polymer) The interesting part is behind the comments after update!

Pete Hunt talks Facebook React

Do you have other resources that could be helpful?

Ben Newman an active React contributor, represents Meteor in the TC39 JavaScript standards process, who initialized ReactMeteor.

[Rebolon]

One question about react integration with meteor : does iron-router compatible with react ? should we use react router ? how to manage subscriptions ? A lot of questions that are actually solved by Blaze, but what about React ?

[rclai]

If I'm not mistaken, the app that Avi and Greenspan are working on is here.

[hellogerard]

I will add unnecessarily to this thread to say the React is clearly HOT right now.

Here are all the meteor / react integrations that I'm aware of:

1. https://github.com/reactjs/react-meteor
2. https://github.com/hipertracker/meteor-reactjs/
3. https://github.com/avital/react-in-blaze
4. https://github.com/ccorcos/meteor-reactor
5. https://github.com/mystor/meteor-routecore

1 and 2 above apparently share a lot of code.

[grigio]

I add also Flow Compoments which is a React -inspired Blaze component lib by @arunoda .

Personally I like Blaze, but React/ReactNative is very hot and a bigger community.

EDIT: An interesting post about React an Reactivity http://futurice.com/blog/reactive-mvc-and-the-virtual-dom

[arunoda]

I think this discussion should be not to switch allow to use react. I think there is a good progress on that. That will help a lot of react developers to choose Meteor over something like gulp+nodejs stack.

I also hope it won't be much harder to mix both Blaze and React. Then that'd be super awesome. That's why we build flow at the first place.

[MaazAli]

This would be awesome. Having official react support would take some load off of MDG.

[Goyapa]

This is a great blogpost from @tmeasday about React. Creating maintainable interfaces with React & Meteor http://blog.percolatestudio.com/engineering/reactive-user-interfaces/

[IstoraMandiri]

Wanted to +1 this. Especially for a properly implemented SSR solution.

Check out my comments on https://github.com/reactjs/react-meteor/issues/41

[IstoraMandiri]

Looks like we already have a POC of SSR! https://github.com/percolatestudio/react-leaderboard. Great work @zol and @tmeasday!

Hope they don't mind, I deployed a demo here: http://react-leaderboard-by-percolatestudio.meteor.com/ Check out the source!

[grigio]

I like Blaze but it isn't much used outside meteor itself, React has a bigger community and ReactNative

[hellogerard]

Agree with @grigio. From a coding perspective, I prefer the Blaze way. However, it's starting to get tough to compete with React. Blaze on the server is on the roadmap. Blaze Native is a glimmer at this point (https://groups.google.com/forum/m/#!topic/meteor-core/hcFHexSg1fg)

[zol]

@hitchcott don't mind that you deployed react-leaderboard. Thanks for getting involved in the discussion!

[bobiblazeski]

1+ for https://github.com/tmeasday/react-leaderboard only react package from the mentioned that has a example that works outside the box

[awatson1978]

Can anybody explain to me how React isn't simply flavor-of-the-month? Seems like we had the same discussions over Famo.us and Polymer just a few months ago.

If anything, it seems like a careful compare/contrast between the three approaches is needed. What are the common approaches between Famo.us, Polymer, and React? How do they differ in terms of encapsulation, inheritance, composability, standards compliance, native widget support, render pipeline, use of precompilers, etc?

[zol]

@awatson1978 we did our best to explain here. The fact that facebook, instragram, yahoo, kahn academy and others having been using react in production for 1+ years suggests it may have more substance than just being the flavor of the month.

[mitar]

Not necessary. Blaze is not really provided stand-alone. If you have your own existing codebase and you want a fancy reactive UI, react is the way to go. But for Meteor this might not be necessary so. Because react has to work with all other systems, they have to provide that top-level state changing and then propagating changes to children, and then diffing the whole thing. Because Meteor depends on Tracker, this can be minimized. But this also means that others without Meteor have harder time using it.

I like how Blaze/Meteor has separation of concerns, templates and logic. I think that with Blaze 2 discussion there are some good ideas how to have components. And server side rendering is just engineering effort, not that Blaze would not be able to support it.

I think that Blaze already internally use diffing, it applies only changes to the real DOM. This is even better if you have 3rd party code modifying the DOM. Not sure how React reacts to that.

[awatson1978]

@zol... and you also gave the same writeup treatment for Famo.us here and were sort of advocating Famo.us component integration just a few months ago. It just seems like it's just coverage of the latest technology trends to keep the spotlight on Percolate (well done coverage, I might add), rather than necessarily advocating a coherent architecture.

I'm looking for a discussion like this one, but focused on Meteor: http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-react-vs-web-components-polymer

So what if facebook, instragram, yahoo, kahn academy etc have been using React for a year? There are other sites that have been using Ember for years. Or Angular for years. Or Bootstrap. Or a thousand other libraries.

Why should I go through and rewrite dozens of applications with this one particular library? Native widget support might be the win. But component reusability? The render() approach of React might be performant, but it's code looks like a mess and would be a giant headache to port existing code to. Why go through all that trouble and still use the HTML precompiler to compile to DOM, and not just built up the DOM one's self? If I'm going to do that, I might as well use Famo.us.

Don't get me wrong. I'm all for React integration, and think it would be an excellent technology to add to the Meteor stack. But I want to see comparative/quantitative analysis and refactor paths before considering replacing a core library like Blaze for something else. I've been burned by flavor-of-the-month too many times before in the past few years.

[murillo128]

My 2 cents,

I kind of agree with Mitar and in fact we have gone the other way round, choosing Blaze standalone (i.e. without Meteor server side) for templating and data binding. It is a pity that the standalone Blaze library is not activelly supported, but it was not that difficult to extract the code and create an npm package (https://github.com/eface2face/meteor-client if any one is interested).

I didn't want to use something that required a high learning curve, and liked the fact that Blaze/Tracker did exactly what the meant to be doing (reactivity, data binding + templating) and nothing else. That allowed us to reuse most of the code we had been already using without any issue. In fact we even created a jquery plugin( https://github.com/eface2face/jquery-meteor-blaze) to make it trivial to use:

In fact, we are now going one step further and started creating our self-made old-school web components based on jquery widgets (https://github.com/eface2face/jquery-widget-compiler).

My point is that I really think that Blaze and Tracker, due to the fact that it has clean interfaces/dependencies has huge possibilities, not only on the meteor community, but as standalone library. So, I would love to see any real live metrics/comparations between React on Blaze/Tracker, to be able to understand what are the caveats/bottlenecks existing in the current code and see if we can improve them.

Best regards Sergio On 07/03/2015 19:33, Mitar wrote:

Not necessary. Blaze is not really provided stand-alone. If you have your own existing codebase and you want a fancy reactive UI, react is the way to go. But for Meteor this might not be necessary so. Because react has to work with all other systems, they have to provide that top-level state changing and then propagating changes to children, and then diffing the whole thing. Because Meteor depends on Tracker, this can be minimized. But this also means that others without Meteor have harder time using it.

I like how Blaze/Meteor has separation of concerns, templates and logic. I think that with Blaze 2 discussion there are some good ideas how to have components. And server side rendering is just engineering effort, not that Blaze would not be able to support it.

I think that Blaze already internally use diffing, it applies only changes to the real DOM. This is even better if you have 3rd party code modifying the DOM. Not sure how React reacts to that.

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/3728#issuecomment-77702792.

[hellogerard]

Still surprised that https://github.com/mystor/meteor-routecore is not mentioned more. It has a fully functioning, Meteor-React integration TodoMVC example with server-side rendering.

Not to say that reactjs:react won't eventually take it over, especially with MDG working on it. It has a different design, wrapping React's render call in an autorun (I actually like the mixin approach better.)

@awatson1978 I take your point about flavor of the month. I understand Polymer much better than I do React right now, so I'm hoping to be able to make an informed comparison over time.

[mitar]

Is there any information about interoperability between React and Blaze? Can be React added to otherwise Blaze content and seen as foreign content by Blaze? Can React work with parts of it touched by something else? Or by just having a partial control over DOM?

[mitar]

@hellogerard: What do you think about Polymer and its integration with Meteor now?

[idris]

I've been writing an app with Meteor + React, and I must say the combination is incredible! The pub/sub and Meteor.call functionality of Meteor are very similar to the Flux concepts in React, and translate very well. I'd love to see Meteor embrace React to create a truly magical stack. Apps will become so much more simple to write.

Oh, and once React Native is out, this is a no-brainer. Awesome JS stack and a native app? :boom:

[MaazAli]

@idris Did you have any noticeable problems? Do you think it can scale well for larger applications, something like phanime?

[idris]

@MaazAli no noticeable problems. React scales really well for large applications. It's the brainchild of Facebook, which is a pretty large app :) It really helps make code more understandable and maintainable, which is especially important if your team becomes more than just a couple of devs.

If you are going to try it, or want to learn more about Meteor+React, I'd suggest signing up for the Reactiflux Slack and joining the #meteor channel.

[andrewreedy]

:+1: for embracing the open standards. If an app is shitty, it's going to be equally as shitty in polymer, react, blaze, famous, ember, jquery ui, angular, etc.. If we are moving in a direction it should be less influenced by the current and more influenced by the lighthouse .. (the standards).

[idris]

I guess Meteor is relatively template-agnostic right now, since meteor-react works great. So I guess it makes sense to discuss React Native here. That would be a relatively big change for Meteor, since it would mean "learn once, write anywhere" instead of "write one, run anywhere". I think at the very least, having React Native as an option is important.

[jonjamz]

Blaze is becoming cool, but it should seem more optional. I think it's important to support major existing UI frameworks in a project as large-scoped as Meteor even while developing your own. A brief comparison between Blaze and the others would help people choose the right one based on their goals.

Overall, I have to agree with @awatson1978 and @andrewreedy here. @idris can you please provide some evidence, even anecdotal, to show how React scales better for larger applications than Blaze or Angular or anything else? And I'm not just talking about performance, here--I'm talking about evolving a high-quality codebase that's easily maintained.

My gut reaction to JSX has been "why the hell would anybody do this?!" Long-established anti-patterns in web development include writing inline HTML in JS and putting JS inside HTML element attributes. Sure, it can be great for a quick demo, and It might even perform well. But it's easy to see it evolving into some horrific mass of disorganized, unmaintainable code.

React smells more like a way to attract trendy developers to Facebook than a smart take on best-practices. And certainly, rewriting an existing application to use it would be a bad idea unless there's a serious win somewhere.

[MaazAli]

Overall, I have to agree with @awatson1978 and @andrewreedy here. @idris can you please provide some evidence, even anecdotal, to show how React scales better for larger applications than Blaze or Angular or anything else? And I'm not just talking about performance, here--I'm talking about evolving a high-quality codebase that's easily maintained.

It's more about Blaze vs Ember, React and other front end frameworks. Blaze is super easy to use but I can't see it scale well until we have self-contained components, inheritance and a good way to manage explicit dependencies like import and export (this is more of a meteor issue in general). In my opinion, having globals doesn't scale well in general. Ember by default supports ES6 import and exports as does React. All of the current ES6 transpilers packaged for meteor cannot properly support imports and exports because of meteor's default way of loading all the files.

Then you've also got the initial page load and the size of .js file the client receives, as far as I am aware Blaze's generated .js file is fairly large comparatively, which again won't scale until we have some type of fast-boot type app rehydration (Ember Fast-boot).

My main concern with Blaze and I guess Meteor in general is being able to export and import modules/components, having explicit dependency management is so much more powerful and clear for other developers than having globals floating all over the place, without this, how do you see meteor scaling well.

[andrewreedy]

:+1: for ES6 modules.. (different issue.. new feature request?)

[jonjamz]

@MaazAli Blaze already has self-contained component capabilities, although that is relatively new and hasn't been marketed very well. I believe your ES6 module concerns relate to Meteor's bundling/compiling and are not Blaze-specific. Happy to be corrected, though.

You can create nicely maintainable application structures in Meteor today. You just have to put some thought into it and write good JavaScript. You don't need ES6 modules. Of course, support for transpiling those would be nice.

[mitar]

Blaze is becoming cool, but it should seem more optional. I think it's important to support major existing UI frameworks in a project as large-scoped as Meteor even while developing your own. A brief comparison between Blaze and the others would help people choose the right one based on their goals.

The issue is that this is more the question of the ecosystem. Even if Blaze is optional (and it already is), if the library I want to use offers Blaze components, I will have to use them. Or reimplement it.

So instead of trying to make guess which rendering system to use, we should rather figure out a way for them to interoperable. So that I can use both of them in the same app. So how to have a rendering which allows that. I saw examples where it was easy to embed React inside Blaze. But how easy it is to embed Blaze inside of React? If we can abstract this patterns out, then we could make this work.

At the end, all of them are compiled down to the same language: DOM. So we might be able to figure out something here.

Same as it mostly does not matter if my library is written in CoffeeScript or JavaScript for somebody using it from outside.

[ccorcos]

I've been playing around with React recently and I really like it.

React is actually quite simple. Its just a rendering engine, and its actually very easy to integrate with meteor using a React mixin. I've created a package for playing around with React that has all sorts of nifty tools that integrate meteor seamlessly with React. Its not a serious package yet, but you may find it interesting, and maybe you can help me with it.

I can see form Meteor's perspective why they want to keep Blaze. Its super simple and elegant, and for simple things, its amazing. However, React is far more powerful at abstracting user interfaces. So much so, that React Native is practically no different from React for the web! The fact that React does not rely on a markup language gives you so much more freedom in how you design and program your application.