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

81–90 of 134 posts

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

#81

Post by xtrumanx »

andreypopp wrote: post #15
hamxiaoz wrote: post #5

Any demo? Or I guess it's at the end of the series.

You can see a little demo of React + Express + Browserify + server side rendering + routing with History API — https://github.com/andreypopp/react-app-express

This deserves its own blog post.

You can probably skip explaining client.js (which seems to be stuff one can learn from React's docs) and just dive in to server.js and the npm packages that you wrote that this app uses.

I've been uninterested in React but really like the idea of server-side rendering for js-heavy apps. Besides Rendr, do you know of any other similar libraries/frameworks?

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

#82

Post by sahat »

shebson wrote: post #11
spicyj wrote: post #7

Earlier quoted context omitted.

Various companies (in one famous case, Twitter) have found that server rendering beats client rendering for initial rendering speed. React is designed so that if you care about server rendering, you can have the best of both worlds -- using Node you can render a component to HTML on the server, then pick it up the prepopulated DOM in client-side JS once your page loads. Since the server sends down plain HTML, search…

Exactly this. Serving fully formed html and picking it up by a client-side framework is great for crawlers and also great for performance. In addition to React, you should check out Rendr ( https://github.com/airbnb/rendr ) - it's a really cool library for doing this via server-side rendering of Backbone views.

Downloaded rendr, fired up the first example simple_00, opening links - Users and Repos, was painfully slow. With server MVC frameworks at least there is an indication by the browser that page you clicked on is currently loading. With client-side MVC frameworks pages usually load instantly and data arrives shortly after. In rendr, maybe it's just a terrible example, you wait 2+ seconds for a page to load and there is zero indication that page is loading.

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

#83

Post by plaguuuuuu »

sahat wrote: post #80

I would be interested to know what exactly React solves when we already have so many options - Ember, Angular, Backbone to do the same thing. Why would one want to increase the complexity of the application by introducing "yet another new thing" on an already complex architecture. I am just not sold on React. If someone could show a demo of why should we use React instead of, Backbone.View for example, then we can ta…

I'm just reading about React now, but it seems it might be appropriate when you have a lot of stuff that needs to be reused

Then again, Knockout would also be pretty good at this, so I dunno. There are a lot of criteria for evaluating a framework... development speed, maintainability, simplicity, functionality. And a lot of it is better evaluated experientially rather than theoretically.

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

#84

Post by magicalist »

danenania wrote: post #79
rurounijones wrote: post #73

God I am sick of the passive-agressive "Finally, we have something GOOD! for X" titles that disparage everything that already exists for X. I saw a reddit article yesterday about "Finally a way of doing X that doesn't suck" despite there already being libraries to do X. This casual dismissal and disparaging of existing work is the kind of thing that causes people to give up on stuff (WhytheLuckyStiff for example) It…

You are making the same sort of evidence-less dismissal that you accuse the OP of (whereas the OP actually explains the reasoning behind his assertion). If you want to question the post's premise, at least point to some of these libraries that you believe are on par with react. Personally, I'm not aware of any that have nearly as compelling a model with regard to performance, composability, and minimization of mutabl…

There's no dismissal in the GP's post. They were merely stating that pretending that some project X is an island is off-putting (and it never is one), and that by claiming that it is, you put some readers already familiar with the field in a defensive mood rather than ready to read about something new.

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

#85

Post by TheHydroImpulse »

sahat wrote: post #80

I would be interested to know what exactly React solves when we already have so many options - Ember, Angular, Backbone to do the same thing. Why would one want to increase the complexity of the application by introducing "yet another new thing" on an already complex architecture. I am just not sold on React. If someone could show a demo of why should we use React instead of, Backbone.View for example, then we can ta…

I think you could break it down into several benefits.

1) Performance -- React, with it's Virtual DOM, and the new idea to treat the DOM as an expensive remote rendering pipeline will give you a huge performance boost.

2) Compose-ability & Modularity -- While React only serves as the "view", there's huge potential for really decoupling your application.

3) Library, not framework -- The notion that React is simply a library is awesome. While I'm not a huge fan of the 1000nd super small libraries to make up your app, without any magic or complexity; I enjoy not being locked-in to a particular solution. Especially when new (potential) solutions are being presented regularly. I think modularity will win in the end. If React doesn't serve your needs in 6 months, then you can easily (still involves work, though) switch it out for something better. But, if you use something like Ember.js, you're tied into it's ecosystem and framework.

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

#86

Post by dredmorbius »

sgdesign wrote: post #46
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…

Not all use cases are equal. Static pages might work great for static content, but what about something like GitHub? Wouldn't it be nice to see the issues list refresh live when somebody else closes one?

What are the cases for that feed role?

Why not deliver an RSS/Atom feed with the page and a standard feed reader within HTML that could present the content, polling at specified intervals.

In the same way that HTML finally standardized on HTML5 semantic page markup (not that HTML1.0 was grossly inadequate), and we're finally getting integrated video / multimedia support (though lacking the ever crucial "off" switch), once you dig through all the bullshit and hype, most of Web 2.0 corresponds to "we can update the page you're looking at while you're looking at it".

Some client-side capabilities to sort and filter content would finish off about 90%+ of the use cases. Good enough.

And you'd end up with far fewer monstrosities such as Facebook, Gmail, G+, etc., in which a simple content stream has a client-side footprint of 1-2 GB. SRSLY?

