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

React: Finally, a great server/client web stack

eflorenzano.com

Post reply on HN
Print view View original

121–130 of 134 posts

Re: React: Finally, a great server/client web stack

#121

Post by spullara »

collypops wrote: post #62
spullara wrote: post #42

Earlier quoted context omitted.

Actually, Twitter gave up on it every performing and everything is rendered server-side.

Actually, it gave up on performing _everything_ client-side, and now renders the first page server-side, and then handles subsequent rendering client-side. It found a performant happy medium, which is something I hope React will enable a lot more people to do with a lot less work.

It doesn't. Subsequent requests are also rendered server-side and are passed down as HTML embedded in JSON that is splatted into the DOM. It isn't a lot of work to do this.

Re: React: Finally, a great server/client web stack

#122

Post by hackerboos »

chc wrote: post #58
ForHackernews wrote: post #26

Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something. P…

So, you read an article about how easy server-side rendering is with React, and your first impulse is to rant about client-side rendering? Did you not read the post or did you just feel an overwhelming urge to posture?

>So, you read an article about how easy server-side rendering is with React

The article just says it's easy. It doesn't provide any concrete examples.

I imagine it would be easy in Node to do this but what about Ruby, Python etc.

Re: React: Finally, a great server/client web stack

#123

Post by chc »

hackerboos wrote: post #122
chc wrote: post #58

Earlier quoted context omitted.

So, you read an article about how easy server-side rendering is with React, and your first impulse is to rant about client-side rendering? Did you not read the post or did you just feel an overwhelming urge to posture?

>So, you read an article about how easy server-side rendering is with React The article just says it's easy. It doesn't provide any concrete examples. I imagine it would be easy in Node to do this but what about Ruby, Python etc.

> The article just says it's easy. It doesn't provide any concrete examples.

It doesn't provide code, but it points out that you can render to a string. It is literally that easy — you can just call React.renderComponentToString instead of React.renderComponent, though in practice there are Node libraries that make this even easier.

> I imagine it would be easy in Node to do this but what about Ruby, Python etc.

Well, it's a JavaScript library. If you can run JavaScript, you can render React templates. For example, Instagram is a Django app that runs a Node subprocess to render templates.

Re: React: Finally, a great server/client web stack

#124

Post by SkyMarshal »

ForHackernews wrote: post #26

Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something. P…

Kids these days, not around in the 90s when all web pages were static and every link refreshed the entire page.

There's a happy middle ground between heavyweight javascript SPAs and static pages.

Frankly I love it when I interact with a web page and it doesn't have to reload the whole page just to update a single element, article, etc that I requested.

But neither am I fan of overly heavy frontend JS apps, like how Twitter used to be [1], or Quora seems to be, for example. Especially since I'm a chronic browser tab abuser where JS-heavy pages bring my browser to a halt or make it chug.

So yeah, aim for that sweet spot happy middle ground when possible.

[1]:https://blog.twitter.com/2012/improving-performance-on-twitt...

Re: React: Finally, a great server/client web stack

#125

Post by SkyMarshal »

rubiquity wrote: post #25
jashkenas wrote: post #23

Earlier quoted context omitted.

Yes, and that's a great use case for it. But you can also use your existing Backbone Views (if they have some nice, say, formatting or data-munging-for-display logic in them) and simply replace your render function with React. The next step you can take is replacing your HTML templates with React's JSX templates, if you'd like...

Thanks for replying and for your work on CoffeeScript and Backbone. I might give this a try as I love Backbone's Model layer. I think I like the second approach you suggested better. That might almost turn the Backbone.Views into ViewModels, right? I'm still up in the air on how I feel about the whole JSX thing but I'm willing to give it a try.

Fwiw JSX is totally unnecessary, and more verbose anyway. Using React without JSX feels almost like using HAML or something for your HTML.

Re: React: Finally, a great server/client web stack

#126

Post by SkyMarshal »

taivare wrote: post #67
jbeja wrote: post #53

Earlier quoted context omitted.

Opa should be more popular.

Also, fruitmachine (Github)- Financial Times - Graphics Lab. They say it handles multiple pages better then React. They also claim to have had the React concept first.

Fwiw the Lift web framework has been diffing a server-side virtual DOM back to the client-side DOM via Ajax since 2007. And I wouldn't be surprised if the concept existed elsewhere even before that. Claims to be the first to have had the idea should be taken with a grain of salt.

Re: React: Finally, a great server/client web stack

#127

Post by jbeja »

andybak wrote: post #101
TeeWEE wrote: post #99

I still don't get it that you would like to write in an inferior language such as js on the server side. Cm'on its broken by design. There are a lot of better alternatives. The only reason to use .js on the serverside is that you don't know better.

To a degree I agree with you but I'm downvoting for the trollish and inflammatory way you phrased your comment. However - there are lots of reasons to use javascript on the server even if we accept there are superior languages.

Can you please name some of those reasons?

Re: React: Finally, a great server/client web stack

#128

Post by hamxiaoz »

jbeja wrote: post #52

I am learning how to make desktop apps with Reactjs + Backbone + PouchDB and Brackets-Shell just for fun and learning purposes, so far it has been a very exciting experience.

I'm doing angular.js + node-webkit for my desktop app, not bad. How is your Brackets-Shell experience?

Re: React: Finally, a great server/client web stack

#129

Post by CGamesPlay »

rubiquity wrote: post #19

If you used this with Backbone, could you throw Backbone's entire View object away and use this instead?

That's the typical approach, since React supports composition much more cleanly than Backbone Views do. You can use some mixin like this to handle event listening and updates: https://github.com/CGamesPlay/resistance/blob/master/public/...

Re: React: Finally, a great server/client web stack

#130

Post by dredmorbius »

danabramov wrote: post #105
Iftheshoefits wrote: post #78

Earlier quoted context omitted.

Browsers aren't general purpose applications. They can't fill every application role on the computer. The more "web dev" tries to push them in that direction, the slower, more difficult to develop and maintain, and generally poor they will be, and then the "dynamic web applications" that run on them will suffer.

What do you propose, exactly?

I've just addressed that elsewhere in this thread:

https://news.ycombinator.com/item?id=7120285

Post reply on HN