HN Explorer

Show HN: Get your coding agent off ~2019 JavaScript, onto modern web primitives (github.com)

4 points by paulirish ↗ HN
Browsers natively handle a lot of what used to take 50 lines of JS (or a dependency): `CSS.highlights` for text range highlighting without <span>s everywhere, `<dialog>` and showModal() give you backdrops and ideal focus management, `field-sizing` to auto-grow textareas as the user types.. (Something yesterday's ftrain post touched on [0])

Models know about some of these by name, but consistently won't default to using the platform-native solution and instead prefer the incumbent <div>+JS based pattern. We started an effort in Chrome to supplement coding agents with this key domain knowledge and we're shipping our 1.0 today, in collaboration with Firefox, MDN, and Edge.

200+ guides (~1.7MB) of curated, hand-crafted implementation best-practices from web experts, updated as the web evolves. (Open source, obv, so.. we'll welcome your bikeshedding ;) Readable versions here: [1]

I've spent the last 9 months obsessing over how to ship this as an agent skill + (Agentic RAG) CLI without blowing up your context window. (Or cedeing activation mechanics to MCP dynamic tool search). The skill description is minmaxed for activating on relevant frontend tasks. The RAG work I'm pretty proud of… originally a 500mb native stack down to a ~7MB pure-JS package, ~10ms search on your CPU.

We just introduced a deterministic 'legacy-scan' (trained on 30k github repos) to identify old 'n dusted patterns that your agent can modernize. (92% avg precision on held-out repos.)

People make a lot of claims about what coding agents are good/bad at. We wanted receipts, so we invested heavily in eval infra [2] to help us hill-climb, but also to identify when knowledge is common enough we can prune our guides. (Ofc, some of the things we thought AI didn't know turned out to be wrong :) We run codex/claude/agy against 200 tasks without the skill and then with.. In total ~1,700 playwright/AST-based assertions. Agents go from 55% pass unguided to 92% guided.

Try it out:

    DISABLE_TELEMETRY=1 npx modern-web-guidance@latest install
    DISABLE_TELEMETRY=1 npx modern-web-guidance@latest search "animate dialog modal"
    DISABLE_TELEMETRY=1 npx modern-web-guidance@latest legacy-scan ./src
If you spot something wrong or weird, give us a holler!

Longer write-up on the 1.0: https://developer.chrome.com/blog/modern-web-guidance-v1

---

0: https://news.ycombinator.com/item?id=50416456

1: https://developer.chrome.com/docs/modern-web-guidance/guides

2: https://googlechrome.github.io/modern-web-guidance-src/

159 comments

[ 0.49 ms ] story [ 49.9 ms ] thread
phyzix5761
"Best Practices" are pretty much dead in the AI era. Pretty soon no one is going to read any of the code AI produces and that's a scary thought.
paulirish
IMO maintainability is the next frontier. If we just allow coding agents to accrete 1k-LOC solutions to problems, the codebases run quick away from our ability to maintain _some_ level of understanding.

So I'll take a 1-line CSS solution over 60 lines of ResizeObserver/setTimeout business. But.. best practices for frontend isn't just the code.. it's ensuring quality UX, that keyboard navigability works, that layout doesn't shift on users.

aidos
Once again, thank you for all the work you and the team have done to improve the web and the experience for developers working with it.
noosphr
You just regenerate the code base, like how you do a recompile in C. Writing code is 2026 is worth as much as writing machine code was in 1996.
soon_to_be_sb
Jesus! what a horrible idea!

Are you in the business of selling tokens/electricity/gpus by any chance? Then good for you!

But terrible for everyone else....

brlewis
>Pretty soon no one is going to read any of the code AI produces and that's a scary thought.

This is a misconception. Have your favorite agent summarize this video for you: https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh

ozim
Ugh it is Uncle Bob, not going to torture AI with this guy.

But the fun part is that all of the proper software engineering practices are aimed at lowering amount of context a developer has to keep in his mind. So it directly applies to agent context. Less verbose code, less tokens to burn, separation of concerns, lower chance agent breaks something unrelated etc.

vik0
>>Pretty soon no one is going to read any of the code AI produces and that's a scary thought.

>This is a misconception. Have your favorite agent *summarize this video for you*: https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh

I can't tell if you're joking here

brlewis
I am not generally against using AI to reduce the amount of information you need to pay attention to, and I was not joking. There are multiple places in that interview with good articulation of the reasons why software fundamentals still matter, and what happens when you don't look at at least some of the AI-generated code.
drawfloat
Why don't you just quote them then? Or quote whatever the LLM you used gave.
[dead] brlewis
[flagged]
zahlman
Your comment got flagged and killed; I don't know whether automated systems attempt to detect AI-generated comments. I vouched for you because the content was explicitly solicited.
zahlman
> There are multiple places in that interview with good articulation of the reasons why software fundamentals still matter, and what happens when you don't look at at least some of the AI-generated code.

Sure, I've seen the video before and remember many of the arguments. I don't agree with everything in Bob's approach, but I certainly agree with what he says about the value of looking at the code.

But that doesn't at all mean that people will do it.

sublinear
The "modern web primitives" are also not even necessarily the "best practice".

Browser-specific implementation gotchas tend to take about a decade to iron out for reasons that never have anything to do with code quality. Users are fickle and so are browser vendors, but that's a different topic.

At the end of the day, there's just no escaping lots of manual testing across device and browser combinations if your goal is a polished result and not just something that "works".

AI has done nothing to make this problem go away. If anything, it's made it worse because people don't even want to look at the code now!

zeroq
Exactly.

I've recently finished a browser game specifically targeting an old iPad Air 1 we had lying around the house.

I had a working version after a weekend, but it took me a month to make it run smoothly on an over 10 years old mobile device. And the most recent browser available is almost 10 years old.

Surprisingly I didn't missed too many "modern" JS features, as these were mostly functional programming oriented which doesn't play well with optimization anyways, and the ES6 was more than enough as a programming platform.

Anyway, what I'm trying to say is that "the best practice" should be making your apps fast and accessible - as much as you can without having to sacrifice something you value - instead of chasing the latest and shiniest.

Don't be a fashion driven developer. :)

jefftk
This is mostly best practices for making websites work better, not for pretty HTML.
stronglikedan
just tell the AI to use best practices when writing code /s
halflife
Finally.

This is exactly what I need when I need it. The amount of pull requests I reviewed with a mess of codes that can be switched to 2 lines of modern features made me write such tools myself, only half assed since I have other things to do.

cyanydeez
I treat all my code as some kind of stochastic machinery. So atleast one stage, I'd just tell an agent to go through and follow the guide.

But I'd not inject all this fluff into the wheels of the machine because it'd just take the "average" of these practices which would be just as useless.

simonw
Distribution suggestion: in addition to the npm packages you have right now, set up GitHub Pages to publish a markdown index document of the skills at https://googlechrome.github.io/modern-web-guidance-src/skill... (currently a 404)

That index page should link to plain markdown versions of all of the documents, and should be designed for search with grep to find the right answers.

That way I don't have to install anything at all - provided my agent has the ability to make HTTP requests I can tell it "Look for tips on https://googlechrome.github.io/modern-web-guidance-src/skill..." and it will fetch the index, then navigate to the most relevant documents - no MCP or npm or installation required at all.

trvz
What’s the point of modern Javascript without over complicating things?
kinlan
https://developer.chrome.com/docs/modern-web-guidance/guides...

(we could make this clearer though)

paulirish
Aye. I like the idea, Simon. The token cost of the index is high enough I wouldn't suggest the technique for regular use but.. agree that for occasional users it should suffice.

We'll make this happen. :)

jph00
If you rename that file to "llms.txt" it'll be a bit more discoverable.
kinlan
yeah that's fair. the infrastructure we are on isn't the most flexible (we will soon move to a newer more custom platform but that's a little way a way)
kohukohunui
It looks like the markdown has cross references that assume that the cli approach is used, it would be nice to separate the content from the tooling to access.
nico
> That way I don't have to install anything at all

It feels that something like this would be the holy grail of agents. A small agent that has only the minimum necessary built in knowledge. The rest, it just retrieves on the fly when it needs (+ caching)

It’s like storing pointers/links instead of the contents

paulirish
In reality that's pretty much what we got here. Very progressive disclosure centric. There's a 'install' command exists because the ecosystem doesn't have good cross-agent ergonomics for installing skills. (Which bums me out).

But yeah.. big corpus of valuable context × minimal agent footprint = happy place.

mtrovo
If created properly, skills are already something like that. You have a front matter summary always available to the agent. The agent can request the full skill content on demand, which might contain additional linked documents with details about APIs and schemas being used, deeper documents about niche subtopics, scripts to help with subtasks, etc.
Havoc
That was my first thought too…why are we distributing text via package managers
advisedwang
Chrome already has too much power in the browser standards world. The last thing we need is everyone's LLMs to follow Chrome team's guidance on how to do web development. This road leads back to "To view this site, please view in [DOMINANT BROWSER]"
philipwalton
Mozilla Firefox and Microsoft Edge are also contributors to this project, so this is a cross-browser initiative to help improve how agents build for the web.
troupo
That's why it seems to skip the most egregious of Chrome-only APIs and focuses on areas where there's large cross-browser agreement.
philwelch
[delayed]
jefftk
Firefox is not a skin of Chrome; it has the only browser engine in common use that's not descended from KHTML.
philwelch
That's true, but in that case just say "Firefox and Chrome", Edge isn't contributing anything.
0o777
Both Mozilla and the Google Chrome team are part of the Web Baseline project and this project. They only recommend best practices supported by Chrome, Firefox, Edge, and Safari.

https://web-platform-dx.github.io/baseline/

simonjgillespie
No Netsurf. I guess thats why you also switched off access on google search pages too because unless a browser is bigger than 1G its not a real browser?
xnx
Not my opinion, but I do wonder if sharing from a different repo would feel more neutral.
tonymet
Let the best API win. why hold them back?
girvo
Because Google/Chrome should’ve been split up under antitrust grounds, instead of the “too hard let’s not bother” judgment they ended up with.
tonymet
because the $200m+ spent public & private on the Microsoft antitrust did a public service? talk about a farce and a waste of resources.

Google hardly has a monopoly. The app experience is very diverse. If anything, Apple is much more anticompetitive than Google.

Or is it that you resent any success?

Google gives away Chromium for free. Microsoft & Linux distros use it.

Thanks, this is one of the most laughable comments of the day.

girvo
You’re incredibly rude.
zeroq
What's the best way to introduce this to a Gemini chat?
paulirish
Gemini web? Probably simonw's strat from the top comment.

There's a plugin for Antigravity that's listed on initial setup (yay bundleware! :) but... yeah if you're using consumer gemini, i'd switch to the Tasks mode because it's more agentic nature helps.

In fact I just did this and it works. :p It regular Gemini, it said it did but kinda liked :) So there it'd be

> Create a perfect HTML contact form with address fields. Check https://developer.chrome.com/docs/modern-web-guidance/guides... — read completely, don't stop at truncation.

yh11
why would you ever use gemini for coding at all
zeroq
Argon is not available in agy for Pro users.
fumar
I added this a few months ago and Claude Doctor has not removed it. It must be working and getting use.
reedlaw
These skills look better than most, but running my code through the legacy scan only found two issues. So while I still think training beats skills, I'm sure this has its place, especially with weaker models.
j45
This is a great idea. I think while so much was being built out in the JavaScript ecosystem, awareness about the equivalent feature releases that were done to HTML, CSS, web components, and other technologies didn't keep pace.

Of course, it's not perfectly implemented the same in every browser, but that's nothing new.

cadamsdotcom
Planning to give this one a wide berth.

The more "legacy code" is getting written everyday the more the web will be forced to remain backwards compatible...

gabrieledarrigo
That's pretty cool!

On the other hand, a bit sad: programming nowadays is just arranging a bunch of Markdown files, possibly generated by another bunch of models.

Not so exciting, in the end.

chalmovsky
Amazing! I'm just writing an article about how Alex Russell's quote about 'React being a legacy technology' got, unfortunately, totally ignored.

And now this just fell in my lap! Some of the arguments I wanted to make seem to be provide here. Didn't have a chance to take a proper look at it, but it looks very promising and nice!

Thank you!

nchmy
I'm not sure that's just a quote. He's written and said tens of thousands of words on the topic!
[deleted]
(comment deleted)
surround
Here's a list of browser features the skills will tell your agent to use that are stable in Chrome but not supported by both Firefox and Safari:

  CSS @function
  CSS calc-size()
  CSS interpolate-size
  CSS corner-shape
  CSS border-shape
  CSS flex-wrap: balance
  CSS text-fit
  CSS text-decoration-skip-spaces
  CSS scroll-axis-lock
  CSS scroll-target-group
  CSS :target-current
  CSS scroll-initial-target
  CSS container scroll-state queries
  scrollsnapchange event
  scrollsnapchanging event
  HTML focusgroup
  Element.startViewTransition()
  CSS view-transition-scope
  Interest Invokers (interestfor)
  LanguageModel (Prompt API)
  LanguageDetector
  Translator
  Summarizer API
  Window.fetchLater()
  Speculation Rules API
  Long Animation Frames API
  VisibilityStateEntry
  PerformanceSoftNavigation
  InteractionContentfulPaint
  Connection-Allowlist
  CSS url() integrity() modifier
  HTML meta name="text-scale"
  HTML template for
  HTML processing instructions
  PasswordCredential
  Promise-returning scroll methods
  Web App Origin Migration
  Local Network Access permissions
  Request.targetAddressSpace
  beforeinstallprompt event
To be fair, the skills also recommend ~11 features not supported by Chrome itself. And the project does seem concerned with compatibility: "Guiding models to use sensible, lightweight fallbacks."
philipwalton
> Here's a list of browser features the skills will tell your agent to use that are stable in Chrome but not supported by both Firefox and Safari:

To be clear, the skills document how to use these features to solve common use cases, and then they give your agent a full browser support table for any APIs mentioned that ar not Baseline Widely available -- and then your agent can decide whether to use them or not, based on your site's browser support requirements.

In most of these cases a cross-browser fallback is also documented.

surround
The line between documenting and instructing is blurry in many cases. For example, these statements are meant to document best practices to the agent, but they sound like instructions:

"DO use fetchLater()..."

"Your own code MUST call fetchLater() directly..."

https://github.com/GoogleChrome/modern-web-guidance/blob/mai...

But yes, the skills do document compatibility and fallbacks well.

philipwalton
Agreed the line can be blurry, but I want to stress that the goal of this project is NOT to push Chrome-only APIs on users.

The mental model we've been using on the team is:

If you hired an expert web development consultant to build X, what would they recommend as a best practice? When does it make sense to use the new API (because it provides real benefits) vs. when does it make sense to wait until it's available everywhere?

To use your `fetchLater()` example, this is a case where the `fetchLater()` API legitimately solves a very real problem for people trying to build accurate analytics or telemetry features, see: https://nicj.net/beaconing-in-practice/

And lots of companies actually are already using `fetchLater()` in production now because of its increased reliability.

cma
I think I can guess from corporate incentives why Chrome supports fetchLater and some others don't.
philipwalton
It's currently being added to WebKit: https://github.com/WebKit/WebKit/pull/73271

Regarding corporate incentives: I was involved in the design of this API, so I know the history. It was proposed many years ago as a solution to make it easier for RUM analytics providers to measure Core Web Vitals metrics that needed to account for more than just page load (e.g. layout shifts and slow interactions can happen any time, not just during page load).

The RUM providers we worked with were reluctant to wait until page unload to send telemetry data because it resulted in too many lost beacons, so what they do instead is send beacons every few seconds with the most up-to-date payload.

The `fetchLater()` API enables them to send just one beacon, which is good for users and also reduces their server load.

ricardobeat
Why was 'fetchLater' chosen over a reliable way to trigger fetch from 'unload' or a similar event, or inversely, adding a 'sendLater' option to sendBeacon? Feels like a bolted-on API for a very specific use case, when the same thing could be built from better primitives?

It's a bit sad that browsers now have two different, "standard" APIs created entirely for the purpose of user tracking, as if things weren't already bloated enough.

[deleted]
(comment deleted)
embedding-shape
Maybe this mental model of yours need to include how difficult it'd be to implement your own version of the suggested API to make it actually cross-platform.

In the case of fetchLater, judging by https://nicj.net/beaconing-in-practice-fetchlater/ (which I think you intended to link actually) since I haven't come across it before, it could be implemented with fetchLater, events and a timeout, perhaps 10 LOC or so? If that's the case, then it almost never makes sense to use Chrome's own fetchLater, rather than those ~10 LOC so it's actually web-friendly instead of just Chrome friendly.

As a side-note, I'm getting increasingly wary about all the new JS APIs that seemingly gets added to our standards ONLY because they have ads/tracking interests. Used to be the people who participated in standards discussions for their ads/tracking interests came up with proper use cases and kept quiet about their erosion of privacy, but seems the mask is fully off today and we're just making browser engines for the ads companies now, yay.

hatthew
In my experience, it's difficult to suggest something to an LLM in a way that it doesn't interpret as a command, unless I explicitly list conditions (which it will take as law rather than guidance).
lelandfe
Sorry, the default behavior for this "web best practices" tool which steers people away from "legacy patterns" has agents using Limited Availability features with complex[0] and nuanced[1] fallbacks?

This would be deeply surprising to me, and I am the target audience for this repo. I'd expect the default here to be Widely Available only with some opt-in for the courageous. I don't know that I'd even enable it.

[0] https://github.com/GoogleChrome/modern-web-guidance/blob/4dd...

[1] https://github.com/GoogleChrome/modern-web-guidance/blob/4dd...

magicalist
> The default behavior for this "web best practices" tool which steers people away from "legacy patterns" has agents using Limited Availability features with complex and nuanced[0] fallbacks?

You have causality reversed here. If you need to detect if the page was loaded in the foreground or background, it is nuanced and (relatively) complex. Therefore it's good for your agent not to just assume document.visibilityState is all it needs to check, or you're going to be getting seemingly impossible log entries pretty quickly.

lelandfe
Tree, forest.

You're making this into a false binary which is wrong (the alternative to adopting Limited Availability features is not "document.visibilityState is all it needs to check"). But responding to my one example is also going to cause us to miss the point I'm making entirely.

onion2k
Here's a list of browser features the skills will tell your agent to use that are stable in Chrome but not supported by Firefox and Safari

That's fine though. Progressive enhancement, adding features to a site when they're available but still offering a working site when they're not, is how we should build web sites. That way they work for the user's device rather than the developer's opinion of what the web should do.

Working that way completely removes the decision about whether or not to use a feature because it doesn't work for some people, and moves it to a decision about whether or not it's worth adding for the users on browsers that can use it. In the past that was a real development effort cost, but today where AI writes the code the effort is much, much lower.

If you're using AI to make something but still using heuristics designed to save coding time then you really need to rethink your mental model of how to decide what gets built.

Websites created today should all use server-loaded content for the first render, small page sizes, a sub-1s loading time, progress enhancement for features, and WCAG 3.1 AAA accessibility (maybe.. at least AA though) because doing that isn't any more effort than not doing it.

embedding-shape
> That's fine though. Progressive enhancement, adding features to a site when they're available but still offering a working site when they're not, is how we should build web sites.

Alright, that's fine and dandy. Is this the actual results of using this skill though that is being advertised here? Is it asking the agent to also make sure it's "Progressive enhancement" so the same stuff more or less works in Firefox and Safari?

If not, your whole point is kind of moot, as you have someone from Google trying to get people to write websites that'll look and/or work differently in Chrome compared to other browsers.

atopal
Not only is it asking the agent, the guides themselves spell out how to make a fallback work in unsupported browsers. That's not just Firefox and Safari, if it's a Chrome only feature older versions of Chrome might not support it either. Here's an example: https://github.com/GoogleChrome/modern-web-guidance-src/blob...

Unless you have specified something different, by default the skill assumes you are targeting Baseline Widely Available, which means everything has to work in all major browsers from at least 2.5 years ago.

onion2k
Progressive enhancement isn't new. It's a concept from the days of IE and Netscape, and it's how we should all have been building website for the past 3 decades.
kevin_nisbet
I tried the skill as an experiment, and while it did give a suggestion that had poor support, it also suggested the library version as fallback (using Temporal). So if that's universally applied it might not be so unreasonable, but I don't do much frontend dev to know whether it's worth the risk or not.
Cthulhu_
I've looked up a few on MDN and they're all listed as experimental, so while they may work in Chrome they're not web standards; I hope everyone prompts their agents to avoid experimental features. That said I'm disappointed this tool seems to recommend using them anyway.
tgv
It's proposed by a Google team. That privacy data isn't going to fly to their data stores by itself. So of course they want to thwart Firefox and Safari.
atopal
Unless you have specified something else, Modern Web Guidance assumes that you are targeting Baseline Widely Available, meaning all major browsers going back 2.5 years. Everything has to either be a progressive enhancement or have a fallback that works in those browsers. Otherwise you have to explicitly ask for that feature. This is a policy that was worked out with Microsoft Edge and Mozilla Firefox, who are also contributing to the skill.
Arubis
The proportion of sites that I have to swap out of Firefox to use has gone from "every couple of weeks" to "multiple times weekly" lately, mostly among clearly AI-coauthored sites. I wonder if this is part of why.
dallen33
Paul Irish?? There's a name I haven't though about in ages! I remember following you on Twitter and your website was full of amazing information. Hope you're doing well!
internet2000
NO THANK YOU. Do not want my agents to contribute to the Chrome monoculture. Chrome is the new IE6.
tonymet
no it's not. they publish the APIs. IE was bad because ActiveX was proprietary and private.
adzm
I find this very useful as a human as well
mococa
More Chromish on web? No thanks.
tonymet
I recommend saying "contemporary" or "suggested" for transient proposals like this. Having modern change every few years is ambiguous and cliche .

These concepts are new, so no one knows if they are any good. They're not modern -- who knows if they will even be put to use?

"contemporary", "proposed", "suggested", "compatible" are better fit. I wouldn't dare use "advanced" because many APIs and proposals actually regress earlier behavior.

pyrolistical
I asked my agent to look at that list and only apply things that work on chrome, Firefox, safari iOS and safari macos

Came up with a good list for my project

codepoet80
I want the opposite of this. I want compatible code -- which is really hard, when there are so many eras to target. So far AI has done a great job of finding that sweet spot -- why would I want a tool that encourages the agent to write less compatible code?