The ideal tech stack for a personal developer blog in 2020 | Hacker News Reader

The ideal tech stack for a personal developer blog in 2020

vriad.com

192 pointscolinmcd268 comments

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

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"?

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

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.

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/

[2] https://concrete.style/

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

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

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

> my work limits Internet only to hackernews

A workplace of dreams. What else do you need anyway?

tcp over hackernews comments?

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.

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

Thanks for using my css microframework <3 It means a lot to me !

Very nice and < 125 kB, well done.

Well done. Looks quite good for the level of simplicity.

I did the same for my site (https://maddo.xxx)

Turns out html covers pretty much everything. Learned a few cool things along the way like:

- `@media (prefers-color-scheme: dark)` (Still working on nailing down color contrast there)

- doing footnotes via anchor tags that (a) automatically number themselves in text with counters and (b) automatically highlight the footnote using the `:target` selector.

not a single line of JS. The biggest perf issue by far is a font that's 64KB, which is probably including more than it needs to.

Deploying is 1 line of `scp`. Recently I got all fancy and added 30 lines of bash to support flags for only deploying assets or posts.

all of it is so fast. Coming from rails and react and all of that, it's refreshing.

I like the way you present your work history at the bottom. If I was an interviewer it's got everything I need to know and nothing more.

I may have seen this on here, but someone made their blog with just html and the posix tool m4: https://github.com/technomancy/technomancy.us

If I ever make a static dev blog, I'm doing the same. I've tried hugo, and it just felt way overcomplicated for what I was trying to accomplish.

The primary advantage of markdown is that it is more readable in plaintext.

Yeah, but you lose lots of HTML features—not even layout-related things, which of course aren't present in Markdown, but things like image captions, <abbr>, <mark>, and so on. I love it for cases in which plain text would otherwise be used but it's lacking a lot of really nice features in HTML that aid readability and accessibility.

Any HTML is valid inside of Markdown, so you just write Markdown and then add HTML when it makes sense.

You can define the image meta, but yes it sounds like HTML is good fit for your needs.

I second this. I'm all in on Markdown and other ASCII-readable formats. By all means, render out to HTML to make things pretty, but consider keeping the source in plain text. You can browse my personal site with curl or even netcat:

curl https://anderspitman.net/txt/19

nc txt.anderspitman.net 3838 <<< /txt/19

Web browsers are terrible plain text readers. Especially mobile browsers. The problems are manifold.

If your plain text document has line breaks to enforce some column width it will rarely match a browser's viewport width. This means the browser will break lines to fit in the viewport but still respect line breaks. So you get lines broken by the viewport and then line breaks a few words later. The text does not flow well at all.

If you only have line breaks at the end of paragraphs the text might flow better but the default viewport width on mobile browsers is (usually) 980px. Desktop browsers set their viewport width to the window width. In either case text ends up hard to read because lines end up really long.

You also lose hyperlinking which makes the web...a web.

If you want a plain text website just make it HTML with a minimal or no stylesheet. A single viewport meta tag will keep the page readable everywhere. Setting it to the device width will make mobile browsers reflow the text based on the screen size.

No one is going to read your blog with netcat or just curl into a pager.

> If you want a plain text website just make it HTML with a minimal or no stylesheet

I have an HTML version of my blog for people who want to read it in browsers.

> No one is going to read your blog with netcat or just curl into a pager.

No one is going to read my blog, period.

No one is going to read your blog with netcat or just curl into a pager.

Idk, maybe we should revive the world of information served raw over TCP or telnet. HTTP is out of control.

In what way do you think HTTP is out of control?

Before you reply please keep in mind JavaScript web apps don't have anything to do with HTTP.

Ok, "out of control" is a slight exaggeration, but HTTP has become a complete reimplementation of what amounts to TCP or SCTP.

Again, in what way? TCP is making sure data gets where it's going and there were no errors introduced by the transmission. A raw TCP socket doesn't have any metadata about what the data is that's coming over the socket. There's a reason the Application layer exists in the first place.

You can make an argument that HTTP should be replaced with another application later protocol but just raw sockets everywhere is ridiculous.

HTTP has eaten the world of application layer protocols because it is flexible and expressive. It's also relatively easy to implement and there's lots of good FOSS server packages available. Most servers make it really easy to plug in back end applications. Combine that with ubiquitous HTTP clients and it's a super low barrier to entry.

You're not going to replace that ecosystem easily and you definitely won't replace it with raw sockets.

I just converted a site to mostly static html because the old cms was out of date and nobody wanted to pay to migrate the site to the newest cms version (for like a decade).

Well eventually the hosting provider no longer supported such an old version of php and the old cms did not support the new php... So it was either re-code the whole site for the new cms or dump it to html and html (with php header and footer) won.

I was trying to redo my project and consulting site. I did one side in hugo. The other I tried react and type script. I just said the heck with it.

I did a basic html page, using an open source css lib, cirrus[1]. Changes are very simple, and I use gitlab pages. My blog is still backed by ghost. But I think raw html is still very powerful.

[1] https://spiderpig86.github.io/Cirrus/

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"

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

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

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

Yep, the use of JS here is a solution in search of a (first world) problem. You have some content you want to share with people, along with a smattering of organization via navigation, categories and tags, some local search and possibly commenting.

That page of just text is a 1Mb download... Is this what the web has become now? Do we really need 1Mb of boilerplate for 10Kb of text?

I don't know where you got 1MB, the page for me was 363.09KB with caching off. That said, I do that React+TypeScript is overkill for a personal blog.

Parent seems to talk about unpacked. I'm also getting 356.24 KB transferred but whole 957.53 KB of unpacked data, which is absolutely crazy for a static page with no interactivity nor media.

Yes you're right, my mistake! I just saw the headline figure but still... it's only text!

I have developed stuff in react (among other things too) but horses for courses: this is an html website with some javascript sprinkles, so it should be tiny imo.

This is what happens when you tell new developers php isn't cool anymore.

"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 ?

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

Indeed, don't you just copy and paste from Mailchimp?

"Hard" is the wrong term. But I'm certainly not alone in being rusty on this stuff. Uncontrolled components, form actions, imperatively reading all the <input> values, `x-www-form-urlencoded` data, etc. If you use this stuff on a daily basis, then I'm sorry for your suffering. I haven't touched it since 2015.

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

As another user mentioned, Next.js has a 'next build' command that creates a HTML build at build time. But it also provides server-side rendering by default.

Next.js also provides a very useful function: getStaticProps. This function will be called at build time - and will provide your (now static) build with dynamic data! It's pretty cool.

I think with Next you can "build" the website (the HTML for each page is generated like it would be if it was executed in your browser) and then serve the static HTML + JS if needed, which makes for good SEO.

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

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.

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

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

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

FWIW I just finished building a (very) basic blog using Gatsby (which is based on React) and SEO scores are fine. Accessibility should also be achievable, though I find that failures in that regard are usually due to developers not caring/having deadlines instead of a lack of available tools.

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.

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.

That's indeed a janky setup :P

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

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"

Eh, not sure about that one. I don't particularly like Ruby or Liquid but I run my blog on Jekyll because it is the right set of tradeoffs for me (works on GitHub Pages, produces a static site), not because I'm particularly invested in the stack. It works, I write things in it, from time to time I extend it to support some new thing I am putting in the blog post I'm working on.

Nothing wrong with that.

Making my blog from "scratch" is a source of motivation for me to actually write articles. The experience so far has been overwhelmingly positive.

I'd love to see a blog post on how your rust/org-mode blog works.

I wrote an article about that here: https://dpbriggs.ca/blog/making-a-blog-with-rust-and-orgmode

The main changes since that article is I use systemd services to manage caddy / webserver instead of tmux sessions.

The short of it is: rocket + tera + org-mode html export + some amount of parsing. There didn't exist high quality org-mode parsing crates when I made the blog.

You can learn more about the org-mode parts from the source code: https://github.com/dpbriggs/dpbriggs-blog/blob/f4936fa2dafea...

Nice, using similar workflow for my blog, emacs export + some post-processing [0].

Even with high quality parsing libraries, when you dip into the most advanced features of org-mode (like literate programming via babel), you end up needing emacs anyway. And it's much more pleasant to tweak existing export code, than figuring out how to reimplement it from scratch.

[0] https://github.com/karlicoss/beepb00p/blob/master/src/compil...

I checked out your articles and I like your writing style!

I thought about doing batch export but ended up being too lazy to integrate it in my release flow. My compromise is to use this snippet:

    (defun make-blogging-mode ()
      (interactive)
      (toggle-word-wrap)
      (toggle-truncate-lines)
      (flycheck-mode)
      (flycheck-vale-toggle-enabled)
      (add-hook 'after-save-hook 'org-mode-export-hook)
      )

And this find-file hook in my blog template:

    # -*- find-file-hook: make-blogging-mode -*-

My new computer is beefy enough that I barely notice the export on save. I wouldn't recommend this on slower boxes as it freezes emacs for a bit.

Thanks! :) There is also 'org-export-in-background' which can export asynchronously! https://orgmode.org/manual/The-Export-Dispatcher.html

