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

React Server

react-server.io

Post reply on HN
Print view View original

11–20 of 143 posts

Re: React Server

#11

Post by nostrademons »

gigabo wrote: post #8
bsimpson wrote: post #3

I'd really love to see a demo of what they mean by "seamless transitions."

The website itself is meant to serve as a demo. :) When you land on the site the first page is rendered by the server. Then the client controller wakes up and subsequent page views ask the server for data, but render in the browser. That's what we mean by "seamless transitions".

"seamless transitions" in the web design world is often taken to mean "transitions" in the sense of CSS animations, i.e. instead of hard page refreshes elements smoothly morph into their positions in the next page state. See eg. Google's Material Design or Apple's iPhone UI. This is a big, largely-unsolved problem in HTML5, at least in making them pervasive, performant on mobile, and easy for developers. Advertising this may lead to some unwarranted excitement and subsequent disappointment, since the website doesn't really have transitions at all of this sort.

Re: React Server

#12

Post by gigabo »

pault wrote: post #5

This is interesting, especially since I just spent the last two weeks setting up a boilerplate for a universal react/redux SPA on spec for a new client. I enjoy the flexibility but the need to develop a deep working knowledge of several independent libraries, transpilers, and build tool configuration files (each of which has several competing options with their own way of doing things) just to get to hello world is c…

For routing of URL paths to "page" objects we use Yahoo's `routr`.

We've tried to keep data store selection out of React Server core. There are so many good options in the React ecosystem that picking one seems limiting.

The data bindings that the framework cares about are at the http request level. We have a wrapper around `superagent` that manages transfer of response data from the server to the browser. So, when the client controller wakes up in the browser and tries to make the same requests that the server just made while _it_ was rendering the page, the data is already present and the requests are short-circuited.

Re: React Server

#14

Post by AShedOfTools »

krebby wrote: post #2

This looks cool. Any way to make it easily work with Relay?

This is something that we're thinking about (https://github.com/redfin/react-server/issues/190), but that we just don't have an answer for right now. React Server was built with running two servers in mind, one for your api and React Server as your front-end. I haven't used Relay much, but I think you could run your Relay server as the api server, then make the request from React Server with ReactServerAgent and it should work?

Re: React Server

#15

Post by gigabo »

nostrademons wrote: post #11
gigabo wrote: post #8

Earlier quoted context omitted.

The website itself is meant to serve as a demo. :) When you land on the site the first page is rendered by the server. Then the client controller wakes up and subsequent page views ask the server for data, but render in the browser. That's what we mean by "seamless transitions".

"seamless transitions" in the web design world is often taken to mean "transitions" in the sense of CSS animations, i.e. instead of hard page refreshes elements smoothly morph into their positions in the next page state. See eg. Google's Material Design or Apple's iPhone UI. This is a big, largely-unsolved problem in HTML5, at least in making them pervasive, performant on mobile, and easy for developers. Advertising…

Oh, hadn't considered that interpretation. Our full project description on GitHub is "React framework with server render for blazing fast page load and seamless transitions between pages in the browser". The tag line on the website is shortened from that. I think the full version is a little less ambiguous, but it's a little too wordy in the context of the site.

Will have to think about a better tag line... Thanks!

Re: React Server

#16

Post by serg_chernata »

gigabo wrote: post #7
serg_chernata wrote: post #4

Earlier quoted context omitted.

I was thinking the same thing and this website doesn't seem to be powered by such technology either.

Actually, the website _is_ powered by React Server! :) We wanted the project website to serve as a demonstration as well as a source for documentation.

nostrademons' description is exactly what I expected as well, thanks for clarifying

Re: React Server

#17

Post by pault »

gigabo wrote: post #12
pault wrote: post #5

This is interesting, especially since I just spent the last two weeks setting up a boilerplate for a universal react/redux SPA on spec for a new client. I enjoy the flexibility but the need to develop a deep working knowledge of several independent libraries, transpilers, and build tool configuration files (each of which has several competing options with their own way of doing things) just to get to hello world is c…

For routing of URL paths to "page" objects we use Yahoo's `routr`. We've tried to keep data store selection out of React Server core. There are so many good options in the React ecosystem that picking one seems limiting. The data bindings that the framework cares about are at the http request level. We have a wrapper around `superagent` that manages transfer of response data from the server to the browser. So, when t…

So I can keep using my preferred redux middleware? That is definitely worth checking out.

Re: React Server

#18

Post by pault »

nostrademons wrote: post #11
gigabo wrote: post #8

Earlier quoted context omitted.

The website itself is meant to serve as a demo. :) When you land on the site the first page is rendered by the server. Then the client controller wakes up and subsequent page views ask the server for data, but render in the browser. That's what we mean by "seamless transitions".

"seamless transitions" in the web design world is often taken to mean "transitions" in the sense of CSS animations, i.e. instead of hard page refreshes elements smoothly morph into their positions in the next page state. See eg. Google's Material Design or Apple's iPhone UI. This is a big, largely-unsolved problem in HTML5, at least in making them pervasive, performant on mobile, and easy for developers. Advertising…

I think "seamless transition from server to client" is probably less confusing. It's also typically referred to as "hydration" in SPA jargon.
Post reply on HN