How to Make a Damn Website
60 points by isuffix
60 points by isuffix
If you don’t have a domain or hosting yet, now’s the time to buckle down and do that. Unfortunately, I don’t have good advice for you here. Just know that it’s going to be stupid and tedious and bad and unfun. That’s just the way this is.
You do know https://neocities.org/ ?
One change I’d make: use Atom instead of RSS. If you’re doing podcasts, you have to use RSS (blame Apple), but for all other kinds of feeds, everything supports Atom at least as well as RSS, and Atom is technically superior to RSS, and easier to write correctly.
Atom has a sensible date format. A big deal when hand-typing.
RSS is a disaster around content semantics, with an unspecified content format for title (characters like <, > and & are not safe to use at all) and description (these days, I think everything will assume it’s HTML), and unspecified meaning of description (is it an excerpt or the full item).
Atom, on the other hand, has type="text|html|xhtml" on text constructs which lets you specify if they should be interpreted as plain text or as HTML, providing confidence that characters like <, > and & won’t be munged in titles, and allowing you to use HTML in titles if you want (far less commonly done than it should be, because most CMSes have made the easy but improper assumption that titles are plain text).
Atom also has a slightly richer content model in the right places, most notably distinguishing between summary and content.
Atom specifies to use xml:base for resolving relative URLs, which fixes a concrete problem in this article. RSS doesn’t define anything.
RSS is a total mess. There were at least nine different and incompatible versions of RSS. The spec that people use these days is still bad in a variety of ways, and in practice it’s supersetted with a bunch of stupid unnecessary extensions papering over deficiencies. (Ever been upset by HTML’s <meta name=description>, <meta name=twitter:description> and <meta property=og:description>? Or wondered why some tools don’t like <meta name=description property=og:description content=…> even though it should obviously be fine? Yeah, we’re talking that kind of nonsense.) Atom is the properly-designed version, solidly specified in RFC 4287.
I've been writing my blog posts in HTML rather than markdown for like two decades and I really don't get why people think they need markdown for this. As long as your editor can auto-close HTML tags it's really, really easy to write. A makefile can cat a shared header/footer onto each page to avoid duplication but like ... you Really Don't Need to overcomplicate it!
I used to do that for my blog for I think around 17-18 years. I got tired of it. I wanted an easier way to generate HTML [1]. I don't use Markdown though, I wrote my own markup language tailored for my blog and how I write posts [2][3]. I included some Markdown-style syntax, some LaTeX-style syntax (to generate non-ASCII characters mostly) and some ORG-style syntax (tables and blockquotes mostly). It works for me, but yes, starting out one can just use HTML. It's not hard, just tedious at times.
[1] And all post entries are stored as HTML.
[2] I use <ABBR> tags to markup TLAs [4] and ETLAs [5]. My markup language makes this way easier to do, and I wish more sites did this. I also have a way to include simple tabular data into a <TABLE> tag.
[3] I still store entries as the rendered HTML. That way, I can change the syntax of my custom markup language without worry, and yes, I have changed it multiple times since writing it.
[4] Three Letter Acronym
[5] Extended Three Letter Acronym [6]
[6] Yes, this is a thing. Thank you IBM [7].
[7] International Business Machines.
Same. I also had got tired of it somewhere before 2011 because when restarting I chose markdown to not have to do that again.
But I've always been lazy, I had already experimented with textile and whatnot before that. Funnily I can also say the HTML4 -> XHTML 1.0 transition also played a part. I already had to fix up my HTML. And then HTML 5.. Better to regenerate.
Reasons I prefer Markdown to pure HTML:
<em> tags etc)[reference][title] syntax)However, stock Markdown's table syntax is atrocious. I usually write a quick script that generates HTML tables if needed.
It's easy but thinking about tags is very disruptive to my thought process and I can never get in the state where thoughts just flow. Also, a lot the stuff I write has math and I need something for that (I know there's MathML but I'm tired of learning new syntaxes and last time I tried it didn't even work on most browsers).
While I don't know what you specifically write. Math heavy stuff always felt hard on computers in general, unless one can write it as code or pseudo code.
About the general disruption though. I think it makes sense to do styling as a second pass. One writes and during proof reading adding style worked great for me when I did that.
Again, I do think math is more specific, but for text it usually boils down to a hand full of tags at most, if you don't write marketing emails or pretend to be an LLM.
I think at large people think they'd use a lot more tags then they actually will.
For math: Do you use something else now?
For math: Do you use something else now?
I've used different markdown renderers with math (KaTeX) plugins.
I currently use a Python build script that uses a custom library that uses the mistune markdown parser with a custom plugin that uses PyKaTeX, a library I wrote for using KaTeX from Python.
(Obviously, a lot of work has gone into this, for something which feels like it should be trivial.)
Maybe Pandoc if editing HTML by itself is really that much trouble (I know some people who have really big problems parsing angle brackets). Also has simple options for templating.
Who is this article for? If Simple Joe doesn't know how to make a damn website, Simple Joe probably needs some help with how to host their webpage. Simple Joe doesn't care about syndication.
I was surprised to see RSS in here as well. I think the basics really should be something like:
The true basics are that web pages are just documents and browsers are glorified document readers.
Most lobsters I encounter already have websites, but for those of you reading this who don't, go change that! I believe in you!
If you don’t have a domain or hosting yet, now’s the time to buckle down and do that. Unfortunately, I don’t have good advice for you here. Just know that it’s going to be stupid and tedious and bad and unfun. That’s just the way this is.
I only set up my own website around a year ago, but I've actually had quite a different experience to the author. Here's my advice:
(assuming you're new to this 🙂)
I set up hosting with tigertech.net, and it has been a joy. They host cppreference.com, so they can handle your blog, and their help articles are all human written and straight to the point. Their prices are fair, and every request I've had has been responded to within a day by a real person.
Beyond uploading files to their server, the only thing I've changed is adding an Apache .htaccess file. This is something I had no clue about before this, but Apache is a standard choice for a server, and the .htaccess file gives you more control than you need. It's organized around modules, like mod rewrite or mod deflate that are all massively documented online. For example, I use mod rewrite to upload /xyz.html files for my pages but redirect to /xyz for cleaner links.
To preview your site locally as it would be served remotely, you should download Apache and set it up to serve on localhost. I also pair this with the browsersync utility that proxies the Apache server and creates a "websocket" that lets it tell the browser to refresh whenever a file changes. This is the only reason I've installed nodejs and I intend to keep it that way.
Why go with a hosting provider and not self-hosting or github.io?
To be clear, I am not affiliated with tigertech, but they've been great for me. They feel like an amazing old-internet company that's just doing everything right and I think people should be aware of them.
It could in theory be simpler. One of the original goals of the web was to edit pages in the web browser and have it update the page, but that was never fully realized. It could be now. You just register a domain/website (most registrars will gladly do hosting), then use the web browser to view your page, which might look like:
Hey! New Page here! Use your web browser to edit this text, then hit save!
The web browser would then use the PUT method (and the server side will authenticate the request) and presto! A new webpage without having to know HTML, FTP, editors, etc. (and I do wish that this was a thing) I kind of do that now with my blog, only I use an editor to write the page, then use a separate program to PUT the entry (and I can add other assets like images).
One of the original goals of the web was to edit pages in the web browser and have it update the page, but that was never fully realized.
Sounds like a wiki.
Only you could edit the page as a whole, not just text in a <TEXTAREA>.
It is actually remarkably easy to allow this tho : put contenteditable attribute on your base element and have a little javascript that puts it.outerHTML back to the server. Can do it in like a dozen lines of code, combined between client and server for the base minimum experience. (though it can quickly balloon up once you start adding things)
And to update, I suspect it still requires Javascript. But that you can do that is cool. Thank you.
(Intentionally posting in a separate comment)
(and if a mod cares, I'm totally ok to remove this)
Tigertech does have a referral program, so if you want to make my hosting cheaper, you could visit https://www.tigertech.net/referral/isuffix.com (stores a cookie and only works if you do sign up with them). However, I really just think they're great and would recommend them regardless.
This is honestly all you need
The example tagged with this actually has several things you don't need. You don't need an html tag, or head, or body. The meta charset is a pretty good idea but also optional. You need the fake doctype, the title, and any content you're writing. That's a valid HTML5 page.
If you don’t have a domain or hosting yet, now’s the time to buckle down and do that. Unfortunately, I don’t have good advice for you here. Just know that it’s going to be stupid and tedious and bad and unfun. That’s just the way this is.
Very much "now draw the rest of the f*cking owl" energy, to be honest.
Off the top of my head, I know https://tilde.town/ offers hosting, but you have to navigate a text adventure to get it.
FWIW, tilde.town is intended as a community first; hosting is somewhat incidental as one of the many ways of using our server to interact with people. Don't get me wrong - if you want to join because you want to make a lil' website for yourself, that's great! Many townies do use it to host their website, and you're absolutely welcome to join.
However, we are not a hosting provider per se - if you don't intend to interact with the community, you'd probably be better served by "proper" hosting, which would also give you more control over your site.
If you don't mind paying a bit of money, NearlyFreeSpeech is really good. You only pay for the resources you actually use, so hosting a small website there costs literal cents - but it's also prepaid, so you won't ever be surprised by a large bill (as opposed to e.g. most cloud providers).
As for free options, I've heard good things about Neocities in the past. Git forges tend to offer basic hosting too, and even if you don't like e.g. GitHub, they usually let you use a custom domain, so you can always jump ship later.
You might also want to check out the rest of the tildeverse, keeping in mind that they tend to be more or less focused on the community aspect too.
Thanks for clarifying the goals of tilde.town. I was working from memory and just scanned the front page and some sites.
I personally host my site on a VPS with a custom domain, something I remember reading about in the late 90s and which then felt like an impossible, unreachable dream.
I still use Seamonkey Composer to create webpages, it's essentially the same as the old Netscape Composer/Kompozer.
Refreshing to see a reminder of how simple the web should and often can be, in the times of extreme complexity and overcomplication.
I'm so glad the author mentioned starting the CSS by element selectors rather than classes. That's an unnecessary abstraction saved.
One reason I switched from this model to hugo (https://alexsci.com/blog/hugo-import/) was the challenge of keeping everything in sync. The title of the post exists in the HTML as both head title and body h1, the index, and the feed, for example. I found I'd forget to change one, so I wrote a manual deployment checklist to ensure they were all synchronized. When you write out every single step it's actually a lot.
I broke my RSS feed a couple times. I put the wrong date format, copy/pasted an RSS item but forgot to change the GUID, and made the images-as-relative-links error. I think you need a validation step, at the very least, as it's easy to break.
One of the reasons I'm considering going back to a plain HTML approach is that I want to archive old posts. I feel that a blog should use the header, footer, and style it used when it was posted. Hugo wants to make every page look the same.
I think there is a middle ground of writing posts in plain HTML while generating the feed and index (maybe sitemap too). If I write another SSG, that may be the concept.
I find it very funny that technical people shit on tools like FrontPage/iWeb/Dreamweaver back in the window when normal people thought about or cared about making a website. Now the social media genie is out of the bottle, and all that's left is arguing what static site generator to use in your programmer windows.
Dreamweaver was better than FrontPage, but both were totally eclipsed by arachnophilia which is still available today
FrontPage deserved it as it was a Microsoft proprietary piece of crap that would often crash server side. I had to reset plenty of FrontPage websites in my time. iWeb/Dreamweaver? I personally never had a problem with those, although I never used them myself.
I can get with the sentimental against complexity and abstractions, but sometimes the complexity comes from what I want to do with the site.
I am sure people using static-site generators know how to make this kind of website, and we sometimes do if what we want is simple enough. However, when I just want to write blogs, rather than worrying about
Static site generators also empower features such as tags, math equations (though I wish MathML were used by everyone eventually), and syntax highlighting. Without a build process (or something like a CMS), I think every one of those features needs to be implemented in JavaScript on the client side.
I think a potential downside is that you now have stuff you need to maintain, update, etc. Of course it depends on the static site generator (and potentially the "theme") one uses, but for a regular blog doing a tiny amount of copy and paste and then just have files removes a lot of stuff that can go wrong.
Also if you use a static site generator you have to potentially debug it or at least the thing that it converts to HTML. Things like math equations and syntax highlighting.
Of course once you have them they are nice and I am the last to argue against static site generators. They work for the vast majority of people, there are also graphical ones that are essentially "offline" blogs. I wished people used them more. However I think the article was about not having additional software and more a "make the thing you will serve yourself, because you might not need anything more than that".
While I understand that especially math is needed and syntax highlighting sometimes they aren't exactly a hard requirement for a lot of people. But sure, if you write about programming a lot with bigger snippets I totally get one would want that. As you mentioned a bit of JS might do the job - if you are okay with JS.
i don't know, adding RSS as a second step for newbies is questionable. Paying for hosting isn't neccessary either, stick with GitLab/GitHub pages or anything that accepts a plain HTML file/text
use in-place CSS/JS until it reaches 10Mb or more :D
Ha! A fellow person of culture... I never got down to writing part 2 of the "series", but I wrote something very similar after hitting a wall with static site generators; especially custom templating systems. Anyway, out of that fell two items; one, [1] a blog post building up a site from nothing (ends up with copy-pasteable dead-simple HTML website + blog template), and [2] my own site maker where I template with Bash and HTML (heredocs are great for HTML template fragments!).
shite_template_standard_page_wrapper() {
cat <<EOF
<!DOCTYPE html>
<html lang="en" prefix="og: https://ogp.me/ns#">
$(shite_template_common_head)
<body>
<div id="the-very-top" class="stack center box">
$(cat -)
$(shite_template_common_footer)
</div>
</body>
</html>
EOF
}
[1] shite: static sites from shell (part 1/2) — feeling the html.energy
We've long dreamed of lovingly hand-crafting our wee home on the Internet, you and I. We would make it ultramodern yet ultralight, simple yet beautiful. Something not WordPress because that's so last century. (Seriously, just go to WordPress.)
No. We were committed. We would do it for the sake of craftsmanship and the environment and World Peace. And that's how we found ourselves awake at 2 A.M., having absurd conversations 1 with Distant Internet Strangers…
[2] shite: The little hot-reloadin' static site maker from shell ... README explains the architecture and authoring experience, complete with animated GIFs :)
The little hot-reloadin' static site generator from shell. Assumes Bash 4.4+.
WARNING: Here be yaks!
shite's job is to help me make my website: https://evalapply.org Thus, shite's scope, (mis)feature set, polish will always be production-grade, where production is "works on my machine(s)" :)
I've made several attempts to create my own website, but I eventually gave up. Even my business doesn't have a website at all (prod tracking for film/games). The "blog" posts I share are basically long-form, letter-style documents hosted on HackMD. Putting concerns about scrapers aside, the standard structure and layout of a modern webpage still feel almost like I'm designing a good old-fashioned newspaper.