Hacker News Reader

Comment by matchu | Hacker News Reader

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 markup, and invisibly promote the page into a full app that can render its own markup.

That is, everything is rendered server-side for the reasons you outline, but that rendering logic also lives on the client should something need to update. This post doesn't detail exactly how to do all that, but it sounds like it's scheduled as a future topic.

View on HN

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.

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

PyExecJS is slow :)

We are actively working on more static analysis tools for React: it's certainly one of our major priorities.

i assume you work on the team at FB. Are you considering writing jsx compilers for platforms like the jvm?

Our approach is going to make js interop performant with our stack (which is not jvm). We don't have a concrete plan at this time. You would need more than jsx to make this work through (jsx is just sugar)

I suppose Rhino can also be used? :)

we use rhino for some types of testing. brutally slow.

Reply on news.ycombinator.com