I think the big number 1 that trumps all others when building a person website is: focus on writing content.
This is by far the hardest part. All the other stuff: it's just tangential. Wordpress, Blogger, Jekyll, Hugo, Medium, hand-written HTML files: IMHO it doesn't really matter if you don't have any content. Just use whatever is easiest to get started with and gets out of your way when writing. For me, personally, it would be writing Markdown in Vim and converting that. For other people, it's something else.
Later, when you actually have some content going you can start focusing on tooling, layout, and so forth. Converting things to another platform usually isn't too hard. But chances are, you will never actually get any content going. I've seen a lot of people create personal websites, write one or two things on it, and then basically don't do anything with it.
I've built some websites for various friends/non-profits over the years, and about 90% of the time they never actually wrote any content. These days I ask people to write content first, and then I'll build the website for them. Most of the time I never hear about it again. That's okay, it's really hard to write content and a lot of people (myself included, before I had more experience with this sort of thing) tend to be way too optimistic about it and underestimate just how hard this can be.
And people will read your website regardless if your content is good. Is Paul Graham's website the peak of web design? Not really. People still read it. Dan Luu's website? Pretty much the most basic HTML file you can get. Still widely read.
That being said, if your goal is also to learn more if you're young or inexperienced: then sure, muck around with these tools all you want. I learned a lot from building my personal website over the years in all sorts of tools (geocities, hand-written HTML, shell scripts, PHP, Python, PHP again but this time with MongoDB, back to shell script, and finally settled Jekyll) and for much of this time I didn't have a lot of content. That was okay, because I learned a lot from the process.
I don't know how many times I've had this conversation with friends:
Me: How's that game you were making?
Friend: I realized I should probably write some tooling to make my life easier. So then I started on that, and I got pretty far, but then I ran into some limitations with the engine I was using, so I decided to write my own. I got pretty far on that, but then I had an idea for a different game, so I shelved the first game and now I'm working on this other one.
Me: Right on, how's the second game going?
Friend: Well I'm investing some time to build tooling before I really get started on it.
This. Perfect description of how to avoid the real challenge.
- Spend time on inventing library instead of thinking hard about the customer need for an App
- Spend time on learning productivity tips instead of doing actual work
- And in this case, spend time worrying about the blog platform instead of writing articles
I learn this lesson hard and constantly remind myself to avoid this pitfall.
It's one of the hardest questions and it comes up on every iteration. For me, delaying my next round of features in favor of a CI/CD system was really satisfying. Now it's great that when I write a new feature, I merge to master, wait a few minutes and see it on the live site. But I'm also battling against the temptation to switch from redux to xstate, switch from dagre to cytoscape, switch from fetch to graphql, switch from akka-http to play, switch from akka to akka typed, switch from scala 2 to scala 3...
I feel like I've moved onto the next stage of this =)...
Friend: How's your game going.
Me: I've got some of the map stuff I was working on working, but last weekend I had a brainwave for a new mechanic idea that I really like, so I spent some time quickly prototyping that out.
Friend: Oh cool, can I see it?
Me: Sure, shows them the prototype
Friend: This looks pretty cool, but I don't think it fits what you're currently building?
Me: I could make it fit, in some ways it's just a resource allocation mechanic, but you're right, it doesn't quite fit, but it's done for now and maybe I can use it in something else in the future. Best get back to my game...
So lots of small chunks of progress with asides now and again when I get some zany idea.
This is definitely me... Is way easier to focus on the fun stuff and try to avoid the hard stuff. Which is how you could spend years working on something without actually finishing it.
"fun" in quotes. The tooling around a project may be fun, in the same way that junk food is delicious. But ultimately, it delivers almost no value to you. I think the reason so many hobbyists do this, me included, is that there's no _need_ to generate value from your hobby, and thus, no incentive to push for the actual project completion!
A business that does this same thing will soon bankrupt (or swallow more VC funding!)
Wait! Am I one of your friends?! ;) Reading this comment and the replies made me understand that, despite country/culture differences, we are the same :)
> I think the big number 1 that trumps all others when building a person website is: focus on writing content.
> This is by far the hardest part. All the other stuff: it's just tangential. Wordpress, Blogger, Jekyll, Hugo, Medium, hand-written HTML files: IMHO it doesn't really matter if you don't have any content. Just use whatever is easiest to get started with and gets out of your way when writing. For me, personally, it would be writing Markdown in Vim and converting that. For other people, it's something else.
This is why I find the quest for availability of anything (as opposed to the old world where everything had a high cost to entry) is mostly bad. It's easy to push out noise. Maybe that comment is noise too though :)
Exactly, look at all the free blog websites, medium, wordpress.com, blogger, etc. They are filled with tons of low signal noisy posts of people with nothing to say. It really makes discovery of good content harder, not just for me as a user, but also for the platforms to highlight that. Most often I get good stuff from websites without any styling, just plain text hosted on a little box under the desk.
I can't count the number of times I've stopped reading a Medium article because it contained information that wasn't just objectionable but was actually downright false.
Many Medium articles are even stolen verbatim from other websites. It's a cancer.
I think this follows Sturgeon's law: "90% of everything is shit".
Is it perhaps even more self-published blogs? Probably. I think Malcolm Tucker wasn't completely wrong in his assessment of blogs[1]. Yet at the same time, it also enabled a large group of people to write and get some form of audience who never would have otherwise.
There are a lot of spaces where I see this. Standup comedy (in France at least, can't speak about the US because it's older) have seen a lot of new people due to a booming scene, but after a few years people are all saying the same thing, its hard to keep going. Life is not what it seems and ease of doing doesn't guarantee long term.
I wanted to make blogs but it was not the right spirit, also it distracts you from doing 'actual' things. Anyway time will settle things out.
Oh it's definitely the case in North America too. Comedy is hard and you can't do it all without an audience, so the quality at open mics is always going to be mostly terrible. Same with any artistic endeavour really, but in most things beginners can just bumble along in private. Not so with comedy. If you're into learning it, I would really suggest a course with enough people that you get a semi-private open mic every week. It's a great way to test material on a semi-realistic audience. I've done a couple here where 2/3s of the class time was our private open mic, like a comedy version of toastmasters, and that alone was worth the money. (Hell, given you have to buy at least a drink at an open mic, it wasn't even expensive!)
I'm really not into it besides my own little private open mics in the shower (80% approval rate). It was just the fact that I saw the young dudes star just before YouTube came along and since, between podcasts, or other videos, you can witness their thought process, beliefs, aging and evolution about their business. The usual I want to follow my dreams then 'i need an average quality act so to attract enough people regularlu', the struggle of renewal. Etc etc
> It really makes discovery of good content harder
You make a fair point but do we always have to say something meaningful. Sometimes reading about some randoms day and how their dog was doing a dog version of a crip walk is mindless entertainment before switching context into that behemoth cpp file waiting for you to refactor and debug.
This is a low effort comment but my point is we don't always need to have all the lights on.
Writing is useful even if nobody reads it. Writing clarifies and sharpens my thinking. I have ideas I wouldn't otherwise have.
I wrote for the void for a long time. At the time, some folks on my immediate team found it useful. Now, a few years later, I'm still referencing those posts.
The important hard work was actually writing and polishing the idea until it was good enough to publish.
Agreed. I currently publish a bit of writing about my software engineering opinions to a website that only a couple of my non-software engineer friends know about. It doesn't make much sense to them, but their playful criticisms help me hone my ideas and hopefully simplify my writing (something I have a big problem with).
Once I added stat tracking to my website I realized I had more hits than expected.
Also, in general, it’s not really about the number of people that read it. If it’s important enough to spend time writing about it, then if even just 1 person reads the post that’s good enough.
Later I discovered others have expressed similar sentiments long before I was even born, e.g. "writing is thinking". Ah well, always nice to feel validated when you independently arrived at essentially the same conclusion as other people who are probably smarter than you :-)
One of the best things I've done is keeping a wiki and log of my notes. Turns out that other people found them useful, as well. These days there are many easy to deploy options for hosting wikis and notes, especially if you're fond of Markdown.
> Small b blogging is writing content designed for small deliberate audiences and showing it to them. Small b blogging is deliberately chasing interesting ideas over pageviews and scale. An attempt at genuine connection vs the gloss and polish and mass market of most “content marketing”.
I think Sheldon Brown's website is another great example.[1] It's a fantastic resource if you're into cycling, and Sheldon made it to Wikipedia with that site[2], which is more than most people with fancy sites can say. Actually, it's probably a better example than Paul Graham, Dan Luu, or Christ Lattner's sites as it shows that not only tech folk will read your basic looking website as long as the content is good.
My favourite bit is how to use a u-lock: put the lock around the back tire within the triangle of the frame, not around the frame itself. This protects both the rear wheel (2nd most expensive part) and the frame because removing the lock would mean cutting through the back wheel. This is widely known as the Sheldon lock strategy.
So true. I have stories both private and professional where people got angry at the site I built for them. Because it was empty. I have learned the hard way to insist on content before sinking time into a site.
Cory Doctorow has a good take on this recently. It isn't just writing content but getting ideas out there that can later become something more. [1] Doctorow calls blogging like a Vannevar Bush Memex but publishing as a series of entries that can start to create a better idea and "nucleate".
>If you’re a writer or an activist or anyone else engaged in critical synthesis, then the news-stories, ideas, sights and sounds you encounter are liable to tug at your attention: this is a piece of something bigger, and maybe something important.
>Every day, I load my giant folder of tabs; zip through my giant collection of RSS feeds; and answer my social telephones — primarily emails and Twitter mentions — and I open each promising fragment in its own tab to read and think about.
>If the fragment seems significant, I’ll blog it: I’ll set out the context for why I think this seems important and then describe what it adds to the picture.
These repeated acts of public description adds each idea to a supersaturated, subconscious solution of fragmentary elements that have the potential to become something bigger. Every now and again, a few of these fragments will stick to each other and nucleate, crystallizing a substantial, synthetic analysis out of all of those bits and pieces I’ve salted into that solution of potential sources of inspiration.
Publishing is better than note taking and there is a rigor to make it readable. However, these don't always have to be complete ideas, they can be part of the idea that is interesting. From there other iterations of new parts of that idea emerge. The writing helps you refine the topic, idea and focus. Similar to how spaced repetition helps you learn or comments help you refine ideas. [2] The ideas are sketches like pre-production, entries are inking like production and then one day a fully fledged post-production quality researched idea/product can emerge.
If it's purely personal as well, I think it helps to focus on the content by treating it as a hobby. Write what you want, post it up, and just keep doing it for yourself.
Eventually you'll start to see that you prefer writing about some topics more than others, and that content might become increasingly specialised as you dive deeper into the topic. Not a bad point to consider spinning it off if you think there's more potential there, or if you believe you've found your niche.
I'm doing this with my own writing (after who knows how many reboots), and I've dabbled with tutorial style posts with heavy code examples, silly experiments, and higher level musings about agile, work in general, as well as my personal experiences with mental health. I've learned that I have the most interest in relating my personal experiences to how we work, whether that's exploring agile or some other methodology, getting into compassion and leadership, or whatever else comes to mind. And every now and then I'll spend most of an evening writing something new. That's my niche.
I was in the same boat a month ago. However, I accumulated content that I wanted to publish, without cluttering it with commercial stuff (e.g. on medium).
Focus on writing was my only criteria. But most themes I found for Hugo, Jekyll etc. had too much layout. I finally settled for a stripped-down mkdocs (du.nkel.dev). Primarily because mkdocs has superior markdown code formatting extensions (superfences etc.). The only thing I am missing is easy integration of a self-hosted open source comment system.
Regarding the OP's website: Unfortunately, it feels too cluttered. Examples: Why the header line `Home / Blog / ...`? I can see this from the URL. Why duplicate the title? Why duplicate urls next to the icons (facebook etc.)? Too much space without any content. Links/Contact/Search.. all mostly uninteresting for the majority of visitors.. Yes, mkdocs has search, too. But I disabled it - no one will use the search function on a blog.
Thanks for the feedback regarding the clutter. Some parts have indeed grown beyond what I originally planned. I was able to remove the breadcrumbs and it didn't feel like a loss. I also shortened the social media links at top of the page since you were right to notice on some pages they took lots of space for no good reason.
I have the opposite problem. I started writing content, then started writing custom markup to convert the content to HTML. But I started having so much fun writing marked-up content, it took over. So I have a content surplus.
I know from past experience (personal and that of others) that getting content online is fairly easy. The part I don't get is how to find an audience for content that 'is good' - but doesn't have broad appeal. Publishers know that stuff, who else does?
Blogger, Medium, et.al... will these free services be around in the future after their money dries up as they find a sustainable business model for hosting your thoughts? Will you own the data you published if it's on some social network?
I just started creating content and also sampling ways in which to put it up. The content I am creating is a book teaching technical topics in English and other languages.
I will use formulas occasionally. I expect there will be a lot of diagrams (made via Inkscape and exported as JPG).
What is the easy way to format this material out as a book with chapters? You mentioned Markdown in vim. Could you give some pointers on how I can get started that way
as a corollary, i wish the writing experience for more varied environments was much better. it's hard when you want to jot something down on the go and keep drafts in sync across devices without getting caught in some cloud subscription service. the tablet writing experience without a keyboard is still subpar, not to mention phones.
It’s a good example of how each person’s experience guides their sense of simplicity.
This person felt like Wordpress was too complicated, despite it being a system you can use to set up a site with literally no coding at all (using Wordpress.com or one of the many hosting providers with one-click installs). You can live-swap themes to see which one you like, again with just some clicking.
Meanwhile he is hand-editing .htaccess files to get the URL structure he wants and switching from JPG to WebP (a change with no real-world SEO value) to try to help SEO.
This is not to condemn or criticize! It’s just that when people have experience with having their hands directly on software development, they may be more likely to prefer a web stack that mimics that feel. “Easier” for a coder is going to be different from “easier” for an artist with no coding experience. Look how many artists use Squarespace or Wix for example, which did not even make the list for this effort apparently.
I agree, but I also think that when developers talk about simplicity it's in terms of understanding the bits and moving parts that make the whole.
Like creating a nextjs app, or a wordpress website, those things are all "simple" to execute - as in easy - you type a command/click somewhere and it's done, you've got the structure and all plumbing done. You can understand all the pieces after working with them for a while and they mostly cover everything you need for their use case (which in this case makes some things simple, creating a new page, or blog entry, uploading an image, etc).
With Squarespace and such it's the same, it's simple, specially for someone who isn't a webdev - but what it's doing is not simple and when you need to stray from what it does and how it works (specially in visual builders) simple things become very complex or even not doable. They're probably still the best tools for a given range of websites/purposes, even if you know how to code, but definitively running transpilers, pre and post processors, chunking files, merging code, scoping blocks of html and css, stacks of middleware, etc, is the opposite of simple.
I think a lot of the difference come from a conflation of concepts. For example, you initially talk about simplicity, but halfway through your post you start using the word "easier". In my view simple and easy are points on two different axes. In the best of worlds you get both, but as an example, a smartphone is a very complex system that is relatively easy to operate, and a unicycle is a very simple system that's relatively hard to operate.
The boundaries only break down when you need to peek and poke beyond the abstractions that make the complexity manageable. If your phone breaks down and you have to troubleshoot and fix it yourself you'd probably much rather be dealing with a unicycle from a practical point of view: there are only a handful of things that'll ever break, and you'll determine which thing broke at a glance. The potential for surprise in easy-complex systems is a good thing to keep in mind when operating a website I think.
> switching from JPG to WebP (a change with no real-world SEO value) to try to help SEO.
Nitpicking, but it _will_ have SEO value once Google rolls out Core Web Vitals this summer. Not massive, but it’s a very easy way of scoring a few perf points.
WebP offers basically no advantage over good ol’ JPG in lossy compression of photos, which was the use case for this site.
I hear you on Core Web Vitals, but most sites will have a long list of more impactful changes to make before they could expect to see any measurable rank improvement by switching from JPG to WebP for photos.
There are other ways of getting traffic besides Google. Sure, tweak your site to please their algorithm and achieve better SEO, but always be scouting for other traffic sources.
Just be careful. The free version of wp.com embeds AD-Code and tracking scripts into your page so they can make money. The paid version is without ADs however. If you want privacy, the one-click installs (like you said) on the majority of hosting providers is better.
The free version of Wordpress.com has become gnarly in recent years. They even use a dark pattern to trick you into thinking you have to buy a domain for your blog when in fact you can always just use a wordpress.com sub domain.
I think this is a good observation of the breadth of knowledge required to actually boot up a site. You're right: twiddling .htaccess while complaining about WordPress complexity seems absurd since the former is such a lower level of abstraction. I wonder if this is just due to poor documentation of wordpress, but I googled how to create personal website and there are tens of thousands of personal website explaining how to set up a personal website. I'll go one step further and criticize: this write-up is too lightly researched IMHO: if it were a research paper I'd give it a D.
Wordpress is easy... if you want it to do what it expects you to want.
Writing an article in WordPress is easy... if you have persistent Internet access. I often don't.
Or, suppose, you want to migrate to a different hosting provider. Something very easy suddenly becomes very hard.
Or you find out that something you were writing about would become illegal. Good luck taking down your wordpress and reading through the content in the browser, with no grep.
Variables from lops can bleed through all code imports. Nightmare!
You find a bug in wordpress... Good luck ever finding it.
You got virus on wordpress. You'll never be able to get rid of it.
You want to add a form? Easy, plugin. Next week upgrade, all broken. Good look making things working again.
Actually all these problems above are solvable... But now you wasted three same time as doing it properly. And you still end up with a piece of $hit...
I think it's more about the type of things you want to waste your time: hacking wordpress or doing beautiful robust engineering.
One is pleasant, other is a nightmare. That's my view, might be different for others.
I'm just building websites with gatsby with some extra features that can reused in new websites: when I fix one website, all websites will get that fix. With wordpress it's not really easily doable.
I'm running more than 100 websites this way and more and more people and business come to me because they want 100 Google page speed and don't want to be bothered with wordpress or doing their own gatsby (even gatsby is not great out of the box).
If you're building a personal website from scratch in 2021 (especially a blog), I strongly recommend Hugo (https://gohugo.io) over Jekyll. I had used Jekyll for a decade and very often hit random quirks that have been completely eliminated with modern Hugo. However, there's a bit of a migration process if you are moving from Jekyll to Hugo despite both being Markdown-based blogs.
If you want a more advanced framework for a personal website, I recommend Wowchemy (https://wowchemy.com/) on top of Hugo, which gives the tools needed out-of-the-box like lazy loading/SEO/object-oriented collections, albeit with a massive learning curve.
IMO one of the big advantages of Jekyll is that you can extend and modify it to no end, which is a lot harder in Hugo. The choice of language plays a big part here: Ruby just makes this kind of stuff a lot easier than Go.
On my website I do stuff like:
- Run Vim to add syntax highlighting (with :ToHTML).
- Add a tag to include a code example from an external file (much easier to test/run when writing!)
- A tag to list "related posts" based on tag.
- Overwrite the standard date formatting function so I use my own date format, and add a custom number format function which uses a thin space to separate thousands.
- Generate pages for my Go "vanity paths" based on just an Array in a Ruby plugin.
- A tag to include images as base64 inside the page itself.
- Run some regexps on the generated HTML to add/change some things.
- Aside from the .html page, it also generates .txt files for people who prefer this and/or usage on Gopher/Gemini (actually, I removed this as it never worked quite how I wanted, but with a little bit of extra effort it would have, I just couldn't be bothered).
Maybe it's crazy to do some of these things like running Vim, but I like the Vim colour scheme and semantics and it's a lot easier to use this than configuring some library. I wrote much of this years ago and has been working without problems ever since, and it didn't even cost me that much effort.
Either way, my point is: this is a major advantage of Jekyll. Hugo probably has some of this by default, but last time I checked you couldn't even add a custom template function. Once you reach the limits of what you can do with Hugo: you're going to have a hard time. If you hit the limits with Jekyll: no problem, lemme just whip up some Ruby code.
I never hit "random quirks" though, in spite of all my hacky stuff.
There are some cases where re-writes in Go or Rust are just so good that the "originals" become almost entirely obsolete. Hugo is one of those tools, ESbuild seems to be another, or ripgrep for Rust for example.
> There are some cases where re-writes in Go or Rust are just so good that the "originals" become almost entirely obsolete.
Why's that?
I use Jekyll here and even with over 500+ articles (posts + drafts) it takes around 2 seconds to get live reload feedback in Jekyll while writing. Jekyll also handles the entire asset pipeline complete with md5 tagging of assets without using Webpack or any build tools. It also lets you write plugins with a few lines of Ruby to add new template filters and other things.
For example I wrote a custom Jekyll plugin that lets me write bullet lists like this after a specific type of header:
- 0:45 -- Something
- 1:45 -- Another thing
- 1:03:31 -- And another thing
And it automatically converts the timestamp numbers into clickable links that jump to that point in an audio player.
AFAIK Hugo has no way to do anything like that, at least no where near as easy as Jekyll. With Hugo wouldn't I have to compile a custom build of Hugo for such a thing? But with Jekyll it was adding 1 file into a directory and writing 20 lines of "business logic code" to add a new filter. Now I just do {{ content | audioseek }} when I want clickable timestamps.
I also wrote another plugin that automatically adds certain rel attributes to external links by adding {{ content | extlinks }}.
Things like the above are why I continue using Jekyll because personally I haven't found another SSG that comes close to how easy it makes it to add custom behavior. I don't mind the 2 second live reload wait and I wouldn't switch away from Jekyll for a speed boost alone. At some point the speed is "good enough". Sure I would love a 100ms reload but I wouldn't give up everything else for that.
I'm not sure if either of the things you linked would solve this specific problem but I also only skimmed the pages you linked.
For example the Jekyll plugin for the timestamps:
1. Looks for a specific type of post and then it scans the body of the post
2. Looks for a specific header on the page and then grabs the list right after that header using an xpath selector (no special classes needed)
3. Goes through all of the elements in the list
4. Parses out the timestamp from the line and changes the timestamp into a link with a data attribute containing a specific timestamp format
There's no custom Markdown or even classes added to the list or post because it lets you naturally write your Markdown list how you would if the feature didn't exist, and the plugin's goal is to add in that new behavior behind the scenes. This lets me keep all of my posts really clean[0].
It would be super interesting to see a Hugo equivalent for the audio_seek custom filter. I don't expect you to spend your Sunday afternoon writing such a thing but it would be cool to see a direct comparison of how you would implement it with Hugo. It might get more folks to move to Hugo too, because the main thing that keeps me using Jekyll is the ability to create adhoc customizations without needing to fork Jekyll.
Not 100% sure if that would work, but on paper business logic LOC would be about the same and using a regex is the more canonical way to handle this sort of processing anyways.
I also ran into similar issue with Hugo, where I'm out of the happy-path. Those short codes didn't work, complex processing of some unique bits of content was easier in Jekyll (but also other script-lang based tools) than it was in tools like Hugo.
> with a layout override to call that modified filter instead of the normal content
Would it apply to all content in a specific layout or only specific bits of a certain layout?
With the way I have it set up with Jekyll, only a specific post gets the audioseek timestamps added to it, because I wouldn't want it to apply to all lists on the site. I also happen to share a single layout for both podcasts and interviews and interview lists shouldn't get processed with audioseek'd timestamps.
With Jekyll this is super easy to pull off because it's only a custom filter. It can be applied to the specific content I want without having to worry about layouts.
I considered switching to Hugo a while back but ended up sticking with Jekyll for the extensibility, like a few others have said. I'm particularly interested in image thumbnailing and format conversion since so many of my posts are image-heavy. I often found that to be my biggest and most frequent barrier to writing since plain text only goes so far on the modern web.
In Hugo, every solution I've seen uses a custom shortcode or custom Markdown image template-rendering hook along with Hugo's build-in image resizing. Many posts even suggest converting image resources to different formats with an external tool. It does seem like the image handling situation in Hugo is improving since it just gained WebP processing support in addition to JPEG: https://gohugo.io/news/0.83.0-relnotes/
Jekyll plugins offer way more power than a shortcode ('include' in Jekyll-speak) can, like how the author of the OP is using Jekyll-Picture-Tag. I've been working on my own similar plugin to handle converting and embedding my site's images, videos, SVGs, PDFs, text files, fonts and weird retro computer formats, etc. For example I can embed an SVG using standard Markdown syntax like `` and get a <picture> tag with the SVG plus rasterized JPG+WebP+AVIF+whatever at multiple sizes all totally seamlessly: https://github.com/okeeblow/DistorteD
Very happy the existence of Hugo lit a fire under the Jekyll team to work on speed though :)
I also tried Hugo in 2020 for my personal homepage and thought it's incredible hard to use if you do not want to use it as a blog. My homepage consists of multiple different pages with different designs and the hoops I had to jump and documentations/blogs to read to find out how to do it was much more time than I wanted to invest in this topic. I can't recommend it at all.
My main gripe that it has expanded and changed too much over the years, it seems they want it to do everything now and it's about as complex to configure as it is to write your own simple tool...
Sure, some software needs to be cared for and polished, but hugo was one of those where I converted my site to it, then it simply ran. It's a binary running locally, I don't care about security updates (as I only run it on my own user input) and until I stumble over a bug I can keep using this version as long as the OS will run it..
I'm using Hugo for my blog, so this is good to hear. My only complaint so far is having to embed front matter in my .md files. Mixing JSON and Markdown feels wrong.
Question: my blog is a git repo of .md files that I run through Hugo and then rsync to my host. Wouldn't it be possible to write a web app that just hits the repo on Github and renders to HTML, and skip Hugo altogether? Are there downsides other than performance?
The main point of a static website is that you don't need a web app to serve it, any web server that can serve files (all of them) will do.
I use my own static site generator to generate the final HTML/CSS (but could be using Hugo or Jekyll or anything else)... when I push the generated files on my gitHub repo, Netlify automatically detects it and starts serving the new files. That's pretty much what you probably actually want.
Takes less than 5 minutes to get it setup.
Note: I have no afilliation with Netlify, just a happy customer.
Front matter is the same with both Jekyll and Hugo, and it's certainly better than the alternative for per-post config which is an unavoidable constraint.
It's theoretically possible to do automatic-render-on-commit-and-sync with GitHub Actions, although I haven't investigated it. There wouldn't be much of a performance hit either.
It certainly does look good for books and for LaTeX documents though. For the Web the problem is that it requires learning several new CSS properties and learn about some typesetting issues ("rivers" and "ladders").
The following does definitely look very good to me:
We're 25 years in, at some point browsers have to get a proper hyphenation and justification algorithm. With a proper H & J algo and high DPI screen, I don't see why it couldn't look great.
I haven't looked in to this, so I can't judge the veracity of this claim.
However, in general I find that hyphenated text on screens never looks quite right to me, even when done right (even though it looks fine in newspapers and magazines). I'm not entirely sure why; I think that it's because on the web lines tend to be a lot longer than in newspapers and magazines, which are usually very narrow columns by comparison. Or maybe it has to do that the screen is typically further away from you. Or maybe both, or something else entirely.
I do think it's valuable to have, especially for narrow columns (e.g. sidebars) or smaller screens. But it's not something I'd want to use on my website like in the example you mentioned.
I recently redesigned my personal website and it looks very fine. The trick is to actually learn about the tricks you're using, as with everything in life. Oh, and you need to set `<html lang='??'>` .
Iirc the reason browsers don't have knuth-plass justification is because it runs in O(n^2), but even so my research tells me justification reduces retention because your mind retains the "shape" of ragged text. I don't have the article on hand but if I find it I'll add it later.
A bit late but [1] shows equal comprehension between justified and ragged-right but much faster reading speeds with ragged right (post-stroke patients in Russian). [2] shows slightly faster reading speed with justified text but less comprehension on a delayed test (also in Russian). [3] has no empirical data but cites articles and claims comprehension is equal between the two formats but ". Poor readers, however, read unjustified text more quickly than justified text."
I would say it's not overwhelming, but I'd go with ragged-right to be safe.
Maybe it require some training but on my phone I find this example low readable, my speed of reading is slowed and my cognitive overhead/eye movements are increased.
To me it's the kind of UX thing that look good if you don't look at it well but once you have to it's just plain inferior.
That looks absolutely terrible and amateurish on iOS Safari, strengthening the point about browsers needing a consistent justification engine.
It actually distributes space between characters rather than words as is the norm in print (and is partly why books and magazines don’t look like a teenage yearbook editor’s first day with InDesign).
Ironically I find the first article easier to read when justified (side-by-side comparison at https://ibb.co/9tvZ75W). When not justified the uneven lines get my attention and I'm losing my reading rhythm. As the article lacks a published date, I do not know whether this is result of technology having advanced since. Nevertheless there're spaces that look bad around the images but maybe a better web design could help with this. Also there's the usual lack of any surveys that articles on design tend to have.
The very first support link it gives disproves the article: hyphenation IS widely supported. In my opinion the article reads as if the author collected evidence to support his preference. Now, it does seem as if text justification is a highly subjective matter.
Thank you for the tips. As for justification, I actually compared my "before" and "after" layouts and found the one with justification better for my taste. The link you posted has some very interesting thoughts, though, and certainly justified text on a web page is a completely different level of typography than text justified e.g. in LaTeX.
Because if it's fixed, can, starting with the first character, go through the text adjusting the space between words and letters (carefully and subtly so that optically it doesn't look as if there has been adjustment unless you look very closely) and swapping out words/changing sentences/re-ordering until the text fits almost perfectly in the space.
(This is also why justification can't ever really _fully_ work on the web in a general sense, can only have an approximation and the question then becomes if it's worthwhile to have that or whether it's just more trouble than it's worth)
In fixed space, like newspapers, human editors would add or remove words in order to make the end result aesthetically pleasing. Non fixed space lacks this feedback loop, so you can end up with text that is both justified and awkward more often.
I think you should justify text. The article you linked is old and hasn't caught up to the development in browsers. It is correct about text being ugly if justified without hyphens but most browsers nowadays support hyphens [0] and have for some time. For a good example of justified text together with hyphens, see: https://www.gwern.net/Holy-wars.
When you justify text for print, you almost always have to manually tweak the result to avoid wrong spacing, bad hyphenation, rivers, ...
Justified text and automatic layout do not (yet) go hand in hand.
Left aligned text has also its issues but, most of the time you won't notice them on screen.
The article you're linking looks better than average, but it feels a bit too much like a text wall to my eyes...
I guess that the lines contain a number of characters and words that is big enough to allow a more even distribution, at the price of longer lines that are less comfortable to read.
For me the rule is still that text that is automatically formatted should be mostly left aligned.
But indeed, if you correctly setup the hyphenation, you can produce something that is somehow OK.
I suspect the wall-of-text effect isn’t caused by justification. Gwern is using first-line indents to signal a new paragraph instead of spacing them, as is more usual on the web.
+1 for skipping justification, which universally looks like ass on screens.
“What about books and newspapers?” I hear you ask, to which I reply: print had expert typesetters eyeballing the whole thing…and even then, some books and newspapers look like ass unless you’re squinting from 10ft away.
Trying to make text fit in a box is an aesthetic choice, but it is technically inferior from a readability standpoint. It was usually paired with columns, which improve readability and would do so without justification.
If a personal website for a software developer should reflect current capabilities or employment trends then it should conform to this checklist:
* Use React. Every paragraph, yes each one, should be a JSX component. If anybody asks you about this just respond with something unrelated about test automation.
* A fancy logo front and center above the fold over a gradient. Catch that eye but leave the user hanging on what the site is actually about because pausing for dramatic effect is most important.
* Mention somewhere that accessibility is important and stand behind that statement with great pride. In the next statement forget about accessibility completely like a bad case of mania and add a bunch of unnecessary JavaScript and specifically describe how much you hate JavaScript.
* Something about Agile. This should compromise the bulk of all human consumable content. It doesn’t have to any make sense and can be completely out of order.
* Actually push all content to the end and just worry about which tools to use then use Twitter feeds for all content.
Sarcasm aside actual content comprised of words makes for a good litmus test to discriminate interested users from people who find such things a chore. It’s the difference between employment recruiters and internal developers filtering those potential candidates.
> I also spent a little time on redirecting the addresses of [...] my old website to [...] the new one. Failing to do this would have cost me a lot in search engine rankings since all the incoming links collected over the years would be gone [...]
I was disappointing that the main reason that they valued keeping past links alive was SEO. To me the innate benefit of not breaking links and bookmarks on your readers (or future readers) should be enough.
This is a very good point - good you brought it up. I do care about not breaking links, though I did not mention that in the text. Actually, you can still reach my site by using the address it used even before the previous one, and there are still links on the web using that very old address, thanks to two levels of redirects.
I've been having decision paralysis about setting up my own personal website. I would personally like to avoid some bloated frameworks or tools like Wordpress, Squarespace, Wix, etc. I'm also not really sure I even want a blog. I'd like to have a collection of articles that aren't just written once and then moved on from but rather are updated and refined over time. I've looked at static website generators, but don't really feel they're that simple.
So I've been looking to just do things from scratch. Maybe it would be nice to write articles in markdown and have a custom static website generator that takes these and publishes them. It could be a fun F# or Racket project. The idea of simple HTML and CSS being loaded for maximum speed and old school web with a little something for interactive graphs and other things is something that sits well for me.
Although, I just took on a new Elixir job, and something with Liveview and Livebook for interactivity could be really cool.
Anyone else struggle with this and end up coming up with a solution or finding one?
> Maybe it would be nice to write articles in markdown and have a custom static website generator that takes these and publishes them.
This is what I do. I have three static websites, each has a small (few hundred lines of code) Python script rendering them. I find it worlds easier than existing static site generators, where going even slightly off the happy path is usually a huge pain.
Some examples of custom things I've implemented, which were basically trivial due to doing it myself:
- A probability table renderer, which produces output like https://i.imgur.com/siNN5Tu.png from a CSV of values and probabilities.
- A custom syntax for acronyms, which get the mouse-over text and a link to a glossary entry inserted (with automatic pluralisation too).
- Custom rules for rendering markdown code blocks, to handle things like rendering GraphViz code to an SVG and inserting that in the page.
I usually use jinja2 for templating and pandoc or pymarkdown for rendering the content.
I've intentionally NOT made one static site generator to handle all three sites, as this is where the complexity and inflexibility of existing static site generators comes from. Specialised tools which can evolve independently are inherently more flexible than one complex tool which tries to do everything.
People often say that using a pre-existing static site generator means you don't have to implement features like hashing assets, rendering feeds, or handling tags/categories yourself. Which is true. But those are all very easy to implement, so it's not much of a selling point.
I am struggling with the exact same problem at the moment.
I am currently contemplating using just http and php, whereby I just save my posts as textfiles along with maybe 1 image file in a folder ( say /posts/{id}/) and the php just takes all those and turns them into HTML using some type of template like the author mentioned. Then do some basic SEO to improve visibility.
I'm no webdev myself and have no experience with building anything on the web but I think this could suffice.
I've been using the minimalist ssg [1], a ~187 sloc sh script to generate my site [2], so that I can avoid dealing with more complicated, messy solutions and to make it easier to switch to a custom site generator if I decide to write one in the future. I'd say I'm pretty happy with it so far.
I feel the same about static site generators, which is why I'm working on Lancer[0]. It's designed to be as close to plain HTML as possible, with just enough features to support generating static sites, and even SSR and server endpoints.
For example, Lancer doesn't have built-in support for markdown. However, it supports arbitrarily transforming your <template> tags so you can add markdown support to your website with effectively a one-liner[1]. It's this type of approach that I hope to build a framework that requires as little framework knowledge as possible, while being flexible enough for all content-based websites.
But, I think, doing things from scratch can be risky: ready-made solutions have a learning curve, but they also do lots of useful things which you might need, and writing all of that from scratch is really lots of work.
For me, it's always about find the right point on the spectrum between "write it myself to do exactly what I need" and "huge, bloated thing that claims to do everything anyone might ever need"
I used PHP for writing a personal page that can make use of functions to avoid repetition. Then I generate static pages (one per language) with a shell script. Another script to scp the static pages to production. Simple and efficient, no framework, no bullshit, two files of helper functions and one CSS.
I chose Jekyll as a static site generator because it was simple enough to understand what it does. Its build step is just taking a directory of markdown files and converting them to html pages using a template. It feels like the next logical step after writing all pages in html by hand.
I love how the first comment at the end of the page asks which CDN and which load balancer the site is using, as if he's filling entire racks with this simple static website. Absolutely hilarious.
Turns out Nginx can serve a lot of static pages very quickly. The largest page on my blog is 70KB. On a VPC with a gigabit connection, I should be able to push about 1,400 requests per second.
My blog is never going to be so popular that I need to support more throughput than that.
I think oftentimes the benefit of a CDN is not (just) performance, but also cost--sure, nginx can serve your pages plenty fast enough, but how much is your hosting provider charging you for that network traffic? The answer is generally "more than a CDN would be" (once you've used up your free bandwidth for the month, of course)
I agree with most of these sentiments. I've often wished I started doing something like this 20 years ago, and have a website which has been around for that long. So I decided to do the next best thing: Make a website which COULD HAVE been around for 20+ years, and make it compatible with the 20+ years worth of browsers since 1995, around when I started using the Web and HTTP/1.1 became common (the latter allowing support of cheap shared web hosting using the Host: header)
I had a website I built using Dreamweaver in college 15 years ago. The hosting was provided by the school, everyone had a FTP server under their name that they could put files on.
The site of course was removed after I graduated, but I still had some of the articles I put on in Word form. Many years later, when I learned HTML/CSS, I'd post those old articles on the new sites I created. I believe I still have some music reviews I wrote wayy back in 2004.
I agree with comments saying that a key point is producing content. I'd spent a couple of years of considering starting a blog (with no commercial/monetisation, but somewhere to post thoughts on technology / games / books I find interesting) and trying out various platforms/solutions and producing very little. Then I finally got started with a simple Hugo/Github/Netlify setup, with the plan of adding more technology bells and whistles if readership or my inspiration to continue producing content justifies it.
A question on which I'd be interested in views: how important or otherwise do people consider the ability to sign up for a mailing list / newsletter to be informed of new content? I dislike the in-your-face modal pop-ups etc. - but am wondering if readers, if they like existing articles on a site, would appreciate a low-key, unobtrusive option of signing up for an email notification.
Um, not if the user signed up for it? Believe it or not lots of people sign up for email lists — especially editorial ones but also commercial ones — on purpose. Not just normies either, I bet there are plenty of people on HN who've subscribed to a bunch of bloggers' lists. I certainly have.
Thank you for the comment. The site already has RSS, and I'd agree there are good technical grounds for preferring it, but I get the impression that its use among users is declining, which is why I was considering other mechanisms. I find it an interesting point of view to consider a feature which alternatively allows users to opt-in to email notifications - but which doesn't disadvantage them at all if they don't - as "user-hostile". (But of course I've seen sites which want to coerce visitors to hand over an email address to be able to access the content they were expecting, and depending on context, I can see cases where that could be considered aggressive.)
It's super important. Most people don't use RSS, and social media doesn't give you a direct relationship with your readers, you're at the whims of the algorithm, so even if they want to keep up with your content, it may not be surfaced to them.
Surprised not to see ghost in here. They have a paid managed version at https://ghost.org and it is fairly easy to set up with any of the public cloud providers. I have set mine up with Digital Ocean (https://ghost.org/docs/install/digitalocean/).
I started writing blog-like text entries in my .plan file in the mid 80s, so others could use finger in UNIX and read what I was thinking.
I later learnt HTML just so I could keep writing my thoughts. I lost content, I got spam, I had to learn to defend myself when the Internet became aggressive. It wasn't like that early on. We believed it was for the betterment of humankind. I know, how naive.
I went through the "Wordpress phase", the static phase (Pelican, then Hugo) but I ultimately decided to define what I wanted to share, and I realized few people really cared about long writings, but rather, the nitty gritty. So I chose to use the Zettlekasten model where I focus on specifics, narrow, single-topic. I chose TiddlyWiki (the Drift distribution specifically), and I have two files, one public, one private. As simple as that. My default is public. If I have a thought, learning, recipe, experience, anything that could be useful to anyone else, I put it on the public file. Otherwise, it goes in the private. As simple as that.
And thanks to CloudFlare's JS compression, the whole thing works great for me. https://ramirosalas.com
I have a personal website, once that has been online since 1997. The reason I have it is because I have written a lot of content over the years, and because having it on my own static HTML page website is because why should I write a bunch of content for free to benefit a social media website or commercial blog service? More sense to have it on my own website.
I spent some up front time setting up Supervisor, Jekyll, and a light server listening to Github actions that, upon an update, just pulls the latest on commit and reruns the static publisher. I even have a staging branch/subdomain.
The first point - easy to update - is critical. If there is any friction to the process, you will just never do it. Your personal time is inherently much more valuable than your work time.
And if you are creating your new personal site, I highly recommend scrapping everything you know and doing it with Grid and Flex.
Hosts like Netlify also do this magic. Pushing to Master on Github runs any Jekyll plugins you want and deploys the site, including things like image optimization and CDN if you want.
> Longevity: since I would be putting in a lot of work, I wanted to be able to expand and maintain the site for at least 5-10 years without major overhaul (but, technology being what it is, I was aware I would probably have to perform some maintenance work onhttps://news.ycombinator.com/item?id=27173728ce every 3 years or so).
With that criteria, I wonder about the choice of Jekyll, which is huge and complicated. I'd be looking for something with fewer moving parts.
I suppose one nice thing is by that limiting yourself to static html output it becomes easier to switch from one generator to another.
A similar worry has led me to use the PHP-based PicoCMS. Basically a thin glue between Twig templating and markdown with minimal dependencies.
Even if it goes totally abandonware, PHP tends to pretty carefully manage backward compatibility and it should continue to function for quite a long time, and much longer with minimal patching.
No major infra dependencies (database, pipelines, serverless…) or special config requirements. Throw it at any bog standard host with no config and it will just go. Like… `pkg install nginx php-fpm php-mbstring` and drop it in your web root and it’s working kinda simple.
And, worst case… it’s Twig and Markdown. There are a dozen other things I could migrate that to without much hassle.
Because, yeah, something with as many moving parts as Jekyll sounds a little heavy and complicated for “a decade of longevity with minimal support”.
I've always adored the idea of personal sites which do not require any build systems or databases, or in other words static sites. On multiple occasions over the years I've had the ambition to start working on my own and maintain it, hence the reason I created(shameless advertising, I know) https://rorigami.site/
But really my main motivation was to have something that's self-contained and does not require any maintenance whatsoever. Ironically every time I decide to make improvements or use it, something urgent immediately pops up... Oh well...
Exactly for longevity (5, 10, 15 years), I will not use any static site generator. I know it sounds ridiculous, but I have better confidence of longevity on Wordpress / Mediawiki than static site generators.
WordPress's core APIs might be very well-supported, but most of their plugin ecosystem doesn't have such guarantees.
I recently tried to revive a 2014 backup of my local hackerspace's website so that I could staticize it, but it wouldn't look right even with the same PHP and MySQL versions, because many of the plugins stopped working.
I think I would have been better off scraping a copy of the site from Archive.org.
Yes. Many plugs will retire, but most mainstream plugins should work or easy to find replacement. A personal website / blog without too many customizations should be easy to revive.
A static site generator that works now will probably still work in 10 years, even if updates cease. And it will be safe to use. After all, it just churns out HTML that you put somewhere.
The same can't be said of WordPress or MediaWiki. You will not be able to run these at all if they become unsupported and will have to migrate, or risk facing security issues.
Sure, SSGs are not for everyone, but the potential for deprecation isn't a major issue, at least for a personal site.
I pay for hosting and Wordpress, is super cheap, I wrote soem blog posts in 2-13 then got bored, the site is still up and is up to date, with no effort from me, no code or sysadmining about. If I need I can start blogging again tomorrow from a browser or I could get a fancy app but if you used some non-standard thing you need to keep admining it, and if you maybe stopped like me for 8 years when you get back you probably forgot all the details about what stuff you used.
If for some reason all those companies selling and supporting Wordpress would not be allowed to continue using it by magic I am sure they are capable enough to migrate it for me.
My only experience with Wordpress is with a simple blog and not complex sales pages or other stuff that require using SEO/sales/magic plugins. Worst case scenario if you are a developer you can dump the wordpress database into a file then write a script and generate plain html files or migrate to some other format.
Wordpress has export function. I am almost 100% sure, if Wordpress dies its replacement will be able to import Wordpress exports, or even its database.
None of the popular static site generators match Wordpress or Mediawiki for how long they've been around. Although for me personally, the established ones are old and popular enough. E.g., I use Pelican, which has been around since 2010.
I really wish more design docs / project reports looked like this article - talking about the whys, goals / non-goals, options considered, prototypes built, challenges, and solutions, learnings and next steps. Kudos!
I discovered Hexo when I decided to build myself a micro-blogging site about my code learning experiences 3 years ago. I was impressed with the whole experience then - I was after a simple-yet-not-stupid static site generator and that's what Hexo gave me. I did have to write my own tooling to get the site to deploy to AWS S3 but I assume that they will have a plugin for that sort of scenario nowadays.
I don't have a personal website, but I operate various online services like pastebins, image uploader sites, and other online tools that many people use. People would get more utility out of those than a personal blog, since I learned (a bit late) that I'm not especially good at writing and communicating my ideas very well.
I can get across an idea, but it usually misses nuance and I find writing personal stuff very embarrassing later on down the road, when I start regretting ever hitting publish. Out of all the personal blogposts I have written, roughly three I am proud of, the rest just embarrass me.
Content is king actually that keeps the site going. Even if you have a personal site and only users are 10 bots and 20 random users.
First website I had made is in 2007 it was full flash site. It was pretty much decent and hosted it on bravehost. After hosting it, I was done, didn't do anything much. Ten years later 2017 I upgraded my site it was full handmade with css and it had lots of things planned but again after 5 posts didn't touch much.
After that still my thought was making the site more attractive and I had ideas for posts/articles. I was collecting stuffs
Looked into SSGs, picked Gatsby for speed they had some starter templates, picked the one from LekoArts started using it.
I had read fantastic blog posts from certain people from HackerNews but they had only one or two posts with the depth they had in their posts, I wish they had written more.
Looking at all of that consistency is the key. Here I have noted down the steps on how I did it and I follow it to add posts mostly once a month.
> Another matter, one of personal taste and experience, is that as a developer, I am used to working with text files, and editing a bunch of files in an IDE felt like a convenient option compared to having to edit each page in a web interface in the browser.
I'm a big fan of "Jekyll Admin" as a way to get the best of both worlds:
It took me about an hour to set up an AWS static website backed by S3 and cached by cloudfront. I use Jekyll and simply sync the _site folder to s3 to update my website.
Some nice things about this setup:
1.) AWS static sites don’t insert trackers
2.) There is zero maintenance
3.) Cloudfront + static website is very fast
4.) Setup can scale near infinitely (so can your bill)
Downsides:
1.) You are locked into AWS. Although migrating to another provider to serve static files would be trivial.
2.) If your website took off in popularity the bill might be more than you are comfortable with.
In 2021? I'd prefer serverless and low-code. If I only need a blog (and not a website) I'd consider posting on substack.com, dev.to, or hashnode.com instead.
> Easy to update: I usually post 1-2 pictures to social media each week, and I wanted adding a picture to my site to be as easy as posting it on any other platform... I could buy a domain and redirect it to my flickr, facebook, or instagram feed
> The best approach would be to have data separated from presentation as much as possible, i.e. for each model to just define a few fields such as: name, model type, image, etc., and use some kind of templates to present this data to the end user.
Low-code builders like onuniverse.com, glideapps.com, draftbit.com (mobile apps), and pory.io come to mind, though none of them let you publish websites via another provider.
> Longevity: since I would be putting in a lot of work, I wanted to be able to expand and maintain the site for at least 5-10 years without major overhaul.
Sound like serverless services like netlify.com, pages.github.com, vercel.com, pages.dev fit the bill to deploy the site to?
I don't see your point: The author settled on Jekyll, which is a third-party tool?
Besides, they mean longevity in terms of having to maintain servers. Serverless abstracts away the server, and its maintenance along with it. More likely that Cloudflare would be here up-to-date with all the security, network, and hardware upgrades in 10 years time than a home server.
I like the satisfaction to manage my proper website and tools. It's like building it's own chairs, I could maybe find better furniture for a better price, but there is a pleasure to make its own things without depending on other services. It's a matter of choice, but for these reasons for a personal website without high availability requirements, I prefer servermore and high-code. =)
I would try to use github.com to host sources of the website and cloudflare pages to publish the website. It's completely free and probably as reliable and fast as possible.
Sometimes I wish I had a website that was just a collection of everything I've shared or written on other platforms, just fully under my control and backed up for later. Is there anything that can spider content based on providing integration creds with various platforms?
Thanks for the article, it's a very readable journal, sharing experiences and writing up also the reasoning behind decisions contributes to future builders.
Maybe someone already said it but I'll echo anyway - unless it's all about going outside the comfort zone to learn new tools, the person building should always first picture what needs to be built, then pick the right materials and tools for the project. Taking their own skills into account when using said tools of course.
Preferably even think a little ahead about your content to come if the site is meant to last for years when picking the tech. Ask yourself some "whatifs". Like what if you want to later on make some trade for yourself and set up shop for your crafts or skillset, can it be done easily enough as well?
TL;DR - Useful and well written article, there's never enough easy-read, non-commercial, experience-based journals about site building basics to help newcomers. Cheers!
No, I didn't know it - thank you. It's probably too late to switch at this stage, but I'll have a look. It's always good to know some alternatives/replacements.
Because they're too restrictive. They're also not something you have too much control over. My site started out with only my resume. I then added photos because why should Facebook benefit? Then came some work stuff I wanted to publish. And then I got into radio control and I posted up builds. In between all of that I play around with some JS ideas/apps/databases.
Maybe Medium and Quora are enough for some, but for some they're just a sandpit when what you really want is a warehouse with a bandsaw, drill press, 3D printer and coffee machine.
Instead of building a website from scratch, you could use SoTrusty and create an order page with videos or photos of your products. 100% Google Lighthouse SEO, >90% Performance (depending on content) out of the box.
This is by far the hardest part. All the other stuff: it's just tangential. Wordpress, Blogger, Jekyll, Hugo, Medium, hand-written HTML files: IMHO it doesn't really matter if you don't have any content. Just use whatever is easiest to get started with and gets out of your way when writing. For me, personally, it would be writing Markdown in Vim and converting that. For other people, it's something else.
Later, when you actually have some content going you can start focusing on tooling, layout, and so forth. Converting things to another platform usually isn't too hard. But chances are, you will never actually get any content going. I've seen a lot of people create personal websites, write one or two things on it, and then basically don't do anything with it.
I've built some websites for various friends/non-profits over the years, and about 90% of the time they never actually wrote any content. These days I ask people to write content first, and then I'll build the website for them. Most of the time I never hear about it again. That's okay, it's really hard to write content and a lot of people (myself included, before I had more experience with this sort of thing) tend to be way too optimistic about it and underestimate just how hard this can be.
And people will read your website regardless if your content is good. Is Paul Graham's website the peak of web design? Not really. People still read it. Dan Luu's website? Pretty much the most basic HTML file you can get. Still widely read.
That being said, if your goal is also to learn more if you're young or inexperienced: then sure, muck around with these tools all you want. I learned a lot from building my personal website over the years in all sorts of tools (geocities, hand-written HTML, shell scripts, PHP, Python, PHP again but this time with MongoDB, back to shell script, and finally settled Jekyll) and for much of this time I didn't have a lot of content. That was okay, because I learned a lot from the process.