Yes, the standard problem of having users upgrade their client software to support the featureset remains, but there are still huge numbers of what are effectively Web 1.0 sites (Craigslist comes to mind) that are phenomenally useful and successful.

I've had a very late and passionate come-to-Jesus love affair with RSS/Atom feeds. Taking Craigslist, for example I can get an RSS feed of any given category search:

http://www.craigslist.org/about/rss

Remember "Web agents", you know "a personal online assistant that would scour the Internet for you"? Well, this is it.

Combine that feed with rsstail and multitail, and you can track items of interest in a console window. Find something particularly useful? Fire off an email alert to yourself.

http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_...

I've got Chromium running on my Thinkpad T520i, sucking down about a gig and a half of RAM. newsbeuter tailing 85 feeds is around 300 MB (a single Chromium browser tab), and rsstail weighs in at about 145 MB resident. Since they're only intermittently active, they swap out with very little performance overhead.

The existing Web design model is a fucking trainwreck waiting to happen. The browser-as-app-platform metaphor has its advantages, mostly in rapid development, though that's also a weakness (users HATE change), and it's a bastardization of two competing uses (content vs. app).

Much of the design and feature set serves advertisers and NSA water-carriers far more effectively than it does users. Sadly, that's where the funding comes from, so it's no real surprise. Be careful what you incent for, you'll get it.

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

#87

Post by lennel »

swah wrote: post #69
matchu wrote: post #41

Earlier quoted context omitted.

I think the author largely agrees with your beefs, since he's proposing this as a client-side and server-side rendering solution. > I've thought for a long time (and blogged about it previously) that the ideal solution would fully render the markup on the server, deliver it to the client so that it can be shown to the user instantly. Then it would asynchronously load some Javascript that would attach to the rendered…

My understanding is that since React has a virtual DOM, it can just render everything on the server with Node.JS, instead of evaluating it in a browser.

initial rendering should definitely be on the server, his premise to render content on the server side and then async load it in is flawed, he adds latency and the dom still has to parse a string at the end of the day and put them on the display tree, so the only bit he offloaded was a bunch of string concatenation (given he used a sane templating system) at the cost of latency. bad trade off IMO.

the downside to his reasoning is that he is tying himself to a single back end (node) if he used something like mustache he coulkd use any backend, but mustache implies parsing templates on the client. googles closure compiles to javascript functions and I am sure something like that exists for mustache and this would seem very sensical.

Converting a large string to a dom element is not expensive, it is when that dom element is added to the actual display tree when things go a bit awol, this is to be expected, redrawing any GUI costs a lot.

React is an excellent library and I am glad people use it, none of the ideas are radical however.

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

#88

Post by xixixao »

The lack of understanding and amount of hatred against web applications (different from web pages) is both sickening and rejuvenating. It is sad because the article is fairly clear, it describes the future of most computing (since most "human" computing will happen on the web) and it really shouldn't be hard to understand. But I am glad that most of the top commenters here instead focus on hating "webdevs". It means these people will stay on the desktop and won't create clones of desktop applications in the browser (see google docs for a missed opportunity of a better office system). History will show which way things shifted, no need to flame about it here now.

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

#89

Post by peterhunt »

lennel wrote: post #87
swah wrote: post #69

Earlier quoted context omitted.

My understanding is that since React has a virtual DOM, it can just render everything on the server with Node.JS, instead of evaluating it in a browser.

initial rendering should definitely be on the server, his premise to render content on the server side and then async load it in is flawed, he adds latency and the dom still has to parse a string at the end of the day and put them on the display tree, so the only bit he offloaded was a bunch of string concatenation (given he used a sane templating system) at the cost of latency. bad trade off IMO. the downside to his…

The important thing with this technique is you can render before any JS has been downloaded, parsed and executed, which is a huge amount of time relative to HTML parse and paint.

fwiw, React isn't tied to Node: I've used it with Django via PyExecJS (which just uses raw JavaScriptCore).

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

#90

Post by lennel »

peterhunt wrote: post #89
lennel wrote: post #87

Earlier quoted context omitted.

initial rendering should definitely be on the server, his premise to render content on the server side and then async load it in is flawed, he adds latency and the dom still has to parse a string at the end of the day and put them on the display tree, so the only bit he offloaded was a bunch of string concatenation (given he used a sane templating system) at the cost of latency. bad trade off IMO. the downside to his…

The important thing with this technique is you can render before any JS has been downloaded, parsed and executed, which is a huge amount of time relative to HTML parse and paint. fwiw, React isn't tied to Node: I've used it with Django via PyExecJS (which just uses raw JavaScriptCore).

I started with this line: >initial rendering should definitely be on the server

this technique is called pre-rendering, and yes, I am amazed people don't do it.

"PyExecJS (which just uses raw JavaScriptCore)." this seems pretty slow or can you cache the execution function. (aka you don't have to parse the js multiple times)

Our backend is jvm so we decided on closure, with this on startup we compile our templates on the server and then pass the rendering functions around pumping the data into it to render initial pages. At the same time, we compile the same templates into javascript functions which are included into our app via the closure dependency system to render on the client. This has the advantage of not having to parse and "compile" a template at the point of delivery.

This is why I think react is an excellent library, because it allows anybody to do this and brings this notion into the minds of developers who jump easily on bandwagons.

I also think that the react team are well on their way to building a library which would fair excellently under all sorts of static analysis

Post reply on HN