
Show HN: A lightning fast personal website built with Next.js - jdnordy
https://jdnordstrom.com/
======
jdnordy
Job hunting during a global pandemic is not easy. I send out 5 applications a
day with a custom cover letter and hear back on 1 out of 10, usually a
rejection, not even a phone screen. Available, qualified candidates are on the
rise and hiring freezes abound.

But amidst all this craziness, the last thing I wanted to avoid distraction. I
needed a project to continue growing as an engineer and doing what I love--
coding.

I recently spoke with a friend from undergrad, Jared Gorski. We talked about
web development, his work at Liferay, my work on Nautilus (a dev tool that
visualizes Docker Compose instances). He also started sharing with my how he
recently updated his website to improve speed. After our conversation, I
checked it out and was inspired. I had already been thinking about SSR (server
side rendering) and how to leverage it. Thus, the mission to build this
website was born.

I would love any feedback from the Hack News community on the site. Thanks!

------
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...](https://nextjs.org/docs/basic-
features/pages#static-generation-recommended)).

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/](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](https://typicalprogrammer.com)

