This works for me in terms of freedom. I can do interactive plots, quizzes, games and all kind of programmable things I can imagine. No restrictions.
In fact, I left Medium because I was restricted to text and images only. I want more. I want words and buttons: https://wordsandbuttons.online
But it's not really aligned with the reasons from the post. It's not a resume. It would have been an awful resume. I wouldn't hire myself by this resume.
And keeping record is, of course, nice. But it has nothing to do with running your own website. You can keep record on Medium, too. In fact, it would be more effective since it works wonders for the small notes.
Still, I totally agree that keeping your own site is a fascinating experience and it's well worth time and effort.
But, as a reader, I think a website like yours is like having a chance to explore that person's personality in a freeform way. The design reflects their aesthetic (similar to how fashion does for the physical form), the organization reflects their favored mental models perhaps, and the myriad of topics and links makes it a graph-like structure for a book/journal/life. It's strange to me that people question a personal website's purpose - but accept that of a coloring or sticker book. To me, that only says that our brains haven't quite caught up with how to use the medium. (Although, if you have read sites like philosopher.life, then I think you have a glimpse of what's possible.)
I don't do hiring, but I can see your website being an item in the "plus" column if I was going to pick whether to hire you or not.
Zooming on the web is a critical feature to me. I find pages all the time with nearly unreadably small text, and occasionally with text too large for me. Firefox remembers zoom levels for me, so I only have to adjust once per site, usually.
This is not meant to be a criticism, just sharing another experience for your awareness. Based on your comment, I don't think the author could make both of us simultaneously happy.
Most designers do not work intimately with the content, so text is more shapes on the page than the main course. I do not mean this disparagingly, I have just seen a lot of designs in my time where the text is placeholder stuff in designs.
In reality text needs to be of a certain line length. If it gets too long then it can be hard to follow. Wall of text is a problem too.
The best way to do text is to make it proportional to the width of the browser window. If the lower font size is the 16px recommended by Google for accessibility then the maximum size can be what you might call enormous - on a 4K monitor. Everything can be just right in between.
If you do have a 4K monitor and you are using it for just one browser window then enormous is what you want - it will look good in the meeting room on a huge screen that everyone can see.
Some fettling of margins can go on too, so a small screen can have narrow margins, so 1rem on a phone and a lot more on bigger screens.
With these methods it is possible to make design a lot easier with everything proportionate to screen size. But if your designers are only thinking in terms of fixed with fonts and they produce the mobile and the desktop views with baked in font sizes that get signed off by the client then you are stuck with it.
It really is up to the design community to get with font scaling and to not be insistent on a couple of fixed font options.
This should be simple but in a multi-disciplinary team where most web design is then sausage-factoried with old layout hacks (so no CSS Grid or CSS variables) then progress is difficult if not impossible.
ive done that because mobile reading the page would see microdots instead of characters at 14 pt font.
i read and access at the ass end, the front is for mobies
i havnt wanted to use JS to check and set font as i really dont want to build a JS site.
<meta name="viewport" content="width=device-width, initial-scale=1.0">
and thanx BTW
I tried spacing it a bit just not, it does look better this way.
I also maintain my own site which is statically generated and deploys to a VPS running docker via git pushes. I haven't written interactive articles yet, but having absolute freedom is imperative for me. I always end up fighting with whatever system I use, except here I can just extend it to do what I need.
See my sibling comment  for links.
Source here: https://git.sr.ht/~andrewzah/personal-site/tree
It's simple, all the interactive plots are HTML canvases with a set of event handler assigned to them. I trigger init ialization functions right after the elements declarations, and they assign all the events: https://github.com/akalenuk/wordsandbuttons/blob/380c97f2535...
Almost every event changes the state somewhere and triggers the redrawing function: https://github.com/akalenuk/wordsandbuttons/blob/380c97f2535...
And that's all. It's a bit messy since it involves keeping state outside the functions, and it also requires a little boilerplate but it's manageable. Maybe if I would have hundreds of plots per page, this would have been a problem but for a blog-post size pages this works fine.
It starts with an idea. The whole thing: writing and interactive elements working together. Thinking it through with drafts and sketches takes a few weeks. Then I copy-paste a ./drafts/stub.html file, and copy-paste the elements that looks like what I'm trying to achieve the most there. Then I maul it into an actual code for the page. Then I write the text that has already been formed in my head, then I edit, and then I edit again, end the next morning I edit the last time. Then I put it into ./pages, fill in the index.html and the rss. Then I upload it to the hoster. That's it.
Some of these things can be automated. There's absolutely no need to deploy things manually. Unfortunately, the automateable things take the least amount of time. Sketching and editing take maybe 90% of it, and the programming takes the 90% of the remaining 10%.