Integrating React with Meteor(info.meteor.com)
info.meteor.com
Integrating React with Meteor
http://info.meteor.com/blog/meteor-the-missing-infrastructure-for-building-great-react-apps
6 comments
If you try building a realtime single page app using Meteor and measure the amount of time it took you to complete it, you'll find that the hype is justified.
But at the expense of performance? I've written a number of applications in Meteor and continually struggle to scale them, even to tens of concurrent users.
Well http://mostexclusivewebsite.com/ currently has 46,000 users concurrently connected, in-line, receiving live updates, waiting for a ticket. So yeah, I would go so far as to say that Meteor can be scaled pretty well.
I've just tried to access the site and it's failing to load half the time, and the other half it's taking over a minute to load. It's awesome you're getting traffic but I'm not sure you can say you've successfully scaled your app right at the moment.
I build stuff with React but never tried with Meteor. But I looked at it, and if you watch the introduction video where he creates something and deploy in like 2 minutes you would go wow as well. It's definitely the most exciting "new" thing I've seen along with React.
Rapid prototyping is an easy win. The real question is how a framework holds up in production. A lot of gripe from long time users of AngularJS comes from Angular's problems in real-world production scenarios (e.g. large amount of data means two-way binding kills performance but two-way binding is what makes the prototypes so compelling; third party directives make it easy to do all kinds of things but writing your own directives can be difficult and disillusioning; etc).
Basically, the important question to ask when being dazzled by impressively easy deployment demos is: is this representative of what my experience will be like developing a real-world medium to large scale production app?
So far my impression of Meteor has been that it's only achieving that "simplicity" by completely ignoring problems like initial page load. Delivering a placeholder on initial page load is an anti-pattern, especially for a technology pretending it's the only "truly isomorphic" technology out there.
Basically, the important question to ask when being dazzled by impressively easy deployment demos is: is this representative of what my experience will be like developing a real-world medium to large scale production app?
So far my impression of Meteor has been that it's only achieving that "simplicity" by completely ignoring problems like initial page load. Delivering a placeholder on initial page load is an anti-pattern, especially for a technology pretending it's the only "truly isomorphic" technology out there.
> The real question is how a framework holds up in production
You're completely right, and that's why I'm also very skeptical about this framework. I'll see how it holds up in a year or two before using it.
You're completely right, and that's why I'm also very skeptical about this framework. I'll see how it holds up in a year or two before using it.
libscore ranks js library usage by crawling sites:
Meteor = 86 sites
http://libscore.com/#Meteor
React = 552 sites
http://libscore.com/#React
angular = 6,882 Sites
http://libscore.com/#angular
backbone = 9,853 Sites
http://libscore.com/#Backbone
Meteor = 86 sites
http://libscore.com/#Meteor
React = 552 sites
http://libscore.com/#React
angular = 6,882 Sites
http://libscore.com/#angular
backbone = 9,853 Sites
http://libscore.com/#Backbone
That's pretty damning for Meteor. I'd have ranked it similarly to React with the difference being that Meteor more actively markets itself and React is mostly being promoted by third parties.
Interesting to see this implemented as a mixin when they just announced yesterday they are fully supporting es6. Looking forward to building some side projects with this and seeing how it compares to using react + flux.
Hi, I wrote this blog post.
We were trying to keep our API surface area small with one way to load data into components, but you're right -- we should probably /also/ add a ES6 base class as a second option, and let the people choose which they prefer.
A lot of React developers still prefer mixins -- react-router recently switched from mixins to ES6 classes and then changed their mind "until ES6 classes have better answers to replace what mixins do (like decorators).": https://github.com/rackt/react-router/blob/master/UPGRADE_GU...
We were trying to keep our API surface area small with one way to load data into components, but you're right -- we should probably /also/ add a ES6 base class as a second option, and let the people choose which they prefer.
A lot of React developers still prefer mixins -- react-router recently switched from mixins to ES6 classes and then changed their mind "until ES6 classes have better answers to replace what mixins do (like decorators).": https://github.com/rackt/react-router/blob/master/UPGRADE_GU...
> we should probably /also/ add a ES6 base class as a second option, and let the people choose which they prefer.
Please provide a higher-order component or ES7 decorator (assuming ES7 will be supported?), would rather not use inheritance.
Please provide a higher-order component or ES7 decorator (assuming ES7 will be supported?), would rather not use inheritance.
^ this. Id much rather use a decorator with ES7 then extending out classes. Although, i thought i heard that react is working on making some better alternative to mixins
That is very disappointing. Decorators already exist in Babel and they work perfectly. I don't know what they're waiting for
I suspect they're waiting for the proposal to be more stable for the official integration. This seems like a great opportunity for the community to write a decorator and let a convention form before it gets merged into the core framework
[deleted]
There's a more detailed discussion about mixins vs. other data loading methods on this GitHub issue: https://github.com/meteor/react-packages/issues/25#issuecomm...
The community is pretty divided and es6 classes are fairly controversial. Don't be too surprised to see a lot of people avoid them. On purpose. And it's not because they aren't familiar with OOP.
[deleted]
That may be the case with the node community, however AFAICT the React community seems much more open to fully utilizing ES6
Its the javascript community as a whole that is divided, generally between imperative/OOP and functional devs. Has nothing to do with Node or otherwise.
Even if you like classical inheritance, the Class keyword is poorly implemented for it, from both a normal OOP language's point of view OR from a prototypal inheritance point of view. It's bad at both.
Even if you like classical inheritance, the Class keyword is poorly implemented for it, from both a normal OOP language's point of view OR from a prototypal inheritance point of view. It's bad at both.
Classes are fine if you understand they're just syntactic sugar for the already extremely widespread constructor+prototype pattern.
The primary reason a significant part of the community hates the ES6 classes is that the class keyword is misleading for people who don't understand prototypal inheritance.
The OOP vs FP divide is orthogonal to that as the FP devs in question generally disagree with the constructor+prototype pattern to begin with (and often shun prototypal inheritance entirely).
There's also the people who want JS to be more like Haskell/Lisp, but they've mostly moved to LiveScript and ClojureScript and only occasionally complain from the sidelines.
The primary reason a significant part of the community hates the ES6 classes is that the class keyword is misleading for people who don't understand prototypal inheritance.
The OOP vs FP divide is orthogonal to that as the FP devs in question generally disagree with the constructor+prototype pattern to begin with (and often shun prototypal inheritance entirely).
There's also the people who want JS to be more like Haskell/Lisp, but they've mostly moved to LiveScript and ClojureScript and only occasionally complain from the sidelines.
> There's also the people who want JS to be more like Haskell/Lisp, but they've mostly moved to LiveScript and ClojureScript
You forgot about Purescript:
http://purescript.org/
You forgot about Purescript:
http://purescript.org/
What exactly is bad about ES6's `class` from a classical inheritance point of view?
I've been creating an application with Meteor and React* and it has been pretty easy thus far. Although I'm not using the official Meteor-React package, it does a lot of the same things that the official package does. The unofficial package also uses a mixin to use with React classes.
*edit: Meant to say React instead of flux
*edit: Meant to say React instead of flux
I would love to see this. I really love flux and want to get flux into it, not just react. If it's open source, I'd really appreciate a github link :D.
What advantages does a meteor+react setup have vs pouchdb+react (synced to couch in backend)?
I would think, with meteor you get the backend rendering (for SEO), and with pouch you get a DB API on the fronted that's available offline.
I would say that the paradigms are a bit different between meteor+react and pouchdb+react. I can't say I am expert in either. I have never used pouchdb, but I am well versed in meteor.
If I understand correctly pouchdb is an in browser implementation of couchdb and some api's which allow the pouchdb to synchronize with a remote, server side couchdb. It is lightweight, allows for easy set up and integration, and really focuses on the database side of things.
Meteor has this same sort of functionality and one could easily say that Meteor and pouchdb could serve nearly the exact same purpose, with the key difference being that Meteor uses mongo as opposed to pouchdb's couchdb. However, Meteor is aiming to be more than an in browser database with remote server synchronization. It also has a robust server side api with many other built in tools and features. I guess I could list out some of them, but I would suggest instead that docs.meteor.com would do a better job at this (I am not trying to say read the docs, I am just saying, they are well laid out and will be more helpful than me!).
I guess I would say pouchdb is a minimalist solution for those who want to synchronize data from client to server and have an offline solution available. Meteor is a complete, and somewhat picky, client/server framework. Their functionality may intersect in some small areas but they both serve very different functional purposes.
If I understand correctly pouchdb is an in browser implementation of couchdb and some api's which allow the pouchdb to synchronize with a remote, server side couchdb. It is lightweight, allows for easy set up and integration, and really focuses on the database side of things.
Meteor has this same sort of functionality and one could easily say that Meteor and pouchdb could serve nearly the exact same purpose, with the key difference being that Meteor uses mongo as opposed to pouchdb's couchdb. However, Meteor is aiming to be more than an in browser database with remote server synchronization. It also has a robust server side api with many other built in tools and features. I guess I could list out some of them, but I would suggest instead that docs.meteor.com would do a better job at this (I am not trying to say read the docs, I am just saying, they are well laid out and will be more helpful than me!).
I guess I would say pouchdb is a minimalist solution for those who want to synchronize data from client to server and have an offline solution available. Meteor is a complete, and somewhat picky, client/server framework. Their functionality may intersect in some small areas but they both serve very different functional purposes.
Thanks for your thorough response!
I've been following meteor, and there's so much convenience. And it looks like, with GroundDB you can take meteor apps fully offline.
However, PouchDB have been making some serious progress to support complex offline apps with a lot of data, like full support for secondary map/reduce indexes.
However, PouchDB have been making some serious progress to support complex offline apps with a lot of data, like full support for secondary map/reduce indexes.
Meteor's story for backend rendering is the spiderable package, which works as follows: "When a spider requests an HTML snapshot of a page the Meteor server runs the client half of the application inside phantomjs, a headless browser, and returns the full HTML generated by the client code."
That's not really a good solution for all the obvious reasons. (Speed, resource usage, dependencies.) Plus, by that logic every client-side webapp supports being rendered on the server, so that's not even a meteor-specific advantage.
Conversely, React actually does supports true universal (aka isomorphic) apps; you can pre-render the app on the server using node (without needing a headless browser), ship it to the client, and rehydrate it. (Ember is working on shipping the same functionality under the name FastBoot.) Meteor doesn't have anything like that.
I'm sure meteor+react has some advantages over pouchdb+react, but it's not because of server side rendering. :)
(Well, as far as I know. I haven't been paying much attention to Meteor development, so it's possible the story has changed in the last few months. But last I checked, true server-side rendering was easy with react, but not really possible with meteor.)
That's not really a good solution for all the obvious reasons. (Speed, resource usage, dependencies.) Plus, by that logic every client-side webapp supports being rendered on the server, so that's not even a meteor-specific advantage.
Conversely, React actually does supports true universal (aka isomorphic) apps; you can pre-render the app on the server using node (without needing a headless browser), ship it to the client, and rehydrate it. (Ember is working on shipping the same functionality under the name FastBoot.) Meteor doesn't have anything like that.
I'm sure meteor+react has some advantages over pouchdb+react, but it's not because of server side rendering. :)
(Well, as far as I know. I haven't been paying much attention to Meteor development, so it's possible the story has changed in the last few months. But last I checked, true server-side rendering was easy with react, but not really possible with meteor.)
React integration should make implementing good server-side rendering much easier. There is already a discussion and community project around this: https://github.com/meteor/react-packages/issues/15
That's good to hear!
Thanks, I had no idea React was building this out.
So in node, you can use the pouchdb API to connect to a full couchdb, allowing you to use the exact same code on the frontend and backend.
Going to try this on my next project!
Will Meteor work with React Native? I'd guess so, since React Native implements XHR and other non-DOm APIs one might expect to find in a browser.
They alluded to it here: http://info.meteor.com/blog/whats-coming-in-meteor-12-and-be...
>"Mobile advances. There are many exciting possibilities in the mobile build toolchain, from new technologies like React Native to a wide range of tooling opportunities relating to cross-platform building and debugging.
With your help, we'll have more to say about these over the coming months."
>"Mobile advances. There are many exciting possibilities in the mobile build toolchain, from new technologies like React Native to a wide range of tooling opportunities relating to cross-platform building and debugging.
With your help, we'll have more to say about these over the coming months."
I made a toy project once shortly after meteor had just been released. I just kept bricking myself that I'd overlook some security setting that would allow people to run arbitrary queries against my DB. When I also looked into scaling I gave up.
Now with the way things have gone with an emphasis on mobile, most sites I'd want to make would be better written as REST-style app servers with pluggable clients.
Now with the way things have gone with an emphasis on mobile, most sites I'd want to make would be better written as REST-style app servers with pluggable clients.
Firstly, your concern about security is completely unfounded; Meteor only allows you to run queries against the database if you write specific ALLOW/DENY rules to let them through. Otherwise, all DB calls go through Meteor methods that are run both on the client (for optimistic updates) and on the server (in a controlled environment). So you let through whatever you choose to let through.
Secondly, Meteor has several modules that allow you to expose Meteor methods as a REST frontend, so it's a trivial change to get that functionality added in.
Secondly, Meteor has several modules that allow you to expose Meteor methods as a REST frontend, so it's a trivial change to get that functionality added in.
I would like to see this with es6 components
You mean web components? I'm not sure it's possible to pass in anything other then strings as values via their attribute changed callback. They simply aren't as well designed and powerful as React components.
By ES6 components OP likely means React components defined using the ES2015 (aka ES6) "class" syntax. The most notable difference is that they don't support mixins, which Meteor seems to take for granted.
Extremely bold words as usual. I don't think I've ever seen any JS technology that manufactures as much hype as Meteor. Every single article from Meteor makes it sound like the best thing since sliced Jesus.
Are there any reliable numbers on Meteor adoption (and retention)? If you listen to people using Meteor it's already more popular than jQuery but everybody else seems apathetic at best. If you go by Stackoverflow numbers (which Meteor shows off on its homepage), it's merely 1/10th as popular as AngularJS (and roughly as popular as express, which never even came close in terms of hype).