TIL. Thank you

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.

>they're gonna be around for a long time

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

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.

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.

> When did you start web development? Serious question

The question wasn't addressed to me, but I'll answer anyway. I started in 1993 and released some widely used web software in 1994.

In your last paragraph you list 13 technologies that supposedly "were all here to stay". If you asked me during the heyday of each technology whether it was here to stay, I would have answered "no" to 12 of them, and "I'm not sure" to meteor. I would have been wrong about Bootstrap because it appears to have been here to stay. I would have been similarly wrong about PHP and Wordpress. My bias appears to be to think things are not here to stay.

TypeScript is here to stay. The value proposition is just too good. And the design decisions have been good enough that it won't be replaced by a better implementation of the same ideas, as happened with several of the technologies you listed. It will go away only when JavaScript goes away, which won't be for a long time (sorry WASM).

Is TypeScript here to stay? It seems popular with frontend dev who like react. Not sure the general development community has bought in.

React hasn't reached jquery status yet. It does seem like it will be here forever but the next generation of frontend tools will look very different. Will react be amoung them? It's hard to make that jump because React is so great now why change it to match the next fad? But if they skip all fads will they miss the boat.

Is react good enough to say we can stop working on it? I don't think we know what react will end up like. It's doubtful it will be around in 20 years like php. I wouldn't bet on facebook being around after laws are passed limiting how they profit.

