I originally wrote this article for a “microcourse” I ran at the University of St Andrews—aimed at a non-tech background—on building a personal webpage. Especially in mathematics, having a personal site (that you control) to host research and other information is pretty invaluable!
Older personal math sites tend to have a very particular “historic” feel. While I personally have a lot of nostalgia for the look, I also think it’s good to take advantage of some of the newer tools that are available today!
One nitpick: right at the beginning it mentions "JavaScript allows dynamic behaviour", and then explains at length what static and dynamic pages are, but doesn't refer back to JavaScript and what kind of dynamic behaviour it provides for websites that are "server-side static". I imagine that if someone who has really zero prior knowledge would read this, that might leave them confused...
I would put “check for spec valid HTML” far down the TODO-list. I’m a perfectionist, so I would run the validator at some point, but I find it’s basically never helpful for identifying usability issues with a website. For a non-technical person setting up a personal site, does it really matter?
Browsers have gotten really good at it, but man, have I wasted hours, missed deadlines because of a stray `<li>item2<li>` and such.
HTML validity and rapid feedback is just as important as the rapid feedback of unit-tests, a type-checker or a even a linter: it shows you mistakes when you make them, rather than later, when you'll merely run into their effects.
I love to see that the effort of preparing a microcourse is publicly available. And also the fact, that you don't "promote" a single static site generator, but also wrap this into a HTML course.
I once did a kind of "tutorial" for hugo[1], because I think it's documentation is hard to follow for beginners, but I should have thought to give some details about the "from scratch" technologies...
It looks great! I started my personal static website more than twenty years ago, and I have maintained it ever since with only a text editor and FTP software. When I began, I learned what I needed from books (!). If I were starting now, your site would be the perfect introduction.
Yes, for the sake of your visitors. If your site is only http, then middleboxes can use your site load to opportunistically attack the visitor.
Of course, the probability that a visitor would not visit any other non-TLS site that day is low, but that probability is getting lower with every passing day.
It is cool to see this on HN! I keep thinking, don't people who use the internet with any frequency already know this? But that was a quarter century ago, that knowledge may have been long forgotten among internet-using normies, and it needs to be documented and remembered.
Really nice, focused write up. Very useful and to the point.
HTML is really very accessible to someone with basic computer skills. It's a shame that a standard business website is now a facebook page.
There is a local gym near me with a static HTML webpage, hosted on local ISP web hosting. It's quick to load, responsive and always up to date. Checking the opening times, address and special events is much easier than on some aggregator site or google maps (which is often out of date). It's also very easy to read on many devices.
I absolutely hate this ' let's just put it on Facebook'. My wife was planning to go to this boutique kids shoe shop. Checked the opening hours,etc. Went there just to see the shop closed. Calls the owner, and she's all surprised: oh but I did post on Facebook that I'll be open from 2pm..
Unfortunately, businesses have to go to where the customers are. Many customers now are 100% Facebook-era, particularly true of the young and those older folk late to computing, and it might not occur to them to check https://www.widgetsRus.com before searching for Widgets R Us on Facebook.
Updating a 'personal' site is also a PITA IF you don't know what you are doing or don't have a streamlined process, e.g. for me I'd just amend the .htm page to say I'm shut from 2pm and FTP it up, 2 minutes, but someone non-savvy will always prefer to post a new message on FB saying 'hey, shutting at 2pm today', takes even less time and less cognitive load.
I'm not saying this is a good thing, by the way. But it's understandable.
EDIT: Not to mention, updating a site on the move is difficult. Pull latest version of site (Github), amend .htm (some notepad app?), then an FTP client on the phone, log in, find, push the file, close, check. Versus opening the FB app and doing some typing.
If we actually got the semantic web that was promised, back in the burgeoning xhtml days, then it seems like Facebook / own website could simply duplicate the latest data from the other page.
There's a nifty tool called Bridgy that helps with this--it's out of the IndieWeb community with their POSSE model: Post on Own Site Syndicate Elsewhere
What does that have to do with personal site vs Facebook? If Github is a problem, don't use Github if you regularly need to update and for some reason you can't do it using the web editor. I mean, WordPress is kind of a big deal.
There's nothing wrong with Facebook if you like a kind of ugly website that randomly pops up crap to prevent people from viewing your site. If you're concerned about people that only use Facebook and no other sites, you can duplicate material on Facebook.
I do as well but let's be honest, many people who create sites for money will not necessarily coach the business to keep it simple, since they will earn less money from it.
By the time you add a CMS (to help the business not screw up the markup), some design help and all the features that the business thinks are easy because "it is just a form", and you are paying several thousand dollars, way more than many small business think is worth it.
The other alternative, I guess, is something like Shopify but many people I have talked to struggle to see why paying a monthly subscription is money well-spent to get something always up to date and fresh. They'll pay a shop assistant pittance which is still more than they would need to pay for Shopping-as-a-service and get less value.
I've had this happen too at Armageddon Shop in Cambridge. When I showed up, the two employees told me to leave because they posted on Facebook that they were closing two hours early due to nobody showing up
I don't even use Facebook, and if I did, I wouldn't check every place I wanted to go on it before I went there
But the response to that request is not an actual copy of jQuery, which it seems when you just look at the URL, but the following body instead:
/* NO, really, NOBODY NEEDS TO INCLUDE A FUCKING FRAMEWORK TO MAKE A COOL WEBSITE. */
console.log("Don't worry, no jQuery was used in this website.");
var $ = function () { $.fancyRainbow = $; $.html = $; return $ }
I got fooled by it, should have verified it was actually jQuery I guess. Now the other comment about jQuery (https://news.ycombinator.com/item?id=33020599) kind of makes sense, almost.
>HTML is really very accessible to someone with basic computer skills. It's a shame that a standard business website is now a facebook page.
It really is a shame. HTML and CSS are among the easiest ways of experiencing for yourself the power and possibilities of ordering a computer to do things for you.
Easy things are easy in CSS. Hard things are... possible. Sometimes barely so. Sometimes impossible without JS. BUT, the easy things are generally easy.
In job interviews, I've been handed code in various languages from assembly to C to Java and asked to figure out what that code does. It can be an interesting challenge, and while I'm certainly not the fastest to figure it out, I usually can.
Give me a bunch of CSS and ask me what it will do... even with the docs in front of me, I am almost certain to get much of it wrong. And I suspect even experienced front end devs (I've never done front end professionally) would struggle with such a challenge.
It takes time to establish discoverability with a website, you either rely on a search engine, word of mouth, business cards, etc. A new small-business website won't magically start generating traffic without some significant effort.
Using a platform like Facebook or Google Maps makes it easier to for other people to find your page when they want to look for it.
True, but a local gym doesn't need global discovery and SEO optimization. They can just put the URL on their business cards, and in a few places at reception. A sticker on their door. 95% of their customers will see it and know where to go.
The problem with coding up a custom website for myself is I end up wanting to customize it to no end. It distracts me from actually writing. Add in a dose of graphic design ideas and very few words go down at all.
I just finished replacing my custom site with a ghost site using a theme that is barely customizable at all. Hopefully, this will make it easier to avoid fiddling with it.
The new site is more generic unfortunately, but on the plus side, I already have almost 20k words queued up for future posts
Let’s say you’re a business owner, don’t have many technical skills, and want to change opening hours for a given day (e.g. public holiday). You’ll have to go at least 5 extra steps that require you to achieve that, than just pulling up your phone, going on your facebook page and changing the hours.
I think we are collectively over estimating average public’s willingness to go extra steps to achieve almost the same results that most of the public already expects.
Engineers tend to think of things like this to be easy. A typical small restaurant owner is probably also a chef/cook of some kind. Their view of the internet might be internet==facebook and they probably think how to properly flavor something is easy. Contrast that where I have to go look up 5 recipe websites, watch some youtube to really grok it and then will forget after a day or so unless I wrote it down and will end up doing the same thing all over next time I cook that dish.
I wanted to ask for a link, then I thought the server on the local ISP might not have the resources to withstand HN traffic, then I thought such a small efficient website wouldn't require many resources!
My personal approach might be too simplistic for some, but this is what I did for my webpage, though I already had some HTML & CSS experience:
>No website generators, no frameworks, no nothing (not even JavaScript)
>Just design the site on the go through some trial and error using vim, CSS and HTML documentation always at hand
>A single .css file to style the entire website--I even threw in some cool animations, which took a while to get right, admittedly
>Publish it through GitHub Pages in under five minutes
>If I want to upload a new blog post, for instance, I just make a copy of an existing one and manually edit the content, then push it through git after I've edited the blog index accordingly
Reading terms like "static site generator", "content management system", "templates", "analytics" or "deployment" gives me an instant headache, especially since it's so easy to open your favorite text editor and design your own website by hand, so to speak. I've self-hosted eepsites, gemini capsules and many other sites this way and the process wasn't remotely as contrived as some approaches I've seen out there for publishing a personal blog
From the readme: “This setup is databaseless, javascriptless, and buildshit-free, so you can edit your website with a text editor and upload it somewhere like a normal person.”
I had a feeling that this could be made, and even thought about attempting it myself, but wouldn't this make every visitor load everything on the site at once, even if they don't want to? Or is it only loaded if it is actually displayed? Perhaps browsers have become more efficient at this and do it right off the bat now, but I think it wasn't the case a bunch of years back.
<img> tags use the loading="lazy" property which doesn't actually load the image until it's displayed. Everything else is just text, which is super tiny.
> Reading terms like "static site generator", "content management system", "templates", "analytics" or "deployment" gives me an instant headache,
Only until you want to automate some of the tasks you do manually and, after a night of hacking, end up with a "static site generator", or, if you want something more dynamic, a "content management system". But at that point, you'll probably still not want to look into existing solutions because learning all the necessary details of product $x is often more time consuming than a straightforward implementation that solves exactly your and not someone else's problems.
90% of the challenge of making my personal webpage is picking the colours. I still hate the green and it drives me nuts. But blue is too comfortable and boring. Maybe an auburn?
Ugh. Is there a place I can share a link and get two minutes of free designer advice?
Single CPU Linode cloud instance ($5 per month), single Go executable generating/caching/serving the simplest/cleanest HTML... could it be simpler or cheaper and still work?
If one of the things you wanted to "take away" was page margin, then sure.
Even at a time when the physical costs of production were far, far more significant than today's, people thought it was important to give a text block some air (https://en.wikipedia.org/wiki/Canons_of_page_construction) so this isn't a frivolous innovation. IMO doesn't have to be a big shift or complicate things; body { margin-left: 2vw; } here would do a lot. Hell, you could toss it as an inline declaration on the body element itself if you're morally opposed to style tags.
Green is also the most challenging one, since our perception of green is twice as good as with other colours. Blue, btw, is generally perceived darker than the technical brightness of the color would suggest. A general advice may be to dial down saturation: especially when applied to larger areas, colours tend to be more intensive as they may appear in a colour picker.
In my opinion this is an objective step forward. Thank so much for the ideas.
So:
- serif title to be more distinct and formal
- a calm blue (do you have the hex?)
- no borders
I'm thinking something isn't quite complete with the "latest posts" now that it's without a border. Maybe they need to be a bit more "condensed" so they don't bleed into eachother visually as much.
I'm going to experiment with your ideas!
Edit: I'm also deeply curious how someone looks at a page and decides things like "the title should be serif." In retrospect it looks so good but I have no clue how people get there. Just a good eye? Experience? Is it some sort of design rule/convention?
#84a0ca is the hex for that grayish blue. If you open up dev tools in chrome or FF they have a colorpicker and you can tweak in real time.
> I'm thinking something isn't quite complete with the "latest posts" now that it's without a border.
No doubt you could improve it further. The borders felt like too much chrome. You could also experiment with a subtly different background color for the cards... not sure if it would work. Or more padding, etc. Basically, the idea is there are many way to achieve visual "separateness".
> I'm also deeply curious how someone looks at a page and decides things like "the title should be serif."
The proper mixing of serif / sans-serif is a standard technique. If you look at pretty much any web page that looks really well-designed to you, they'll have a "font palette" just like a color palatte. Often it will be just two fonts but sometimes more, and it's typically a mix of serif and sans.
I am not a professional designer... I've just picked up a bit over the years.
also, there is no reason why you need to have colors for your fonts. try to do black (or dark gray) and a lighter gray. maybe throw some colors around for some things but you don't need color everywhere.
A simpler alternative: Don't worry about the colors. Just provide text and links, and let the user's preferences handle color and style. If the user did not configure their own preferences, browser defaults tend to be readable and accessible.
Ahh about this. I recently found a very good Twitter thread about choosing a color for a non-designer. Sadly, I think I didn't save the thread and now I cannot find it.
I'm working on an automatic designer. You just focus on the content and have instant preview how your website will look like in several different templates/designs.
There is Genetic Algorithm that can mutate styles of the current templates (that you liked) and generate endless designs till you find the one you like the most.
Has building a webpage never been easier or never been harder for a newcomer? I honestly can't tell. On the one hand there is an abundance of tools to ease the process, on the other hand even the entry level tooling for a webpage in 2022 is staggering.
Easier if you go the SaaS heavy, all in one route.
It's a hellscape if you want to DIY it end to end though, which OP's article covers very well. What he doesn't spend any time on is how long it takes to get a proper "Hello, World!" at yourdomain.com without you being warned about using an insecure website.
At a minimum in most cases you need:
* a server, configured to serve your hello world and present your identity
* domain name
* DNS records pointed to your domain
* SSL cert of some kind, probably issued by lets encrypt for something like this (creating a certificate authority is a project in itself)
* reverse proxy if you are interested in serving over http+https
Each of these can be done rather quickly once you are familiar or blindly following a guide, but reasoning about what each part is doing is very time consuming.
> Has building a webpage never been easier or never been harder for a newcomer?
Interestingly, both.
It’s very easy to make a basic website that more or less works.
It’s very hard to make a website that does anything well.
Mistakes that people make on very basic, static websites:
- Images not optimized, so page speeds are very slow. Bad for Google rankings (incl. Google Business Profile / Google My Business). Sometimes these images break the design, and this can look very unprofessional.
- Responsive design is either non-existent or super janky.
- Content is not presented with a focus on how the users will most likely want to interact with the available information. This includes simple things like phone number, address, and/or hours near the top of the page for B&M businesses. It also includes more complex things like clear page/site organization and navigation.
Many people who make these sites know that they are bad, but they aren’t willing to pay the thousands it would take (at least in the US) to get someone to do a simple 5-page brochure site right (assuming that they don’t get scammed).
The gap between easy-to-make junk and tougher-to-make jewels is currently quite large both in terms of skill required as well as potential cost.
Depends on what you want to do. At its most basic level, you can still build and host a site exactly like you could in the olden days, there are still plenty of traditional hosting companies you can upload your work too, and getting a domain for such a site is easier and cheaper than ever. Plus SSL certificates are cheaper and easier than before, since Let's Encrypt has driven down prices in that market by offering a free solution.
It's also easier from a CSS perspective too, since flexbox and grid have taken all the stress away from designing traditional 3 column layouts, and making them work on multiple device sizes. No more floating divs for you this time!
But there's a difference between what's possible and what's expected, and I think that's where the confusion lies. If you want to make a 'web app' in the style of Google Maps or Gmail or Airbnb or Netflix or whatever else, then yeah you're gonna need to go down the long, somewhat confusing road of JavaScript frameworks and NPM and what not. And there are user expectations that a popular site will probably have many of the complex features that such frameworks enable, as well as a 'fancier' visual design than the sites of the 90s and early 00s.
So the skill floor has stayed the same, but the ceiling has risen tenfold, and that's where the complexity can come in.
In the 90s any huge site could get away with a table layout that worked well in exactly 1 fixed resolution without custom fonts and you certainly did not need to worry about SSL. Load times were not something to really worry about. People would wait. Most importantly, Google would not punish you for any of that stuff.
But now, you do. At the basic level very little has changed to make any of these things automagically free. For example css has advanced a lot, but you actively have to know and use it to make things work, where as in the 90s you mostly did not have to do anything and nobody (neither search engines nor users) would care.
So I would argue the real world skill floor has risen by a lot, in a mix of increased user expectations and and google expectations. On the other hand there's a wave of (SaaS) tools to flatten it. I am not sure what that nets to.
It used to be really easy back when Netscape Navigator (and Communicator) still included a WYSIWYG HTML editor and ISPs provided users with some megabytes of hosting accessible with simple FTP.
I am with Telekom in Germany. I just moved out and got my first ever „own“ internet connection/contract, so no hidden treasures there. What I did learn is that the e-Mail Account that you also used to get from your ISP still works and that my parents have been using that email address for the past ~18 years.
> my parents have been using that email address for the past ~18 years.
I feel this. My mom has been complaining to me lately that her email makes her reset her password every time she logs in. She's still using an ISP email account from a company that got merged into AT&T years ago, but she doesn't want to change it because it's the email everyone has. I looked into forwarding it to another email, but of course they charge a monthly subscription for that feature.
It's easier than ever if you ignore all the 'professional' tooling. Just Chrome or Firefox dev tools and an HTML file and you have an environment with instant feedback, auto-complete everything but none of the nonsense that most front-end developers deal with (since, as an amateur, you only need to make 1 page).
It depends what you need to build. You can still completely build a website with only a text editor and a basic web server host. Cheap and simple, if you're willing to learn html and/or css.
If you want to build Facebook, that's another kettle of fish.
Using absolute links is the complete opposite of what you should do. If the page you are linking to lives in the same path, there is no reason not to link to it relatively. It makes the path structure more modular.
Your being completely ignorant making this statement (about a personal webpage that is built from scratch). It is 100% their choice. How they reach the conclusion to write their links is 100% theirs.
"there is no reason not to link to it relatively." You have clearly been so isolated in your thinking, you are incorrect. Again, it is their link to share.
I feel like the common case, especially for new HTML devs, is to use one website.
And when they get more experienced, they'll probably want to migrate that site to a new host (for example my site was bbkane.github.io before I moved it to bbkane.com), which will break absolute links to the first (now down) domain. Yes, best practice is to set up a redirect from old to new anyway, but that's the kind of thing someone doing this for the first time doesn't think about.
So there's definitely a case for beginners using relative links. And it's less repetitive to type!
I'm also interested in how it is going to be for multicultural individuals (with their own personal webpages). You have 2 webpages English, German. Could be a collection of these pages only in English.
Amazing! Will definitely use this information for my author side.
I have no programming skills and always wanted to have a self hosted website that is quick, small, without any fluff where people can download my stories. Maybe to interact with me and with each other too. End of story.
But when I googled "website programming" it's mostly generic advice for design (everything looks like everything else) and bloated (slow) code.
You might want to look at some "elder self-hosting sites" (i.e pre f*book) like https://www.dreamwidth.org where you could easily set up an internet presence without fluff.
Adding that in HTML5, closing <p> <td> <th> <li> <dt> <dd> and other tags like these are optional. You can choose to not close those, and your HTML is just as valid.
If you practice not closing, you can do without any markdown language. As the HTML itself gets almost as simple as markdown. Plus, gives you advanced control not found in markdown.
I was going to say this! Moreover, besides self-closing tags, in HTML5 there are many optional tags. For example, you almost never need to write explicit html, head, body, tags. The given minimal example thus can be simplified to something like this:
<!DOCTYPE html>
<title>Example Webpage</title>
<h1>Welcome to my webpage</h1>
<p>This is some content!
I agree with your remark regarding the redundancy of markdown. It makes almost no difference to write markdown or html5 by hand. If people knew this, it would seem they would replace their "markdown engines" with cat (to put the header to each page), or simply with nothing at all.
> Moreover, besides self-closing tags, in HTML5 there are many optional tags.
Those are (rooted in) SGML elements having start-element tag omission allowed, whereas HTML's "self-closing tags" (in HTML5 parlance) correspond to elements having end-element tag omission allowed. In your example, SGML infers the missing tags for html, head, body, and p to arrive at the canonical form:
<html>
<head>
<title>Example Webpage</title>
</head>
<body>
<h1>Welcome to my webpage</h1>
<p>This is some content!</p>
</body>
</html>
Super cool, love how they can be used for prototypes to cover that gap from "CS professor's plain HTML website with a 1998 copyright notice" to "fiddling with margin and padding values". BareCSS in particular looks so nice I would never have believed it uses no classes or styles! https://github.com/longsien/BareCSS
nice, i’m building a personal css framework that builds on top of a classless base that is similar to bare.css, so i’ll have to go raid it for ideas like how/where it employs grid and flexbox. =)
ps - looks like they use some non-standard html elements and attributes to be completely classless. that's ok, but not generally what i'd want, though i'm quite tempted by the non-standard 'grid' tag.
Keep it mind that you cannot use github as free host for anything.
"GitHub Pages is not intended for or allowed to be used as a free web-hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS)."
>> Keep it mind that you cannot use github as free host for anything.
I found Github to be great for a static personal page. I found it notoriously buggy once attaching a domain. I've yet to find a good run-down of how to consistently host static sites with domains + ssl on Github.
Recently took on the challenge on learning Hugo, its quick but his learning curve is high (compared against Jekyll and Gatsby), specially because the docs seems to be more curated towards content management and how to deal with markdown limitations rather than web/front-end design, therefore there is no tutorial hell for "how to design your own theme", you have to look at how others solve it to give you and idea and once you get a glimpse on how they do it, you can go fast without using shortcodes, partials and other "weird things hugo have".
Only thing i will change in Hugo is how unopiniated tries to be, it always has at least 3 to 4 ways to the same thing and configurate the same thing with json, toml, yaml, etc...
I picked hugo for a project because of some fever dream I was having about golang whilst learning that language. I still suck at both. And I probably don't use either enough to get good at the moment.
Hugo has sharp edges and interestingly the thing I have noticed is that I would expect that Hugo should be getting to an almost finished sort of state with the project. Yet there seems to be a lot more stuff being added and just so much flexibility. Maybe I picked the wrong tool, but I agree with all of you're points about the non-opinionated nature being a disbenefit.
Pretty detailed guide! I'd just like to emphasize that nowadays you can literally create and deploy a personal homepage entirely for free.
For the individual touch, buy a custom domain for a few bucks, link it and even add a free custom mail (e.g. with Zoho's free tier).
It's remarkable how knowhow and budget requirements have dropped in recent years so that anyone can create something pretty good-looking in no time.
Personally, I use the combination of:
1) Hugo + GitHub + Netlify + Zoho for my personal blog and email (summed up here: https://geo.rocks/post/setup) and
2) Material for MkDocs + GitHub for projects.
A good (and IMO essential) deployment addition would be to host it on a bare metal machine and run a quick apache/nginx server. It important that people still know how to host their own site, properly from scratch and without big tech.
No. The article is (per the author) for non-tech folks to build themselves a personal web page. If they don't have easy access to ~free hosting at university_name.edu/~my_name to do that, then there are lots of cheap domain name registrars and good-enough-for-this hosting plans out there.
Vs. the technical aptitude, knowledge, and ongoing time commitment of running their own bare-metal servers, for a minimal-traffic personal web page? That's more like insisting that everyone must learn to sew, and make their own clothing.
I think it's still worth knowing how to host the website locally, even if it is only available on your local machine / LAN. Having to go through the deploy step and wait a couple minutes every time to view the tiniest changes is not very good, especially in the early stages of writing a website from scratch when you may be making a lot of mistakes.
Since I use Hugo to build personal sites, running `hugo server` locally produces a local version of my website that I can view in my browser at localhost:1313/ and which auto-reloads with every change. Hugo builds incremental changes almost instantly.
There are free "forever" VPS options from Google, Azure, and Oracle that you can use to deploy non-commercial servers. And together with either a free subdomain provider, or something like freenom to find a free domain registrar, you can have a fully free setup without using "no code" providers.
I'd rather recommend something like noip's free tier over Freenom btw.
They're an incredibly skeezy company and if memory serves me right actually are one of the extremely few ccTLD registrars to get fined for mistreating customers (which is extremely uncommon, ccTLD registrars have kinda free range to do whatever they want generally speaking).
In a more direct sense, they stole several domains from me about a decade ago by marking my account as abusive and then tried to resell those domains for ~6.24 euros to anyone else as a "premium" domain name (which I figured out when I made an alternate account) once they got some slight amounts of traffic. Very scummy.
It's a free provider so these aren't unexpected shenanigans, but I'd still advise anyone looking for a registrar to not use Freenom. Go for a dynamic DNS provider instead if you're starting out, there's quite a few with free plans. If you're willing to throw a few bones for a proper domain name, I'd recommend Porkbun myself but there's other options too.
I wonder if one needs a framework like Hugo, Jekyll, etc. if one only wants to host a personal site without a blog? Is there any advantage compared to starting with one of those bare CSS templates and building a static website that way?
If you want to have a simple web presence, you might want to look at some "elder self-hosting sites" (i.e pre f*book) like https://www.dreamwidth.org where you could easily set up your personal site, as I already mentioned in another comment.
Disclaimer: just a self hoster, who experimented with dreamwidth.org some years ago, and no fan of todays dominant "social" media sites.
There is one, XSLT. However, outputting valid XML was considered too arduous for the average webdev so we need to reimplement everything we want in JS instead.
XML and XSLT has been a mainstay of my career for over 20 years. They are web standards with multiple implementations. It'll keep plugging along for another 20 years while all these other proprietary "frameworks" come and go.
To be fair, when XML was cool, XSL did a good job in carrying out templating-language-like-features. Use case was like: Write semantic XML document, use XSL to generate XHTML, render XHTML in browser. Modern browsers still run XML with XSL.
I still use browser-side XSLT in my apps. Google had threatened to remove support but there was much pushback from the enterprise community that has many business apps using that approach so Google backed down. Still no guarantee that they'll pull the plug in the future.
Almost all webservers have support for server side includes. SSI are very limited and basically all you do is include one html file in another html file like <!--# include file="/footer.html" -->. It is the perfect combination of templating power and static html. It allows you to avoid all of the complexities of "static site generators" and "deploying" and all that cargo cult jazz.
Yes x 1,000,000. This is the only thing that drives me to something like React (other than the fact that I’m not actually a programmer and it’s the only thing I know) to build a site.
I know HTML! I know CSS! But how do I make a template sidebar, say, without a framework. It’s possible, sure. But a PITA. React just makes it easy, which is like using a baseball bat to kill a fly.
Check out Eleventy[0]. It’s my static site generator of choice. It’s pretty simple to pick up, high HIGH use case ceiling, and delightfully quick. Works with a bunch of different templating languages, too.
You are undeservedly downvoted. I think that there is a strong case for using frames as a templating strategy for static sites that are hosted on say S3 or Github.
Server Side Includes was probably the only thing that came close. While not actual templating, it did serve me well for code reusability and being able to make updates in one place. I made heavy use of them, even after discovering php3. It wasn't until I discovered smarty that I stopped using them. I miss those simpler days.
HTML Imports is (was) an awesome solution to client-side declarative composition. Sadly, it never gained traction in browsers - mainly because Mozilla said they won't implement it. The only option now is imperative code.
> other than it's obligatory "written in rust" advantage.
I completely fail to see how implementation language would be an advantage to a static site generator, especially the security advantages that Rust is often recommended for. Memory safety is great if you're exposing a program, but here i'm just exposing the results of the static site generator, and none of Rusts features will be evident there.
The only advantage from my point of view would be site generation speed, which goes for both Go and Rust over Python/Ruby.
I agree with this. It seemed so strange: The first half focused on doing everything from scratch and owning every line. The crash course on HTML and css was great, and the focus on it being a static site, hand-built in a text editor. Then, when it came to deployment, it was a 180 degree turn: Let's forget the details and rely on modern, magical black boxes like GitHub and Cloudflare! The opposite of owning your own destiny. Kind of jarring.
To be more in line with the first half of the article, I would have expected the author walk through registering a domain name, pointing it at your computer's IP address (or your VPS), getting an SSL certificate, configuring web server software on that computer, and so on.
See above comments on "paying a small company for hosting."
I've been using hostdime for the last 15+ years for this. Of equal, if not greater, benefit has been "being able to pay someone for email." Everything works smoothly. And more importantly, you can call and talk to someone if they, or you, or in my case my father screws up something drastically.*
*Somehow, and I don't know how, one day he deleted ALL, including business sensitive, of his email. ALL OF IT. I was certain we were screwed, until the company said -- well, this is drastic and you'll have to pay for it, but we could roll your entire server back a day before it happened.
Uh oh, how much?
Fifteen bucks.
(That plus the then $5 a month, now about 20 or so, is some of the best money I've ever spent. Have no clue what gmail people would do if this happened.
Less than 5 USD/EUR per month should buy you traditional web hosting ("webspace"), a domain, personal e-mail addresses and probably even database access. There are plenty of providers to choose from.
Yes agreed, and then you can go with a local web host - local to your country or city. And let's face it, cpanel or equivalent is fun to mess around with. Much more fun than github, zola and cloudfare pages!
If the aim is to satisfy non-technical website builders, then the HTML files can be simply SFTP'd up to the web host. Badabing badaboom.
Emacs is a visual editor (which also applies to Neovim, btw). Ed is a command line editor. But even if we assume that "command line" means "terminal", then it would still be wrong to describe it as a "command line editor", in the same sense at is wrong to describe a computer as a facebook client.
You are confusing line editor with command-line editors. If you interpret command-line editor as editing the command line, emacs has eshell. If you interpret it as an editor from a terminal, it's that, too.
Aren't all "line editors" also "command line editors"? Either way, that is not my point. I just wanted to point out that Emacs shoudln't be boxed into the same category as Vim, because while Vim ist most commonly used in a terminal, Emacs isn't.
That's a fair point, more precise phrasing would be "If you prefer a command-line interface, ..." which should be sufficiently vague to make almost everybody happy.
All files/pages will be publicly discoverable. I regularly chuck stuff on a webserver to share files (like /files/dat-283992.txt) that's only meant to be accessed by people I share the URL with, but that's not possible when the repo is public.
Additionally, your Jekyll config files will also be public, which I guess some people might not want, for whatever reason.
It's a very common mistake so there is lots of help for it: You search "disable directory listing" for whatever webserver you use. I mostly use apache:
> I regularly chuck stuff on a webserver to share files (like /files/dat-283992.txt) that's only meant to be accessed by people I share the URL with, but that's not possible when the repo is public.
It's just something to be aware of. In progress drafts committed could be seen and typos/fixes are publicly logged. That is unusual to be so openly accessible.
It means that not only the current state of the website is available (which it of course always is), but also your full edit history and the file tree.
Making a personal website is surprisingly hard. This article doesn't even go into meta tags, next-gen image formats, GDPR-compliant analytics, or how to add a newsletter.
I want to see more personal websites in the world. So, I've been building Postcard [1] to make it easy to set up a personal website. Caching, opengraph meta tags, page-speed optimization - it's all built in. I'm working right now on making domain connection the smoothest experience possible.
I mean, you don’t really need meta tags, next gen image formats, gdpr analytics or a newsletter to have a personal website. I have a personal site that works just fine and I don’t have any of the things you listed.
As for hard, I guess it can be incredibly easy or hard depending on how you want to look at the problem.
I wonder what happened to "upload the files via ftp and be done with it" deployment process? Setting up cloudflare, github, github pages, amazon, etc is just too in-the-trenches.
Throwing out a resource that helped me build my own website to host my resume (and led me to get an Azure Fundamentals cert)-- the Cloud Resume Challenge, which has been seen on HN in the past. (https://cloudresumechallenge.dev/)
Has been a huge help to me since I don't directly work with cloud resources like AWS or Azure in my current IT role.
I didn't read the article because it's too long, but here's how I do my dirt-simple page.
A css. A markdown to html converter. An index file (1 in each directory). A dozen lines of code in that index file. The rest is markdown and images for content. Use the directory tree to organize your stuff. Voila! Works great.
Can vouch for cloudflare pages for frontend for an easy static frontend deployment experience. Manages HTTPS, configuring deployment on pushes to repo, connecting to custom domain etc all with a few clicks.
Same. My personal page was on heroku. I realized it had vanished and very quickly I put together a page, GitHub repository connected to cloudflare, connected an unused google domain, redirected my old domain (I wanted to use the new domain).
I would suggest internal css in the head tag for a simple site. otherwise if the html loads too fast you’ll see an unstyled page before it reads in the css file
I'm using Cloudflare's CDN + image optimization, email services, and workers for private API access. I get 0.2s for TTI. A static website just means that your assets are pre-built.
So last week HN said "hey, go read The Pragmatic Programmer if you havent", and, I finished chapter one up a night or two ago.
It said, paraphrasing, "A single broken window in a neighborhood is often the catalyst that begins the transition from a nice neighborhood into a bad neighborhood. Everyone starts looking at that busted window and figuring everything's busted. Everyone starts to treat everything like it's busted and that's that, it's ruined". Ok, heavily paraphased.
Putting a little notice up, "Hey, we see this! And we know it's gotta get fixed, so here's a plastic sign with a recent date on it so you know we're around and working on it" is better than just leaving the mess. And an "under construction" sign on a website is meant to be this treatment.
I think the book is old enough that we hadn't invented the default-cynic who would immediately look for a 22 year old timestamp on the construction.gif and invalidate the entire concept with counterexample.
I believe the concept is sound, even if in practice it's often abused.
I've looked into this somewhat though I've not implemented any solutions.
There are some standalone site-search tools including lunr.js, among others (lunr is what I remember finding when I researched this a few years ago, there are now several other options).
Email forms can be implemented entirely as HTML forms, though you might want to include some anti-spam / anti-abuse options. Another option is a simple mailto link:
Likewise, the statement in the clip neglects the baseline starting point of the object.
I know it's comedy science, but "pie" is already a thing, as are apples. So "apple pie from scratch" refers to AFTER the apple and pie have been invented, not before.
I wouldn't use Cloudflare for deployments. They're known for arbitrarily taking over domains they manage and replacing their contents with their own PR pages with no advance warning. They're communicating with customers poorly too.
If you've read the news in the past month, CloudFlare removed its DDoS protection and caching service from KiwiFarms based on series of false reports, essentially taking the site offline.
But didn't cloudfare backtrack on that and state they don't want to be moderators of content because they want to be seen as a utility? They used the example of a phone company who doesn't care/not liable if you say naughty things on the phone. They want to be like the phone company.
No, they didn't they still haven't restored service, and they cut it based on completely fake reports, without any warning or communication. They're not trustworthy.
At least it's somewhat positive they "sort of" backtracked? To be clear, I'm in favour of these providers acting like utilities and staying out of content disputes.
I'm confused. This is a personal web site guide that encourages using a site generator like Hugo or Jekyll or Zola. (And it's on the front page of Hacker News, so it seems like it's interesting to many of us.)
If you mean, why is no one pushing Zola, this site is obviously encouraging it, so it's inaccurate to assume "no one" is.
I originally wrote this article for a “microcourse” I ran at the University of St Andrews—aimed at a non-tech background—on building a personal webpage. Especially in mathematics, having a personal site (that you control) to host research and other information is pretty invaluable!
Older personal math sites tend to have a very particular “historic” feel. While I personally have a lot of nostalgia for the look, I also think it’s good to take advantage of some of the newer tools that are available today!