Blogging on Next.js: Generating static index pages | Hacker News Reader

Blogging on Next.js: Generating static index pages

javacrisps.com

25 pointsstopachka23 comments

Personally, I don't get why people chose Vue, React, Next etc... for their blog. Maybe it makes sense for comments but I write all of my posts in markdown and run it through jekyl. I don't support comments, because I post it on places like Facebook, Hacker News, Dev.to where comments already exist on that platform. Why reinvent the wheel? Furthermore, generating a statically loaded HTML site that references 1 style sheet, a couple of images makes the site infinitely faster to load and cache for future visits.

> Why reinvent the wheel?

Because sometimes it's fun, and when you're doing it for personal projects it's up to you what route you want to go down. Wordpress or Ghost would be valid choices, too.

I imagine there are people out there who would find it easier to get a Next / React blog setup than to work with Jekyll, because they're familiar with JS and have never heard of or touched Ruby.

> because they're familiar with JS and have never heard of or touched Ruby

I used Jekyll on a couple of project and never had to touch Ruby, but Eleventy is a better option for JS devs.

Has the 11ty community gotten better at tutorials and adoption materials? One of the reasons why I went with gatsby is that there are many blogs about how to add tags to your site, i18n, etc?

One of the issues I had with 11ty in the past was that it was hard to get started. At least with gatsby they provide a guided experience with a bunch of community content to get you through.

Not sure about now, I haven't messed with it in almost a year.

In general I found it straightforward but I had a couple of headscratching moments and the docs weren't super helpful.

I enjoy Jekyll, and run about 6 live websites with it.

But lately I’ve been using Gatsby/React, first out of curiosity, but now because it’s much quicker for me to develop.

Jekyll’s partials are nice to use but can become hard to read when there are too many variations, or if there are things to be calculated per instance. The Liquid template engine is quite limited.

Also, I absolutely love React’s CSS Modules, which solves the namespacing of Jekyll’s partials.

And in general I find working with React components much easier.

I still use Jekyll for tiny projects [1], but go the Gatsby way for more complex stuff.

[1] https://f1standings.com/

Love your F1 site! Making it my home page.

Why use React for a blog where 99% of the content is static?

React is amazing at composition. Compared to most other things I tried. Next.js lets you render into static assets with super fast in-page transitions (out of the box).

And if you want to add more complex behavior, it's easy to transition it on per page basis. i.e. I want to lock some pages (courses) only to GitHub sponsors.

This is a bit 'harder' to do than alternatives like Hugo, Eleventy etc. (in my opinion)

Oh and for blog part, if you want to do some fancy things like mdx, React/Next is nice as there is a template you can use for it https://github.com/hashicorp/next-mdx-enhanced

Otherwise, you'd have to create something of your own.

I do see your point about composition.

Using partials is nowhere near as nice as using real components.

I'm working on a Node SSR project and after trying a couple of templating engines I ended up using Svelte components in SSR mode.

Makes it easy to build a CMS into your static website and edit it from production. My personal site is Next.js + TinaCMS and all the content is stored in the GitHub repository

https://tinacms.org/guides/nextjs/github/initial-setup/

Is that the same approach as Netlify CMS?

How does it handle authentication? Is there a backend somewhere?

What I wonder is why static, I come from blogging with dos blog( untile godaddy broke it). And while I never understood the use of plugins like silverlight or adobe I don't really see the harm in using a native js framework to pull the artical contents from the server and update the DOM over pulling and retemplatizing the whole html page. Am I missing something or is static more of a mind set gained from dealing with sites that need to draw the first render faster and handle larger scale in a day then my little old blog will see in a life time?

The point of using a SSG and deploying to a static host is that hosting becomes extremely simple. No need for a database, HTTPS included, deploying is just copying files, CDN is already included, and it's either free or very cheap.

If you're ok with editing code files (markdown, html, etc) this is extremely simple to setup. You can even get a template somewhere[1] and just start producing content. Obviously this is only feasible for devs or maybe designers with HTML/CSS skills.

I'd like to add that SSGs can also render dynamic data from an API or directly from a DB at build time.

[1] https://jekyllthemes.io/

That site is still static. Static doesn't mean there's no dynamic content but rather that no new files are sent from the server, including new JS files. If you ship the entire JS framework on page load, then the page is still static.

You can have a static SPA with code splitting though.

Yeah I agree, what do you mean by "though"?

Well, you said:

> no new files are sent from the server

But you can have 'static' with code splitting and send new files from the server on each route change.

Well it's more like, if there's a file bundle, it can be served, but no new files will be generated by the server and sent. The code split files already exist on the server, they're not generated anew so yeah it's still static.

there's people here running doom on a pregnancy test, and you're surprised people want to run a blog on React?

As much of running it on a pregnancy test as nikola's valuation.

https://twitter.com/Foone/status/1302453246536028160

I can’t put my finger on it, but something feels odd to me about these React based or similar static site generators that don’t depend entirely on server side rendering (though that seems to be an option). Perhaps a fraction of a percentage of web users block JavaScript by default. What would their experience be on such sites? Do these non-SSR frameworks handle accessibility well? I’d appreciate it if someone could do a comparison on how these frameworks do compared to the ones that are typically server side rendering only.

I've only got experience with Next.js, but I think it's less on the framework and more on the developer to design a site that degrades gracefully.

The framework's job is to upgrade gracefully - e.g. to facilitate building runtime functionality that meshes well with the statically rendered output.

Next.js and its fellows let you statically render anything you want. It can be a fully static output if you like.

The benefit of building it all out of React components is that there's no integration or binding that has to be done between the "static" elements of the page and the dynamic ones. They're one and the same, the only difference is the first render happens at build time.

A Next.js page that degrades gracefully is just one that's useful even if it only renders once.

Reply on news.ycombinator.com