Angular went all-in on TypeScript in a way that React still hasn't. The React crowd is the general development community, and TypeScript has expanded into it.

jQuery is still tops in usage in the general development community.

But perhaps the frontend developer community has accepted typescript.

I'm not a webdev, but TypeScript has an appeal for me. I think one thing that clearly separates it from others is tooling. VS Code, love it or hate it, is an enabler and currently it works great with TS, both are Microsoft products. Also TypeScript _is_ JavaScript with types augmentation. In this manner it is from worse-is-better school of thought which almost always leads to a long time leader.

All technologies you listed were either a framework or something that made you bend your solution around it. For comparison you can add a type annotation to your vanilla JS code to start using TS goodies.

Comparison to Closure Compiler would be more fitting, but it was a bit awkward and it never achieved a significant fraction of TS's adoption. It probably is still used, but there is no competition between them. Also it never had as good an IDE.

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.

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?

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.

Well, if it’s that standard it could be put into the ES spec, and if that ever happens, Babel will deprecate Typescript. That’s all it would take before Typescript will become another relic.

I am not opposed to Typescript, but I am trying to show that we’ve been here before many times.

Don't forget DHTML and XHTML.

Isomorphic is a thing and is used in the technologies mentioned in the article.

Six years, roughly the time it took Angular to rise until version 2.

Sorry for the sarcasm, I've been trying to learn web development for some months, starting with the basics (HTML, CSS, plain JS) and slowly adding more modern frameworks (Bootstrap, NodeJS, ...).

The course is a few years old already and it feels like 80% of what I learn is now completely irrelevant. I just wonder how frontend developers keep up with that pace.

If I'd write a blog, I wouldn't want to spend half of my time into refactoring and migrating to newer versions, frameworks, etc. But maybe that's just me.

"I just wonder how frontend developers keep up with that pace."

Leapfrog.

