See https://gohugo.io/tools/search/. Not sure how well they scale to thousands of posts, but they work by statically generating multiple static search index files at build time that are queried via client JavaScript when hosted. The search UX is actually really good because they tend to respond instantly as you type your query and allow complex queries.
I've used https://lunrjs.com/guides/getting_started.html briefly and it has lots of options for things like different fields, complex queries, fuzzy searching and wildcards. Didn't notice anything specific about dates but you could always add date as a field then filter out a date range manually at the end. I'm sure there's better libraries now as well.
We've gone from SSGs for ease, speed and reduced resources, to talking about implementing search with multiple megabyte client side indexes and hundereds of thousands of prerendered search result pages.
When does this become 1 step forward with the SSG and 2 steps back with search solutions like this?
You don't pre-render the search pages. You generate some search index files on the build step (something like a map of keywords to matching post URLs), and then client side JavaScript requests the search index files it needs on demand and generates the search results on the page. For a modest blog, I think the compressed index can be a few 100K. A single large image can be bigger than that.
Nothing is perfect, but the above is really simple to host, is low maintenance, and easy to secure.
This is just server side search with more steps, since the index needs to be selectively split and returned, and then search results page generated from the index.
Sorry, I don't mean to come across as disagreeable. You're right, nothing is perfect, and this is obviously a workable and usable solution. My issue is if we analyse it beyond "it looks like it works", it starts to look like a slightly worse solution than what we already had.
Nothing wrong with moving backwards in some direction, as long as we can clearly point to some benefit we're getting elsewhere. My issues with SSGs is most of the benefits they offer end up undermined if you want any interactivity. This is a good example of that, as you end up compromising on build time and page load time compared to an SSR search solution.
> it starts to look like a slightly worse solution than what we already had
You don't see how the server based solution is an order of magnitude more effort to maintain, monitor, optimize, and secure compared to hosting static files? Especially if search is a minor feature of your site, keeping the hosting simple can be a very reasonable tradeoff.
Lots of blogs/sites also do fine with only category and tag filtering (most SSGs have this built in) without text search, and users can use a search engine if they need more.
My point the entire time has been that an SSG is not good for sites that want interactivity.
I agree with you, lots of blogs/sites do fine with just tag/category. Those sites don't have interactivity and so you could SSG them and use free static hosting. We're in agreement on this. But I have explicitly been talking about sites that want interaction. Still - how many personal sites that "do fine without interactivity" are actually "interactivity was too much of a technical/maintenance challenge"?
I completely see how a server based solution is an order of magnitude more effort. We agree on that too. Running any servers efficiently typically has fixed overhead for server infra and processes. Running 3 pieces of server software or even 3 servers is harder than 1, but significantly less than 3x harder.
If you want interactivity, a server is needed. This means you are already maintaining, monitoring, optimising and securing a server solution. Adding SSG processes alongside your existing server solution does not remove any problems relating to servers, because you still have servers. It does add complexity though because you're running servers, and some SSG pipelines. These architectures clash and create more work. Running 2 conflicting architectures can be a lot more more than 2x harder than running 1 architecture.
If you want interactivity and don't want to run a server, then you must use a 3rd party service. This brings its own issues, especially if you have a personal website because you want to own your own stuff.
I feel like you're repeating to me "servers are hard, SSGs are good" - you can't have an SSG without a server, and you definitely can't have interactivity. If you have a server anyways for comments or search, then by using SSGs, you're not removing your need to deal with servers, you're adding an extra picky new thing to your servers. And what complex feature of a personal website does the SSG solve specifically? Generate the text/HTML. Compared to comments and search, generating html from markdown is so painfully easy. SSGs tie our hands behind our backs for the hard interactivity problems to solve the easy text rendering problem.
This seems like a really, really crystal clear point to me. But you, Jeff and Susam have all tried to say that SSGs are generally better, easier, safer or faster. I felt like that from 2016 - 2024. But when you've been pressed, all of you have ended up saying variations on:
- SSGs are great for sites without interactivity (agree, you know and I know though, most personal websites do want some form of interactivity, even just search or comments, and the only reason not to is technical hurdles.)
- Comments and Search are doable with SSGs, but not trivially, or without compromising on things which were traditionally seen as crucial for an open and accessible web (agree, see jeffs comments and search tickets)
- You use SSGs not to solve any particular problem, but just for fun. (agree, that's fine, but if that's your only reason, that's probably a sign there's virtually no technical advantages.)
- The problems you used the SSG for originally have been solved with compute power, storage, connectivity and bandwidth becoming more available over the past decade
I really appreciate and respect your's, Jeff's and Susam's time to respond, I want to be in agreement with you, as you all have the experience and reputation in personal websites. I just can't see it though. I mean this whole HN topic is about Jeff's post "Jeffgeerling.com has been migrated to Hugo" which on the surface looks like a success for the ease of SSGs, but when you probe deeper, it's the text that's been migrated, and comments and search have been disabled.
Why are we here if SSGs are so obviously the easiest, most reliable way to run a personal website? Jeff's site is currently working less than it did before and the fixes are future TODOs are essentially "pick a compromise" (sorry, no offence Jeff - I still think you're great!)
> But you, Jeff and Susam have all tried to say that SSGs are generally better, easier, safer or faster.
I'd just like to clarify that this is not what I was trying to say. In fact, once a website needs server-side programming to support interactivity (comments, subscription, etc.), I don't think SSGs are necessarily better. I think we both agree there to an extent. I think there are tradeoffs.
There is a certain inherent complexity in addressing concerns like performance, portability, etc. that, as waterbed theory suggests, just gets pushed to different places depending on whether we choose an SSG-based solution or non-SSG-based solution. What I have been trying in my other comments is to explain my reasons for why I made the arguably questionable choice to use an SSG for content pages while relying on server side programming for comments and subscriber forms.
I certainly see the appeal of serving the entire site, including both content pages and comment forms, using server side programming. It does simplify the 'architecture' in some ways. However, since I maintain my personal website as a hobby, I need to make the tradeoffs that feel right to me. I realise this is not a very satisfying answer to the question of whether a hybrid solution like mine (SSG plus server side programming) has merits. But I was never trying to argue its merits in the first place.
This is all entirely fair, thank you, I understand, I didn't mean to misrepresent.
> However, since I maintain my personal website as a hobby, I need to make the tradeoffs that feel right to me. I realise this is not a very satisfying answer to the question of whether a hybrid solution like mine (SSG plus server side programming) has merits. But I was never trying to argue its merits in the first place.
Hey, I'm a firm believer in the idea that the best solution for a personal website is the one that's the most fun for the owner to maintain! The reminder that it's not all about technical merit makes yours one of the more satisfying answers - thanks again for the considered responses:)
Sounds like we agree! There's no perfect solution and I'm not saying SSGs are always the best fit. It really depends on the project and what the people involved value.
For my own solo projects, the ease of hosting for static sites is often such a big win for me that I'm willing to forego some interactivity even though more interactive features would be nice. Knowing that I can upload several static sites and they'll run themselves without any maintenance for years and without potential security problems keeps my life nice and calm. It depends what you want to prioritize.
I agree, nothing is perfect, there's a time and place for everything - I just think the coverage and advocacy of SSGs is disproportionate to the number of places where they improve things. I'm going to summarise the discussions I've had in this topic in a post over the next few weeks and I'll post it here. Thanks for humouring and challenging me :)
I still do feel there's something not quite right. Hopefully I'll be able to get it out in the summary as I think we're all done with walls of text here. But I think you actually captured it perfectly in your last remark:
> For my own solo projects, the ease of hosting for static sites is often such a big win for me that I'm willing to forego some interactivity even though more interactive features would be nice.
They make the web worse for the world by tempting the developer to take the easier, less interactive route than what would have been taken in the pre-SSG world.
I think I'm troubled by this because the idea "it makes it easy to do the lazy, worse thing" seems completely at odds with the fact that it seems to be what the people I would consider leaders in the field are doing. That's why I still wonder if this view might be a me problem, or maybe the field is just moving backwards? I don't know.
> They make the web worse for the world by tempting the developer to take the easier, less interactive route than what would have been taken in the pre-SSG world.
If I didn't have the static site option though, I might not host a project at all because I don't want to have to deal with the maintenance burden. I haven't kept up but it would be nice if there were more options between a no-maintenance static site hosting, and a high-maintenance dynamic site.
Would be amazing if the web/browsers had standardized ways by now of easily adding common website features like authentication, search, comments, votes, and saving user data (via bring your own storage) that didn't require everyone to host and maintain a custom stack. Email is a solved problem that you don't have to host yourself for example, why is it still such an effort for the other common website features?
Assuming 500 bytes of metadata + URL per blog post, a one megabyte index is enough for 2000 blog posts.
As already mentioned, you don't generate search result pages, because client side Javascript has been a thing for several decades already.
Your suggestion of converting markdown on every request also provides near zero value.
Writing a minimal server backend is also way easier if you separate it from the presentation part of the stack.
Based on https://news.ycombinator.com/item?id=46489563, it also seems like you fundamentally misunderstand the point. Interactivity is not the point. SSGs are used for publishing writing the same way PDF is used. Nobody sane thinks that they need a comment section in their PDFs.
I'm sorry, I find your post insulting. I wasn't engaging in bad faith discourse intentionally, but your assumption that I am - ironically - doesn't feel like appropriate etiquette here either. Despite that, I'll try answer sincerely.
Your 1 megabyte index file has just added over 2 seconds to your page load time in 30 different countries based on average internet speeds in 2024. Chuck in some pictures, an external comment library and your other SSG hacks, and you've just made your website practically unresponsive to a quarter of the planet and a bunch of other low powered devices.
Value is relative. The benefit of rendering markdown on every request is it makes it easier to make it dynamic, so you don't need to do SSG compromises like rebuild and reupload multiple pages when a single link changes.
You're replying in my thread here, to my original points. My original points were that SSGs don't make sense for sites with interaction, which is why were were discussing the limitations of SSG search approaches.
> SSGs are used for publishing writing the same way PDF is used. Nobody sane thinks that they need a comment section in their PDFs.
Thank you! We're in agreement, it doesn't make sense to use SSGs for sites that require interaction. When you do, it forces the rest of your site to do the compromising search stuff like we're discussing here.
I really like Hugo as well. I've found it significantly faster than Jekyll which makes iterating much more pleasant and it's a single binary to download/run vs having to deal with Ruby and its package manager.
I'm amazed there still isn't a decent free simple to host CMS solution with live page previews, a basic page builder, and simple hosting yet though. Is there one?
There's https://demo.decapcms.org/ (previously Netlify CMS) that you install and run via adding a short JavaScript snippet to a page. It connects to GitHub directly to edit content. You can running it locally or online, but you need some hosting glue to connect to GitHub. Netlify provides this but more options would be nice and I think they limit how many total users can connect on free plans. You can get something like a page builder set up via custom content blocks, but I don't think there's going to be a simple way to render live previews via Hugo (written in Go) in a browser. A JavaScript based SSG would help here, but now you have to deal with the JavaScript ecosystem.
> That's especially odd as I think those links were the defaults from the Archie theme
Internal redirects are really easy to miss without checking with a tool because browsers aren't noisy about it. Lots of sites have unnecessary redirects from URLs that use http:// instead of https://, www vs no-www, and missing/extra trailing slashes, where with some redirect configs you can get a chain of 2 or 3 redirects before you get to the destination page.
I help startups with the UX/UI and web design of their products. This includes web apps, websites, landing pages, copywriting, and I can assist with frontend development where needed. My background of launching my own products and being a full stack developer helps me create practical designs that balance usability, aesthetics, development effort, and performance. I work to fixed price quotes for self-contained projects.
---
The best live example of my work is Checkbot (https://checkbot.io/), a browser extension that tests websites for SEO/speed/security problems. The entire project is my own work including coding the extension itself, UX/UI design, website design (the homepage is optimised to load in 0.7 seconds, 0.3MB data transferred), marketing, website copy, and website articles on web best practices.
[ Rated 4.9/5, 80K+ active users, 100s of paying subscribers ]
---
I have 10+ years of experience, including a PhD in software verification and 5+ years working for myself helping over 25 companies including Just Eat, Triumph Motorcycles and Fogbender (YC W22). See my website for testimonials, portfolio and more: https://seanw.org
Note: For large projects, my partner usually assists me in the background (I’m working on starting a design studio with her in the future)
---
Email sw@seanw.org with a short description of 1) your project 2) how you think I can help 3) the business outcome you’re looking for and 4) any deadlines. I can get back to you in one working day to arrange a call to discuss a quote and how we can work together!
I help startups with the UX/UI and web design of their products. This includes web apps, websites, landing pages, copywriting, and I can assist with frontend development where needed. My background of launching my own products and being a full stack developer helps me create practical designs that balance usability, aesthetics, development effort, and performance. I work to fixed price quotes for self-contained projects.
---
The best live example of my work is Checkbot (https://checkbot.io/), a browser extension that tests websites for SEO/speed/security problems. The entire project is my own work including coding the extension itself, UX/UI design, website design (the homepage is optimised to load in 0.7 seconds, 0.3MB data transferred), marketing, website copy, and website articles on web best practices.
[ Rated 4.9/5, 80K+ active users, 100s of paying subscribers ]
---
I have 10+ years of experience, including a PhD in software verification and 5+ years working for myself helping over 25 companies including Just Eat, Triumph Motorcycles and Fogbender (YC W22). See my website for testimonials, portfolio and more: https://seanw.org
Note: For large projects, my partner usually assists me in the background (I’m working on starting a design studio with her in the future)
---
Email sw@seanw.org with a short description of 1) your project 2) how you think I can help 3) the business outcome you’re looking for and 4) any deadlines. I can get back to you in one working day to arrange a call to discuss a quote and how we can work together!
There's 100s of color palette generation tools, where most only let you customize a single color then try to autogenerate tints/shades without much thought about accessibility or tints/shades customization. The main features of this tool are:
- Emphasis on accessibility. A live UI mockup using your palette warns you if your tints/shades are lacking contrast when used in practice for headings, paragraphs, borders, and buttons, and teaches you the WCAG rules. Fixing contrast issues and exploring accessible color options is also made much easier using an HSLuv color picker, where only the lightness slider alters the contrast checks, and not the hue/saturation sliders (most tools use HSL, where hue/saturation changes counterintuitively alter contrast checks which makes accessibility really tough!).
- You can tweak the hue/saturation/lightness of every tint/shade. This is useful because autogenerated colors are never quite right, and customization is really important for branding work when you have to include specific tints/shades. The curve-based hue/saturation/lightness editing UI also makes this a really quick process.
- Instead of just a handful of colors, this tool lets you create a full palette. For example, if your primary color is blue, you always end up needing other colors like green for success, red for danger, and gray for text, then 11 tints/shades for all of these, so you want a tool that lets you tweak, check, compare and manage them all at once.
It's mostly a demo on mobile so check it on desktop. I'm still working on making it easier to use as it probably requires some design background to understand, but really open to feedback!
Major flaws in a specification for one function are usually quickly picked up when the proof for another function relies on the missing specification properties e.g. if you only prove the list returned by a function has a certain length and nothing about the contents of the list, you're going to quickly find out when another function needs to prove anything trivial about the contents of that list.
Not that it's flawless either, but supplementing with standard e.g. unit tests helps catch specification bugs like this and you could generate unit test examples from the specification to review for correctness as well. You would notice problems when running the program too just like with regular programming, you wouldn't just write proofs about your program and not try running it.
Nothing is perfect but just like in regular programming languages where adding a few simple regular automated tests or some more accurate static type annotations (e.g. JavaScript to TypeScript) will catch a lot of problems compared to nothing at all (and with diminishing returns), a proof of some simple properties will flush out a lot of bugs and edge cases. So I feel the common reaction of "specifications can have flaws" is overplayed when it's clearly a big step up the process of eliminating bugs.
> Major flaws in a specification for one function are usually quickly picked up when the proof for another function relies on the missing specification properties
Great point! In a sense, it's testing by immediate use at compile time. I always imagine this to be the greatest productivity booster, even greater than AI. You'll notice things are wrong as you type.
> Major flaws in a specification for one function are usually quickly picked up when the proof for another function relies on the missing specification properties
Great point!
> supplementing with standard e.g. unit tests helps catch specification bugs like this
I don't think it does -- any specific input+output pair that a unit test tests for will satisfy all the constraints of a complete spec, so it will necessarily also satisfy an incomplete spec (i.e., a subset of those constraints). You could detect overly strong spec constraints this way, but not insufficiently strong ones.
I think you’re picturing the unit test case the opposite way around to me, but what I see relies on having something generated for you. While a unit test case will also pass the weak specs, there exist spec meeting implementations that don’t pass the test.
So either that requires “generate valid code and let’s test it” or that you can write a proof statement like:
If : there is at least one implementation which is valid for the following properties, and does not meet this single property (fixed input output pair) - specifications are under defined.
> there exist spec meeting implementations that don’t pass the test.
Ah, I see what you mean. Yes, in practice you would have an actual implementation, and if it failed the test but passed the spec you would know the spec was underspecified. I stand corrected.
> If : there is at least one implementation which is valid for the following properties, and does not meet this single property (fixed input output pair) - specifications are under defined.
Clever! But I guess we're probably some way from being able to existentially quantify over all possible implementations... It might be that the only satisfying implementation is one for which we cannot even prove termination. More optimistically, maybe it turns out that whenever there is a satisfying implementation, there must be one in some simple class (like straight-line programs) that can be checked exhaustively.
I miss the Freelancers thread as well. The kind of information you post when you're looking for a freelancer or open to freelance work is really different from typical posts for permanent positions. The freelance posts are going to get lost now within the Hiring thread.
> It's funny that it skips the entire cascading part of Cascading Style Sheets though. Are there major downsides besides that?
I think cascading is a bad default. It's useful, but only sometimes, and often causes headaches like unintended coupling and confusion about why rules are being overridden. The utility class approach (like Tailwind) makes a lot of issues like this go away. I don't see a good reason why the traditional approach is worth the extra pain or discipline.
CSS can be laser-like specific if you want it to. Want to only affect that thing? Use ids, inline styles or learn how to write proper selectors.
I am by no means a CSS expert, but 90% of CSS issues I heard complaints about boiled down to the complainers not having spent the time necessary to learn the basics. And the other 10% were solved by :has()
That being said, most other styling solutions I had used (e.g. in GUI libraries) will quickly make you wish you had CSS.
> CSS can be laser-like specific if you want it to. Want to only affect that thing? Use ids, inline styles or learn how to write proper selectors.
You've still go all the normal CSS problems like having to debug complex selectors, jumping between files to debug styling, having to name lots of things you're only going to use once, verbose media queries, verbose styling attributes, and not knowing when it's safe to delete styling because you don't know where it's shared.
And for what benefits? To say we're writing CSS "the right way", when it was designed for styling traditional documents and not for complex UIs?
This also strikes me as a "if everyone learned to do it properly, there wouldn't be a problem" statement. It's ignoring the reality that nobody can agree on the proper way to write CSS, and writing discipled CSS is fatiguing and time consuming. And even if you could get everyone to adopt the same approach, the above issues are still a big deal.
It's a real failing when a language or methodology requires you to invent your own complex discipline to tame it (e.g. C and C++), and get everyone on the team to follow this. At some stage, it's better to scrap everything and try again with what was learned to avoid the mess.
> 90% of CSS issues I heard complaints about boiled down to the complainers not having spent the time necessary to learn the basics. And the other 10% were solved by :has()
I really don't agree, I understand traditional CSS and how to use complex selectors and it's just not a good approach except mostly for styling traditional Markdown-like documents and adding your own utility classes. If laser-like specific selectors is something I want more of the time, I want this as the default and for it to be easy.
Tailwind is a very thin layer above CSS and you can't use it properly without knowing CSS. Coupled with the way you reuse styles in Tailwind by using templates (instead of sharing via classes), it solves most of the problems with CSS in a simple way that people find simple to follow.
Tailwind's major downside is it isn't the "traditional" way (which nobody can agree on anyway for complex UI styling), so Tailwind gets attacked for being the wrong way without its benefits and tradeoffs being examined properly.
Jumping between the files? The cascading part means you can always add in a file after and overwrite it. I don't see how this would get better without the cascading part.
My point isn't that CSS is perfect. My point is that someone has yet to show me a better styling language that isn't purely hypothetical. I am happy to learn new languages if there are clear benefits.
I mean having to jump between the HTML and multiple CSS files (which often you have to track down by using the browser inspector) to make edits to while styling things. When HTML and styling are tightly coupled anyway and almost always edited together, it just slow everything down for no good reason vs co-locating them together via utility classes.
> The cascading part means you can always add in a file after and overwrite it. I don't see how this would get better without the cascading part.
If you mean overwriting styles set somewhere else, this is what makes CSS confusing and hard to refactor. Cascading is just best avoided whenever you can.
> I am happy to learn new languages if there are clear benefits.
I can recommend looking at Tailwind. Make sure to use it with some kind of templating language e.g. so a "button" component goes in a template file, as that's the way you reuse styling (vs copy/paste) which critics seem to miss. It makes styling much simpler and quicker (everything is co-located, no need to write selectors, no need to make up class names, very concise syntax especially for mobile), especially if you're doing complex responsive designs.
I am editing my CSS files predominantly in the browsers inspector this has the benefit showing you what it looks like directly, potentially even with mobile preview.
I also don't need to hunt down CSS files because I rarely ever got more than 5 css files in projects I authored myself usually more like three: style.css for general stuff, fonts.css for fonts and multiple foo.css for page/section-specific stuff that isn't needed elsewhere thus only one of those is ever loaded.
For most "theming"-like stuff I make extensive use of css variables I want all my things to look like the button? Well just add the same styling with the variables in place.
As for the divide between HTML and CSS: to me HTML is 99% semantic. That means I describe the information as it should be described and the rest is done in CSS. Nowadays I rarely ever feel the need to create useless divs or go back and edit the HTML to fix styling issues thanks to grid layouts.
It wasn't always that way, but thst was to a degree the point of the linked article as well.
> As for the divide between HTML and CSS: to me HTML is 99% semantic. That means I describe the information as it should be described and the rest is done in CSS.
How do you visually group and align elements in designs like this one by only using semantic elements? I agree there's a few things in there that could be ol/ul/li tags but there's a lot of divs that are just flex containers or flex items. I don't see what useful semantics they could all have when they're mostly for cosmetic reasons.
Location: Edinburgh, UK and remote (I’m used to time zone differences and async work)
---
I help startups with the UX/UI and web design of their products. This includes web apps, websites, landing pages, copywriting, and I can assist with frontend development where needed. My background of launching my own products and being a full stack developer helps me create practical designs that balance usability, aesthetics, development effort, and performance. I work to fixed price quotes for self-contained projects.
---
The best live example of my work is Checkbot (https://checkbot.io/), a browser extension that tests websites for SEO/speed/security problems. The entire project is my own work including coding the extension itself, UX/UI design, website design (the homepage is optimised to load in 0.7 seconds, 0.3MB data transferred), marketing, website copy, and website articles on web best practices.
[ Rated 4.9/5, 80K+ active users, 100s of paying subscribers ]
---
I have 10+ years of experience, including a PhD in software verification and 5+ years working for myself helping over 25 companies including Just Eat, Triumph Motorcycles and Fogbender (YC W22). See my website for testimonials, portfolio and more: https://seanw.org
Note: For large projects, my partner usually assists me in the background (I’m working on starting a design studio with her in the future)
---
Email sw@seanw.org with a short description of 1) your project 2) how you think I can help 3) the business outcome you’re looking for and 4) any deadlines. I can get back to you in one working day to arrange a call to discuss a quote and how we can work together!
I help startups with the UX/UI and web design of their products. This includes web apps, websites, landing pages, copywriting, and I can assist with frontend development where needed. My background of launching my own products and being a full stack developer helps me create practical designs that balance usability, aesthetics, development effort, and performance. I work to fixed price quotes for self-contained projects.
---
The best live example of my work is Checkbot (https://checkbot.io/), a browser extension that tests websites for SEO/speed/security problems. The entire project is my own work including coding the extension itself, UX/UI design, website design (the homepage is optimised to load in 0.7 seconds, 0.3MB data transferred), marketing, website copy, and website articles on web best practices.
[ Rated 4.9/5, 80K+ active users, 100s of paying subscribers ]
---
I have 10+ years of experience, including a PhD in software verification and 5+ years working for myself helping over 25 companies including Just Eat, Triumph Motorcycles and Fogbender (YC W22). See my website for testimonials, portfolio and more: https://seanw.org
Note: For large projects, my partner usually assists me in the background (I’m working on starting a design studio with her in the future)
---
Email sw@seanw.org with a short description of 1) your project 2) how you think I can help 3) the business outcome you’re looking for and 4) any deadlines. I can get back to you in one working day to arrange a call to discuss a quote and how we can work together!
reply