u/Standard_Scarcity_74

Is anyone actually using _routes.json on cloudflare pages, or just relying on the default include everything behavior?

Digging through the docs and it lets you manually set include/exclude paths so pages functions only run on routes that actually need them instead of every request getting checked. Seems like it'd help with cold start stuff on function-heavy sites but I can't find much real world experience with it, mostly just the docs page.

Anyone actually hand write these and see it make a real difference, or is it one of those things that sounds good on paper but nobody bothers with in practice?

Been working on a static page (on the side as a side project) that shows nearby pharmacies that are open. Someone checking at 2am should see 24hr pharmacy and poison control info, someone checking at 2pm just needs a normal list. Static HTML obviously has no idea what time it is for whoever's looking at it.

I thought about just adding a backend for this but the whole point of the page is that it needs to survive 3am traffic spikes during outages when people are panic searching for an open pharmacy. That's also exactly when a database or server is most likely to choke. Didn't want that risk, especially for this use case.

So instead I'm using a Cloudflare Worker that reads request.cf.timezone (it's just there, geolocation based, no JS needed) to get local hour and day, then picks between 3 pre-built static HTML chunks (day, night, weekend) and swaps it in with HTMLRewriter. Nothing gets rendered per request, the worker just picks which pre-built chunk to serve. Those chunks are cached as normal static files, so no database, no server, no sessions, just static files plus a tiny function that picks which file to show.

An annoying catch though is that cf.timezone is based on IP not the actual device clock, so VPN users get the wrong local time. Figured that was fine since the alternative (reading time via JS) breaks for people with JS off, which is a group I actually care about here.

If anyone's dealt with this kind of thing before, curious how you handled the caching side of it.

Quick update. We didn’t ban AI or replace the dev, but we had to tighten things up.

We locked down PRs. Now, nothing gets merged without a clear explanation of what the code is doing. If it’s AI-generated, they have to clean it up and actually understand it before review.

We also standardized a few things (data fetching, where client logic lives, caching) and forced smaller commits so changes are easier to reason about. It’s definitely less “paste and pray” now. New problem though... velocity dropped hard. Reviews take way longer, and now this dev is struggling to explain or refactor what Claude gives them, so PRs just sit there. We traded chaos for bottlenecks.

At this point I’m not sure what’s worse, unpredictable code or slowed-down progress. Sounds like whining but idk, just wanted to get that out there in case anyone has any further suggestions???

So I’m working on a private recruiting tracker for a single company, with job aggregation, applicant tracking, simple role-based dashboards, and fairly complex filtering/search. One of the devs on the project basically doesn’t write code anymore. He just pastes prompts into claude and drop whatever comes out straight into the repo.

The issue is it looks fine until you actually try to run or scale it. We now have inconsistent patterns across the codebase, random client-side logic where it shouldn’t be, duplicated data fetching strategies, and caching behavior that changes depending on which part of the system you’re touching. Debugging anything is painful because there’s no clear intent behind the code, just layers of generated fixes stacked on top of each other.

What makes it worse is he doesn't really engage when things break. He just goes back to claude and tries another prompt, which usually makes the diff even harder to reason about.

At this point I feel like I’m spending more time untangling AI-generated code than actually building the system. How are people dealing with this kind of collaborator??? I've seen claude slop everywhere as of late, but I didn't know I'd have to deal with it myself.

Thanks to everyone who shared advice on my last post about building a static food safety checker for niche pets.

I want to keep the architecture purely static and cheap on Cloudflare Pages or Netlify, driven by a simple JSON dataset. However, because exotic pet care advice evolves quickly and vet guidelines vary, I need a lightweight workflow for vet or owner corrections without me manually committing JSON updates every single time.

Since I really want to avoid spinning up a full backend database or user authentication system just for this, I'm trying to figure out the most practical Jamstack pattern.

I've been considering a few angles, ranging from a basic embedded form service like Tally, to a git-backed CMS like Decap, or even using a light serverless edge function to push submissions straight to a repository pull request.

What is the lowest-friction way to handle community data contributions on a static site without over-engineering the setup? Am I missing something?

I’m working on a small passion project idea and was wondering if anyone knows good data sources for this.

The idea is a “can my pet eat this?” site, but for more niche animals like chinchillas, bearded dragons, or axolotls. Basically a fast, filterable grid of foods (fruits, veggies, insects, etc.) labeled as safe, sometimes okay, or toxic. Got the idea after seeing a friend carry a misfed pet iguana into their vet clinic.

I want to keep it simple and static (probably just a JSON dataset), but I’m not sure where to find reliable, structured info for something like this. Most of what I’m seeing is scattered across forums and random articles.

Are there any good databases, APIs, or even well-maintained resources you’d recommend pulling from? Even something semi-structured would help a lot.