You learn the newest hotness right now (and hope you're right), evangelize it like a Southern Baptist at a tent revival, ride the wave for a few years until it's obvious the wheels are coming off in one of the three or four predictable ways, then pick up the new, new thing and pretend the past never happened.

It helps to change jobs every nine months or so; otherwise, someone will ask you to do something to that ancient archaic legacy stuff. Nobody wants that.

> I just wonder how frontend developers keep up with that pace.

It's a full-time job. I have a cynical theory that this pace is beneficial to webdevs, because as long as they can keep convincing their employers and customers that they need bleeding edge frontend tech, they can enjoy their absurdly high salaries (as compared with the rest of the industry).

"I just wonder how frontend developers keep up with that pace."

Understand the principles behind these frameworks, see that they hit just some point between conflicting tradeoffs, understand problem domains and how they interact with these tradeoffs. It's not like jQuery is accomplishing something fundamentally different than React, it's just that they make wildly different design choices that have implications on composability, maintainability, etc.

After you've learned a few of these (and the principles they are built on top of), you'll understand that it's going to be pretty easy to learn the next 10 of them.

Are you taking colt Steele's web dev course on Udemy?

Ah ah yes, that's the one. Did you take it too?

I have that but I'm currently doing the webdev course by Angela yu. Heard that colt steele has planned for an update.. no one knows when. As far as I can see the big difference is colt doesn't cover react.

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.

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.

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

Having a database for a personal blog seems like overkill.

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

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.

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

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

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

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.

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?

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.

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.

Haha, 23 year old developer here. First professional dev job at 18, coding since very young though.

> "Five years ago in 2015, we were sort of coming out of Jquery."

And HTML5 was still freshly standardized, Angular meant Angular.js, and your average web app was SSR MVC with view templates injected with controller variables, made interactive with jQuery.

Rails and MongoDB was the move, GraphQL would've been released the same year, and everyone would be convinced it was a fad and huge meme.

The React that would start to gain popularity around that time was a completely different ballgame. Redux wasn't hip yet, people were still using Flux from FB or Ken Wheeler's Flux plugin:

https://github.com/kenwheeler/mcfly

What a wild ride it's been.

i think (but i'm not sure) that this blog post is a joke?

I don't think so. Check the accompanying githup repo.

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.

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

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

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.

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

In the distant past, we used client side includes. They were known as framesets.

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

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

    cat header > index.html
    cat page >> index.html
    cat footer >> index.html

    cat header page footer > index.html

("cat" is short for "concatenate".) ;)

even better! (although you may want some steps in between)

I think that personal sites are usually the ideal grounds for exploring a new technology or learning a new language/framework/cloud/fill-in-the-blank. That's why a lot of them run on often-times ridiculously over-engineered tech. If you have a site that is working for you - great! Could every developer's blog be a set of HTML files and a script? Sure. But many developers prefer to tinker and build on new technologies, and their personal site or blog is a great place for that tinkering.

HERESY!

The only true path is mine, I write .htm files in vim and serve them with nginx.

Yes, I agree, cloudyelling or not, no stack is better. I recall in my teenage years, I built 2 or 4 "CMS" in PHP/MySQL, at the end, added all that AJAX when browsers blessed us with the possibility of making HTTP calls from JavaScript! But in the end, migrating from server to server, learning more about everything, the only thing that seems somewhat stable are plain text or pure html. I know I can edit them in 2000 years, if I am still alive by then.

Nginx? Why not busybox httpd with OpenSSL sconnect? So much bloat. :p

busybox and OpenSSL? So much bloat. My blog is browsable with netcat :p

nc txt.anderspitman.net 3838 <<< /txt/19

Had to check. +1 works like a charm. You win.

Hmm, you're right, but I do use the nginx as reverse proxy for some of the other sites which are not static :P I'm also running everything in docker containers, so I'm closet-hipster I guess xD

That's what I do with my website[0] as well (just on nginx and with vim via SSH).

However, something that requires more functionality - syntax highlighting, tags, version control, easier deployments - I recently switched to Markdown + Hugo. [1]

I find it all to be very subjective. The above author clearly favors TypeScript and React, and for a personal blog, I see nothing wrong with slightly over-engineering it. His blog loads quickly, doesn't require an absurd number of network requests, and doesn't include any trackers. Fairly minimalist as far as the endproduct is concerned.

[0] https://chollinger.com/ [1] https://chollinger.com/blog/

There's nothing wrong with that approach tbh; when you think about it, the only reason to make a dynamic website is to prevent duplication, things like headers, menus, styles, etc. But there's ways around that, like frames.

as a non web developer who needed to get a static site with a consistent header and footer up I just made a makefile which watches an src directory and cats the header and footer onto each file

Everyone's "less" is different I think.

Someone has a workflow that they know like the back of their hand and has low friction... that's less. Good for them.

Folks get worked up on developer choices so much, if it's a blog and it's not doing something seriously bad ... it's their site and their call IMO.

When I was into photography one of the biggest lessons I learned was you use the tool... you're going to use a lot. It doesn't matter what it is as much as the tool should allow you to do the thing and not get in the way because you think you "should" be using something else.

I'll make a basic UI eg. menu/side panel/body/basic write interface and then use LAMP. I can add additional capabilities eg. commenting/stats(view counting) if I want... don't think I personally need anything more than that. My stuff is dynamic eg. using TEXT for body through MySQL. I use Node now as a backend but for something quick I can still use PHP which is where I came from/started with. I can host images wherever/maybe add free CDN account.

I write something like HTML and process it with m4.

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

Around the same time, Vladimir Agafonkin (perhaps in response to the above??) released 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 :)

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.

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.

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

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.

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.

