Building a personal website in 2021
origami.kosmulski.org
origami.kosmulski.org
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.
It's 2021. Build a cathedral of a website for a single tweet, it will say a lot more about you.
Although I wish, obviously, we all read more.
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 :-)
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.
> 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”.
One of my personal favorite shite pages with great content.
[1]: https://www.sheldonbrown.com/
[2]: https://en.wikipedia.org/wiki/Sheldon_Brown_(bicycle_mechani...
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.
- 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.
On the other hand, there are good examples of companies that survived/thrived by selling their tooling (e.g. Unity, Yammer).
Friend: Sounds good. How's it going?
Me: Well. I needed to be able to debug my code. https://github.com/tts-community/moonsharp-tts-debug
Friend: Oh, neat. So your game is done now?
Me: Not exactly. I had to add in matchmaking by reverse engineering Steam. https://github.com/SteamRE/SteamKit/pull/704
Friend: Ah. Alright. Can I play it now?
Me: Nah, I was finding it hard to maintain code. I wrote a Lua code bundler. https://github.com/Benjamin-Dobell/luabundle
Friend: Sweet.
Me: Yeah, I decided to integrate it into the official tooling. https://github.com/Berserk-Games/atom-tabletopsimulator-lua/...
Friend: I'm sure the community will be thankful.
Me: I hope so. I now run a small community of TTS developers. https://github.com/tts-community/
Friend: Right. You must be done by now.
Me: Nah, I couldn't statically type check my code. So I wrote some types. https://github.com/Benjamin-Dobell/tts-types
Friend: Seems unnecessary for a prototype, but sure.
Me: I had to write my own IDE to use them though. https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis
Friend: Right... So how's the game going then?
Me: Oh, I'm not doing that anymore. I now consult for Berserk Games, developer of Tabletop Simulator.
Friend: ...
A business that does this same thing will soon bankrupt (or swallow more VC funding!)
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 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 :)
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.
Many Medium articles are even stolen verbatim from other websites. It's a cancer.
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.
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.
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
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?
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.
[1] https://doctorow.medium.com/the-memex-method-238c71f2fb46
This often shared, but I just read recently article comes to mind: https://jeffhuang.com/designed_to_last/
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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
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.
Extending the Markdown rendering appears possible without building Hugo itself, albeit not for lists: https://gohugo.io/getting-started/configuration-markup/#mark...
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.
[0]: https://github.com/nickjj/runninginproduction.com/blob/maste...
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.
Yuck.
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.
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.
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?
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.
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.
https://www.netlify.com/blog/2016/10/27/a-step-by-step-guide...
Couldn't I hit Github using just statically served, client side JS?
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.
Anything else that's not js, imo you're making the biggest mistake... Eventually you'll need js...
* Edit a page on my laptop or iPad with iA Writer.
* Commit it to git and push it to a repo I host.
* Every 5 minutes, a cron job runs on the server that does `git pull && hugo && rsync` to update the live site.
Jekyll took half a minute to do the same build that Hugo does in 1 second, and now the process is so fast that this workflow is practical.
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 :)
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..
- don't justify text, it doesn't look good and it makes text harder to (https://designforhackers.com/blog/justify-text-html-css/)
- 'On this page' section is too long. And once I scroll down I don't see it anymore so I can't use it for navigation. Look at https://getbootstrap.com/docs/5.0/getting-started/introducti... or https://tailwindcss.com/docs/installation to see how useful can it be.
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:
https://generatedcontent.org/post/44751461516/finer-grained-...
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 would say it's not overwhelming, but I'd go with ragged-right to be safe.
[1]: tug.org/TUGboat/tb38-2/tb119veytsman-justify.pdf [2]: https://tug.org/TUGboat/tb37-2/tb116akhmadeeva.pdf [3]: https://benjamins.com/catalog/idj.8.2.03sti
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.
#content {
font-family: "AtkinsonHyperlegible", sans-serif;
text-rendering: optimizeLegibility;
font-size: 0.5cm;
line-height: 1.4;
max-width: 70ch;
}
@media screen and (min-width:70ch) {
#content {
word-break: break-word;
text-align: justify;
text-justify: inter-character;
hyphens: auto;
hyphenate-limit-lines: 2;
}
}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).
Here's another vote for looking totally borked. I don't know if it's because I've disabled javascript, or something else - but, no.
If you want to say that you need to argue against over 100 years of newspaper and book typography.
Granted, this isn’t print, but if you want to make blanket statements like that, you need to defend them against a very long lineage of design.
I don’t think it needs any more justification than that.
It was good typesetting. It was probably never good typography.
(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)
[flagged]
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.
“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.
* 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.
No, the order of paragraphs is important. A/B testing is necessary to find out the best one.
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.
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?
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 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.
[1]: https://www.rgz.ee/ssg.html
[2]: https://culhane.top, source: https://sr.ht/~learax/culhane.top
This was the first time I ever touched a static site generator. It was harder than I expected, but my expectations were probably unrealistic.
I was so happy with what I got that i decided to replicate my more-than-10-year-old Tumblr with what I just built as a test.
I "host" it for free on Netlify. And if anything goes wrong with them, I can just move it anywhere I want.
My only pet peeve is that I'm not yet used to committing content with git alongside the code, but that's it.
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.
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.
My blog is never going to be so popular that I need to support more throughput than that.
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.
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.
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
Shameless plug: https://samiam.org/
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.
I'm a big fan of "do what you love."
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.
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.
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.
Besides a few minor configuration updates, it worked almost out of the box after the upgrade on a new server.
2003 vs 2008
Also I realized another issue with SSG, the setup is on the desktop, not on the server. I have problems with this too.
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.
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...
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”.
My tech stack is: Hexo Markdown Node.js Heroku
Here is my whole story!
http://www.primaryobjects.com/2015/12/15/a-tale-of-migrating...
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.
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
https://bobbydreamer.com/things-that-my-new-site-should-have
One epiphany, what's the point of making the things attractive, if I dont continually add something. So I stopped everything I was doing
https://bobbydreamer.com/epiphany-moment
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.
https://bobbydreamer.com/how-i-made-this-site
What I use to make this site 1. Content in markdown(MDX) 2. Using firebase for hosting 3. GitHub as version control.
Hosting a static site on Azure costs me 2-3$/mo which is well within the free credits I get from my work-sponsored MSDN subscription.
I'm a big fan of "Jekyll Admin" as a way to get the best of both worlds:
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.
> 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
There exists no-code apps that post your social media feeds to a weblog. One of the better ones I know is milkshake.app https://news.ycombinator.com/item?id=20154181
> 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?
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.
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="../style.css">
<meta name="viewport" content="width=device-width">
</head>
<body>
<div class="main">
<?php
include "../Parsedown.php";
$pd=new Parsedown();
$mc=file_get_contents("../contentHeader.md");
echo $pd->text($mc);
$mc=file_get_contents("contentMain.md");
echo $pd->text($mc);
$mc=file_get_contents("../contentFooter.md");
echo $pd->text($mc);
?>
</div>
</body>
</html>
After trying several "simple" Content Management Systems, this is where I arrived. I wish I did it 10 years ago.
Upside: there are many "one click" options (Substack, Webflow, etc) that make it dead simple.
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!
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.
Here an example of a store in Germany: https://menu.sotrusty.com/item-una-feinschneiderei
What do you think about it? I appreciate any feedback. Thanks :)