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..
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.
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'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
>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.
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.
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!
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.
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.
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.
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.
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!
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.
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.
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 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 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.
> 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 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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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>
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.
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.
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.
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:
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.
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.
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.
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 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.
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).
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.
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).
261 comments
[ 3.3 ms ] story [ 274 ms ] threadHTML 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.
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.
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.
https://brid.gy/
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 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
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.
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.
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.
There are so many, so many sites that would be perfect with just basic HTML and maybe some CSS
One of them even pull in jQuery...
- http://bettermotherfuckingwebsite.com/ => GA
- https://thebestmotherfucking.website/ => Plausible + jQuery
- https://perfectmotherfuckingwebsite.com/ => No JS included
So 3/4 have analytics, + one with jQuery.
Tested by looking at requests made in the network inspector of the browser developer tools.
You're right. My adblocker blocked it, so I didn't spot it. What I said about jQuery, however, is still true.
> - https://thebestmotherfucking.website/ => Plausible + jQuery
Wrong—this one doesn't use jQuery, and none of the others do, either.
> https://thebestmotherfucking.website/js/jquery-3.5.1.min.js
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:
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.While I think this is a bit of a stretch I think the really inaccessible part of it is knowing how to host and deploy it.
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
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.
https://astro.build/
It offers a JSX templating language and "adapters" for deployment on various hosts like Cloudflare.
Things I liked about Astro:
- It can use front-end js frameworks like Svelte and Vue as components (and it can load the JavaScript only once these components appear).
- familiar JSX, scoped CSS and single-file components for astro components.
- Some nice plugins for responsive image optimizations.
- nice touches like hot module reloading. It's nothing new, but it does just seem to work.
I also believe there are optional SSR elements to astro now, but I have not played with these.
Perfect to learn on without needing to use money.
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.
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.
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.
"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)."
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.
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!
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.
Maybe a mention of using https://validator.w3.org/ would also be helpful to check that all the html is correct and complete.
i remember learning CSS/XHTML and getting your website to pass the validator so you could proudly show the badge on your website was a big deal.
I'm not 100% sure what the difference is, but you can see the source code at https://github.com/validator/validator and report any issues.
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 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...
Great work, thanks.
[1]: https://pilabor.com/blog/2021/05/building-a-blog-with-hugo/
".." navigates to the parent directory of the directory containing the current file.
"." refers to the directory containing the current file.
As for hosting, i personally use the free tier of Azure to host mine (https://azure.microsoft.com/en-us/products/app-service/stati...). It doesn't allow for anything "business related", but neither does Github.
It does however provide free SSL certificates, which is/was something that github pages didn't do at the time, but i think they've since changed that.
Zola is basically a stripped down Hugo. I don't see any reason choose it over hugo 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 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?
I dont fully understand why it has never been included in the HTML standard.
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.
(Now obsolete though)
[0] https://www.11ty.dev/
For example, my RSS feed is processed with XSL to provide a friendly landing page:
https://interconnected.org/home/feed
(view source, second line)
Disclaimer: just a self hoster, who experimented with dreamwidth.org some years ago, and no fan of todays dominant "social" media sites.
I use http://zim-wiki.org + a customized template.
http://jrm4.com is it.
even for resume https://github.com/casualwriter/casual-markdown-cv
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.
A friendly reminder that Emacs is not a "command-line editor".
If you mean "line editor", emacs has batch mode.
"Unless you pay, GitHub Pages requires your repository to be public."
How is that a problem with a static website?
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.
https://duckduckgo.com/?q=apache+disable+directory+listing+h...
Have you heard about encryption?
It's no different than sharing a link to a file in your Google Drive accessible only to people with the URL.
Encryption doesn't play the role you seem to think it plays here.
Yes, aka encrypt it.
> Or I could give it a unique undiscoverable URL.
…which is not possible if the repository is public.
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 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.
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:
Cf. http://sgmljs.net/blog/blog1701.html (the TALK slides) explaining the inferences SGML does on the example input in detailIt'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.
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.
It's rare enough that the CEO publishes a blog post every time they do it.
"This is a hard case and we would caution anyone from seeing it as setting precedent."
"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.
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!
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).
E.g., <https://victoria.dev/blog/add-search-to-hugo-static-sites-wi...>
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:
I have used water.css, simple.css and Tufte.css and all of them are great.
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.
Use real vim.
I learned a few weeks ago that my ISP still does this. It’s a bit hidden in the depths of the customer portal, but it is there!
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.
I was taken aback and delighted that they had a drag and drop directory enumerating your CSS and HTML files.
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.
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.
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.
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.
If you want to build Facebook, that's another kettle of fish.
If you mean, why is no one pushing Zola, this site is obviously encouraging it, so it's inaccurate to assume "no one" is.
No fuss. Whole process felt very "clean".