Original article title: “Why I Created Banner Blog”. But I honestly don’t think it explains why. You establish the
problem, but don’t remark on a couple of existing alternatives that might satisfy your requirements, and more importantly, you don’t explain why you’re making it a
platform, rather than just something for yourself. Because honestly, if you want to blog, running a platform for everyone and their dog… well, that’s something completely different, and something which will take away from your blogging opportunities.
Current HN title: “Why Blogging Platforms Suck”. This would honestly be a completely different article, and one I’d generally agree with (which is why I will always insist on controlling my own site stack). Yet you appear determined to get into running a blogging platform, and I would be curious why.
Some more remarks:
• Well done on inlining the stylesheets. Having zero subresources has a way bigger effect on page load time than people tend to expect. (Want bonus marks? Strip unused styles from the sheet, and inline custom properties where possible (currently always)! You can save hundreds of bytes! Hundreds, I say!)
• You’re not compressing responses, but generally might as well; though thanks to TCP slow start stuff, it’s unlikely to make any meaningful difference at this scale. (You can get it down from just under 11KB to about 3.5KB.)
• The JSON-LD block is all wrong. It claims it’s a http://schema.org/website (which I believe must be spelled http://schema.org/WebSite to be interpreted correctly; aside: uh oh, the JSON-LD spec uses lowercase schema.org slugs in examples, sigh) but it should be an Article, and then has a nonsense `about` field that puts the title as the @type. Which is something I’ve seen once before, on Bear Blog. Are your tech stacks similar and it’s the same library doing it, or did you copy it, or is it sheer coincidence that you did the same wrong thing? (Aside: I don’t really get why people bother with JSON-LD—does it actually help anything? In theory it’s neat, sure, but in practice does anything actually use it and wouldn’t use the traditional meta tags if it weren’t there?)
• `body { width: 100% }` needs removing. It means that the page always overflows horizontally. If you removed the default 8px margin, it’d merely become unnecessary rather than harmful. `body { min-height: 100vh }` is also not what you want, though the situations that expose the problems are likely to be rare; but the normal trick for getting what you’re going for (… if you even decide it’s worth it) involves setting a minimum height of 100% on html and body.
• : type="image/x-icon" is superfluous since it’s the only icon, `shortcut ` is superfluous (that’s a matter of ancient history), … and in fact the entire tag is superfluous given it’s the only icon and the URL is /favicon.ico.
• Your font size is significantly too large on large screens. It’s extremely too large on small screens. I recommend not exceeding 1.25rem (typically 20px) as a :root font-size, and sticking to 1rem (typically 16px) on smaller viewports.
• Please don’t use a base font-weight of 300. On some very common configurations (generally involving Windows and low-DPI screens), it can be fairly difficult to read. Body text should always use weight 400. (From this and the scrolling things, I’m getting the sense you use macOS.)
• `font-family: Roboto;` means that most of your viewers will get the default font, which defaults to a serif like Times. Honestly, I recommend sticking with it. Serifs are generally cooler. But if you actually care for what you specified, then make sure a generic family is included.