Server-side pre-rendering: I do not understand how it currently works with Pux

[cies]

First: thanks for making Pux, it is an amazingly complete and useful piece of machinery.

In the issues I found that server-side rendering should be implemented, but I do not see how that works. Also I think that to do pre-rendering of the kind that I found very useful in React apps, it needs to be able to parse the routes on the server-side, in order to know how to pre-render the right page.

Currently it uses a middleware to catch any routes and serve the index.html, then the actual rendering takes place on the client.

Now if the routing code can be used server-side (possibly combined with a cookie) to pre-render the page that would otherwise get rendered on the client, and serve that instead of the index.html: that would be the useful kind of pre-rendering I've come to like from using React.

I'm not aware of any framework in a strongly typed language that compiles to JS (PureScript/ Elm/ GHCJS) that can do this trick.

The benefits of doing this kind of pre-rendering are:

• SEO optimal (1. still crawlers prefer HTML over having to render the JS; 2. ability to serve faster)
• Serve faster, possibly by implementing (something akin to) proxy caching
• Render the first page faster (no need to: first download an empty HTML page, then download and interpret an JS file, then execute the JS file to update the DOM to contain content, then render the DOM)

[alexmingoia]

With the Pux 8 release, the starter app now has a full isomorphic routing and rendering configuration.

• src/Server.purs starts an express server that routes requests, waits for data to load, and then renders the app HTML.
• src/Client.purs renders the app in the browser, using the state in the HTML response sent by the server.

Check it out and let me know if you have more questions about how it works.

[cies]

Wow and thanks! I'll have a look.