The point was that they choose React by default instead of thinking about other tools which might be better suited. There was no reason to make this an SPA, they didn’t even consider not using React.

I agree about learning new things, but this isn’t a new language or syntax. At best you spend 10 minutes at the documentation and you know everything you need to know.

Is it really? You might as well say it's been a disturbing trend that developers aren't familiar with assembly language anymore.

As abstraction on top of abstraction is created, it becomes easier and easier to write software, so naturally there are now more frontend devs who aren't familiar with web dev basics. And if all you have is a hammer, every problem will look like a nail. Similar trends happen for backend devs and in devops. Is that really a problem? Only if you are a company that hired them with different expectations.

> it's been a disturbing trend that developers aren't familiar with assembly language anymore.

That is a disturbing trend.

React solves multiple problems, sure. But I would say that templating isn’t one of them, and it definetly isn’t an abstraction to something more obscure.

You have this on the backend and devops side as well, but I would argue that most competent developers there know that there are other solutions.

Maybe my experience is more skewed towards front-end developers, but I would make the same statement about backend devs if they instantly choose one technology over the other, simply because that’s all they know. (Not even because they can defend that technology with reason)

I cane here to say this. In fact, I’m wondering now if the site is actually satire!

100% Agree. But let's be honest. For most developers, the 1st priority of a personal blog is not page views, but job offers. So it makes sense to make your personal site using the tech that matches your skills.

Absolutely agree, but in this case I don't think it was the justification the author used.

We've been using Gatsby for a blog. Writing the layout in React gives us backend devs experience with it whilst staying relatively simple.

Markdown then gives us a nice way to write content and separates layout and presentation from that content.

Gatsby has loads of plugins and examples so getting started is easy. There's a plugin for an RSS feed.

I'm completely with you that a blog can be HTML and CSS, but I can clone a Gatsby starter blog and add some markdown files within 15 minutes. I see this approach as a low cost alternative to Wordpress.

You don't need Gatsby for any of those things you want to do. You can accomplish the same goal with a much simpler toolkit, like Eleventy. Or my favorite, Bridgetown, for the Rubyists out there.

Wordpress is surely way "bigger" solution than this.

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/

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

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

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

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

Any how-to’s that explain a little more how one might accomplish this with emvi? Eg using it at a front end/cms for a blog?

Not yet. We will start adding documentation after we left beta. Right now we are working hard on the new UI, which is time consuming.

You can take a look at our client libraries [1] and at this sample [2] for now. The js client is the most complete one.

[1] https://github.com/emvi

[2] https://github.com/Special-Tactical-Service/wiki

From the sample:

Client initialization: https://github.com/Special-Tactical-Service/wiki/blob/master...

Reading an article: https://github.com/Special-Tactical-Service/wiki/blob/master...

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.

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.

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.

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.

