3 ms·

I built my personal website with nothing but Express and JS template strings: https://github.com/brundonsmith/website https://github.com/brundonsmith/website. I

by _bxg1 7y ago

I built my personal website with nothing but Express and JS template strings: https://github.com/brundonsmith/website https://github.com/brundonsmith/website. It's so simple to do that I almost question the necessity of "static site generators" in general (Next.js of course does much more than static site generation).

lioeters 7y ago
Interesting approach, how every page is a JS file that builds the HTML page as a string; structurally it looks almost the same as how React/Next.js do it. With that setup, I imagine it's fairly trivial to add a "static site generator": - Run the local server that serves the rendered pages. - Run a Node.js process that will take a given array of all page routes; make HTTP requests to those local URLs; and save the rendered HTML into folders, for a complete static site.
- _bxg1 7y ago
  Yep, that's what it already does :) And a neat property is that I could freely move different render functions between static, request-time, and client-side if I wanted to. People tend to think of React rendering and the like as this special, mysterious process. But the only special thing about it is the way it efficiently reconciles and updates an existing DOM to match a new DOM. That initial render is really no different from PHP. Static site generators are just PHP with a prewarmed cache.
  - genuine_smiles 7y ago
    > I could freely move different render functions between static, request-time, and client-side if I wanted to You can do the same thing with Next.js, and you can move between client-side and static with Gatsby > But the only special thing I think there might be more to unpack here, but when using react being able to typecheck and lint my jsx is pretty sweet. React also makes it much harder to create cross site scripting vulnerabilities.
  - lioeters 7y ago
    Ah, I didn't dig deep enough to see that it already does what I described, heheh. So it's a static site generator as well as a server that dynamically renders. I like the sound of being able to "partially compile", having the choice to leave some routes rendered at request-time or client-side. I heard the analogy (equivalence?) before, that statically rendered sites are caches that are invalidated at build time. Makes sense, and thinking of it as a strategy that can be partially applied - rather than as an all-encompassing framework or tool - is insightful, so it can be mixed and matched with dynamic rendering as needed.
    - styfle 7y ago
      What you described here is basically how Next.js works :) The blog post mentions the 3 APIs that make this possible: - getStaticProps (Static Generation): Fetch data at build-time. - getStaticPaths (Static Generation): Specify dynamic routes to prerender based on data. - getServerSideProps (Server-Side Rendering): Fetch data on each request.

by _bxg1 7y ago

lioeters 7y ago

Interesting approach, how every page is a JS file that builds the HTML page as a string; structurally it looks almost the same as how React/Next.js do it. With that setup, I imagine it's fairly trivial to add a "static site generator": - Run the local server that serves the rendered pages. - Run a Node.js process that will take a given array of all page routes; make HTTP requests to those local URLs; and save the rendered HTML into folders, for a complete static site.

_bxg1 7y ago
Yep, that's what it already does :) And a neat property is that I could freely move different render functions between static, request-time, and client-side if I wanted to. People tend to think of React rendering and the like as this special, mysterious process. But the only special thing about it is the way it efficiently reconciles and updates an existing DOM to match a new DOM. That initial render is really no different from PHP. Static site generators are just PHP with a prewarmed cache.
- genuine_smiles 7y ago
  > I could freely move different render functions between static, request-time, and client-side if I wanted to You can do the same thing with Next.js, and you can move between client-side and static with Gatsby > But the only special thing I think there might be more to unpack here, but when using react being able to typecheck and lint my jsx is pretty sweet. React also makes it much harder to create cross site scripting vulnerabilities.
- lioeters 7y ago
  Ah, I didn't dig deep enough to see that it already does what I described, heheh. So it's a static site generator as well as a server that dynamically renders. I like the sound of being able to "partially compile", having the choice to leave some routes rendered at request-time or client-side. I heard the analogy (equivalence?) before, that statically rendered sites are caches that are invalidated at build time. Makes sense, and thinking of it as a strategy that can be partially applied - rather than as an all-encompassing framework or tool - is insightful, so it can be mixed and matched with dynamic rendering as needed.
  - styfle 7y ago
    What you described here is basically how Next.js works :) The blog post mentions the 3 APIs that make this possible: - getStaticProps (Static Generation): Fetch data at build-time. - getStaticPaths (Static Generation): Specify dynamic routes to prerender based on data. - getServerSideProps (Server-Side Rendering): Fetch data on each request.