[gregjor]

Wouldn't the fastest web site consist of static HTML files? I don't see anything that needs React or any rendering or build step. Writing JS that does nothing more than put HTML in the DOM seems like a Rube Goldberg contraption for a site with static content.

[jdnordy]

Great point. I actually wrote about this as I reflect on building the website. Next.js pre-renders the static files at build time, so JavaScript isn’t building the site on the client side or even on the server side. You get the benefit of writing in React (DRY, modular, and JavaScript focused) over just writing HTML.

[gregjor]

You have to weigh costs when talking about benefits. In the case of a small site with static content, you could write it with no JS code at all. The React code arguably makes it DRY and modular and all that, but unnecessarily. Now it's an order of magnitude more complex, with dependencies and a rendering step that don't need to exist at all.

DRY, modular, etc. are not blanket principles that one must honor at all cost, in every circumstance. They are ways to simplify and organize complex code bases. Not making the code base complex in the first place takes first place, though.

Brian Kernighan wrote "Controlling complexity is the essence of computer programming." The best way to control complexity is to eliminate it, and not introduce it in the first place.

[jdnordy]

The rendering process happens at build time, so the extra step on rendering isn't affecting performance in production (https://nextjs.org/docs/basic-features/pages#static-generati...).

And it allows me to dynamically "fetch" my writings as I add more. I don't have to create a whole new html file. I simply write a markdown file, add it into the repo on github (I use slackedit which syncs directly to the github repo), then the website gets rebuilt with HTML, and then deployed.

Making the code base more maintainable and better suited for my purposes.

On the other hand, I do agree with you. React is a bit heavy weight for a static website. Next.js still ships the whole react bundle in production. So, while time to first paint is the same speed as a simple html, js site, the time to interaction is much slower and the network load higher.

Trade-offs for sure.

[gregjor]

I do something similar to publish my site/blog. I write in Markdown, then push to GitHub, which converts the Markdown to HTML and serves it through GitHub pages. I have my own URL but the site actually runs on GitHub. There's a build step but it's handled automatically in GitHub. I'm just writing Markdown.

https://pages.github.com/

That way I'm just maintaining a repo of Markdown files, though I could write HTML files too.

My site is "lightning fast" except for the cursed Disqus plugin, which I want to remove.

https://typicalprogrammer.com

[jdnordy]

Also, I want to look more into Brian Kernighan. I've heard this quote thrown around quite a bit and I want to do more reading up on him. I always love learning more.

[gregjor]

That quote is from the book Software Tools, kind of hard to find these days but well worth it. Kernighan is most famous as the K of K&R, co-author of The C Programming Language, probably the best book ever written about a programming language. He also co-authored The Elements of Programming Style, also hard to find now but mostly available online.