Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Integrating React with Meteor

info.meteor.com

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Integrating React with Meteor

#11

Post by spion »

phoenixmatrix wrote: post #9
pgm8705 wrote: post #2

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.

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.

That may be the case with the node community, however AFAICT the React community seems much more open to fully utilizing ES6

Re: Integrating React with Meteor

#12

Post by phoenixmatrix »

spion wrote: post #11
phoenixmatrix wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Integrating React with Meteor

#13

Post by pspeter3 »

anarchy8 wrote: post #8
avital wrote: post #5

Earlier quoted context omitted.

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 a…

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

Re: Integrating React with Meteor

#14

Post by 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.

Re: Integrating React with Meteor

#15

Post by natrius »

phoenixmatrix wrote: post #12
spion wrote: post #11

Earlier quoted context omitted.

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.

What exactly is bad about ES6's `class` from a classical inheritance point of view?

Re: Integrating React with Meteor

#16

Post by Lazare »

metaverse wrote: post #14

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.

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

Re: Integrating React with Meteor

#17

Post by djmashko2 »

avital wrote: post #5
pgm8705 wrote: post #2

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 a…

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

Re: Integrating React with Meteor

#18

Post by djmashko2 »

Lazare wrote: post #16
metaverse wrote: post #14

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.

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…

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

Re: Integrating React with Meteor

#19

Post by trcollinson »

metaverse wrote: post #14

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.

Post reply on HN