I haven't actually made it live yet, but it's just a static site once it's generated. I'll either push it to my github pages (probably what I'll do), or I'll upload it to my webhost, which I also have (but has been dormant for awhile).

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.

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!

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.

The ideal tech stack for a personal blog is whatever the person wants to maintain, update, and, most importantly, use.

Hugo is awesome! (Apart from the Go templates, before you get the hang of them..)

A year or two back, shouting REACT at everything and everyone could actually land you a new job, but now... I'd just stick to Hugo and focus on my content if I wanted to impress any recruiters.

Hugo is great but check out Zola, it is basically like Hugo but with better templates IMO.

the built in image processing is kind of a big deal for Zola that's handy. a cut above all node based pipelines that have horrible native modules for that. I kinda just want to write Vue components for posts rather than markdown so turn between trying Zola it nuxts new content cms

As a full-stack developer who spends a good proportion of my time at my day-job working with React, I totally agree. My personal website is Hugo, and entirely JavaScript free.

Same here, even a lot of my personal projects are now just SPA free by default. I do use Node on the backend, but most of the time, a templating language like pug gives me everything I need.

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/

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

Wow. This site pointed out something that should've been obvious. I had an uncompressed image uploaded.

I'm still bloated, but performance is a lot better. Thanks for the link!

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.

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.

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

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 :)

It’s much like Wordpress in the sense that you can get it up and running very quickly. The time cost is in how much you want to customise it.

Once it’s set up it’s just markdown, no ruby required.

If you're using GitHub Pages to automatically deploy the website for you, then you can't use plugins, which kind of sucks.

I use Jekyll too. It just works and I'd happily use it on future projects.

Even with ~300 posts and ~100 drafts it only takes 2 seconds to see auto-reloaded updates when I'm actively writing. That's within WSL 1 too (room for speed improvements are there with WSL 2).

It also has nice plugins to process SCSS and bundle your CSS / JS, along with md5 tagging all static files for cache busting without having to use Webpack or do anything complicated. You just reference them using a specific plugin's template tag. But at the same time you can choose to use Webpack if you'd like.

I'm not sure why the author mentioned Jekyll is too restrictive. You can write plugins to do some pretty custom things. Like, I wrote a few lines of Ruby to parse out time stamps from a list to make them clickable links so that I can jump to that position in a custom audio player, very similar to how clickable time stamps work on Youtube. You can pretty much do anything.

Another Jekyll fan chiming in. It was a good sign for me that it's not super-actively maintained, yet still commands a strong following in an arena with fairly low switching costs. Out of the box, it has most things you want and very little that you don't.

Principle 1 on the Jekyll philosophy is 'no magic', and that's why I love it. It tends to behave as expected, and what it provides is simple enough that I maintain a feeling of full control over the output. I've wrote some little bits of JS to add minor client-side enhancements, and the Jekyll plugin system is easy to dive into if you want to add some site-render features. Great tool.

Kudos to the author for putting something up for discussion. Replace the word 'The' with 'My' in the title and it's a nice exploration of where React tooling for static sites is at.

Keep publishing and sharing mate, you're good at telling a story and have more good content ahead of you.

I appreciate it! Too late to edit the title unfortunately (I posted this right before going to bed...bad move).

You lost me at "plugins" I'm afraid. I looked into ways to mix in React + TypeScript into both Hugo and Jekyll and it just seemed like an uphill battle. Based on my criteria (which I'm realizing aren't very popular on HN!) the best approach is to build everything "React-first" with Markdown mixed in, instead of the other way around.

> You lost me at "plugins" I'm afraid.

Plugins are optional. If you used Webpack directly to manage your static files you could just tell Jekyll to load them from whatever directory Webpack outputs them to and then you can build your SPA to render blog posts however you see fit.

If you're using React you would want to use a native Webpack config right? This way it works anywhere, and isn't tied into any specific static site generator.

One of my goals is to maintain that same authoring simplicity. All I need to do is create a new `.md` file in the right directory and a new blog post is created - just like you. I just don't want to fight an uphill battle every time I want to leave that lane.

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

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

I wonder if he actually tried embedding HTML into Markdown, because that's as simple and straightforward as it can be: just start writing HTML in the Markdown document, and after the closing element, continue with the markdown text. This should completely cover the requirement to embed interactive elements into markdown using a static site generator like Hugo or Jekyll without having to deal with an overly complex dependency like React.

