Comment by bakkoting | Hacker News Reader

Comment by bakkoting | Hacker News Reader

Parent Full thread

> If you spot something wrong or weird, give us a holler!

But how? Hopefully filing an issue on the modern-web-guidance-src repo is the right place? Anyway I filed one for using fromBase64 and toBase64 instead of atob and btoa.

But since you're all in on agents anyway you should consider having one look through at least all of the JS, DOM, and HTML spec commits in the last 3-5 years and automatically triaging any that are clear improvements and are not used by agents. Would be pretty straightforward.

---

Btw, I think it would be very helpful to automatically provide versions of this depending on what browsers you're targeting. I don't want to use anything that hasn't been available in all evergreen browsers for at least a year, for example; I think most developers have a similar standard, or at the very least don't want to use the bleeding edge. And while it is _possible_ to get that from your repo, it takes some effort, either writing a script or letting the agent use its own judgement for every feature. That's work you could do on your end and save the rest of us from needing to.

Thanks for filing! Yes, the modern-web-guidance-src repo is the right place: https://github.com/GoogleChrome/modern-web-guidance-src

> Btw, I think it would be very helpful to automatically provide versions of this depending on what browsers you're targeting.

This should work today (though not exactly in the way you describe). The skill tells the agent how to interpret guides based on browser support signals it gets from context (e.g. the prompt itself, or AGENTS.md).

You can see those instructions here: https://github.com/GoogleChrome/modern-web-guidance-src/blob...

> This should work today (though not exactly in the way you describe). The skill tells the agent how to interpret guides based on browser support signals it gets from context (e.g. the prompt itself, or AGENTS.md).

Right, my point is that I don't want to spend a bunch of time and tokens loading the skills and having the agent reason through whether they apply based on browser support. I want that to be automated so that it only loads in the first place those things that are actually applicable. Having a prose description is not a substitute for automation; it is almost always better to do things mechanically rather than asking the agent to do it, in cases where it is possible to do mechanically.

I think this matters even if you're at Google and tokens are free but it _definitely_ matters for the rest of us.

If your feature use policy is that you will never use any feature unless it's supported in at least X, Y, and Z browsers, then yes something like this would be possible. But most sites don't have a policy like that.

Most sites are willing to use some features as a progressive enhancement, whereas other features they won't even consider using unless it's in 99+% of their users' browsers.

And unfortunately there's no easy way to make that decision for users on a feature-by-feature basis, because it all depends on what use case they're trying to accomplish, and what will happen if the feature is not available (given that particular use case).

So our approach is to (1) explain in the guide how to implement the use case with the modern feature, (2) explain why the modern feature is the preferred solution (e.g. what the user benefit is), and then (3) explain how to implement a fallback solution if the feature is not available.

I think we could potentially experiment with some version of what you're describing, like a config option where we only surface guides that have robust, widely-available fallbacks, and where we have high confidence that it makes sense for the majority of sites to be following the recommendations in the guide.

I'll raise it with the team.

> But most sites don't have a policy like that.

My experience differs from yours. It's true that there is some tiny fraction of features where it makes sense to do progressive enhancement, but for most sites and almost all features this does not make sense: the burden of testing and maintaining a site that effectively has multiple versions depending on what browser you're using is simply not worth it. For typical dev teams outside of Google/Meta/similar, the right thing (and the overwhelmingly common thing) is to target the intersection of features available on your supported browsers and not make any behavior conditional. I'm not interested in any guides that need fallbacks on any of the browsers I target and I expect the same is true of the typical dev team outside Google.

Couldn't this be a simple deterministic build from the provider rather than mass replication of inference for essentially every user?

I believe I answered your question in this reply: https://news.ycombinator.com/item?id=50449873

Reply on news.ycombinator.com