It may not have a zillion libraries, but surprised that a site trying to be zippy uses low-contrast text (obviously, I am not a fan of the "increases engagement time" school of thought).
Agreed. I feel like I'm always the first in my company to complain when someone proposes a too-thin or too-light font style or color, but this read fine for me. I'd move away from monospace if anything, but I take that as a stylistic choice they made even if it hurts readability a little (not like thin gray that's used without even noticing: the dev already knows what's written there, or doesn't care if it's lorem ipsum, and checks the font only for form instead of also for function).
It passes minimum (AA) contrast recommendations but fails enhanced (AAA) contrast recommendations. I also wouldn't settle for it on a site I'm responsible for.
I genuinely believe Gatsby is the epitome of everything wrong with front-end development. It’s such a bad framework. So complex and confusing and fragile just to generate static pages.
Nice, it’s always interesting to discover blogging stacks.
Historically a blog requires a feed, this is typically where super minimal stacks stop, although I guess you could scrape your index.
I wonder how many web devs can still build a blogging app, a webshop, etc from first principles when mostly it’s all npm create packages and template languages.
I started a php / SQLite blogging stack with basic web based editing and a feed (ah and tagging, a search), hope to add more indie web features to it.
Simple static sites are great ideas. Writing HTML/CSS and not relying on a WYSIWYG back-end editor is an awesome way to work, especially if you're using a templating engine to generate the static content as mentioned here. However, in my experience the people paying to have websites built or your in-house marketing team maintaining and updating the company website, making sure the SEO is up-to-snuff, etc. can't do these things. They don't want to learn how to do these things. The unfortunate truth is that more times than not they require Wordpress or something like it to do their job.
This seems to fall into the 'simplistic, not simple' school of thought. You can have a relatively simple website if it doesn't do anything and if it cuts corners.
Take your dark mode, which is just about the only nontrivial feature I see on this page. (One could also criticize the low contrast of the appearance and other problems, but that's less relevant to the simplicity thesis you're claiming.)
First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load instead of the correct way of CSS body classes; so you get the 'flash of white' unavoidably on every page load - just what every dark mode user with their phone to their face at midnight wants to see! (If your solution doesn't work, it doesn't matter if it's 'simple' or 'complex'.)
Second, you implement what is like 3 lines of JS (setting localstorage & dark-mode) by pulling in what looks like an entire interpreter for a custom 'hyperscript' https://hyperscript.org/ language which seems to mostly just offer some sugar over JS; now, maybe you use 'hyperscript' elsewhere for reasonable purposes, but surely pulling in a 96kb (uncached) library solely to run
def saveMode() if first classList.value of <html/> contains 'dark' set localStorage.kkColorMode to 'dark' else set localStorage.kkColorMode to 'light' end end
init if localStorage.kkColorMode is empty set localStorage.kkColorMode to 'light' end if localStorage.kkColorMode is 'dark' add .dark to <html/> end
is a bit against the spirit of this "simplicity is the ultimate perfection" enterprise...? Personally, I feel like I see some easy perfection to add right there. (And is this hyperscript stuff also why the HTML doesn't validate?)
Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it. And since localstorage expires and users switch devices, they would have to do so repeatedly. Is this a good thing? A user probably would disagree with the developer who is touting how 'simple' the dark-mode implementation is because they cut corners in handling system settings/auto-dark-mode...
> First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load ...
I agree with your whole comment, but the media query approach is also tricky.
You typically still want to offer a toggle while respecting prefers-color-scheme, and you may want to give priority to whatever choice the user has made with that toggle if they've used it on your site before. This still requires JS and localstorage.
So what to do? My preferred choice is having an inline style element of:
body {visibility: hidden; opacity: 0;}
This will maintain the previous page until DOMContentLoaded, at which point you can query prefers-color-element and localstorage, set the body class correctly, and let the page paint.
I've been considering this recently for my site and I settled on having prefers-color-scheme on the root domain with dark. and light. subdomains. If the user chooses a color they just get bumped to a subdomain that sets a cookie with their preference. If they come to the site from an external link and they have a preference cookie they get redirected to the subdomain again. Absolutely no clientside JS is needed anywhere, no FOUC issues, and it's trivially simple to code because it's literally just a redirect in the server config based on a cookie value.
I really should spend the time to actually build it, but Diablo 4 came along and I got sidetracked.
I don't know whether to be fascinated or horrified by this proposal, but I admire the novelty - I can definitely say that in all the dark-mode proposals/implementations I've looked at over the years we've been fiddling with ours, I've never seen that suggested.
My idea has the benefit that users can block the cookie if they want to and still use whatever mode they want, although they'd lose the redirection 'functionality' if they do that.
This sounds like it would have the same problem as redirects to mobile subdomains - users will share links to light. and dark. subdomains, unknowingly forcing their preference onto the recipient.
The proper solution is to only implement the media queries and yell at browser vendors to make this easier to toggle either for all websites or for specific websites. Implementing a light/dark mode switch in every website is absurd.
unknowingly forcing their preference onto the recipient
I'd suggest knowingly rather than unknowingly. It's a link to a website after all. It should link to the same thing that the person who shared it was viewing. That's the point of a URL - when you share one the recipient should see what you were seeing.
FWIW I would also like browser vendors to do a better job at enabling users to manage their preferences on a per site basis though.
You can also swap out the CSS file for one that explicitly sets/unsets light/dark mode. This allows for a website that works in any browser even if your Javascript breaks or doesn't load.
Or you could use cookies. No need to mess with localStorage. Just set a cookie "prefersDarkMode" to true or false and have the backend send the right file. No need for an interactive backend, nginx can handle serving files based on cookie contents. No need for cookie popups/walls either.
> This allows for a website that works in any browser even if your Javascript breaks or doesn't load.
I just use <noscript> for this. If you don't have Javascript you're just going to get whatever your prefers-color-scheme is set to. Users without JS don't expect things like a dark-mode toggle to work anyway.
The nuts-and-bolts implementation of inlined-CSS to avoid flash-of-white is separate from the UX toggle question, which is why I listed them as separate criticisms.
The former is just wrong of OP: no user wants the FOUC flash-of-white, end of story; similarly for some of the other solutions proposed here (block the entire page, really? talk about burning down the village to save it). The latter has more leeway for design: we settled on a tri-toggle to use the media-query but allow users to override and hardwire light/dark mode, and that seems to work most naturally. But there may be other contexts where something else would be better.
Indeed, for toggles, you could even try not having a toggle at all and relying on the system setting through the media-query. (However, as appealing as this is - why have separate controls when the user already has a global control and can enable/disable it? - we found this confused & angered users: https://gwern.net/design-graveyard#automatic-dark-mode So, gotta have a toggle. At least for now; maybe as dark-mode becomes universal, at some point users will become educated enough that you can afford to use only the system setting?)
> block the entire page, really? talk about burning down the village to save it
I'm curious for what the other approach is. Users find it annoying to refresh the page and have their dark-mode setting change, or have their dark-mode setting change while navigating the site.
So I have to block paint until I can query local storage in order to avoid flashing, what's the alternative? Below someone suggested using cookies and only serving CSS that does the desired styling, which I guess is doable but requires a non-trivial infrastructural change.
As long as you have a good reason for your decision. Some things you just have to make tradeoffs and can’t please everyone. Enter key to submit or enter key for newline in a chat context? You’ll go crazy trying to solve for all - sometimes it is just not possible
You don't need to hide the entire page until fully rendered. You inline in the head just the bits of CSS/JS you need and set styles from there, so if you are in dark mode, it's set to dark before anything has rendered, without needing to block a huge amount of time. You can see how it works on my site https://gwern.net/ - set dark mode in the toggle (assuming it is not your system setting already), and refresh or force-refresh; note that there is no flash of white nor is the page hidden until rendering is fully finished.
The idea there is what we call 'demo-mode', a new feature to try to enable helpful chatty features but for only _n_ page loads. So the full theme toggle (or Control Strip in Mac terms) is exposed on the first page load, but then is left collapsed into the gear on subsequent page loads to reduce clutter.
I don't think it should 'try to slide up then it dies'; do you mean you can't see the gear at all?
I don't notice any "flash of white" (Firefox, Chrome, Safari on Mac; Firefox, Chrome on Android). Not on initial page load, refresh nor toggling between Dark and Light. It seems to just work.
Well yes, the entire page flashes white if you have FOUC because you implemented it wrong. And since mobile browsers are usually fullscreened, it means the entire device flashes you; I assume you don't use dark-mode much if you haven't noticed this. But dark-mode users do notice and once in a great while, even complain to you about it.
Honestly if the goal is a website as simple as possible, dark mode should not belong there at all. We've had simple readable websites in 90s long before the dark mode fad was a thing, only having light mode is fine.
> Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it.
There's so much complexity here that goes against the philosophy of a simple website if simplicity is the goal. They should just skip dark mode entirely. HN itself is perma light mode, it doesn't stop me from reading it at night.
hn isn't pure white and it does kill me at night on powerful monitors... just like I can't do dark mode outside on a laptop. Sure we did readable websites in the 90s, on dialup or slow dsl, and they took forever to load on small monitors. We also didn't have USB or SSDs.
Dark mode and light mode is a nice tradeoff for varied lighting conditions.
Well I don't really mean white, but more of pick a default theme that works in both day and night and stick with it. So that it's all kept very simple. You could use a dark theme as the default as well, but light mode tends to be more accessible in more situations so I prefer light over dark. As an example, I think the Solarized Light palette is pretty usable in all situations.
If you have ergonomic issues with mostly white screens, it should be the job of your operating system or web browser to police this. It wouldn’t be difficult to implement a feature that sets a maximum total luminance for each page. Perhaps even automatically inverting the colours if it’s over a certain threshold.
> If you have ergonomic issues with mostly white screens
...you need to turn your display brightness way down!
Hold a piece of white paper next to your display. Open a window with white background. Is the window/display brighter than the piece of paper? It's too bright.
It depends on the display of course, but just as an example: my brightness setting is at 2 out of 100. At the work computer it's 19 out of 100.
I've been using Chrome's experimental "Dark Theme" feature on Android for months primarily for reading HN at night. It works great for HN, but occasionally it renders other websites completely unusable.
Why would simple avoid dark mode? It respects the user's preferences.
My site uses CSS to respect light/dark theme, so has no manual toggle. (A manual toggle requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS.) It was quite simple to do: just a media query and setting a few colours.
I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar. I don't know of a browser that does this, yet.
'Simple' is always relative to requirements. Otherwise, you'd just be sending 80-col ASCII textfiles down the wire (or something even simpler than that, like nothing at all).
Is dark-mode a good requirement? I'm not sure. It's nice to have, and our dark-mode does look great on a recent smartphone in the dark - but if I had known just how hard a good dark-mode would be, and how many of the issues we would struggle with (issues which OP runs headlong into), I think we would've skipped it. There's a lot of other things that time & energy could go into.
For most websites, I would say that they have far too many problems to spend time on dark-mode, no matter how trendy dark-mode is. (Users who really want dark-mode can install one of many extensions/plugins/apps/screen-inversion tools. They work reasonably well, and usually avoid issues like the white-flash FOUC.)
I was reading this thinking "that's a great analysis" and then read _who_ posted it. OP, this is the author of https://gwern.net, which has been very influential in the design of many technical blogs / personal sites and has some very inventive and fantastic ideas. Ie, the author knows what they're talking about.
My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar.
/u/gwern, in case you read this, your design along with Tufte.css were one of the influences of my own site: https://daveon.design/ . (Also present is inspiration from older-style publishing and manuscripts, and personal preferences. But your site was the first one -- a key influence -- I saw that inspired me with what a modern, clean personal website could be and how it could look, as well as what it might contain. It's a real honour to see you here and reply!)
> My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar.
I agree that it should definitely respect the OS level setting but I really like it when I'm given the option to override that setting. What if I don't like the way a site implemented their dark mode styles and I would rather switch back to light mode for just that one site. Having no toggle on the site I would have to go to my OS level settings, turn dark mode off, then later remember to go back to my OS level settings and turn it back on.
That's very flattering. So I'll relay some comments on your site:
- you make sentence-spacing a major design goal. I looked into that a bit ago and I found little or no real evidence that sentence-spacing is a good idea (https://gwern.net/doc/design/typography/sentence-spacing/ind...) and it would be expensive to implement: you do the only reasonable thing of injecting <span>s... but oh so many <span>s. If you get long pages like mine, that is going to cost you - DOM nodes are not free, soldier!
- one issue with sentence-spacing is that you are fighting HTML & CSS the entire way. They just do not want to do it. You correctly note that it's hard, but you accidentally demonstrate it's even harder than you thought: you have justification enabled but not hyphenation... so all that happens is that sentences get stretched out to make them fully-justified and you get large double-spaces everywhere! Your current implementation winds up being not so much 'sentence-spacing' as 'every few words spacing'. (This is especially glaring in the sidenotes, like on the page I'm looking at right now, 'Stephen Zamadics' looks like 'Stephen_________Zamadics'. Since you set the column narrow, you probably want good hyphenation too... perhaps server-side, if you're deadset against JS.)
- Dropcap positioning is hard, especially if you'd like it to work on more than one browser, and I'm not surprised yours has problems; pretty much everyone screws those up. (At least, I assume you don't intend the positioning problems like the '1' almost overlapping the 'someone' in cases like https://daveon.design/creating-joy-in-the-user-experience.ht... .)
- I think the dotted underlining is too hard to see: much too small and close to the link. Are you sure you don't need `text-decoration-thickness: from-font` & `text-underline-position: from-font`?
- Rubricating the entire sidenote on hover seems excessive.
- Sidenote numbering is very confusing. They get numbered 1/2/3/4... and then all lose their numbers in favor of ''? Mixing numbered & unnumbered is confusing enough, but then transitioning at the utterly arbitrary '5' let me baffled and wondering if the ''s were supposed to be a separate kind of sidenote like a margin-note. Definitely a case for 0/1/infinity.
- Sidenotes come off as cluttered and hard-to-read, at least partially because they are all 1 big paragraph. Breaking them up would increase readability. I hope you didn't inherit Tufte-CSS's unnecessary and artificial limitation to non-block elements...? (I can't believe they refuse to fix that.)
- EB Garamond is a variable font, which is a bit of a questionable choice because OS+browser support is still relatively low. (Just browser-wise, it's only at ~95% global https://caniuse.com/?search=variable%20font so add on OS incompatibility... The text should still render, but it won't look like you expect it to. Example: https://share.obormot.net/screenshots/Arcturus_Screen%20Shot... Also shows the sentence-spacing problems & dropcap problems.)
- The use of auto-smallcaps (after H1s, I guess?) winds up feeling busy and confusing. Look at a page like https:...
For information, static sites are unchallenged imho.
Even for a certain level of collaboration, I think one could get away with using static sites. I haven't tried this in practice but imagine having a git-based CI/CD flow for a static site, where non-technical end users could use the web-based Markdown editors of github.com or gitlab.com to make small changes, save and push via a pull request.
Each merge is of course approved by a more technical user.
I would love to hear if anyone has tried this model.
I'm a technical writer and this is how I'm running docs at my company. You'd be shocked at how easy it was to get one of our content marketers comfortable enough to start opening pull requests for an internal-only docs site. (It helped that I assured them that, thanks to how branches and approval workflows function, absolutely no changes they made could ever wreck the live site.)
I've thought of something similar! A git-based flow for a friend's static portfolio site, where he can make text edits and upload images, and the site builds that content with HTML templates.
Not sure how the GitHub markdown editor would feel for the user. It might be really great, even for uploading images.
I was imagining a static admin page, WYSIWYG, that makes git pushes on submit. These were the headless CMSs that seem to be able to accomplish that:
Github.com and Gitlab.com have after all put a lot of effort into their WYSIWYG editors, but they're not very useful for image uploads.
That part should probably be handled separately just to avoid slowing down the git repo with huge binary files. For example upload an image to S3, note the path, enter it into a markdown syntax image url.
There are many ways to skin that cat, depending on the technical skill level of your client. They could even e-mail the images to a script, or message them to a bot on an IM service, that then returns the URL for them to use in Markdown.
I am trying it now for some volunteers that I am building a web site for. Building the web site and responsive theme almost from scratch took about 10 hours of work, and further changes will only be the addition of news items ("posts" in Jekyll slang).
The theme is HTML and CSS plus about 20 lines of jQuery JavaScript to handle simple toggle effects such as the hamburger menu on mobile. Probably could be done without jQuery but I am not a web developer and that's what I know. Posts are written in markdown and the idea is that the others will either send me an email or later will open a merge request on GitLab.
There's a fairly popular site I run that is run like that, except we don't use github. Just `git push production production` to push the production branch to the production machine. The bare git repo there has a post-commit hook that detects production branch pushes and unpacks the branch to the correct server directory, compiling some static assets along the way. If we want you to be able to push to production we just add your public key to the machine where that git repo resides (no login, just git). Makes pushing changes very easy. But it's obviously not high-availability, or CDN-backed or anything crazy.
What are your thoughts on (1) Obsidian vault (folder of markdown files), (2) stored on a shared Google Drive folder (several team members can edit files using Obsidian) (3) Less technical users could publish the site by using GitHub Desktop app. When they commit changes (4) git-based CI/CD uses MkDocs-Material to publish the site somewhere...
Maybe I'm misunderstanding, but this doesn't sound all that different from your average static site generator—Python-based Jinja templating for HTML files versus Ruby-based Liquid templating for HTML/Markdown files (i.e., Jekyll).
For sure! I'm all in favor of bespoke new tools. If anything I'm just confused about the way they describe this in contrast to SSGs (and why a SSG wasn't a good option for them), and then go on to create a tool that literally generates a static site. :P
Maybe I'm being obtuse, but the reasons they gave for not using an established SSG primed me to expect a radically new solution. Versus "we didn't like any existing SSGs so we built our own," which was my takeaway from the whole thing.
I was thinking the same thing. If the author's goal was simplicity, it seems like a strange choice to forgo using an existing SSG only to build a bespoke one on their own.
A PHP site (for the includes), or an out-of-the-box SSG would make much more sense, IMO.
If it is a website - then it is plain HTML with some CSS. The exception is - there will be some JS if we want saucer flying across screen.
If it is an application - the logic will be coded in plain JS that talks to backend using JSON based RPC. No frameworks bar some domain specific libs. Minifying / building step can be included for production.
Fancy that! HTML and CSS? To make a Website? They must be mad!
All joking aside, I use the same stack save for the templating. Unless you are a web developer I don't see the point of a CSS framework, it's much easier to roll your own. Nor of a site generator, I tried Hugo it saved no time at all. Nor of JavaScript, a few months ago I tried replicating the websites of a few companies to improve my css skills, HTML and CSS were enough to reproduce the appearance of all of them, yet none of their website would even appear without JavaScript enabled.
We stack on framework after framework, new languages, new tools, all for nothing but increased complexity and busy work for a new generation. (Save for the 5% of websites that actually need that stuff.)
Also interesting to see they actually sell a service, would have been curious to know what their prices are like.
I see your point. My recommendation if you wish to improve your designs is to do them outside of CSS if you don't already. With something like figma or Penpot you will have your fonts, palette, spacing and layout all predefined.
Then once all your views are created using these common elements, you only need to transcribe them as classes in your CSS and use those few classes where needed in your HTML.
I'm not a design expert, so take it with a grain of salt, but I used to be terrible and following that workflow allowed me to get decent.
Without some design knowledge and experience (and dedication), starting from a blank canvas in Figma, Framer, or Penpot is going to be extremely difficult. Design is an art and skill in its own right.
Of course but starting from the assumption that he is doing it himself he will have an easier time using design software than jumping into CSS.
Design software encourages/enforces good design rules through its interface. You couple that with a willingness to learn and a bit of practice and you can achieve some nice things. Especially given that the design of some types of websites is very codified like SaaS or blogs.
Reminds me a bit about the minimalism trend where people boasted about getting rid of all their belongings, only to mention at the end that they borrow everything they need from their parents or roommates.
Are there ways to view tweets without an account? Kind of like archive.is? For now, I could enter it in Google and view cache, but I assume that will go away soon.
And if I understand correctly, it's not the index.php, but the actual service behind it, that earns thousands per month. Looks nice :)
Just because you can doesn't mean you should. Just because it's one file doesn't mean it's better. It'll be shit to maintain, it'll make working with multiple developers a pain (merge conflicts much) and having one file means having minimal structure at best. There's a reason why we split things up into multiple files.
I could also write his cool startup in just one line if I just remove all newlines. Does that make it even better than 14.000 lines? Obviously not.
Why? Most companies require skills in frameworks and libraries. The fact you can glue them together shows a different skill, that you'll most likely use in job daily.
This feels so forced. Make a joke CV, strip it of any mentions of these "bad" things, try applying. Good luck.
There's a ton of value in building stuff without tools. It's somewhat similar to learning two frameworks; seeing React's philosophy makes me a better Vue programmer. In a similar vain, building stuff without tools teaches me a lot about what those tools actually offer me. What stuff is really hard? What stuff is really easy to abstract out? How do Vue/React/Whatever do these things?
It also teaches you more about your platform. In the end, all these web tools and frameworks are running in that same browser. I find especially with newer web developers, it's hard to solve something in React/Vue/.. because they don't know how to break up the problem. If you'd roughly know how to solve the problem without those frameworks, it becomes much easier to figure out how to solve it with them too.
Finally, I also just get toolchain fatigue. If I want to build a simple landing page, I don't want to learn new stuff, I don't want to read what changed in the latest versions, what the correct way of the day is to set up a project. Honestly, I don't even want to have a build pipeline and module swapping dev server, that inevitably needs to be configured. Just some static html/css/js is often good enough. And as I said, you also learn which problems frameworks solve well, so you'll know when some static files isn't the right choice.
I think everyone writing content for the web should learn HTML and maybe some CSS - although the design part should be done by someone good with CSS, so that you only need to use semantic HTML, or you will end up with div's all over.
I think CSS is an order of magnitude more complicated than html, so I'd leave that to the professionals. But pretty much everyone should learn html, I agree with that.
With a little bit of CSS I mean enough to know how to add some extra padding to all buttons on the site, like finding button { padding 4px } and change that to 6px.
I believe the most minimalistic and productive way is to just use php. The language was specifically just created for that. If it's a simple site then you don't need composer you don't need router logic. just create separate files for header footer navigation and include them on each page.
if you want simple, you can't beat PHP + HTML. I wouldn't actually go that simple for anything that's more than a single purpose script, usually I would at least have a separate templating library, but it's really nice that you can do it.
Ya, or any server side scripting language. You just want the ability to refactor your site, as in, name, save, and load data and code blocks.
And if html allowed inserting html as it does css or js from external files, even that would be mostly be redundant. If only it let you use <html src="" /> at will.
Even better better just <html src="" /> or even <div src="" />
Functionality should be considered based on potential utility. Not sure what politics are involved at the w3c, but if it's not that, then maybe it's their philosophy and approach that has them not going for that which is most useful.
You can build a router and layout in about 100 lines with no libs. If the router just checks the existence of the file and the layout just includes header.php, pagename.php and footer.php. I do that for simple sites. Very easy and fast.
I agree with your sentiment, but with just 5-20 hours of effort one can make an effective Eleventy-based custom site generator which is then deployed on Netlify for free (and edge-available globally).
Edit something, git commit/push, and within 30 seconds your changes are live everywhere. It's pretty awesome, and it requires no "server" hosting.
Agreed, with the caveat that it's only so easy if a server is already set up for it. Otherwise it loses a bit of it's edge, but not by much.
We are being simple, and I consider a simple PHP site about one step above HTML and CSS in required complexity, and about 5 steps below anything else in regards to tooling/setup/execution.
I think every flavor of Linux except Alpine includes PHP by default if you go the VPS route and every $2 shared host also has PHP. Seems like a bit of a moot point.
Working with PHP has always been such a breath of fresh air. No build process, just upload the files via FTP and it works. You can keep it as simple as you want (just include() files, write functions directly, I never really need to use classes in PHP).
Totally agree. I think where complexity really creeps in is as you add multiple new content editors with varying skill sets.
If you want a team of people that don't know HTML or rest of the stack to edit, manage and deploy it then you're going to need a more complex abstraction.
The alternative might be a training programme for new staff in HTML, CSS, git and rsync.
You're trading one type of complexity for another. As you say, it all comes down to use cases.
I've landed on the same approach for my photography portfolio. Benefit of jumping ship from development to photography is that I don't have to rely on Squarespace like most other photographers!
After trying a few server-based options like Ghost, Statamic and self-built ones with Phoenix or Vapor (I've covered some ground as a dev) and the usual SSG options I ended up just writing everything as straight HTML without any templates and upload to a Hetzner server using rsync.
The lack of templating for shared UI like navigation is a touch irritating, but with some RegEx magic I haven't found a change I want to make that takes more than a few minutes. I got caught out early on with some greedy RegEx that nuked some content, but git to the rescue.
Image generation with all the sizes and format variants is laborious, but it prompts me to try new layouts rather than relying on cookie-cutter ones like Ghost. Plus I've noticed a slight improvement in image quality generating my web variants out of my RAW editor (Capture One) vs using the libraries and CLI tools used in most SSGs.
It's slower, but my thinking is that it's more akin to putting together a photo book. It take more effort up front, but once it's done, it's done for good, and won't need mangling in and out of various CMS over the next 20 years!
Someone beat me to the punch and added the URL (thanks!).
The site is what's left over after trying a few different options, most notably Ghost and later Zola.
Most of the current layout mimics what can be created within Ghost's editor. I then migrated to Zola which shares the bulk of the layout. Currently most of my images are coming from Zola's "/processed_images" directory. You can view the Zola codebase here[1] if you like.
The layouts I'm currently working on (not yet published) are heavily influenced by Andrew Clarke's work [2] and his book "Art Direction for the Web" [3] which I highly recommend if you want to explore less generic layouts online. I hope that on day my site can be example that web design can be as varied and interesting as print!
It's something I've considered with both nginx and caddy because I've got the server so I may as well use it! I prefer a server over services like Netlify because I can deploy with rsync rather than git (or the web-based UI). Plus it lets me log the many 404s I get after so many site migrations, and then create 301s. Most services like Cloudflare and Netlify just swallow details like that unless you pay for upgraded analytics.
I keep it as vanilla HTML though because I like the fact that I can open any page as a standalone file with no server and almost any browser can render it. I'm not saying this won't change, but for now I'm happy without SSI.
Plus, I'm using Nova for some Panic-based nostalgia (Coda was big when I started), so I like having the code and rendered HTML side by side in Nova's preview.
I moved from static HTML to 11ty (https://11ty.dev) for the same reason and I'm pretty happy with how simple it allows you to keep things. Plus, it helps me avoid yak shaving instead of writing content!
I think for a site like this I'd go with 11ty, just a clean project without a template or custom config, one collection to pull the photos from Flickr inline the styles.
(just sharing my personal approach, nothing wrong with Jamie's approach, ofc)
Also, you might find some value in an approach that I used recently (https://news.ycombinator.com/item?id=36592641). Using a Google Sheet as the data driver was easy, but it could have just as well been a filesystem of photos.
I really want to like Vapor because it's just a simple stripped back server-side framework; but I always get frustrated building with it. I've loved learning SwiftUI, but Vapor - even with Leaf swapped out for Plot - just isn't as ergonomic.
Plus I have the lingering memory of working with Elixir and Phoenix LiveView which is kind of the gold standard for web frameworks at the moment in my opinion.
- Svelte + TailwindCSS (Basically just a couple html files, plus the power of templating)
- Flickr API (To pull my photos from an album that I use just for this website)
- Netlify (To host the site - all have to do is `git push` and the site auto deploys!)
Total cost (incl hosting): $0
With Flickr I can manage the photos from my phone via the Flickr app.
With Netlify I don't have to tinker with an actual server box, plus it's free.
I'm still using Dreamweaver 8. I have to run it under Wine on Linux, but I have a permanent license, and it works fine. That does most of the drudge work. Sometimes I'll hand code some Javascript.
I wish there was a modern version of Dreamweaver that didn't phone home, didn't use "cloud", and didn't require endless payments.
I've not tried this for any adobe products, but you could try running them in a locked down environment (container, vm, whatever) and don't allow network access.
Adobe Creative Cloud apps stop working after a while if they can’t phone home. Adobe Creative Suite apps do not.
“After Adobe Systems' acquisition of Macromedia in December 2005, Dreamweaver 8 was added to Adobe Creative Suite 2.3 and was later succeeded by Adobe Dreamweaver CS3.“ [1] (Replacing Adobe GoLive, good riddance)
So you could use up to Dreamweaver CS6 with just a serial number (usually requiring one-time internet activation), but anything newer requires regular internet access.
The article says "Unfortunately, Jamstack tools require an initial setup and an initial (and continuous) learning" but with the bare minimum, static website generators are nothing more than glorified template engines.
I'm using Hugo and for my purposes, I always start without any theme. Basically, I start to write a markdown file for each page, and an HTML template, then if I need more complexity I have the power available underneath.
Static website generators are not necessarily complex to use, and they generally stay compatible from version to version so you only need to learn the new features and only if you want to use them.
269 comments
[ 0.23 ms ] story [ 290 ms ] threadCould be because I'm reading on desktop and it works better on mobile.
He is using, as far as I can tell, the solarised theme colours.
They are very readable.
[EDITED] https://www.rundata.co.za
It's my site, also using solarised (although, it respects the clients dark/light mode, so you will see either solirsed dark or solarised light)
basically you just write in HTML, CSS and a wee bit of JS wherever you want it, and have a couple of tiny npm scripts that glue it together.
Put it on netlify, cloudflare, github, or wherever and it scales right up.
In comparison our blog is in Gatsby, and boy does that framework never seem to work right away when we start it up for adding a new post.
Historically a blog requires a feed, this is typically where super minimal stacks stop, although I guess you could scrape your index.
I wonder how many web devs can still build a blogging app, a webshop, etc from first principles when mostly it’s all npm create packages and template languages.
I started a php / SQLite blogging stack with basic web based editing and a feed (ah and tagging, a search), hope to add more indie web features to it.
Take your dark mode, which is just about the only nontrivial feature I see on this page. (One could also criticize the low contrast of the appearance and other problems, but that's less relevant to the simplicity thesis you're claiming.)
First, your dark mode is implemented wrong in the lazy corner-cutting way of doing JS post-load instead of the correct way of CSS body classes; so you get the 'flash of white' unavoidably on every page load - just what every dark mode user with their phone to their face at midnight wants to see! (If your solution doesn't work, it doesn't matter if it's 'simple' or 'complex'.)
Second, you implement what is like 3 lines of JS (setting localstorage & dark-mode) by pulling in what looks like an entire interpreter for a custom 'hyperscript' https://hyperscript.org/ language which seems to mostly just offer some sugar over JS; now, maybe you use 'hyperscript' elsewhere for reasonable purposes, but surely pulling in a 96kb (uncached) library solely to run
def saveMode() if first classList.value of <html/> contains 'dark' set localStorage.kkColorMode to 'dark' else set localStorage.kkColorMode to 'light' end end
is a bit against the spirit of this "simplicity is the ultimate perfection" enterprise...? Personally, I feel like I see some easy perfection to add right there. (And is this hyperscript stuff also why the HTML doesn't validate?)Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it. And since localstorage expires and users switch devices, they would have to do so repeatedly. Is this a good thing? A user probably would disagree with the developer who is touting how 'simple' the dark-mode implementation is because they cut corners in handling system settings/auto-dark-mode...
I agree with your whole comment, but the media query approach is also tricky.
You typically still want to offer a toggle while respecting prefers-color-scheme, and you may want to give priority to whatever choice the user has made with that toggle if they've used it on your site before. This still requires JS and localstorage.
So what to do? My preferred choice is having an inline style element of:
body {visibility: hidden; opacity: 0;}
This will maintain the previous page until DOMContentLoaded, at which point you can query prefers-color-element and localstorage, set the body class correctly, and let the page paint.
I've been considering this recently for my site and I settled on having prefers-color-scheme on the root domain with dark. and light. subdomains. If the user chooses a color they just get bumped to a subdomain that sets a cookie with their preference. If they come to the site from an external link and they have a preference cookie they get redirected to the subdomain again. Absolutely no clientside JS is needed anywhere, no FOUC issues, and it's trivially simple to code because it's literally just a redirect in the server config based on a cookie value.
I really should spend the time to actually build it, but Diablo 4 came along and I got sidetracked.
Use css variables everywhere, and have a defs-dark.css and a defs-light.css that define the colors.
Then, on nginx, serve the correct stylesheet based on cookie value.
Better than subdomains for dark and light, no?
The proper solution is to only implement the media queries and yell at browser vendors to make this easier to toggle either for all websites or for specific websites. Implementing a light/dark mode switch in every website is absurd.
I'd suggest knowingly rather than unknowingly. It's a link to a website after all. It should link to the same thing that the person who shared it was viewing. That's the point of a URL - when you share one the recipient should see what you were seeing.
FWIW I would also like browser vendors to do a better job at enabling users to manage their preferences on a per site basis though.
Disabled JS != disabled CSS.
<noscript> <style> body {visibility: visible; opacity: 1;} </style> </noscript>
Or you could use cookies. No need to mess with localStorage. Just set a cookie "prefersDarkMode" to true or false and have the backend send the right file. No need for an interactive backend, nginx can handle serving files based on cookie contents. No need for cookie popups/walls either.
I just use <noscript> for this. If you don't have Javascript you're just going to get whatever your prefers-color-scheme is set to. Users without JS don't expect things like a dark-mode toggle to work anyway.
The former is just wrong of OP: no user wants the FOUC flash-of-white, end of story; similarly for some of the other solutions proposed here (block the entire page, really? talk about burning down the village to save it). The latter has more leeway for design: we settled on a tri-toggle to use the media-query but allow users to override and hardwire light/dark mode, and that seems to work most naturally. But there may be other contexts where something else would be better.
Indeed, for toggles, you could even try not having a toggle at all and relying on the system setting through the media-query. (However, as appealing as this is - why have separate controls when the user already has a global control and can enable/disable it? - we found this confused & angered users: https://gwern.net/design-graveyard#automatic-dark-mode So, gotta have a toggle. At least for now; maybe as dark-mode becomes universal, at some point users will become educated enough that you can afford to use only the system setting?)
I'm curious for what the other approach is. Users find it annoying to refresh the page and have their dark-mode setting change, or have their dark-mode setting change while navigating the site.
So I have to block paint until I can query local storage in order to avoid flashing, what's the alternative? Below someone suggested using cookies and only serving CSS that does the desired styling, which I guess is doable but requires a non-trivial infrastructural change.
I don't think it should 'try to slide up then it dies'; do you mean you can't see the gear at all?
> Third, this binary toggle is a bad way to implement dark mode because it ignores system/browser settings, so if a user has, say, enabled dark-mode on their smartphone OS, they still get served light-mode until they manually enable it; note that some systems change it based on local time/ambient light too, which is quite nice... if websites & apps respect it instead of overriding it.
There's so much complexity here that goes against the philosophy of a simple website if simplicity is the goal. They should just skip dark mode entirely. HN itself is perma light mode, it doesn't stop me from reading it at night.
Dark mode and light mode is a nice tradeoff for varied lighting conditions.
...you need to turn your display brightness way down!
Hold a piece of white paper next to your display. Open a window with white background. Is the window/display brighter than the piece of paper? It's too bright.
It depends on the display of course, but just as an example: my brightness setting is at 2 out of 100. At the work computer it's 19 out of 100.
Are they powerful or misconfigured? Something is wrong if the screen hurts your eyes, no matter the colors.
My site uses CSS to respect light/dark theme, so has no manual toggle. (A manual toggle requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS.) It was quite simple to do: just a media query and setting a few colours.
I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar. I don't know of a browser that does this, yet.
Is dark-mode a good requirement? I'm not sure. It's nice to have, and our dark-mode does look great on a recent smartphone in the dark - but if I had known just how hard a good dark-mode would be, and how many of the issues we would struggle with (issues which OP runs headlong into), I think we would've skipped it. There's a lot of other things that time & energy could go into.
For most websites, I would say that they have far too many problems to spend time on dark-mode, no matter how trendy dark-mode is. (Users who really want dark-mode can install one of many extensions/plugins/apps/screen-inversion tools. They work reasonably well, and usually avoid issues like the white-flash FOUC.)
My site uses CSS to respect light/dark theme, so has no manual toggle. It requires Javascript and I have a personal goal to have a JS-free site, just pure HTML and CSS. I also think that a site should respect the user's own light/dark settings, and so a toggle, if one ever exists for a site, should really be a browser setting on the browser toolbar.
/u/gwern, in case you read this, your design along with Tufte.css were one of the influences of my own site: https://daveon.design/ . (Also present is inspiration from older-style publishing and manuscripts, and personal preferences. But your site was the first one -- a key influence -- I saw that inspired me with what a modern, clean personal website could be and how it could look, as well as what it might contain. It's a real honour to see you here and reply!)
I agree that it should definitely respect the OS level setting but I really like it when I'm given the option to override that setting. What if I don't like the way a site implemented their dark mode styles and I would rather switch back to light mode for just that one site. Having no toggle on the site I would have to go to my OS level settings, turn dark mode off, then later remember to go back to my OS level settings and turn it back on.
- you make sentence-spacing a major design goal. I looked into that a bit ago and I found little or no real evidence that sentence-spacing is a good idea (https://gwern.net/doc/design/typography/sentence-spacing/ind...) and it would be expensive to implement: you do the only reasonable thing of injecting <span>s... but oh so many <span>s. If you get long pages like mine, that is going to cost you - DOM nodes are not free, soldier! - one issue with sentence-spacing is that you are fighting HTML & CSS the entire way. They just do not want to do it. You correctly note that it's hard, but you accidentally demonstrate it's even harder than you thought: you have justification enabled but not hyphenation... so all that happens is that sentences get stretched out to make them fully-justified and you get large double-spaces everywhere! Your current implementation winds up being not so much 'sentence-spacing' as 'every few words spacing'. (This is especially glaring in the sidenotes, like on the page I'm looking at right now, 'Stephen Zamadics' looks like 'Stephen_________Zamadics'. Since you set the column narrow, you probably want good hyphenation too... perhaps server-side, if you're deadset against JS.) - Dropcap positioning is hard, especially if you'd like it to work on more than one browser, and I'm not surprised yours has problems; pretty much everyone screws those up. (At least, I assume you don't intend the positioning problems like the '1' almost overlapping the 'someone' in cases like https://daveon.design/creating-joy-in-the-user-experience.ht... .) - I think the dotted underlining is too hard to see: much too small and close to the link. Are you sure you don't need `text-decoration-thickness: from-font` & `text-underline-position: from-font`? - Rubricating the entire sidenote on hover seems excessive. - Sidenote numbering is very confusing. They get numbered 1/2/3/4... and then all lose their numbers in favor of ''? Mixing numbered & unnumbered is confusing enough, but then transitioning at the utterly arbitrary '5' let me baffled and wondering if the ''s were supposed to be a separate kind of sidenote like a margin-note. Definitely a case for 0/1/infinity. - Sidenotes come off as cluttered and hard-to-read, at least partially because they are all 1 big paragraph. Breaking them up would increase readability. I hope you didn't inherit Tufte-CSS's unnecessary and artificial limitation to non-block elements...? (I can't believe they refuse to fix that.) - EB Garamond is a variable font, which is a bit of a questionable choice because OS+browser support is still relatively low. (Just browser-wise, it's only at ~95% global https://caniuse.com/?search=variable%20font so add on OS incompatibility... The text should still render, but it won't look like you expect it to. Example: https://share.obormot.net/screenshots/Arcturus_Screen%20Shot... Also shows the sentence-spacing problems & dropcap problems.) - The use of auto-smallcaps (after H1s, I guess?) winds up feeling busy and confusing. Look at a page like https:...
Even for a certain level of collaboration, I think one could get away with using static sites. I haven't tried this in practice but imagine having a git-based CI/CD flow for a static site, where non-technical end users could use the web-based Markdown editors of github.com or gitlab.com to make small changes, save and push via a pull request.
Each merge is of course approved by a more technical user.
I would love to hear if anyone has tried this model.
Not sure how the GitHub markdown editor would feel for the user. It might be really great, even for uploading images.
I was imagining a static admin page, WYSIWYG, that makes git pushes on submit. These were the headless CMSs that seem to be able to accomplish that:
https://www.siteleaf.com/
https://decapcms.org/
And not git based, but similar idea of static content editing: https://editable.website/
And this is what the admin edit page usually looks like: https://quick-edit-demo.vercel.app/admin/index.html#/collect...
But it was taking a bit of work to configure.
That part should probably be handled separately just to avoid slowing down the git repo with huge binary files. For example upload an image to S3, note the path, enter it into a markdown syntax image url.
There are many ways to skin that cat, depending on the technical skill level of your client. They could even e-mail the images to a script, or message them to a bot on an IM service, that then returns the URL for them to use in Markdown.
The theme is HTML and CSS plus about 20 lines of jQuery JavaScript to handle simple toggle effects such as the hamburger menu on mobile. Probably could be done without jQuery but I am not a web developer and that's what I know. Posts are written in markdown and the idea is that the others will either send me an email or later will open a merge request on GitLab.
And that's cool. Making stuff is fun.
Maybe I'm being obtuse, but the reasons they gave for not using an established SSG primed me to expect a radically new solution. Versus "we didn't like any existing SSGs so we built our own," which was my takeaway from the whole thing.
https://news.ycombinator.com/newsguidelines.html
A PHP site (for the includes), or an out-of-the-box SSG would make much more sense, IMO.
If it is a website - then it is plain HTML with some CSS. The exception is - there will be some JS if we want saucer flying across screen.
If it is an application - the logic will be coded in plain JS that talks to backend using JSON based RPC. No frameworks bar some domain specific libs. Minifying / building step can be included for production.
Works well for me.
All joking aside, I use the same stack save for the templating. Unless you are a web developer I don't see the point of a CSS framework, it's much easier to roll your own. Nor of a site generator, I tried Hugo it saved no time at all. Nor of JavaScript, a few months ago I tried replicating the websites of a few companies to improve my css skills, HTML and CSS were enough to reproduce the appearance of all of them, yet none of their website would even appear without JavaScript enabled.
We stack on framework after framework, new languages, new tools, all for nothing but increased complexity and busy work for a new generation. (Save for the 5% of websites that actually need that stuff.)
Also interesting to see they actually sell a service, would have been curious to know what their prices are like.
Then once all your views are created using these common elements, you only need to transcribe them as classes in your CSS and use those few classes where needed in your HTML.
I'm not a design expert, so take it with a grain of salt, but I used to be terrible and following that workflow allowed me to get decent.
Design software encourages/enforces good design rules through its interface. You couple that with a willingness to learn and a bit of practice and you can achieve some nice things. Especially given that the design of some types of websites is very codified like SaaS or blogs.
Super easy to get started and has lots of goodies to generate static HTML. You can scale it up later if you need more than just a static website.
https://twitter.com/levelsio/status/1675829733668319233/phot...
Not using any modern CSS layout though, ehhh I would never want to return to the age of .clearfix, that feels like the opposite of simple.
And if I understand correctly, it's not the index.php, but the actual service behind it, that earns thousands per month. Looks nice :)
Also fwiw, another one here without a logged in Twitter acc
End users don't give a shit what you build it with, but none of it matters unless you're willing to shit products out.
I could also write his cool startup in just one line if I just remove all newlines. Does that make it even better than 14.000 lines? Obviously not.
This feels so forced. Make a joke CV, strip it of any mentions of these "bad" things, try applying. Good luck.
It also teaches you more about your platform. In the end, all these web tools and frameworks are running in that same browser. I find especially with newer web developers, it's hard to solve something in React/Vue/.. because they don't know how to break up the problem. If you'd roughly know how to solve the problem without those frameworks, it becomes much easier to figure out how to solve it with them too.
Finally, I also just get toolchain fatigue. If I want to build a simple landing page, I don't want to learn new stuff, I don't want to read what changed in the latest versions, what the correct way of the day is to set up a project. Honestly, I don't even want to have a build pipeline and module swapping dev server, that inevitably needs to be configured. Just some static html/css/js is often good enough. And as I said, you also learn which problems frameworks solve well, so you'll know when some static files isn't the right choice.
Cross Browser compatibility has also gotten better.
And if html allowed inserting html as it does css or js from external files, even that would be mostly be redundant. If only it let you use <html src="" /> at will.
https://en.m.wikipedia.org/wiki/Server_Side_Includes
https://blog.cloudflare.com/edge-side-includes-with-cloudfla...
Functionality should be considered based on potential utility. Not sure what politics are involved at the w3c, but if it's not that, then maybe it's their philosophy and approach that has them not going for that which is most useful.
Edit something, git commit/push, and within 30 seconds your changes are live everywhere. It's pretty awesome, and it requires no "server" hosting.
We are being simple, and I consider a simple PHP site about one step above HTML and CSS in required complexity, and about 5 steps below anything else in regards to tooling/setup/execution.
A website/webapp with millions of visits per day and a ton of stakeholders requesting features every week, on the other hand...
It all depends on the use case, like most stuff.
If you want a team of people that don't know HTML or rest of the stack to edit, manage and deploy it then you're going to need a more complex abstraction.
The alternative might be a training programme for new staff in HTML, CSS, git and rsync.
You're trading one type of complexity for another. As you say, it all comes down to use cases.
After trying a few server-based options like Ghost, Statamic and self-built ones with Phoenix or Vapor (I've covered some ground as a dev) and the usual SSG options I ended up just writing everything as straight HTML without any templates and upload to a Hetzner server using rsync.
The lack of templating for shared UI like navigation is a touch irritating, but with some RegEx magic I haven't found a change I want to make that takes more than a few minutes. I got caught out early on with some greedy RegEx that nuked some content, but git to the rescue.
Image generation with all the sizes and format variants is laborious, but it prompts me to try new layouts rather than relying on cookie-cutter ones like Ghost. Plus I've noticed a slight improvement in image quality generating my web variants out of my RAW editor (Capture One) vs using the libraries and CLI tools used in most SSGs.
It's slower, but my thinking is that it's more akin to putting together a photo book. It take more effort up front, but once it's done, it's done for good, and won't need mangling in and out of various CMS over the next 20 years!
The site is what's left over after trying a few different options, most notably Ghost and later Zola.
Most of the current layout mimics what can be created within Ghost's editor. I then migrated to Zola which shares the bulk of the layout. Currently most of my images are coming from Zola's "/processed_images" directory. You can view the Zola codebase here[1] if you like.
The layouts I'm currently working on (not yet published) are heavily influenced by Andrew Clarke's work [2] and his book "Art Direction for the Web" [3] which I highly recommend if you want to explore less generic layouts online. I hope that on day my site can be example that web design can be as varied and interesting as print!
1: https://github.com/jamiedumont/zola_jamiedumont.com
2: https://www.smashingmagazine.com/author/andy-clarke/
3: https://www.smashingmagazine.com/2019/03/art-direction-relea...
I keep it as vanilla HTML though because I like the fact that I can open any page as a standalone file with no server and almost any browser can render it. I'm not saying this won't change, but for now I'm happy without SSI.
Plus, I'm using Nova for some Panic-based nostalgia (Coda was big when I started), so I like having the code and rendered HTML side by side in Nova's preview.
I think for a site like this I'd go with 11ty, just a clean project without a template or custom config, one collection to pull the photos from Flickr inline the styles.
(just sharing my personal approach, nothing wrong with Jamie's approach, ofc)
Also, you might find some value in an approach that I used recently (https://news.ycombinator.com/item?id=36592641). Using a Google Sheet as the data driver was easy, but it could have just as well been a filesystem of photos.
Plus I have the lingering memory of working with Elixir and Phoenix LiveView which is kind of the gold standard for web frameworks at the moment in my opinion.
With Flickr I can manage the photos from my phone via the Flickr app.
With Netlify I don't have to tinker with an actual server box, plus it's free.
I love it <3
I wish there was a modern version of Dreamweaver that didn't phone home, didn't use "cloud", and didn't require endless payments.
“After Adobe Systems' acquisition of Macromedia in December 2005, Dreamweaver 8 was added to Adobe Creative Suite 2.3 and was later succeeded by Adobe Dreamweaver CS3.“ [1] (Replacing Adobe GoLive, good riddance)
So you could use up to Dreamweaver CS6 with just a serial number (usually requiring one-time internet activation), but anything newer requires regular internet access.
[1] https://macromedia.fandom.com/wiki/Macromedia_Dreamweaver_8
https://250kb.club/
https://1mb.club/
I'm using Hugo and for my purposes, I always start without any theme. Basically, I start to write a markdown file for each page, and an HTML template, then if I need more complexity I have the power available underneath.
Static website generators are not necessarily complex to use, and they generally stay compatible from version to version so you only need to learn the new features and only if you want to use them.