I’ve been working on an astro site that’s basically a large catalog (no checkout, just browse and outbound links) for a friend. data comes from a CMS + supplier feeds, and I’m prebuilding pages for everything. hosting-wise I’ve tried netlify and cloudflare pages just to see how they behave. It works fine at smaller scale, but now builds are getting slower and price updates are starting to feel awkward. prices can change a few times a day, and rebuilding the whole site every time doesn’t feel right.

I’m debating between keeping everything static vs pulling some data at runtime, like keeping the pages static but injecting prices client-side or via edge functions.

Search/filtering is another concern. Pure static filtering is starting to feel clunky at this size, so I’m wondering if I should just offload that to something like algolia.

At what point should I stop forcing a static approach and just go hybrid or fullstack?

Now that I'm starting a few new static site projects, I'm realizing I'm probably overdue for a refresher on the UI/UX side of things.

A lot of the design advice I come across seems geared toward highly interactive applications with user accounts, real-time features, and complex user flows. Meanwhile most of the sites I'm working on are content-focused, relatively lightweight, and intended to load quickly with minimal client-side complexity.

So I'm curious what people are paying attention to these days. Are there any UI/UX patterns, design trends, navigation approaches, content layouts, accessibility practices, or general frontend conventions that have become more common in static sites over the last few years?

Just trying to get a sense of what's changed while I've been spending most of my time on the infrastructure side of things.

Thanks in advance.

Need opinions on how to proceed.

I'm working on a site for a small law firm and ran into a problem. They want attorney profile pages, practice area pages, case summaries, articles, and FAQ content. Pretty standard. The issue is that the same legal concepts end up being referenced across dozens of pages, and they want terminology to stay perfectly consistent everywhere.

My first instinct was to centralize a lot of that content and generate references during build. The problem is that changing a single definition or disclaimer can end up affecting a large portion of the site output. On one hand, centralized content makes maintenance easier. On the other, it becomes harder to understand the full impact of a seemingly minor edit.

Should I prioritize consistency through shared content, or accept some duplication to keep changes more localized? Wdyt?

Thanks in advance.

I’m getting ready to hand off a static site to an older business owner, and I’ve run into a problem I didn’t really anticipate.

The site itself is finished, but they occasionally update things like operating hours, seasonal closures, and a few service descriptions. They’re comfortable using email and basic office software, but asking them to touch a repository, markdown files, or anything build-related is completely unrealistic.

My original plan was to have them send me changes whenever they needed something updated, but that feels like it’s going to become a bottleneck pretty quickly.

I’ve looked at a few CMS options, but most of them seem like they’d introduce way more complexity than the site actually needs. All they really want is the ability to change a handful of fields a few times a month without worrying about breaking anything.

What should I use for clients who need occasional updates but aren't particularly technical?Thanks in advance.

I ran into this while working on a documentation site that generates API references, versioned guides, and cross-linked concept pages from a shared content graph.

I changed what I thought was a harmless bit of taxonomy logic, basically adjusting how “related topics” were weighted when tags overlapped across versions, and the next build suddenly touched almost 70% of the output.

I initially assumed something was wrong with cache invalidation, but after tracing the dependency chain it actually made sense. The related-topic graph fed into sidebar generation, which fed into section indexes, which affected search metadata, which changed chunk hashes for a bunch of client-side assets. Even feeds and sitemap ordering shifted because some pages gained or lost inbound references.

Nothing broke but the build stopped feeling like “render markdown into pages” and started feeling much closer to a compiler resolving dependencies across a graph. Feels like a lot of static tooling still presents builds as isolated page rendering, even when the underlying behavior starts looking much closer to a compiler pipeline.

Would be interesting to hear how other people are modeling dependency relationships once projects reach this point. I’m starting to hit the limits of treating builds as mostly linear generation steps, and I’m curious what patterns people settled on once invalidation and recomputation started becoming graph problems instead of page problems.

I keep running into this problem more often than I’d expect.

Once a site gets large enough, full cache purges stop being practical, so I start relying on selective invalidation. But the second pages share generated data, derived content, or bundled assets, it gets surprisingly hard to reason about what actually needs to be purged.

I update one piece of content and suddenly I'm wondering which pages depended on it, whether shared chunks changed, whether unrelated assets got rehashed, whether edge caches are even respecting the purge consistently. And because most static hosts abstract the CDN layer away, debugging this mostly turns into guesswork. Sometimes stale content disappears immediately, sometimes one region hangs onto it longer, sometimes HTML updates before assets do. Nothing is fully broken, but the site can end up in this awkward partially-updated state for a while.

At some point it starts feeling like cache invalidation quietly becomes part of the application architecture whether you planned for it or not. Does anyone have a setup for this that actually feels reliable? Thanks.

I’ve been noticing that my builds don’t always produce identical outputs, even when the inputs are the same.

File ordering shifts, generated JSON changes slightly, sometimes even HTML differs in ways that aren’t obvious from the source. Nothing breaks, but diffs get noisy and it’s harder to trust what actually changed between deploys.

Has anyone found any ways to reduce or eliminate this kind of thing?