Here's an example of embedding a WASM home computer emulator with just a few lines JS (and I'm not exactly a web development expert, so with a bit more knowledge and experimentation I'm sure this could be made much more fancy):

https://floooh.github.io/2019/01/05/wasm-embedding.html

I did, but I wasn't satisfied with that option.

I'd like the ability to embed arbitrary React+JSX into my Markdown, something which can theoretically be done (i.e. with the Hugo Babel plugin). But then I immediately realized I would have issues with importing my styling libraries (I used a custom-built Tailwind-esque set of emotion[0] classes) and using React Hooks.

As you can probably tell I have a hard time letting go of the power/flexibility of the React/SPA approach since it's all I've used for several years now.

I've been using Github pages with Markdown for my personal website and it is so simple and just works.

Haven't yet seen a reason to switch to anything else.

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

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.

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.

Yes. With static site generators you can still serve custom pages to your heart's content... It's not like you can -only- create posts and that's it.

With Hugo/Zola I set my generator to include MathJax javascript if I enabled it in the front matter of the post. Etc.

Even if you need a data API - if its just a demo (or slow moving data), you can just directly serve .json files.

I feel the YAGNI is strong in this one.

I'm not using "static" to imply "non-interactive", just that there shouldn't be a server that does any rendering/data loading.

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.

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

For a techy person, GitHub pages + markdown is all you need: 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.

I'd add to use Jekyll now (https://github.com/barryclark/jekyll-now) for a few more out-of-the box conveniences. Sadly, it's unmaintened, but the it gives a sufficient base as-is.

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

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.

Why reinvent the wheel? Use Wordpress/Ghost etc

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

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.

You can write your own theme still. I wrote my own. Mine serves 2.6kB for CSS and 16kB for app-specific javascript--mostly for highlighting of code blocks

Because writing your own blog engine is a good way to learn various web technologies that you haven't had a chance to use.

I agree, but then really you're not interested in creating blog content per-se, but in exercising your engineering skills. I think it's important to be honest about that intention both with your audience and yourself when writing articles like this.

+1 for this. I use Posthaven because it's the simplest way for me to publish blog posts plain and simple (and has been for years.)

A lot of devs get excited by the idea of building a blog and not of actually writing the content. You've got to actually have ideas to share and be prepared to put in the time to write posts.

I wouldn't even think about tech before you've got a backlog of at least 2 or 3 posts.

I recommend reading through some of my criteria (ability to use npm modules, TypeScript React components, etc). May be possible with Wordpress (haven't tried it) but sounds like an uphill battle.

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

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.

That’s not the point I’m making. http://wipmoore.info/posts/2017/09/17/security-simple-vs-eas...

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?

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/

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

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.

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!

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

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.

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/

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.

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 :)

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

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 [1] https://www.builtrigs.com [2] https://gridsome.org/ [3] https://www.11ty.dev/

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?

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.

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.

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

Like creating your own DSL, or programming language, or game engine lol. It is the fun that counts.

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

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.

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)

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.

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/

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.

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?

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

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

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.

> Three hours of package bumps

It takes less than ten seconds to type `npm update`.

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.

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

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

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

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

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.

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

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

https://www.theolognion.com/programmer-starts-a-blog-doesnt-...

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.

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

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.

Yet, here I am, currently setting up a static blog using Publish: https://github.com/JohnSundell/Publish

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

Built on Laravel + Vue + Tailwind.

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

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.

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

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.

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.

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

> I'm not sure if many people here do websites for a living

I'll hazard a guess at >90%.

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.

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

I'm not sure it is. There's a GitHub repo to go with it: https://github.com/vriad/devii

Post isn't a satire, the title is tongue-in-cheek (and a huge miscalculation).

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

React isn’t a good tool for a blog.

recommend taking a look at the newly released for Vue developers. https://www.npmjs.com/package/@nuxt/content

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

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

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

Html

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.

Why not just wordpress?

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.

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

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.

It’s using tech mostly used on the frontend (React), but using it on the backend via Next.js to generates static files that you can serve with any simple host you like.

What do you mean? It is Jamstack, you only need CDN to serve it.

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

https://hackerspring.com

Reply on news.ycombinator.com