4 ms·

Cool stuff! In a somewhat similar vein, I've been working on a static site generator (like Jekyll) that uses React/Redux instead of a templating system: https:

Cool stuff! In a somewhat similar vein, I've been working on a static site generator (like Jekyll) that uses React/Redux instead of a templating system: https://github.com/thomasboyt/peridot https://github.com/thomasboyt/peridot It actually is very similar to any other isomorphic React app, except instead of hosting an API, it simply renders each page out to a file, as well as a JSON version of each post that acts as the "API" used to retrieve further pages from the frontend app. There's an example site here: http://loudplaces.disco.zone/ http://loudplaces.disco.zone/

daveidol 11y ago
Thanks for this! Very cool idea. I haven't looked closely enough - do you pre-render the pages somehow to maintain SEO?
- avolcano 11y ago
  Yep! It's a bit convoluted at the moment, and I should comment it better, but it basically just does the following: 1. Get a list of all posts and compute their URLs 2. Run each URL against the React app's react-router table (https://github.com/thomasboyt/peridot/blob/master/src/pagesBuilder/render/renderRoute.js https://github.com/thomasboyt/peridot/blob/master/src/pagesB...). This gets the static markup for each route. 3. Wrap this static markup in a <Page /> container (which has e.g. <script> and <link> tags for assets), and write the resulting output to an HTML file. That HTML file is what you initially load. It then loads a Webpack bundle of the same React app, and once that's loaded, React on the front-end "re-renders" into the already-rendered React app container (though it doesn't actually re-render the DOM, as it's able to diff against the existing DOM nodes). There's some more nuance to this - for example, the server-side rendering also passes in a Redux store with the state needed for rendering the page (e.g. the contents of a post), as well as embedding the JSON-serialized state in a <script /> tag so when the front-end code takes over, it can just load the embedded state. Honestly, though, the isomorphic rendering only took a few hours to implement, and most of that was me figuring out how to use Redux (previously, I'd used other Flux implementations that had somewhat different concepts). The biggest takeaway I've gotten from this project is that React isomorphic rendering is way easier than I thought.
snake_case 11y ago
I'm also working on a React + Markdown static site generator heavily inspired by Jekyll. For the past few weeks, I've been experimenting with how I could render both React + Markdown into HTML and minimize the numerous edge cases that occur during the build process. For example, ReactDOMServer.renderToStaticMarkup(page) will remove all line breaks in the HTML output. The problem with that is pre/code elements will have their line breaks removed as well which for obvious reasons is not good. Oh and another problem, it converts all (or most, if I remember correctly) HTML entities to their literals.. so those code blocks may look pretty messed up in the browser. But after weeks of experimenting with different rendering/build processes and libraries, things have finally been coming together recently. Unfortunately, my private repo is a mess due to all the tests and methods I've tried. I'm going to be releasing a clean public repo of the project soon after I develop a landing github.io page for it. That will also be open source and serve as a great example for how to use the generator. However, I did rewrite my live website from Jekyll to my generator (need to come up with a good name still..) this past week. http://jakedeichert.com http://jakedeichert.com Regarding build times on my $5 DigitalOcean droplet, my website is built in ~3.7s with Jekyll and ~9.5s with my generator. I still have many ways to improve performance and I haven't tested NODE_ENV production mode yet which the React team says should be much faster due to no warnings/error checking. Though, most of that build time is due to Babel converting my ES6+JSX components into actual JS that Node can execute. I'll be focusing on lowering this build time for the next week or two probably.
- bjt 11y ago
  Very cool project. But two weeks to shave off 6 seconds of build time? I gotta wonder: https://xkcd.com/1205/ https://xkcd.com/1205/
  - dchuk 11y ago
    Not that it really matters, but his system added 6s of build time, not shaved it off
  - snake_case 11y ago
    I'm hoping to drop the 9.5s to more like 4-5s. I don't think it can reach the speed of Jekyll since Babel is heavily used to convert the jsx to js at the start of the generation. If everyone wrote pure js React code, then the babel step would essentially be eliminated which should definitely be a config option. Dropping at least a second or two should be easy. My code is a beautiful mess right now, and I know there's so many parts I can improve, let alone also using the production version of React instead of the warning/error checking version. Also, when I say 2 weeks, I actually meant more like 40 hours over the course of 2 weeks. It's a side project :)

