[metaverse]

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.

[trcollinson]

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.

[metaverse]

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.

[Lazare]

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.)

[djmashko2]

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

[Lazare]

That's good to hear!

[metaverse]

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!