Integrating React with Meteor
info.meteor.com
info.meteor.com
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).
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.
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.
Meteor = 86 sites
React = 552 sites
angular = 6,882 Sites
backbone = 9,853 Sites
*edit: Meant to say React instead of flux
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...
Please provide a higher-order component or ES7 decorator (assuming ES7 will be supported?), would rather not use inheritance.
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.
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.
You forgot about Purescript:
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.)
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.
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.
>"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."
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.
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.