[PaulJulius]

I really think the negativity in the comments here is overblown, and misdirected.

The author has a totally reasonable set of requirements: React + TypeScript, writing posts in Markdown, small amounts of interactability, and static site generation. It may be an indictment of the JavaScript ecosystem and the current state of the web that nothing exists that can help the user accomplish this out of the box, but that doesn't diminish the validity of the author's requirements. (It's also possible that next.js, Gatsby, or another framework can actually support these with relatively little configuration.) But we should applaud the user for wanting to create a totally statically generated site! (I noted that Gatsby's homepage was not static generated and clearly takes a second before displaying content.)

Given that the author wants to render to static HTML, I interpret React + TypeScript to primarily mean JSX + TypeScript. Is this really any different than saying Liquid + Ruby, or Go templates + Go (used by Jekyll and Hugo respectively)? JSX and React's component based system were literally designed for HTML, and I'd argue it is definitively a better solution than the raw template libraries offered by other languages. You get automatic "syntax"-checking of the HTML by using JSX. By using JavaScript you have proper control flow instead of the awkward in-line conditionals and loops in templating libraries. A Component-based system makes code-reuse significantly easier. And by using TypeScript you can get type-checking for all of this. Unfortunately, using JSX and TypeScript means that you need some sort of build pipeline, and that's where the current state of JavaScript really rears its ugly head and adds a lot of complexity.

Writing posts in Markdown is also totally reasonable, as is wanting to support small amounts of interactability in future posts. A couple of comments mention that you could just add raw HTML to a Markdown file and call React from there, but that doesn't solve the compilation problem. A lot of comments also missed the desire for interactivity. It's for a developer blog! I'd love an interactive inline demo or explanation!

The blog title might have been a little overstated (the ideal tech stack), and the "zero memory of how we used to build forms in the pre-React times" isn't a great look, but I do think the actual content is solid.

[metalforever]

This is so ridiculous coming from someone that did front end during the pre SPA days. I don’t event know where to start here . It’s a blog, not a complicated backend solution requiring a stack like this. Just throw in something simple to get the posts from the database and update the dates and you’re done . It’s over engineered and symptomatic of major issues in the front end community.

[bilalq]

I'd recommend not being so quick to dismiss the author. Your suggested alternative is actually way more complex. The approach described sets up a static site generator that allows for deployment to a static asset webhost (like S3/CloudFront). What this means are that there is no server to administrate or manage. Aside from the cost and performance advantages, this drastically simplifies the operational overhead. There's nothing to patch, no networking to configure, nothing. Just upload and be done. Moreover, there's no database at all either. No need to manage database credentials, no need to pay the costs to keep a database running, no need to patch a database server, etc...

This is the total opposite of overengineering. The stack the author is running is way simpler than one where you have to spin up a webserver, database, caching solution, etc...

[stevens32]

Having a database for a personal blog seems like overkill.

[outworlder]

Not if your "database" is something like SQLite. That is preferable to most alternatives, if you actually want to manipulate data.

If the blog is not much more than a .PLAN file, sure is overkill. But having access to a DB and programming language opens up a few possibilities – and cleaner code compared to hacking some bash scripts doing text manipulation magic.

Now, starting with a database from day zero? I'd say it is a case of YAGNI. Don't add stuff you don't need now. If you need it in the future, then add it. But don't go paying for a hosted DB if a SQLite would suffice.

Oh, and even then, a database would be more useful for the site generation step. Having a DB being called for every page rendered is a recipe for going down with HN traffic (or Slashdot in the older days).

[wolco]

It allows you to do fun things like save comments, post polls, create news items to load on certain days.

Being able to save anything and retrieve can be useful.

[ivanfon]

I just don't understand why a "static site" needs to download and run almost 1 mb of minified JS.