daveidol 11y ago

Thanks for this! Very cool idea. I haven't looked closely enough - do you pre-render the pages somehow to maintain SEO?

avolcano 11y ago
Yep! It's a bit convoluted at the moment, and I should comment it better, but it basically just does the following: 1. Get a list of all posts and compute their URLs 2. Run each URL against the React app's react-router table (https://github.com/thomasboyt/peridot/blob/master/src/pagesBuilder/render/renderRoute.js https://github.com/thomasboyt/peridot/blob/master/src/pagesB...). This gets the static markup for each route. 3. Wrap this static markup in a <Page /> container (which has e.g. <script> and <link> tags for assets), and write the resulting output to an HTML file. That HTML file is what you initially load. It then loads a Webpack bundle of the same React app, and once that's loaded, React on the front-end "re-renders" into the already-rendered React app container (though it doesn't actually re-render the DOM, as it's able to diff against the existing DOM nodes). There's some more nuance to this - for example, the server-side rendering also passes in a Redux store with the state needed for rendering the page (e.g. the contents of a post), as well as embedding the JSON-serialized state in a <script /> tag so when the front-end code takes over, it can just load the embedded state. Honestly, though, the isomorphic rendering only took a few hours to implement, and most of that was me figuring out how to use Redux (previously, I'd used other Flux implementations that had somewhat different concepts). The biggest takeaway I've gotten from this project is that React isomorphic rendering is way easier than I thought.

snake_case 11y ago

I'm also working on a React + Markdown static site generator heavily inspired by Jekyll. For the past few weeks, I've been experimenting with how I could render both React + Markdown into HTML and minimize the numerous edge cases that occur during the build process. For example, ReactDOMServer.renderToStaticMarkup(page) will remove all line breaks in the HTML output. The problem with that is pre/code elements will have their line breaks removed as well which for obvious reasons is not good. Oh and another problem, it converts all (or most, if I remember correctly) HTML entities to their literals.. so those code blocks may look pretty messed up in the browser. But after weeks of experimenting with different rendering/build processes and libraries, things have finally been coming together recently. Unfortunately, my private repo is a mess due to all the tests and methods I've tried. I'm going to be releasing a clean public repo of the project soon after I develop a landing github.io page for it. That will also be open source and serve as a great example for how to use the generator. However, I did rewrite my live website from Jekyll to my generator (need to come up with a good name still..) this past week. http://jakedeichert.com http://jakedeichert.com Regarding build times on my $5 DigitalOcean droplet, my website is built in ~3.7s with Jekyll and ~9.5s with my generator. I still have many ways to improve performance and I haven't tested NODE_ENV production mode yet which the React team says should be much faster due to no warnings/error checking. Though, most of that build time is due to Babel converting my ES6+JSX components into actual JS that Node can execute. I'll be focusing on lowering this build time for the next week or two probably.

bjt 11y ago
Very cool project. But two weeks to shave off 6 seconds of build time? I gotta wonder: https://xkcd.com/1205/ https://xkcd.com/1205/
- dchuk 11y ago
  Not that it really matters, but his system added 6s of build time, not shaved it off
- snake_case 11y ago
  I'm hoping to drop the 9.5s to more like 4-5s. I don't think it can reach the speed of Jekyll since Babel is heavily used to convert the jsx to js at the start of the generation. If everyone wrote pure js React code, then the babel step would essentially be eliminated which should definitely be a config option. Dropping at least a second or two should be easy. My code is a beautiful mess right now, and I know there's so many parts I can improve, let alone also using the production version of React instead of the warning/error checking version. Also, when I say 2 weeks, I actually meant more like 40 hours over the course of 2 weeks. It's a side project :)