
The ideal tech stack for a personal developer blog in 2020 - colinmcd
https://vriad.com/blog/devii
======
jcrawfordor
The tech stack for my personal blog is a <100 line Python script that reads a
directory of plaintext files and drops them into Jinja2 templates. It's longer
than it needs to be because I wasn't feeling like being clever when I wrote
it, so to produce the RSS feed it just starts the whole thing over again with
some copypasta from the first time around. I know that with some smarter use
of Jinja I could eliminate that whole step and be <50 lines.

It's really just a (bad) static site generator, it's just that every static
site generator I've run into so far was way more complicated than I need and
so it was faster to write my own with only the three features I want than to
learn a big complicated tool.

I guess I have mixed feelings here. It makes sense to invest time in a
complicated setup for a personal website as a hobby project, and I am quite
clear that I am not a software person so that's just not something that really
interests me as a way to spend my time. Spending a ton of time "developing a
blog" feels to me like it's just a big roadblock in the way of actually, you
know, blogging. I acknowledge that a good part of that is personal preference.

On the other hand... much of the post really concerns me. The author talks
about React and TS like they're the only alternative to writing bare JS. Well,
for one, there are other, simpler options even within the TS ecosystem. For
another, the website doesn't really seem to have any behavior that requires
JS, so I'm not sure why JS needs to be involved in the first place.

The rejection of using MD along with React seems like... a damning
condemnation of React? Is it really that hard? People tolerate that?

The assertion that most CMSs require two round-trips to deliver the content
speaks of someone who has not really seen the world outside of modern JS
front-end... It would be very uncommon for a CMS in another language to
require more than one round-trip, as the content is prepared server-side
before delivery of any kind of front-end.

I guess, if I am to be opinionated (which I certainly will be), my feeling is
that the author should have spent their hobby time exploring the world
_outside_ of React rather than hammering what seems like a rather round peg
into a rather square hole, and then presenting it as "ideal."

~~~
colinmcd
Thanks for the measured response here.

I address the fact that the site, as it currently exists, doesn't need any of
this currently. I tried to be clear in my "criteria list" that I'm designing
for power and flexibility; I don't want to limit myself down the road.

I definitely could have verbalized my stance on headless CMSs better. I'm very
aware that there are ways to use them without requiring two round trips. But
in the very next paragraph I say "I want every page of my site to be pre-
rendered to a set of fully static assets". The solution you allude to (a
headless CMS with server-side rendering) requires a server and doesn't meet
that criteria.

I also know you can do generate a static site with Next/Gatsby + a headless
CMS that's integrated into your build step. I didn't do that way because it
seemed overkill - I'm happy using my file system as my CMS.

You mention that I reject using "MD along with React". Which bit of the post
are you alluding to? I do reject the idea of putting React components inside
of `<script>` tags inside of a Markdown file. Based on my criteria, the "React
+ a sprinkling of Markdown" makes more sense than "Markdown + a sprinkling of
React". Otherwise it's an uphill battle (with a fair bit of boilerplate) to
use React Hooks, import styling libraries, etc.

I'm not sure I follow your logic w.r.t this being a damning condemnation of
React. There a build step (either Babel or TypeScript) required to use
cutting-edge React. That additional layer of separation is what makes it so
hard to do React+TS inside of these Markdown-centric CMSs. I don't think that
impedance mismatch reflects poorly on either React or the SSGs - they each
have their uses.

Could you elaborate on the "other, simpler options even within the TS
ecosystem"?

~~~
jcrawfordor
I think I misunderstood your comment about markdown and react together, I
didn't get that you were referring to nesting them two levels deep like that.
It makes more sense that that's a pain - for what it's worth, in my non-web
content authoring I do a lot of embedding LaTeX in markdown and it can become
a bit of a mess.

The boundary between a 'headless cms' and a 'static site generator' can get
somewhat fuzzy. The approach that I _usually_ take here, when it's less of a
hobby project, is to use a full-featured-editor-included CMS and then
aggressively cache the pages so that behavior is just delivery of static files
in the 99% case. This is an extremely common pattern with WordPress, for
example---I would never call WordPress a paragon of performance but it is
quite fast with the commonly used caching plugin that essentially reverts it
to a static site generator for common cases. It's even better to do the
caching in a web server or other in-between layer which is generally going to
be faster at shuffling files than whatever language your CMS is in.

When it comes to simpler options with TS, I would just write what you need in
bare TS. That gets you the advantage of typing without the weight of a
framework. It does make it more difficult (though of course not impossible) to
rely on framework components but I don't feel that really need them in your
use-case.

Finally, totally with you on relying on the file system as a CMS. In my case I
actually use the file name verbatim as the post title, one of those things
that seemed too simple to work up front but is actually basically fine. The
only constraint is that "titles" (e.g. file names) must start with the date
because I just sort them to order posts - this is all so that posts can just
be plaintext files (or markdown files, but I stick to plaintext as a stylistic
decision) without needing to be parsed for any kind of header metadata or
something. It is a limitation but I'm pretty happy with it a self-imposed one.

I also, to be fair, have a bit of a negative gut reaction to React in this
kind of situation. In my line of works (operations or, to be more fashionable,
DevOps), I have had more encounters than I can easily count with "react apps
that should be static files" and are significantly more complex to deploy and
maintain than they ought to be as a result. There's nothing like fighting with
the TypeScript compiler in the build chain for, well, a static file. I'd be
less harsh on this if I hadn't also experienced so many cases of developers
shrugging when it ends up doing something undesirable, because they don't even
understand the React part of it all well.

I'm not really convinced that it can deliver faster development but I'm also
not _un_ convinced. I am pretty convinced that it ends up adding significant
complexity that can really bite you when you encounter what ought to be
trivial problems, and there's such a large push towards "batteries included"
frameworks in JS, combined with the very fast turnover in popular frameworks,
that it seems excessively common for developers to be building on top of a
framework that they don't really understand well (because they just learned it
and it does a lot under the hood) and that just has rough edges to deal with
(because it's relatively new). It's enough to make you a little bitter after
growing up on Python and, of all things, PHP, where frameworks and libraries
tend to stick around for a long time, most developers have longer background
with the language and framework, and the build-test-deploy toolchains are
generally simpler. Not necessarily easier to use, but simpler---these two do
not necessarily come along with each other, see 'create-react-app' and its
'eject'... a solution that is easy to use but so complex that it has a
tendency to explode when you look askance at it.

------
karatestomp
The other day I started an HTML document from scratch, in VSCode.

I kinda blacked out and came to 5 seconds later, and thanks to autocomplete
and muscle memory, the whole skeleton of a document was there. HTML and Head
and title and body and all that. It was so fast & fluid.

I'm ashamed to say I'd kinda forgotten how easy it is to just _write fucking
HTML_. It's even got me reconsidering things like Markdown—I mean, fine for
webforms and such, but if I'm just writing a document, is it of any use? Toss
in a script to add a menu & header to every page & dump the output in a folder
and I'm not sure I need more, now, and I can write that in Perl or Bash or
Python or whatever in a minute or three and it'll run everywhere, nothing to
install.

~~~
marvinblum
This! I wrote my personal website [1] a few days ago (after it was blank for
years) and went for concrete css [2] and plain HTML together with some Go code
to serve the files. I set up a server on Hetzner Cloud [3] and my site was up
within minutes using Traefik to get a SSL certificate from Letsencrypt. All in
all it took me about 2 hours. If you start to play around with a CMS it can
take you days if not weeks. Just write plain HTML, boring but sometimes very
efficent.

[1] [https://marvinblum.de/](https://marvinblum.de/)

[2] [https://concrete.style/](https://concrete.style/)

[3] [https://www.hetzner.com/](https://www.hetzner.com/)

Edit: Bonus! I did the same for my brothers website:
[https://schnittfest.gmbh/](https://schnittfest.gmbh/) Just if you're curious.

~~~
qnsi
I heard in a jazz bar that you can host static sites for free at Zeit and use
plain css for grid now, but I am unable to verify the rumours as my work
limits Internet only to hackernews

~~~
marvinblum
Sure, but I'm on Hetzner anyways for different reasons. I didn't say it's
ideal, just that it's simpler to write HTML+CSS sometimes. How you serve the
files doesn't matter.

~~~
qnsi
Cool. I am sometimes posting for lurkers maybe someone gets inspiration

------
bovermyer
I would amend this blog post's title to be the following:

"The ideal tech stack for a personal developer blog in 2020 where the author
is a React front end developer who loves TypeScript"

~~~
mjburgess
I went in thinking, "probably a static github io page, right?".

I said, out loud, at the first heading: "are you insane?"

~~~
FlyingSnake
I was surprised as well. Sane developers should stick to Jekyll or Hugo.

------
dusted
"Even something simple (like the email newsletter signup form at the bottom of
this page) would have been hard to implement without React" the fuck ?

~~~
mustardo
Yep... I feel old knowing about `<form action="/newsletter" method="post">`
and handling form url encoded data server side

------
dynamite-ready
I'm quite surprised by the negativity here. If I was commissioned to make a
custom blog site for someone, I would probably go down this route, and use a
headless CMS to make it easier for others to generate content. But using plain
markdown is not a bad choice if you can't be bothered with, or can't afford a
server.

With the stack described as I understand it, the front-end flexibility is
preferable to what the likes of what WordPress will give you, and the stack
will allow a developer to decouple the CMS backend from whatever plans he or
she has for the frontend.

I suppose one can complain about React all they like. I'm not the biggest fan
of React, but component based rendering has it's advantages, so I can't see
the issue with that choice.

The only thing I don't like, is 'JS all the way down'... Not because I hate
the language (I think the language is fine, and TypeScript is overrated). But
just because I'm still not quite sure what the effect on SEO and accessibility
might be, when developers go 'full JS'.

~~~
metalforever
If I was commissioned to make someone a blog site , quite frankly I would just
install Wordpress and call it a day.

~~~
dynamite-ready
You'd be missing out, tbh.

Going down the JAM stack route provides a number of opportunities to improve
on many of technical aspects common to the development of a CMS backed
website.

For a start, you'll miss out on opportunities cheaper hosting with
'serverless' deployment. But I think the chance to decouple the frontend from
the backend is valuable enough, fwiw.

~~~
wolco
Ironically serverless is move expensive. For a dollar month you can get
wordpress hosting.

~~~
dynamite-ready
If you build a JAM stack site, many places will host it for free. GitHub most
famously.

~~~
metalforever
Relying on free hosting for a commercial enterprise is not smart!

------
jupp0r
Authors first requirement is

“I want to build the site in React and TypeScript. I love them both
wholeheartedly, I use them for my day job, and they're gonna be around for a
long time. Plus writing untyped JS makes me feel dirty.”

That preference is not true for others and I feel like that makes the
article’s title misleading.

~~~
tilolebo
>they're gonna be around for a long time

how many months does that translate to in frontend dev time?

~~~
gherkinnn
This meme is tedious.

Typescript is here to stay. No question.

React has been a thing now for what, six years? And it feels like 80% of FE
job opening require React. And no major shift on the horizon.

~~~
runawaybottle
When did you start web development? Serious question.

We went through all the ‘here to stay’ a few times over already.

Cordova, Bootstrap, Backbone, Coffeescript, Angular, Grunt, Gulp,
Require.js/AMD, I think we already moved into and out of React Native lol,
that whole Mongo thing, everyone had to be a D3 expert almost at one point,
isomorphic apps almost became the thing - Meteor, they were all here to stay.

~~~
cableshaft
I think TypeScript is about as standard for Javascript as it's going to get, I
feel. I can't imagine writing Javascript without it anymore. But then again it
took TypeScript coming along that made writing JavaScript something tolerable
outside of having to use it for work.

I don't think there's going to be any new typing system that's 5% better that
everyone is going to shift to just because it's the new hotness anymore. Or at
least I hope not. TypeScript is good enough, let's just stick with it for the
foreseeable future if you want to write type-safe Javascript, please.

I'm still using Angular at work, and I rather like it. If I needed to make an
SPA outside of work I'd probably use it over React at this point. But that's a
web framework, and those seem to come and go with the wind.

~~~
purerandomness
Have you been around last time, when CoffeeScript definitely was here to stay?

Or that other time, when Dart was almost here to stay, and on its way to
replace JavaScript?

~~~
gherkinnn
Coffeescript was here to stay? I always saw it as a seki-esoteric language
people sprinkled their CV with.

Dart was a push by Google but went nowhere.

TS drives Angular, has first-class support on React and soon in Vue. Most libs
have TS typings. Nextjs (amongst others) provide easy TS integration. It’s
being pushed by M$, C# and Java like seem to like it and Enterprise (tm)
adopts it.

It’s an entirely different beast.

------
dpbriggs
Another aspect is that your blog should make you want to blog.

The tech stack therefore mirrors your interests.

It feels great to use tools built by _yourself_ for _yourself_. Doubly so if
the stack is janky (rust / org-mode for me).

The feeling that you've made something makes you want to invest more into it.
To make sure the tools were worth making in the first place.

~~~
TeMPOraL
Oh god, don't tell me about janky stack.

My stack for the blog is Org Mode compiled by Emacs into HTML, which then gets
parsed by my Common Lisp static site generator. It's a weird setup, but it
came to be because:

\- The rest of the site, and the overall template, is generated straight from
Common Lisp (using a much saner syntax for markup and styling than HTML/CSS),

\- writing a parser for Org Mode for anything but the most basic features is a
rather complicated endeavor, so it's better to let Emacs deal with it and then
clean up the exported markup,

\- I also imported posts from my old Wordpress blog, as HTML dumped from a
database, so I had the tools to slice and dice DOM in my CL generator anyway.

I really hate how bad this design is. It needs rewriting from scratch into
something designed closer to a build system, but that would take a lot of
time, so I procrastinate on that endlessly. On the other hand, writing blog
articles in Org Mode is super fun, so the frustrations cancel out with the
benefits.

~~~
dpbriggs
That's indeed a janky setup :P

What libraries / frameworks do you use in Common Lisp to generate the site?

~~~
TeMPOraL
CL-WHO - to generate HTML

LASS - to generate CSS

colorize - to colorize source code snippets and embed documentation links in
them

Plump, Plump-SEXP, CLSS - for occasional fixing of imported HTML documents "on
the fly"

------
jaredcwhite
"I literally have zero memory of how we used to build forms in the pre-React
times"

Don't mean to pick on the author, but these sorts of comments scare the shit
out of me. React is fine for what it was originally billed as (a library for
building UI components), but the way people use it to take over the entire web
stack is bananas. Definitely not needed for a static blog, LOL.

P.S. Use LitElement anyway, not React. The future is Web Components.

~~~
desert_boi
The meme about Web Components being the future is older than React at this
point.

~~~
stevens32
I was/am pro web components but the likelihood of it "being the future" seems
extremely grim. No one's happy about front end tooling, but for the moment it
still beats the alternatives. Shadow dom is hellish to work with at scale - I
think what a lot of the critics may miss is that much of the "why" of modern
front-end is that it scales with team size.

------
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.

~~~
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).

------
hawkice
As a non-React developer: forms, before React, were actually super simple. The
author mentions they forgot how to do forms the normal way, but like, can you
imagine how excited they'll be by the simplicity?

~~~
runawaybottle
Well, think about time just for a second. Take your average 25 year old
frontend developer, for example. Five years ago in 2015, we were sort of
coming out of Jquery. That means all these people had to be doing professional
modern web development at the age of 20. What’s the likelihood of that for
most people? Take you average bootcamper, by definition they didn’t know
modern web development when they were about 22. If they graduated recently,
that means around 2015 they were maybe 17 years old, and if they went to a
bootcamp post college, they sure as hell don’t know anything from the
2009-2016 era.

So that’s who writes this stuff. They literally don’t remember a world where
you can build very simple things without state management, without scoped
styles, without jsx.

I’m not an agist, but it’s like c’mon dude, it’s a blog, when did you start
web development? Don’t write your own blog posts yet please, mature a little
first. Way too much noise out there now days.

Why do you need type checking for your blog? You really going to double check
that you’re posting a string or something? Do whatever you want, but stop
posting about it like it doesn’t sound unnecessary to the rest of us.

~~~
saagarjha
You don't have to live through something to be aware of it. I'm not a web
developer, and in 2015 I think I might have started programming, but even I
have figured out that HTML forms are a thing that exist.

------
tristor
Seems completely unnecessary and overly complex for anyone who doesn't love
Javascript. I'm using Hugo + Git commit hooks to drive deployments. Easy
enough, works just as well, didn't require reinventing the wheel. I embed rich
content all the time.

~~~
colinmcd
What kinds of rich content? React + TypeScript, or something else? Have you
used the Hugo babel plugin?

------
piercebot
A lot of the comments here are reminding me a lot of Tom MacWright's critique
of modern web development:

[https://macwright.org/2020/05/10/spa-
fatigue.html](https://macwright.org/2020/05/10/spa-fatigue.html)

Around the same time, Vladimir Agafonkin (perhaps in response to the above??)
released tinyjam,
[https://github.com/mourner/tinyjam](https://github.com/mourner/tinyjam),
which bills itself as "an elegant, zero-config static site generator in 100
lines of code, an experiment in radical simplicity."

Maybe the above two links will resonate here :)

------
encom
Here's my stack: I write .html files in GNU Nano, and serve them with Apache.
I've done that for about 20 years (with varying editors and servers), and I
don't see why it needs to be any more complicated putting words on the
internet.

Yes yes, old man yells at cloud etc, but I'm a strong believer in "less is
more".

~~~
NewEntryHN
It becomes more complicated as soon as a you have a sidebar with "Last
articles" in which case you would need to edit each single HTML files to edit
the sidebar consistently. Even with a single archives page you need to think
about updating the archive for each new article. Also Markdown is definitely
more author-friendly than HTML, but that's more like an extra.

~~~
frereubu
If you're using Apache, which he said he was, you can just use server-side
includes:
[https://httpd.apache.org/docs/current/mod/mod_include.html#e...](https://httpd.apache.org/docs/current/mod/mod_include.html#element.include)

~~~
microcolonel
Another option is to use cat and a shell script or Makefile, or I guess some
people use m4.

~~~
llimllib
I use a makefile that runs a short python script, very simple

------
jcpst
I’m sorry, but this is ridiculous for a static site. React and Typescript with
embedded markdown?

This problem has been solved a thousand times over with much simpler tooling.

> I literally have zero memory of how we used to build forms in the pre-React
> times.

:(

~~~
woutr_be
> I literally have zero memory of how we used to build forms in the pre-React
> times.

This is honestly quite a disturbing trend with a lot of front-end developers
these days.

I recently asked a front-end dev why they chose React for a simple app over
simple server-side templating, he's reaction was "we don't need SEO, so why do
we need React SSR", like how does that argument even make sense. They seem to
have forgotten you can build stuff without a JS framework.

The default has to be SPA + API, even when you don't actually need it.

~~~
joekrill
> I recently asked a front-end dev why they chose React for a simple app over
> simple server-side templating

I don't really get this argument. What makes "simple server-side templating"
better than React components? I'd argue that these React components
effectively _are_ templates. If someone is proficient in React, why are we
suggesting they have to learn some other random templating language? Not to
mention deal with additional things like file organization, transpiling, etc.

~~~
ryanbrunner
If the argument is "what makes ERB / JST / some other templating language
better than React for server-side rendering" then sure, there's not really
much difference.

What I suspect was the intent of the original question was "why does a simple
app need to be an SPA with an API on the backend", which I do feel is
something that adds significant complexity to any project. It's sometimes
worth it, but I'll never be convinced that having to maintain an API alongside
client-side rendering is faster or easier than a traditional server-rendered
application.

~~~
woutr_be
Complexity is one thing, but more importantly is choosing the right tools for
the job. There definitely are cases where you want SPA + API, but this wasn’t
one of them.

------
marvinblum
I recommended this on another HN post a few weeks ago: use Emvi [1] to write
your blog articles and access them on your personal page on a server you
control through the API to display them. You can store the HTML and attached
files to serve it statically and update it from time to time. Should you
decide to abandon Emvi you still have everything in place. I did this for a
gaming community wiki (sort of, I don't store articles on the webserver). The
main advantage is that your site is literally just a dumb frontend and uses
Emvi as a headless CMS and the editor experience is nice. You can take a look
at it [2] and the source code on GitHub [3].

[1] [https://emvi.com/](https://emvi.com/)

[2] [https://wiki.sts.wtf/](https://wiki.sts.wtf/)

[3] [https://github.com/Special-Tactical-
Service/wiki](https://github.com/Special-Tactical-Service/wiki)

~~~
dpbriggs
Just wanted to say that I am impressed by the emvi landing page. Slick and
high fps.

~~~
marvinblum
Thanks :) We're working on a new one as we're redoing the whole UI.
@danielschramm is writing it.

------
siralonso
Lots of negativity here, but I think if your goal is to be able to sprinkle in
bits of interactivity (or demos) among mostly static content, this is a great
choice. Yes, it has more dependencies than some other solutions - but the goal
isn’t to be zero-dependency - it’s to remove as much friction from your
publishing process as possible while still providing the required capability.

If you want to intermix markdown and react, check out MDX. You can write a
file that’s 99% vanilla markdown, and just drop in a react component at the
appropriate point.

------
DJHenk
A personal blog should be whatever the author wants it to be of course, and a
developer should play with whatever technology he/she wants. But as a backend
developer, I don't want any Javascript on my site, because I hate writing it
and I don't like browsing it.

These statements indicate to me that this "ideal tech stack" is rather
personal to the author:

> I want to build the site in React and TypeScript

> I don't want limitations on what my personal website can be/become. Sure, my
> current site consists of two simple, static blog posts. But down the road, I
> may want to...

> I literally have zero memory of how we used to build forms in the pre-React
> times.

I think I'll keep it at Hugo for now, with just HTML and CSS.

~~~
cableshaft
Came here to say Hugo is the correct answer for a Personal Developer blog,
unless you're using it to showcase your skills in a particular technology, at
least in my experience.

Finally dived into Hugo and it's just so easy to get going with making
Markdown content and turning it into a static site with one of the themes from
their gallery. There's a bit of a rabbit hole to go down if you want to get
more custom than that, but it's extremely customizable and you can learn a lot
about how to do so just looking at the source code from themes in the gallery.

The only tech I really have to worry about is HTML, CSS, Markdown, and a
little bit of template scripting for ranges and reading variables from the
config files, if I want to customize the theme.

I've gotten excited about building my personal website again because I don't
have to screw around with the technology hardly at all, I can focus on just
making content. Which is what you want for a personal site. You don't want a
bunch of friction slowing you down from actually getting content out there.

I don't have to worry about dependency hell with Hugo either, it's just an
executable.

~~~
fossuser
How do you host your site?

I've been using Github Pages which has Jekyll support and that's worked fine,
but I'm curious where people host their Hugo sites (or how hosting works when
you run the server yourself).

Is it AWS? Dreamhost? or something else? Do you have to manage a proxy or
handle load/cost spikes? Can a surge of traffic take down the site?

I haven't read a ton about this, but I'm curious about it. It'd be neat to
have full control over my own publishing if something ever happened to github
pages.

~~~
nickysielicki
That's the beauty of a static site generator -- github just expects valid HMTL
to be generated and pushed to a specific branch. Github has no more Jekyll
support than it has support for Hugo or a custom static site generator written
in bash.

I host my hugo-based blog with github pages.

~~~
fossuser
Ah ok - I think I understand.

Github does have special Jekyll support, but you just generate the hugo static
files locally and only push those up to where Github expects them to be?

I think with Jekyll Github will re-generate the static files for you and works
with the RSS plugin automatically.

Good to know though - might be worth checking out Hugo, thanks!

~~~
nickysielicki
Huh, I didn't know that Github had that sort of integration. I'm surprised
that they're willing to run arbitrary ruby like that.

------
FlyingSnake
Apart from the questionable complexity of the tech-stack, it's not even
performant. According to WebBloatScore¹, the bloat score is 2.21. The webpage
size is 491kb, makes 18 requests. In comparison, HN frontpage score is 0.175.

[1] [https://www.webbloatscore.com/](https://www.webbloatscore.com/)

~~~
ausbah
That's a pretty cool tool! The most bloated site I managed to find was
Facebook's login page at ~77.

------
ferros
Personally I work in tech all day, I want my blog to be as simple as possible
and to focus just on my writing.

Still using Jekyll.

~~~
NalNezumi
I'm looking in to Jekyll as well, since it's what github recommend and I
really can't be bothered with templates and re-learning all web stuff when all
I need is to be able to write text and show pictures.

Haven't really gotten started with it, but I wonder where the limitation of
the tool will be felt? Do you need to know Ruby and the things around it too?

I were thinking of also suggest it to my SO who have past experience in web
design but no programming skill at all (I can at least set up her github
account). My guess she would be more picky with how the page looks though.

~~~
pizza234
> but I wonder where the limitation of the tool will be felt

I use it and I don't feel any limitation. One can always add Javascript
(AFAIK) if they want new functionality.

What bothers me is that adding new functionality should be attempted first in
the idiomatic (for the platform) way, which in the Jekyll case, is the Liquid
language. I personally don't like it, but it's not a big deal to add small
features (e.g. tagging).

Wordpress (AFAIK; I don't use it) has a large amount of plugins. If the
intention is from the beginning to customize the blog functionality - as
opposed to styling - probably Wordpress can be easier. But we're not talking
anymore about a minimalistic design.

> Do you need to know Ruby and the things around it too?

Not at all! Just write in plain markdown with Front Matter.

~~~
NalNezumi
thanks for the feedback! If JS can be done (and from a quick look css html and
basic stuff is there), I guess I can also recommend it to my SO :)

------
clarry
> I worry that many developers (maybe even you, dear reader) are settling for
> suboptimal, restrictive static-site generators that place limits on the
> interactivity and flexibility of your website.

I wonder what sort of interactivity you want on your text?

> This degrades page load speeds and user experience, which accordingly
> degrades your rankings on Google. Instead I want every page of my site to be
> pre-rendered to a set of fully static assets

Oh, you want a static site. That's what I want too.

~~~
jasode
_> I wonder what sort of interactivity you want on your text?_

In case you glossed over it, I think he said it in his post:

 _" But down the road, I may want to build a page that contains an interactive
visualization, a filterable table, or a demo of a React component I'm open-
sourcing."_

~~~
mhh__
Isn't all of that done client side i.e. still possible with a static site?

~~~
indigochill
Yes. You can go crazy with static sites. I use Github Pages for this. On one
I've done a single-page Javascript-driven text adventure. On another I've
embedded a Unity application that runs a dynamic 3D starmap with WebGL. I've
also seen roguelikes. What you can't do is run server-side logic, but you can
do an -awful- lot on the client.

~~~
gonzo41
When workplaces were still slowly still migrating to GIT, we had Git and SVN.

SVN rocked because you could run static sites in it, a little bit of jquery
and whatever and I was building a ton of simple business productivity tool as
single page apps. All with the peralta guarantee of support.

------
jamestimmins
A lot of these comments reference the ability to make extremely simple
css/html sites. That's strange, because it's pretty clear that's not the
outcome OP is looking towards. There are some really fancy personal websites
out there, and if that's the end goal, with lots of interaction and features,
this seems like a reasonable starting point.

------
foob4r
Here's mine: Jekyll blog with no js. Git push to my home server [1]. It runs
in a docker container with a watch. The simplicity means adding a tor proxy in
front was as easy as running another container.

[1] [https://goel.io/blog-2020](https://goel.io/blog-2020)

------
soygul
For a techy person, GitHub pages + markdown is all you need:
[https://quanticdev.com/articles/website-with-github-
pages](https://quanticdev.com/articles/website-with-github-pages)

When you already know Git & GitHub, you get an all-in-one experience with your
code & website side by side.

~~~
matwood
Glad someone already said this. And if you want something a bit more fancy,
use a static site generator like Jekyll or Hugo.

~~~
fossuser
Github pages has out of the box support for Jekyll and I think that's the
dominant way people use it.

I've heard good things about Hugo though (generally people seem to like it
better than Jekyll), but I set up my site before it existed and I think Pages
still only supports Jekyll.

------
sub7
Why reinvent the wheel? Use Wordpress/Ghost etc

~~~
christiansakai
Aren't Wordpress and Ghost heavy in a way that it has some number of CSS/JS
that we don't need?

~~~
johnonolan
Hi! John from Ghost here - Ghost has no bloated styles or scripts which are
injected by default. You have full control of the frontend and can make it as
minimal (or maximal) as you like.

My answer to the OP would be:

If you want to write (on a blog) then do literally anything but turn your blog
into a development project that you'll definitely never finish - because it
just becomes the excuse for not writing. (almost all developer blogs)

If you want a fun developer project to experiment with your personal website,
and messing with new technology is the goal, then this stack sounds like a lot
of fun. It also sounds like it will be obsolete and no longer shiny in 12
months, but again, if this is your goal then you probably don't care.

TLDR: developer tools will usually end up being great for development,
publishing tools end up being great for publishing. Pick the one that suits
your desired outcome best.

------
drej
> Devii is powered by Next.js. We chose Next.js because it's the simplest,
> most elegant way to generate a static version of a React-based website.

There's nothing simple about this crapton of dependencies. Sure, it may be
easy to build things this way, but let's not conflate the two terms.

~~~
dan_can_code
Regardless of the dependencies, the point that it is the 'simplest, most
elegant way to generate a static version of a React-based website' applies.
Next.js is ridiculously simple to get up and running with - even for JS
rookies.

~~~
drej
That’s not the point I’m making.
[http://wipmoore.info/posts/2017/09/17/security-simple-vs-
eas...](http://wipmoore.info/posts/2017/09/17/security-simple-vs-easy-rich-
hickey.html)

~~~
dan_can_code
What point are you making? The linked blog post just defines simple and easy.
I am not sure how this relates to your previous comment regarding
dependencies.

> In essence simplicity is about reducing then amount of waste in development
> and increasing the longevity (service life) of the system we build.

I would argue the implementation of nextjs in the context of static, react-
based a blog falls under this definition in your linked blog post. Unless I'm
missing something?

------
dan_can_code
This is so strange - I am on course to build my own developer blog with a
similar stack (minus TypeScript, and syntax highlighting).

I am also using a CMS instead of just plain markdown - in this instance it is
NetlifyCMS.

Netlify CMS is the perfect go-between of a fully-fledged CMS, and a much too
basic static site with just markdown - I dislike the experience of writing
markdown and would rather use an editor.

With NetlifyCMS - the blogging flow is as follows:

\- User logs into NetlifyCMS

\- User updates content

\- Content is 'pushed' to the repo as a commit.

\- CI / CD picks up changes on master branch

\- CI/ CD publishes changes

\- The site is updated!

The example code can be found here:
[https://www.netlifycms.org/docs/nextjs/](https://www.netlifycms.org/docs/nextjs/)

It is extremely simple to get up and running - but also offers great
flexibility if, as the author has stated, you wish to use your website to demo
components - visualise data, anything custom really!

The only difference with my implementation is instead of using the `public/`
folder, I created an 'admin' folder within 'pages', with an index.js file for
the HTML contents, as referenced here:
[https://www.netlifycms.org/docs/nextjs/#adding-netlify-
cms](https://www.netlifycms.org/docs/nextjs/#adding-netlify-cms). The only
reason being, I didn't want to have to specify '/admin/index.html' every time
i want to edit the content.

My only gripe with this blog post - is its insuniation that it is 'ideal'. I
think its pretty clear from the post, it is only 'ideal' for the author.
Unfortunately, the HN community has taken the opportunity to rip apart the
authors opinion - which is disappointing. Thanks for the content, Colin!

~~~
colinmcd
Thanks Dan :)

NetlifyCMS looks really cool. It definitely took me a while to come around to
writing MD directly (basically until I discovered VSCode's hot-reloading
Preview), but I understand the appeal of a rich editor.

I'd definitely get rid of the word "ideal" if I could post this again It
attracted a little (read: lot) more vitriol than I expected. I submitted this
right before going to bed so by the time I woke up it was too late to edit the
title.

~~~
dan_can_code
My pleasure, Colin. I am too lazy to use brackets and hashes in my writing is
all - glad it works for you, regardless.

I think from the context of your writing - it was fine. I found it pretty
clear it was from your 'personal' view. As they say however, all publicity is
good publicity - I look forward to any more content you will be posting!

------
ldeangelis
> As much as I love the Jamstack, it doesn't cut it from an SEO perspective.

Static generation is a big part of JAMstack. Headless CMS means that the CMS
only does the CMS part, and then you can plug Hugo, Gatsby or anything that
you want with it.

------
alexgaribay
I'm still of the firm opinion that a blog on Ghost is a great option for most
people. It works with very little maintenance; Letsencrypt is built into the
CLI tool so it's very easy to get SSL; the editing experience is great; images
are optimized for sizes; custom theming is possible; and if don't want Ghost
to render your pages, you can hook into the API and use it as a headless CMS.
I use Ghost for every blog I run as well as the marketing pages for my apps.

------
nindalf
Ideal tech stack if you _need_ react components in your site.

I'm perfectly happy using Hugo + git hooks. It's easy as

1\. Write a post in markdown

2\. Commit and push

3\. A post-commit hook runs hugo. Refresh your page and the post is live.

The friction to create a new post needs to be as low as possible. I can't get
it any lower than this.

It's dead simple to set up too - [https://blog.nindalf.com/posts/setting-up-
this-blog/](https://blog.nindalf.com/posts/setting-up-this-blog/)

------
jamesu
My main problem with blogging is not really the tech stack itself, but rather
getting into the flow to consistently write and complete stuff. Every slip-up
which happens on the way from brain to page drastically reduces the chance
something will get published.

e.g. troubleshooting a broken deployment script because something broke after
an update? -> no post. needing to manually manipulate images? -> no post. page
rebuilding taking too long? -> no post.

~~~
p410n3
The image thing is big for me. You can literall tell when I switched from a
handwritten site to a CMS as soon as started to include images.

I definitely wanted to use srcset to serve a performant website, but i was too
lazy to do that manually or to make a script for it.

Now it doesnt matter anymore :)

------
huy-nguyen
> Next.js is quickly eating everyone else's lunch in this market, especially
> Gatsby's (sorry Gatsby fans).

Can someone comment on the latest version of Next vs Gatsby?

------
tbran
The most important thing to me when building a blog or info type site is how
hard it will be to maintain or change in a year or more.

I have one site running on Wagtail (Django) for the past 3 or 4 years, and two
other sites currently built with Hugo (LotsOfOpps[0] and BuiltRigs[1]). I've
put together lots of other sites with Hugo, Wordpress, and other Django CMSes.

The Wagtail site is definitely overengineered, and I usually dread making
updates to the code a few years on.

I've messed around with other generators like 11ty[2] and Gridsome[3] (both
pretty cool projects!), but I mostly keep coming back to Hugo. It's pretty
simple, and so far I haven't had to worry about a 3rd-party package breaking
stuff.

[0] [https://www.lotsofopps.com](https://www.lotsofopps.com) [1]
[https://www.builtrigs.com](https://www.builtrigs.com) [2]
[https://gridsome.org/](https://gridsome.org/) [3]
[https://www.11ty.dev/](https://www.11ty.dev/)

------
katsura
Hmm, my network tab says 1MB of resources loaded, from which the images are
only around 50kB. How is this ideal for an almost text-only static site?

------
sambroner
Ideal may be a bit strong, but I'll assume it's ideal for Colin (author.)
Learning is a big part of it, but so is familiarity.

I just started the same type of project: a personal website with a homegrown
framework that makes everything easier. It was hard! Picking these
technologies with no constraints and imperfect knowledge is tricky.
Ultimately, I went with tools I wanted to learn more about, but that I was
pretty confident would get me to a static site.

This ended up being webpack + loaders/plugins (some homegrown). Plus I'm
writing content in Google Docs and exporting it to HTML after being inspired
by the wave of Google Docs articles on HN.

Like Colin, I eventually want to put animations or data transformations on
there. Fun process.

------
9nGQluzmnq3M
Creating your own stack for your personal blog seems to be the modern-day
equivalent to creating your own programming language: it's a huge time sink
with virtually no sane justification, yet developers are drawn to it like
moths to a flame.

~~~
MoOmer
Sometimes following rabbit holes is fun for personal projects - not every
project is measured strictly by utility.

------
_bxg1
Here's mine; I'm pretty proud of it. It's JavaScript but the only meaningful
dependencies are Express (basic HTTP server) and a markdown parser. It's
basically a hand-rolled static site generator + a static file server. Both of
those are trivial to do with JS/Node. I over-engineered the static file
serving a little bit in hopes of keeping files cached in memory, but that bit
can easily be replaced with Express' built-in static file serving middleware.

[https://github.com/brundonsmith/website](https://github.com/brundonsmith/website)

------
throwanem
Wild to see so many people fail to realize that part of a "personal developer
blog"'s job is CV support. From that perspective, it makes perfect sense to
build it with the same technologies as the jobs you're looking to get.

But hey, I guess it's a lot more fun to talk about how somebody's hobbying
wrong and they should've used Jekyll or Hugo or PHP or a shell script or a
Python script or a Makefile or just hand-write everything and use framesets
like it's still 1997 and the concept of user experience hasn't been invented
yet. Carry on.

~~~
theamk
I think everyone is surprised because the choices made actually result in a
worse UX. Sure, the backend decisions make developer's life easier, but they
turn a static page of text into a big cpu and network using monster.

Everything has its place, and I am not sure react+ts is the right thing.

(and this was exacerbated by the post title.. The current title is nice, but
the HN submission title made it sound like this is ideal _for everyone_ )

------
donaldihunter
Hugo + Org mode is my jam. I find org-babel incredibly helpful for posts
containing code snippets because they get authored and run inline, with any
output captured directly into the blog-post.

------
52-6F-62
Jumping in on this one. I built a very basic server in Go (learning project)
that parses posts from markdown and folder structure and lists them in a
terribly arbitrary order and otherwise serves static html with some js
enhancements that degrade without killing the site. Sits behind an nginx
proxy.

Everything is quite outdated, mind.

[https://github.com/robertfairley/rf-19-go/](https://github.com/robertfairley/rf-19-go/)

------
pjettter
I dunno. Lately I've been into static sites based on Blazor with json files in
blob storage. Fast, C#, no server. And no JS. Just C# to WebAssembly. In
VSCode I can do dotnet new blazorwasm, then dotnet publish then publish to
Azure blob storage via extension and presto. Yeah you can also put MarkDown
files in DropBox and have some app pick it up and put it in your blob storage.
No forms. Just your favorite Markdown editor.

------
PedroBatista
Maybe I'm getting "too old for the shit" but, why is he using all that latest
"web app" tech to build a series of web pages?

~~~
colinmcd
It's all I've ever known.

More concretely: I try to address that in my list of criteria section under
"React + TypeScript". I couldn't shake the feeling that doing anything complex
in the future was going to be even more complicated if I have to fight against
an SSG framework to do it. I also address the fact that currently this is
wildly overengineered currently :D

------
aaanotherhnfolk
This setup is going to lose its sheen really quickly when every attempt at
writing a blog post also accompanies three hours of npm package bumps

~~~
colinmcd
All my dependency versions are pinned, and I'm not using any global CLIs that
may change under me. Valid concern though if you don't take precautions.

------
flog
I just remade my personal site after a 6 year break.

It took me 4 hours to redo a static HTML and CSS mockup, learning a bunch of
great new things about CSS Grid and Vars... then another week to convert that
static into a Gatsby static-generator site.

It's sort of insane how over engineered we've gone on this stuff. HTML and CSS
are pretty great tools for a blog. We can skip the React, GraphQL, etc.

~~~
anderspitman
So... why did you convert it to Gatsby?

~~~
flog
Keeping up with the Joneses. I think it’s good to have opinions on the new hot
thing.

------
sephicr
Strange that no one has commented this yet, but most (all?) of his "choices"
are a blueprint of the official "Create a Next.js App" tutorial at
[https://nextjs.org/learn/basics/create-nextjs-
app](https://nextjs.org/learn/basics/create-nextjs-app)

------
reacharavindh
Hugo (static site generator) + a theme (Ananke - based on Tachyons CSS) +
Markdown for content. Hosted on a CentOS 8 VPS on GCP.

[https://aravindh.net](https://aravindh.net)

No JS tinkering. Just simple HTML and CSS to customise the theme for my taste.
Not as simple as editing raw HTML with vi, but I'm good with it.

------
decebalus1
Jesus Christ, the crap we're spending time on.

[https://www.theolognion.com/programmer-starts-a-blog-
doesnt-...](https://www.theolognion.com/programmer-starts-a-blog-doesnt-write-
about-their-static-site-generator-setup-in-the-first-post/)

~~~
colinmcd
Haven't been banned from GitHub yet but the "shunned by community" is coming
together nicely.

Also, to be fair, it's my second post.

~~~
decebalus1
> Also, to be fair, it's my second post.

Precisely. If it was your first post, I wouldn't have posted that. Also,
please don't take it the wrong way, this is just humor. I appreciate you
sharing knowledge with the world, it's something I haven't done in a long
while so I respect that.

------
rcarmo
I hacked this together last year, and changing the rendering bits should be no
trouble: [https://github.com/rcarmo/azure-durable-functions-node-
blog-...](https://github.com/rcarmo/azure-durable-functions-node-blog-engine)

------
adamzapasnik
I'd say the perfect tech stack is the one you already know or you the one that
is close to your daily stack.

No point in learning "the ideal" stack, if you can use something you know that
is as good as any other stack.

Let's be honest. You can develop and deploy static site anyway you want.

------
throwawaysea
I think the ideal stack is one where you don't maintain the stack and instead
use someone else's managed service. Otherwise it can turn into a huge
distraction and a rabbit hole, keeping you from operating the blog itself.

------
hutattedonmyarm
Yet, here I am, currently setting up a static blog using Publish:
[https://github.com/JohnSundell/Publish](https://github.com/JohnSundell/Publish)

------
sideproject
Yeah, I decided to roll mine out too (here's an example -
[https://blog.sideprojectors.com](https://blog.sideprojectors.com)).

Built on Laravel + Vue + Tailwind.

------
benfrain
Scans to see how he is dealing with native comments... Realises the issue
remains unsolved, along with 99% of ’CMS’ solutions... Continues with
Wordpress.

~~~
colinmcd
What do you mean exactly? Are you referring to adding a comments section to my
blog? I didn't even consider doing that, but if you want that then Wordpress
makes a lot of sense.

~~~
benfrain
Yes, the title is ‘the ideal tech stack for a development blog...’ I consider
commenting functionality an essential component of a tech blog so was hoping
that was solved in the post. It isn’t, and it hardly ever is but I wish there
were more choices in this regard

------
DrBazza
If you want React in your blog, is it really a blog any more?

It's trivial to add React into a Markdown page, since Markdown allows you to
include html tags.

------
johnrackles
Earning my daily bread with writing React with TypeScript and using next.js,
this is exactly what I would use for my personal blog.

Sorry for the many negative comments. I'm not sure if many people here do
websites for a living, but I can't imagine doing stuff any other way anymore.
It's just so convinient from a developer standpoint. Is it overkill for some
websites? Maybe, but in the end you are dead on with your sentiment that it
needs to be fun for YOU to use. So I hope you are not disencouraged by the
many negative comments.

~~~
colinmcd
Thanks John! Not discouraged (or surprised) by the reaction. I think using the
word "ideal" in the title was a fatal mistake - lesson learned :)

------
inopinatus
Surely this is meant as satire, the title is clearly tongue-in-cheek.

I’d worry that some less experienced folks might take it at face value, rather
than as a salient warning about the dangers of grossly over-engineering for no
discernible benefit.

~~~
chrismorgan
Nah, this is to me clearly in earnest. Nothing whimsical about it, it’s all
very practical.

(It’s not the tech stack I’d choose, but I see exactly why it’s being chosen.)

------
mbdesign
I've started using 11ty recently and can recommend it as a Jekyll on steroids
(and maintained).

------
metalforever
React isn’t a good tool for a blog.

------
uptownhr
recommend taking a look at the newly released for Vue developers.
[https://www.npmjs.com/package/@nuxt/content](https://www.npmjs.com/package/@nuxt/content)

------
exabrial
JBake. Really that's about it. Maybe add Cloudflare or a similar service.

------
mschaef
"The ideal tech stack..." goes on to rattle off half a dozen or so components,
ranging from languages to libraries.

Ugh.

It's a personal blog. A small amount of mostly static text and images served
on demand in a couple different formats. Maybe some search/tag capabilities
and maybe a comment section.

This problem is essentially the foundational problem that the web was
initially trying to solve twenty-five years ago. And to be honest, twenty-five
year old server-side solutions still do a pretty good job of it. (Although
admittedly, the format of the resources served by those solutions are now far
richer than they used to be.)

------
noxford1
I really liked using Nuxt + AWS Amplify for personal sites.

------
cvaidya1986
It’s actually no code

------
domenicrosati
Html

------
gazelle21
Why not just wordpress?

------
andersco
This is front end only so not really a complete stack.

~~~
colinmcd
True. I briefly mentioned Headless CMSs but didn't really give them the time
of day. I didn't want to do anything that required a server/db/CMS, but I
didn't do a good job of justifying that decision.

I do think the term "tech stack" has come to be used more broadly than your
definition.

------
troughway
This thread is over-the-top negative.

If anyone wanted point-blank reasons as to why HN can be a shithole sometimes,
look no further.

------
hacker256
Shameless plug - I built Hacker Spring so you can blog or host your website by
just sending an email.

[https://hackerspring.com](https://hackerspring.com)

