I'm very interested in what the models have visibilty into and the differences between the models, and then by extension what it means for us as web developers. I think we're not in the best position and a lot of the data in the models is supprisingly stale. In please mind the model gap I tried to measure how far behind a model actually is:

[...] the platform did not stop moving the day the training data was frozen.

The interactive timeline in that post plots each model's cutoff against Chrome releases, and the gap is bigger than most people expect. I don't really know why we don't talk about this more. If I was a library author, or a new framework author, or heck, I just updated and released a new version, then I would be doing all I could possible to make sure the models had access to it (and search isn't always the answer imo)

I did also try to check whether the "model half-life" everyone keeps citing is even a real thing, and mostly talked myself out of it:

On reflection, model halflife really doesn't make much sense and it's just a bit of a buzzword to mean that models now ship faster.

What surprised me was the lack of data "in the model". I had a lot of fun and I spent a lot of money and a long time on does a url in a prompt steer an llm's output, testing whether a URL sitting in a prompt changes the answer, and the bit that stuck with me was not about URLs at all:

If your site relies on JavaScript to load its content, that content is very likely not in a model (you might consider that a feature).

You can watch it happen in the results: the models can't (obvjously) can't recall the data they don't have when given an identifier (a url) that's not in the model. They then recover when you hand them the actual page (kinda obvious). When the content is memorised, the URL seems to clearly tilt the output just by being there towards the content that behind that URL, which if this really really is true, I think is something we can take advantage of instead of stuffing our prompts with context, the mere presence of that URL will influence the output to align with what's behind that page - this could be a big win for skills and well established best practices.

During the proccess of creating the post I found that there was 0 recall for ChromeStatus.com and I thought it was a pointer to my idea failing and it turns out that ChromeStatus.com is JS rendered and the content wasn't in things like CommonCrawl and by extension depending on what the indexer's did, likely a pointer to the data not being in the model.

That left then left me with a question I couldn't easily answer at the time: when one of the many bots hitting those URLs loads a page, what does it actually do? Fetch the HTML and stop? Parse the CSS? Run the JavaScript, or just download the .js and move on? So I built ua-tracer to watch, and wrote it up here

The early data already broke an assumption I did not know I was holding, that "an AI read my page" means one thing. It does not. GPTBot parses your CSS but runs no JavaScript, ClaudeBot stops at the CSS file, and of the OpenAI agents only OAI-SearchBot runs the script. Point a crawler at uatracer.com and you can see what yours does.

Finally, my last post was something I hope was a bit more constructive and shows how web development might change with new tooling. In how might a modern lighthouse work with large language models I built an audit where the model does the judging rather than a pile of hard-coded checks, and one of the things it looks at is how much of the page exists before any JavaScript runs. I pointed it at one of my own sites (iwanttouse.com):

Coverage was 6 percent, that is, only 6 percent of the words a browser eventually renders were in the HTML before any JavaScript ran.

I knew at the time that I was building a JS-powered site, but it was nice to see the LLM pick this up based on the descriptive tests and then offer up a solution for how to fix it.

The live playground runs the whole find-fix-verify loop on a set of deliberately broken pages, and there is a full report with the evidence it gathered from the example site if you want to see the shape of the output.

I love that this is a loop and not a tool.

I mean... I wrote that bit thinking I was clever, but it's also a tool: npx web-uplift@latest audit https://paul.kinlan.me/

So I built ua-tracer to answer it, and it's a tool that I think will be useful for many web developers trying to understand what any browser or bot does when it accesses your site.

Click through any row in that list and you land on the trace detail, a request-by-request account of what that one user agent did:

How it works

Every time a user agent loads https://uatracer.com/, the site mints a unique trace id and a per-request secret, and renders a page whose every asset (stylesheet, script, images, font, manifest) carries both in its path. The secret is private to that one page load, so only the agent that received the HTML can fetch the probe assets: no guessing, no replay by anyone else.

/r/{id}/{secret}/style.css     the real stylesheet
/r/{id}/{secret}/main.js       the real script
/r/{id}/{secret}/photo.png     a real PNG
/r/{id}/{secret}/font.woff2    a real woff2 font

Because the id is unique per page load, every later asset request can be tied back to the exact homepage hit and the user agent that made it. I also added other probes that come what those assets themselves reference (paths below drop the {secret} segment for readability):

A plain downloader (think curl) nomrally just fetches the HTML and stops. A CSS-aware fetcher additionally hits css-bg.png and css-font.woff2. A UA that parses the manifest reaches manifest-icon.png etc. Social unfurlers (Twitterbot, Discordbot etc) fetch the social-card image. Finally, only a user agent that runs JavaScript will ever touch js-ran.gif or post to /timing.

What a trace looks like

Open any trace and you get a request-by-request account of how far the agent went: which asset types it fetched, whether it followed the CSS-linked resources, whether it executed JavaScript, and the client-side resource-timing waterfall it posted back if it did.

This particular trace is synthetic: I generated it by pointing a made-up user agent at the site and walking it through the assets by hand:

curl -A "Mozilla/5.0 (compatible; DemoBot/1.0; +https://example.com)" https://uatracer.com/
# then fetch the trace-scoped assets it references:
curl https://uatracer.com/r/{id}/{secret}/style.css
curl https://uatracer.com/r/{id}/{secret}/js-ran.gif   # the JS-execution beacon

The trace detail is intentionally public: share /trace/{id} as a link and anyone can read the result, which makes it easy to pass a finding along ("look, this agent doesn't run JS").

Some early analysis on what the bots actually do

This site hasn't been live that long so it's not got heaps of data yet (hence this post to try and raise some awareness), but I've got some insights that I think are interesting.

One caveat first: a User-Agent string is trivially spoofable. The tool also checks each request's source IP against the CIDR ranges its operator publishes. Every major crawler operator now publishes a list you can match against: Google, OpenAI's GPTBot and OAI-SearchBot, Bing, and Anthropic's ClaudeBot (IP list). So a "Googlebot" or "ClaudeBot" trace is either verified (the IP is in the operator's published range) or flagged as likely spoofed. The one exception in the data so far is OpenAI's ChatGPT-User, which is triggered by a person rather than run on a schedule and publishes no fixed ranges, so its User-Agent alone can't be confirmed.

Bots from the same company do not behave alike. OpenAI seems to run at least three agents against the site (all IP-verifiable), and each does something different:

• GPTBot (+openai.com/gptbot) fetches every directly-referenced asset and parses the stylesheet, following the background-image, the @font-face source, and the @import. It does not run JavaScript.
• OAI-SearchBot (+openai.com/searchbot) presents a full Mac Chrome User-Agent and runs JavaScript: it executed both the classic script and the ES module, and followed the CSS background image. Of the OpenAI agents, this one is browser-grade.
• ChatGPT-User (+openai.com) fetches the page and its assets but runs no JavaScript and parses no CSS.

Anthropic's ClaudeBot (+claudebot@anthropic.com) fetches the full asset set like GPTBot, but stops at the CSS file: it never reaches the background-image or @font-face inside it, and it does not run JavaScript. So "an AI is reading my page" breaks three different ways depending on whether that AI is GPTBot, OAI-SearchBot, or ClaudeBot. (ClaudeBot traces · GPTBot traces · all bots)

Googlebot is documented to render JavaScript in a second pass (Google's JavaScript SEO docs describe crawl → render queue → a headless Chromium executing the script later). I have not caught that render pass in the traces yet; what I have seen is the fetch-only first stage. So "Googlebot doesn't run JS" would be the wrong conclusion to draw, and the tool is set up to record the second stage if and when it arrives. The same applies to Applebot (Apple's docs say it "may render the content of your website within a browser"); the seven Applebot traces I have are IP-verified real but fetch-only so far.

Some bots announce their intent; most don't. DomainArrivalsBot/0.1 identifies itself as either (+homepage-extract; research) or (+homepage-only; research), telling you in the UA string whether it takes the whole page or just the root. That honesty is rare. Most agents either masquerade as browsers with full Mozilla/AppleWebKit strings (OAI-SearchBot above is a textbook case) or skip the courtesy entirely: okhttp/5.3.0 and Go-http-client/1.1 between them account for dozens of visits, and both are raw HTTP libraries with no name.

This is the data I wanted for aifoc.us and couldn't get from any log. The bots reading the web are not one thing; they are a population, and the only way to know what a given one does is to watch it. We can measure page views to the nearest second; we still can't tell whether the thing reading the page ran the code on it.

Try it

The site is at uatracer.com. Open it in a browser to mint your own trace, or point a crawler at it. The source is on GitHub: a single Deno file and a Deno KV database, nothing more. (note - I've used an agent to build this out)

I'd love some feedback on this and if you have any other tests that you would like me to add.

Sources: bot IP ranges and what each operator says

• Google publishes its crawler IP ranges (common-crawlers.json) and recommends a reverse-DNS check: resolve the IP to a googlebot.com hostname, then forward-resolve it back to the same IP (Verify Googlebot). Googlebot also runs JavaScript in a separate render pass using an evergreen Chromium (JavaScript SEO basics).
• OpenAI publishes ranges for GPTBot (gptbot.json) and OAI-SearchBot (searchbot.json); overview at platform.openai.com/docs/bots. ChatGPT-User is triggered by a person and has no fixed ranges.
• Bing publishes bingbot.json and a verification guide using reverse-DNS to a search.msn.com hostname.
• Apple publishes Applebot CIDRs at search.developer.apple.com/applebot.json and a reverse-DNS check against *.applebot.apple.com (About Applebot). Apple notes Applebot may render pages in a browser, like Googlebot. (Apple also runs Applebot-Extended, which doesn't crawl but controls use of crawled data for model training.)
• Anthropic publishes its crawler IPs at claude.com/crawling/bots.json, covering ClaudeBot, Claude-User and Claude-SearchBot (help article). Anthropic notes that IP-based blocking "may not work correctly or persistently guarantee an opt-out", but the list is sufficient to confirm a request genuinely originates from Anthropic.

I kept it distinct from this site because I know that quite a few web developers who follow my content are not fond (to put it mildly) of LLMs and the AI industrial complex, and I felt it would be good to split the two.

I will keep publishing my posts on the other site, but I thought it might be good to try and pull together the 30-odd posts that I've created and try and explain where my head is at and provide some colour on how I got there.

Before I dive too deep, I think we are potentially in a golden age for the web, with a massive influx of people having major barriers to entry removed. Barriers that once were the reason why people preferred Instagram and similar services are being lowered to the point where anyone can build on our platform (and I'm seeing lots more people building).

Anyway, here we go:

Models inherit a stale web, and they set us back a year

The thing I keep coming back to is that the models we now write code with learned from a web that is already old. I made the model gap to show this concretely: measured in Chrome releases (I know, I know, the web is far broader than just Chrome, but also Chrome has easy data to access on chromestatus.com), even the freshest model is several versions behind, and most are ten to twenty behind. The "knowledge" cutoff is a serious issue for the web platform, and the ecosystem of libraries and tools that are being launched but are not easily available to these models is massively gaining traction (Claude Code).

That connects to model half-life, where I looked at how quickly models are superseded, and to dead framework theory: if a framework stops appearing in fresh training data, the models stop reaching for it, and the framework quietly dies regardless of its merits. I wrote this thesis at least 6 months ago, and I think I've been proven correct (which is why we built Modern Web Guidance). The flip side, though, is that I've found guided output getting better than what people create (I think auto-research loops to optimize web performance, as an example, will massively raise the bar for the quality of the web people experience).

My uncomfortable conclusion across all of these is that the web inside the model is the web that developers actually inherit, and right now it is a year out of date and getting staler with every release.

We can discover functionality and link to it

I have been trying to give the web a federated way to link to functionality for over a decade. I wrote what happened to web intents and later reinventing web intents about the first attempt and its failure. The idea never left me; ask anyone who knows me, I never shut up about it.

WebMCP is the thing that finally makes it plausible. I argued the case in webmcp is the new web intents ... maybe, and then, once I had actually built a relay that discovers and reuses a page's tools across sites, I dropped the maybe in i think i've got it. This sits on top of older thinking about why the link is the web's most underrated primitive (a link is all you need).

I want to explore more about what an addressable unit of the web should look like for agents, building on SLICE, and how it might evolve. Naturally, there is a lot of worry about the I in SLICE that I want to explore a little bit more.

The browser is an amazing sandbox and other platforms are racing to what we have already

If a program is mostly a prompt, then the interesting question is where you run it safely. I think the browser is the answer, which is the argument in the browser is the sandbox. That follows from the prompt is the program, where the entire application is a Markdown file, and shipping a prompt, where the portability of a prompt becomes the distribution model.

I have been poking at the edges of this too: building a claw in the browser is a genuinely dangerous experiment in how much access an in-page agent can get.

I really think we should be exploring this space a lot more, making some small changes to the platform (heh, Safari doesn't have CSP3) and really pushing on what every super-app platform doesn't yet have that can really differentiate the web.

Agent loops, and what they actually enable

Once you have written a few agents, you see that we have a new pattern for software (that people call agent loops). It is slower and vastly more expensive, but it is also opening up a world where it's easier and easier for people to instruct their machines and get accurate results. It's rather incredible, and it reminds me of how much more approachable HTML was when I started.

I built my own provider-agnostic loop, wrote it up in agent-do, and it enables me to do a lot of experimentation, for example:

• a whole small company replaced by agents in a container (business in a box)
• building a claw in the browser
• the prompt is the program, where the entire application is a Markdown file
• and shipping a prompt

I know I linked to these above, but I think the browser sandbox and agent loops are going to change a lot about how web experiences could be built in the future. I don't think we are there yet, but I can imagine a world where entire websites and services are higher-level instructions and design guidance.

Development is changing quickly

I really don't know what else to say about this: the sheer volume of machine-authored work already landing, which I measured in damn claude, that's a lot of commits, is astounding, and it could lead to strange new economics of paying for tokens instead of people (the token salary) and how we charge for services (token slinging).

I'm personally fully on board with these tools, and I think I've become quite proficient. While I do encourage people to understand how the platform works and how the browser works, I don't think we are going back at all. In fact, everything will accelerate now that the technology and tools exist.

Generated content and content negotiation

This is the thread I find most exciting for the web specifically. If a page can be generated on demand, the old idea of content negotiation gets a second life: the server does not pick from a few fixed representations, it generates the one you asked for. I keep using NotebookLM as the proof that a tool which generates a custom view of a corpus is already a kind of browser.

I'm personally kind of shocked there isn't more experimentation about how the future of sites and browsers might work. As tools that generate content get higher quality and quicker, they are going to open up new areas of the platform:

• If we can intercept requests to synthesise responses, what does it enable?
• If we take hypermedia to the extreme and enable any content to be turned into experiences that people prefer, what will happen? I know a lot of folks who learn via manga; why shouldn't they be able to consume content in their preferred format?
• I think we now have the Memex, so what happens to the CMS when content is generated (hint: they can adapt), and how can markup change to be more expressive (Headless stopgap)?

There's going to be even more change to the web as the latency of models falls, making generating UI and new content modalities on the fly viable (and I think sites should lean into generating content in the form their users prefer).

Maybe we can also get back to site mashups, and stave off the threat of super-apps (btw, this is a huge risk.)

How browsers might adapt

First, super-apps are coming, and they hint at a world where you barely open a browser at all. It might be a little way off, but I would love browser vendors to work out how the web will remain a first-class citizen if this happens. That's why I think WebMCP is critical, as is exploring what is listed below.

Elements: web components are a quietly perfect packaging format for agent-generated UI, and almost nobody frames them that way.

Can we bring in primitives and interactions that you don't get on other platforms? I'd love for us to explore how the link might evolve. I did this in embedding, which is really about transclusion: pulling live functionality from one site into another, the E in SLICE, and an old web dream that agents might finally make real.

I built a lot of demos to try and show this in action:

• Hyperlink Experiment: There is a lot in here.... I struggle with the hubris the industry has around the link. I set out to experiment with the concept of linking on the web and I really want to encourage people to really push the boundaries of what a link is and, if possible, how technologies like LLMs and image recognition models change how the web fundamentally works.

• Merge - Extension - One of the things I love about the web is that you don't really know what is on the other side of a link. One of the things I dislike is that you don't know what is on the other side of a link. I also wonder what the intent of a link is.

• Trails - Extension - This uses no LLM technology, but I built it with an LLM. Vannevar Bush's "user links" let you create your own links on pages and have them be permanent.

• Summary - Hover over a link and get a summary of what is on the linked page before you click it.

• Stretch Text - Taking Ted Nelson's idea and trying to make it usable. Select some text and zoom in (expand) or zoom out (summarize). After reading Ted Nelson's ideas on this, it was up to the author to offer this, and knowing how people publish on the web, people just aren't going to do this. LLMs make it possible to add extra context or summarize it. I didn't really test this too much in the end because I wanted to get Merging and Trails working.

• I made a lot of other experiments, such as linking into images with descriptions, and also making it easy to do image maps again by using English (using the Segment Anything model) instead of points. Link to audio content via timestamps with a Whisper-like model. Pull in the UI of a linked element into the current page, taking the Merge experiment one step further.

If browser vendors choose, they could solve interop issues once and for all. In how might a browser be developed, I explore how a browser might be developed to the point where the major points of interop difference are fundamental issues of where the browser vendor thinks the web should go. I also go a little further out into some sci-fi.

The End

That's roughly where I am. There's still lots I will be exploring.

I am very excited about the future because I think we could continue to see millions more people start publishing on the web, the web getting higher-quality experiences, and waves of new innovation into what the web could be.

It uses a double iframe architecture to reduce the ability of any generated code to access your API keys or host page data. The outer iframe exposes a limited API to the host page it mediates all communication with the inner iframe.

Both iframes are sandboxed and both iframes are created via blob URLs so their origin's are null. This means that the inner iframe cannot access the host page or any of the host page or the outer iframe. The outer iframe can't directly access the DOM of the inner iframe other than changing the href source.

If I was to summarise the features of this component I would say it supports:

• AI-Generated Content: Turns text prompts into interactive web apps (calculators, games) or SVG images.
• Sandbox: Uses a "Double iframe" architecture to ensure generated code cannot access your API keys or host page data.
• Multi-Provider: Supports Google Gemini (via API Key) and Chrome Built-in AI (experimental window.LargeLanguageModel).
• Vanilla JS: Zero framework dependencies. Built with standard Web Components.

Usage

You can install the component directly via npm:

npm install @paulkinlan/generate-html

Then, import the component script and use the tag in your HTML:

<script type="module" src="/src/generate-html.js"></script>

<generate-html
  prompt="Create a snake game"
  api-key="YOUR_GEMINI_API_KEY"
  model="gemini-2.5-flash-latest"
  provider="gemini"
  type="html"
></generate-html>

The demo can be accessed here: https://generate-html-element.paulkinlan-ea.deno.net/

For more details, check out the GitHub repository.

I built a "Deep Research" agent using Val Town that allows me to trigger complex research tasks simply by sending an email. It uses Google's Deep Research model to perform the heavy lifting.

It is pretty simple to get started, you just need to send an email.

1. Send an email to: deep-research@valtown.email
2. Subject: Your research topic (e.g., "Latest advances in quantum computing") - this is only used in the title of the reply
3. Body: Detailed research question or context that will be sent to Deep Research
4. Wait: The system will process your request and send the research report back to your email

The architecture is interesting because Deep Research can take a while to complete. I couldn't just hold the connection open. Instead, I set up a two-part system on Val Town:

1. An Email Handler: Receives the query and kicks off the job with the Google GenAI API, saving the task ID to a JSON object in valtown blob storage.
2. A Cron Job: Periodically checks the status of pending tasks. Once a report is ready, it formats the result as HTML and emails it back to the sender.

It's a great example of how serverless functions and simple state storage can build powerful asynchronous agents.

You can fork this project or view the source code directly on Val Town.

View the Code on Val Town

That's the core idea behind my latest project, Fauxmium.

Fauxmium is a proof-of-concept that explores what it's like to browse an effectively infinite web. Everything you see inside the Fauxmium browser is generated in real-time by AI. It is not real.

It works by launching a real Chrome browser, but with a twist. It intercepts every navigation and image request and routes them to a local server. That server then prompts a generative AI model to create the HTML and images for the URL you requested, streaming the content back to your browser. The result is a unique, ephemeral, and often surprising browsing session.

➡️ Check out Fauxmium on GitHub

Getting started is simple. If you have Node.js installed and a GEMINI API Key, you can run it with a single command in your terminal. I'd recommend running it with DevTools open to see what's happening under the hood.

npx fauxmium --devtools

Once it launches, just start typing in any URL you can imagine and see what the AI comes up with!

How It Works (The Gist)

Under the hood, Fauxmium combines a few key components:

1. Browser Control: It uses Puppeteer to launch a headful instance of Google Chrome.
2. Request Interception: Puppeteer intercepts every request and sends it to a local proxy server.
3. AI Generation: The local server uses the Vercel AI SDK and the Google Gemini API to handle requests. It takes the URL you requested and uses it in a prompt to ask an AI model to generate the corresponding HTML page or image.
4. Rendering: The generated content is streamed directly back to the browser and rendered.

Currently, it supports text generation from Google (Gemini), OpenAI, Anthropic, and Groq, with image generation handled by Gemini. You can tweak the prompts it uses by editing the text files in the prompts/ directory—they're re-read on every request, so you can experiment without restarting the server.

I've launched a new blog. It's called AI Focus, and it's dedicated to exploring the intersection of artificial intelligence and web development. My goals of the blog is to cover a range of topics that I think are going to affect the web and web development in the coming years.

Why? I think that the nature of the web has changed and it will change even more in the coming years. I love the web and web development, but I don't think we can idly sit by and assume that "the web will always win". I don't "always bet on the web", I bet on the people who build for the medium that is the web, that is the users, the authors, the developers, the designers, the creators and web browser engineers. I think we are going to have to adapt to the changes that "AI", or at least the technology that is Large Language Models, bring to the web, and I want to be at the forefront of that change.

I'm experimenting with a more essay focus to the writing which pose more questions than answers at the moment. I've been silently writing articles on it for the past couple of weeks, covering topics like:

• The future of embedding?
• The future of linking?
• Will there be a super-app?

My buddy Andre Bandarra has also written some great pieces about Mashups and assistance in web development

Let me know what you think, and also what topics you'd like to see covered in the future. I'm always looking for new ideas and perspectives, and I want to expand my understanding and opinion.

This is a great talk from Annie Sullivan at BlinkOn 20 about the availability and adoption of web features. Annie discusses the importance of understanding how features are used in the wild, and how this can inform the development of new features.

I took a few notes on the talk, which I thought were interesting and linked to them below:

• Core Web Vitals: Discusses work on improving web page quality metrics (LCP, INP, CLS) using HTTP Archive data to identify and fix issues [00:00:21], [00:00:50] and how this was the groundwork for the talk.
• Baseline Data: A baseline dashboard by the WebDX community group provides metadata on web features, including their availability status and [00:03:32] and how Annie would use this aligned with usage data to understand the adoption of web features (rest of the talk)
• Key Findings:
  • Wider availability leads to higher adoption [00:05:56] <-- We all had a feeling this was the case, but it's nice to see it backed up with data.
  • Feature adoption isn't significantly skewed by website popularity [00:06:15].
  • 1. we can do splits on data easily, 2) HTML and JavaScript features show clearer adoption patterns than CSS [00:07:19].
  • HTTP Archive data aligns well with real Chrome usage data [00:09:27].
• Analysis Tools: Uses HTTP Archive and BigQuery to analyze feature usage [00:10:14].
• Adoption Factors:
  • Site-building platforms (e.g., WordPress) [00:12:54].
  • Third-party embeds (e.g., YouTube) [00:08:52].
  • Progressive enhancement with fallbacks [00:17:43].

Our team has long been pushing to understand API usage and how collaborating with site-building platforms can help us understand the impact of our work (selfishly for me), but I do think broadly that this type of insight helps us get more investment in to the web platform and helps us prioritize the right things.

I loved this post from Andre about running sentiment analysis in the browser using a model that he'd trained on embeddings generated from a YouTube comments data was great and shows that you don't have to run everything through the full language model and instead can use just the embedding APIs to get a decent result.

The client side part of the code can be seen below:

const input = 'Hello, your video is amazing!'; const embedResult = await genAi.models.embedContent({ model: 'text-embedding-004', contents: [input], }); const embeddings = embedResult.embeddings.map(embedding => embedding.values); const outputTensor = await model.predict(tf.tensor2d(embeddings)); const argmax = await tf.argMax(outputTensor, 1).array(); const labels = ['Positive', 'Neutral', 'Negative']; const results = argmax.map(i => labels[i]); console.log(results);

const probabilities = await tf.softmax(outputTensor, 1).array() console.log(probabilities);

I think this post would be good for every developer to read. It's more about communication than just blogging.

The biggest mistake software bloggers make is meandering.

Often, the author has some valuable insight to share, but they squander their first seven paragraphs on the history of functional programming and a trip they took to Bell Labs in 1973. By the time they get to the part that’s actually interesting, everyone has long since closed the browser tab.

This is me to a tea. I remember when I first started blogging and I would just get traffic, times have changed and I certainly need to be a lot clearer with my writing.

This really resonated with me:

If you want people to read your blog, choose topics that have a clear path to your readers. Before you begin writing, think through how readers will find your post.

I tend to fart out a blog post, and the guidance here is very similar to the guidance I hear from a lot of content creators. Study your medium, understand your audience, how to reach them, and then plan plan plan.

If you're interested in the broader topic of writing for an audience (probably a more business focused one) then I really enjoyed Pyramid Principle by Barbara Minto, it's helped me a lot within my role as a way to communicate more effectively (although, I still have a long way to go).... I've heard it's favoured by McKinsey consultants, while that's not my cup of tea, the principles seem sound to me.

background: linear-gradient(to right in oklch longer hue, oklch(95% var(--vibrance) 0) 0 100%);

I know CSS pretty well, but I'm mind blown by what Adam produces. It's like when I draw, I know what I want, but translating it from the image in my brain into something that looks good on paper is a whole other story.

I have a bit of love-hate relationship with TypeScript, but there are parts of the typescript Type system that I really like. This article from Piccalilli is a great introduction to TypeScript's utility types (which is one of the areas I like, even though it is a bit complex)

Utility types are types that modify other types. You can think of them as functions, but they operate on types instead of values. It’s mind bending at first — especially if you’re coming from languages that don’t have anything similar — but we’re going to walk through a load of examples to see how they work.

Mind-bending indeed.

One of my favorite types that I've made is here in Breadboard. It could take a function and return a proxy for that function that had the same calling parameters.... I think... I'm not sure, I wrote it a while ago... heh, that's the "hate" part of the relationship. :D

I’ve been banging on for a while now about how much I’d like a declarative option for the Web Share API. I was thinking that the type attribute on the button element would be a good candidate for this (there’s prior art in the way we extended the type attribute on the input element for HTML5).

I'm fully aligned with Jeremey on this one, there's a heap of commands and actions that a user invokes in the browser that should be more accessible from the client and be able to be invoked without JavaScript.

Turns out there is work being done around this area for dialog and popover elements, with scoping for more elements in the future.

Things have been rolling along and invoketarget has now become the command attribute (there’s also a new commandfor attribute that you can point to an element with an ID). Here’s a list of potential values for the command attribute on a button element.

Right now they’re focusing on providing declarative options for launching dialogs and other popovers. That’s already shipping.

More details about what Jeremy is talking about can be found in this developer.chrome.com article.

I agree with where Jeremy wants to see this head, as the article says "We welcome community input—if you have suggestions don't hesitate to file an issue on the Open UI Issue Tracker."

Maybe we can get button command="bookmark"... I joke... kinda... we used to have an API for this back in the day and while I don't think we would want an API to your bookmarks, I could see a world where a lot of the Fediverse's issues could be solved with a few more declarative commands.

Something that I've been thinking about a lot recently is that the medium that is the web. It enables a lot of things that only the web can so this post by Brad Woods really resonated with me and it talks about how the web can be used to adapt stories to different mediums.

Different mediums convey information in unique ways and creators interpret the same story through unique perspectives. Tolkien gives relatively little detail of what Middle-earth looks like, leaving much of the work to the reader's imagination. Jackson on the other hand paints vivid pictures. Tolkien emphasizes the length of the journey by detailing every step, making readers feel the weight of the adventure. Jackson focuses on the major events, creating a fast-paced narrative. Neither approach is superior. Each explores Middle-earth from a different angle. Adaptations allow audiences to make a deeper connection with the story, enriching their understanding and appreciation of the original work.

What the browser offers

The browser offers the following communication tools:

▪text ▪image ▪video ▪sound ▪interactivity ▪video game environments (2D and 3D) With these, we can recreate most story mediums. For example, using image and text to make a comic book or sound to make a podcast. This gives the creator freedom to choose the communication tool(s) that best fit the story they want to tell.

Yes. YES. YES! I love it.

He also discusses the idea of Personalization and Interactivity. Quadruple yes! The web as a medium is so incredibly versatile and I love seeing people explore that.

In 2014 Jeremy Keith published a post "Continuum" and it touches on a different aspect of the value of the web: it's resilence and ability to adapt to the devices it runs on and the browsers it runs in.

I'm still working on how I want to be able to express the value of the web more, especially in a world where it looks like the youth of today who grew up with mediums such as YouTube, TikTok, Facebook and Instagram don't naturally see the web as a medium that they can use to express themselves (or even enjoy).

As a side note, this blog is a gold mine of neat experiments and explainers

• https://garden.bradwoods.io/notes/svg/draw-on-scroll
• https://garden.bradwoods.io/notes/css/blend-modes
• https://garden.bradwoods.io/notes/javascript/web-api/intersection-observer
• https://garden.bradwoods.io/notes/javascript/web-api/intersection-observer/dynamic-header
• https://garden.bradwoods.io/notes/misc/news
• https://garden.bradwoods.io/notes/game-dev-journal/03-persistence

When I was preparing the Interop post yesterday, I found one of the agalia links didn't work and while I was hunting for the new link, I found Planet Igalia. :mind-blown:

I've always wondered what's happening at Igalia and while I love the podcast, I do love a good Blog.... I'm really not sure how I missed this entire part of the site, but it's go so much good information and often frequent deep dives in to browsers. For example Maxsim Sisov's post on "Unmasking Hidden Floating-Point Errors in Chromium’s Ozone/Wayland" - such an awesome read into an area I had zero knowledge about.

Triff and marv.

We feel that validation and enforcing baseline features are the minimum that a linter needs to support in 2025, and so we spent a lot of time making the no-invalid-at-rules, no-invalid-properties, and require-baseline rules as comprehensive as possible.

Love it!! Absolutely love it.

One of the areas that we would love to see more of (and we hope to work) is more integration of Baseline in to developer workflows. That could be Linters (like ESLint), boot-strappers, IDEs, compilers, frameworks, DevTools. You name it, I think it would help the entire ecosystem if we could get see increase awareness and usage of Baseline and therefore adoption of the features that all the browsers implement natively in to the hands of developers.

Exciting times.

One of Shopify’s key metrics is Checkout Conversion Rate (CCR), which measures the rate of successful checkouts completed over a period of time. Through testing, Shopify found that removing unnecessary steps led to more customers completing their checkouts. Guest checkouts using autofill had a 45% higher CCR than guest checkouts without autofill. Basically, the customers who didn’t have to spend time filling out forms were more likely to actually buy something at the end of their online shopping trip.

Emphasis mine, but this is incredible and is something that I think has gone under the radar.

For the longest time it was thought that there was no way to measure the impact of autofill on the web. In 2016 I developed a small snippet to detect when autofill happens and while no one paid attention, it's good to see that with the introduction of CSS :autofill pseudo-class in Baseline, we can create some simple JS that will more effectively detect when autofill happens.

There's also now better autofill tooling in Chrome DevTools, so my hope is that more people will start to understand the impact of autofill on their sites and start to optimize for it....

... maybe.. There is still a lot of concern in the ecosystem about autocomplete=off and a lot of people that don't want the user's agent to control the autocomplete experience.

It's exciting to see the web platform continue to evolve and improve. Interop along with Baseline are aimed to solve some of the top challenges that developers have when building for the web.

Ultimately we only make progress as a platform when the major user-agents make shared and consistent progress on the platform and this has been a huge effort from the teams at Google, Microsoft, Mozilla, and Apple, not to mention Igalia and Bocoup as well as all the developers that have helped to prioritize what is important to them.

Here are the announcements from other browsers:

• WebKit
• Firefox
• Edge
• Igalia
• Bocoup

While I've been following the progress on Interop I hadn't noticed that they are looking at new areas of investment:

In addition, and as in previous years, there's a set of areas for investigation. These are areas where we don't have enough information or tests to include as a focus area, but the group feels some work should be done to get them to a stage where we can include them.

• Accessibility testing
• Gamepad API testing
• Mobile testing
• Privacy testing
• WebVTT

This feels like a good set of areas to focus on. I'm particularly interested in the Accessibility testing and Privacy testing. I think these are areas that are often overlooked and are critical to the success of the web platform.

Finally, I encourage everyone to look towards the tooling that is available because of the work that the Interop group is doing to understand all of the web-features and their availability across the platform.

You can follow along on the Interop 2025 dashboard at https://wpt.fyi/interop-2025 and as things become Baseline Newly available they'll show up in the Baseline 2025 list on webstatus.dev too.

This is such an amazing site and has become a bit of a daily habit for me. It's a brilliantly simple idea that means I'm browsing more of Wikipedia than I ever have before.

I built a similar demo a while ago using the now-defunct Portals API because I want to explore what a Web Browser could be if it had a UI like TikTok. My hypothesis was that while links are amazing, what is behind them is hidden, and worse (imo) it's behind a banner image that is often not representative of the content.

So the idea was that as long as you had a list of sites that you might visit it might be neat to have a way to flick between them quickly and get an idea if you actually want to dive into the content. The portals API seemed like a good way to do it because it could run JS, but was non-interactive and in theory privacy-preserving.

I adapted it in mid-2024 to use generated screenshots of the pages. I also thought I should give it a snappy name. Flick the Web's code is here and the you can play with the demo that runs over the latest articles on HackerNews.

I'm really glad that WikiTok did this and also it has been open sourced as I can totally imagine that this type of UI takes off on the web.

The web has always been a great place for me to explore writing and sharing my thoughts, and it was a large part in getting me a Developer Relations role at Google. This site is my own little corner of it that I can control. When I get the time, I try to write about things that I find interesting. You might find it interesting, you might not. I don't really mind, I just like to try and improve my writing.

I do get the occasional email from people who read my blog and they ask me how I write and edit my blog. I thought I would write a little bit about it.

My blog infrastructure is pretty simple. It's a mostly static site built with Hugo. I chose Hugo because it takes 3 seconds to build my entire site and I really value the rapid local building and near instant deployment. All of the other Ruby and JavaScript builders would take sometimes over a minute.

Because my site is not amazingly dynamic, I felt that I didn't really need Wordpress, but I did need a tool for editing.

The hosting is on Vercel, but I've no affinity for it. I just needed something that could host a static site and get it built and hosted in seconds (which Vercel does).

Because Hugo is mostly driven by Markdown I used a tool called SpinalCMS as my editor because it had a GUI and could import my archives, but there were a couple of bugs in it (It doesn't use a date format that works well with Hugo) and text editing (try delete past a paragraph). So I built a simple in about 30 minutes called... well, it doesn't really have a name it's just a URL https://blog-craft-editor-paulkinlan.replit.app/

The editor is just a static page that uses TipTap as the actual bit you write in (seriously, TipTap is a great editor API). I have some little bits around the editor that can load and save files back the the filesystem and suggest titles and descriptions, but that's it.

The only other thing is I have list of things that I've been meaning to complete. I may never actually complete any of these posts.

For the site itself, I really want to encourage people to speak to me, but there's not always a lot of engagement. I use commento.io and it works well.

And that's about it really.

In this post Addy describes his use of Cline (Jan 30). It was the first time I'd heard of it. I was kinda surprised because I've been on top of tooling for a while now.

For the longest time I'd been using Replit, it had a nice flow to it. I could ask it to help me solve a problem and it would just apply the code to the project. For me, it was a nice way to get things done.

I liked Replit, I built a lot of apps with it, however their hosting is expensive and their new checkpoint based pricing model frustrated me, especially when it made very clear mistakes.

At the time (like two weeks ago) Copilot didn't apply any changes to the code, it just suggested things which I had to then copy and paste... and even then the suggestions just weren't that good.

Cline has replaced both Copilot and Replit.

I don't mind paying for the use of an LLM and as noted by Addy:

I’ve also deeply appreciated Cline’s proactive accounting of cost during a session. This is most notable when switching between model providers:

I love that I can see where the costs are coming from. I can see how much I am spending on the model and how much I am spending on the compute. It's a nice touch.

When you add this with something else Addy points out:

The DeepSeek-R1 + Sonnet hybrid approach Recent benchmarks and user experiences have shown that combining DeepSeek-R1 for planning with Claude 3.5 Sonnet for implementation can reduce costs by up to 97% while improving overall output quality.

It's a pretty compelling solution.

My own workflow at the moment has be to plan with R1 (via OpenRouter) and then implement with Sonnet. I personally don't look at the costs, but I do inspect the output a lot and this has felt like a pretty good balance for my personal projects.

Based on my experiences with replit.com, websim.ai and a host of other tools, it feels like it's possible to convert a description of a site into a functioning experience. In fact, the more I play with this type of tooling the more I center on the importance of the specification of the thing you want.

For example, if I have the following prompt. I would expect a site with three pages, an index page, a projects page and about page.

The content will be about Paul Kinlan, a Web Developer and lead of the Chrome Developer Relations team. 

Headshot url: https://paul.kinlan.me/images/me.png

The site should have a marquee resume page that provides a summary of who he is.
An about page with contact details (Email: paul@kinlan.me, Twitter: @paul_kinlan)
A page about his project. It should have a list of projects:
 + reactive-prompt - https://github.com/paulkinlan/reactive-prompt - prompts that react to changes.
 + f - a LLM to JS library - https://github.com/paulkinlan/f
 + reactive-agents - https://github.com/paulkinlan/reactive-agents - build agents that react to input

Maybe something like this to should be created.

Oh!

https://github.com/PaulKinlan/AiWebForge is the tool that i've built that takes a prompt and creates a runnable site. The theory is that there should never be any manual changes to the server, it should all be specified and defined in a prompt.txt file.

One thing that is working quite well is as the site and the content is fetched and LLM'd into existence, it's then used as context for future requests. This then helps with consistency of things like styles across the site.

What I like about this is that I can very rapidly iterate on ideas, and for the most part the output is what I want.

Now, don't get me wrong there are lots of issues with this right now:

• It's not super quick, so I wouldn't really want to serve this. On the first run for each file it has to pass the entire site through the LLM.
• It doesn't reuse as much shared logic from other files
• While the data is cached, once its evicted from the cache a subsequent fetch could render completely different content
• I ask the LLM to create accessible content and follow best practices, but does it?
• What are the energy cost to generate this? I can't work that out and I don't know if it is more or less than the energy requirements of the people building sites
• It doesn't yet support server side logic, so you can't have a form that posts to a server

Thinking further on that last point and the work that I did on Runnable JS functions from a prompt, I would love to be able to introduce server runtime functionality. If the site needs a web-form, can we describe what the site needs to collect and how to store it and when the site runs it will just auto-generate the functionality (correctness aside :))

I really like the concept that Ben Thompson talks about (mostly in the context of VR) of just-in-time UI, there's a world where this type of tool could be useful for building a simple UI that gets a very simple task done at run-time.

If you get chance, have a play and let me know what you think.

There's obviously a lot of push back on LLM's be it what they were trained on and how much energy they use. However the technology is here, and Dion poses a great question: Will natural language become the way people control their computers?

Two things resonated with me:

The reason that we see so many applications pop up with a chat side bar is a signal that we are building bridges between the computers and the humans in natural language ways.

and

Future: your English is the source, and as your computer systems improve, they can be regenerating new and improved implementations. It behooves you to invest in testing and validation in this world, but this is something that is actually really needed any way… we just sometimes get away without doing it.

I maintain a list of apps that I'm happy for people to use. I've also got a huge list of disposable apps that I've built for myself. I'm pretty certain that "natural language" as the main development language will happen at some point and as it developes millions more people will have the ability to control their compute in ways that echo how Spreadsheets enabled people to manipulate their data in their businesses.

Dion centers some of his discussion on Chat-first vs Spec-first. I agree that the Spec is important, I just don't know how this part will develop. Do we develop the spec completely up-front, or is there a chat-like assistant that accretes the spec as we develop. I'm thinking the later, I can imagine a world where we have a set of critics that attempt to objectively look at your spec and tell you what's missing or what could be developed further.

While Quake is something I still love to bash on once in a while, the Web and Email are the two main technologies that are still pervasive in my day to day life.

When people ask me what I do, firstly it's a bit hard to say "Developer Relations manager" and have anyone know what that means. So I say that I'm a Web Developer or Software Engineer, and while it's true and I still build a lot of sites, a huge amount of my time is spent in email.

The Web and Email are both the technological basis for my career to date. Yes, I have to deal with huge amounts of SPAM. I get unearthly amounts of mail from my colleagues and I still struggle to manage my inbox (Anyone want to subscribe to my "Inbox 9000" course?)

I might be alone in this, but one of the ways that I "browse the web" is not inside a browser but inside my email. I get hundreds of Newsletters (Substacks and otherwise) a week, each providing content that I find valuable that is hosted on a URL, but is completely undiscoverable by things like search. While I still love RSS, email is the only way that I am getting this information in a unified interface.

I always liked email as an interface for performing actions too. It's asynchronous nature is built in to how we expect to use it and you never know if there is a person or a machine on the other end of the email address. Over the years I've built some basic services, but more recently I've been on a bit of a rampage. I've built services that Summarize the newsletters for me; provides a critique of the email; generates images based on a subject; Sends newsletters and PDF's to my reMarkable; A service that fetches web pages for me; A service that reminds me at certain times... the list goes on.

While I build these tools, I just don't see many services built on the back of email as an interface. Friendfeed was one of the first services that I vividly remember letting you perform actions via email and Google App Engine also had an inbound email handler (long-since deprecated), there are perilously few services that I can find that are built off the back of this communication modality. Yes, there are ticket systems for support etc, but outside of that we tend to focus our UIs' on Apps and Sites. (If you know of any services that use email as their input mechanism, leave a comment).

I think the issue stems from two things:

1. There's just not many services that do inbound Email->Webhook. I was sad when Google App Engine cancelled their inbound email service. I did end up using SendGrid, and it's... fine.

2. Munging text and extracting meaning from that text has been almost impossible.

I'm hopeful with the progress in Large Language Models we might just be able to see more services use email as the primary interaction modality. Both from a text processing side, to also performing actions based on the content. Some people might say this is Agentic (email's very asynchronous model helps a lot - send an email, some action is performed by a machine or a person, and the result sent back)... Actually, I do too. I don't understand why we sit watching text stream in over a chat interface, I personally just want to fire off an email and get a result as I get on with my day.

I'm also hopeful these types of tools will get easier to deploy too. val.town is an amazing service and has the concept of inbound email "vals". Vals are small chunks of TypeScript/JS attached to an email address that when emailed will run. It's really that simple. It's beautiful in fact because it's instant to get it hosted.

Combining both LLM's and the ease of deployment, I do hope for a world where email becomes an even more useful, open, cross-platform tool for discovery and action.

I saw The success of Interop 2024! in Stefan Judis's Web Weekly Newsletter.

Jen Simmons at Apple on WebKit pulled together this great post about the progress that has been made in 2024.

In 2024, there were 17 such focus areas: Accessibility, CSS Nesting, Custom Properties, Declarative Shadow DOM, font-size-adjust, HTTPS URLs for WebSocket, IndexedDB, Layout, Pointer and Mouse Events, popover, Relative Color Syntax, requestVideoFrameCallback, Scrollbar Styling, @starting-style & transition-behavior, Text Directionality, text-wrap: balance and URL.

The value of Interop is so important. It's the reason that the web has been so successful. It's the reason that we can build things that work across all devices and all browsers. It's the reason that we can build things that work for everyone and I'm grateful for the collaboration between all the browser vendors on this.

We just have to be careful to say "the web is XX% interoperable" when the data in the interop project is a percentage of the shared focus areas, not of the entire platform. The dashboard is pretty clear, the actual situation of wider interoperability has a long way to go.

Either way, we should celebrate this progress. The web is getting better.

I really like Simon's approach to running a link blog and his principles really resonate with me

I always include the names of the people who created the content I am linking to, if I can figure that out. Credit is really important, and it’s also useful for myself because I can later search for someone’s name and find other interesting things they have created that I linked to in the past. If I’ve linked to someone’s work three or more times I also try to notice and upgrade them to a dedicated tag.

Lifting people up is something that I've always valued (and valued when folks did it on my content). I probably lost my way at the start of my DevRel career - parts of the DevRel job ladder include being Industry influential. I took that to mean being an expert in web development and while I think I'm reasonable and I've built a great team, I love seeing other people succeed and I love sharing their work.

I try to add something extra. My goal with any link blog post is that if you read both my post and the source material you’ll have an enhanced experience over if you read just the source material itself.

This was actually something I struggled with in my first iteration of my link blog. I'm still not sure I can always provide more value than the original author but also I have a hunch that linking out of sites is a dying art.

Simon also had a bit about the technology behind his link blog:

The technology behind my link blog is probably the least interesting thing about it. It’s part of my simonwillisonblog Django application—the main model is called Blogmark and it inherits from a BaseModel defining things like tags and draft modes that are shared across my other types of content (entries and quotations).

This blog is entirely static (Hugo) and I've been butting my head up against the wall. Static is neat, but it's not enough. If you want to add Activity Pub, well you have to bend Hugo a long way. Add a link blog? Well, that's not too hard given it's structure but it also means having to make a full git-commit to the repo, and this was something that slowed me down last time.

I've been creating a fair number of web-apps with Replit. These "agents" are awesome, they take me through the entire app process. But what if I just want a small bit of my application written in English? How far can we get?

f is a small JavaScript library that I've created to play around with the idea of programs defined with natural language.

const isOdd = await f`is a given number odd?`;
console.log(isOdd(101))

Fun! who needs npm when when you can use an entire LLM to determine if a number is Odd or not :D

It can get a fair bit more complex. How about fetching data from a URL?

const spaceData = await f`fetch JSON from https://api.spaceflightnewsapi.net/v4/articles/`:
const news = await spaceData();

This will (in most cases) create a function that will fetch and return the data from the given URL.

Wouldn't it be nice if we could create a URL from this data?

// Describe the data structure so the the UI prompt has a better idea of what to build.

const schema = await f`Return a JSON Schema for a given object. The schema should be in the format defined in https://json-schema.org/understanding-json-schema/reference/object.html and should include all the properties of the object. The schema should include the type of the property, the format of the property, the required status of the property, and the description of the property. The schema should include all the properties of the object. The schema should include the type of the property, the format of the property, the required status of the property, and the description of the property.`;

// Describe the data
const schemeDescription = schema(spaceData);

const spaceUI = await f`Using the data defined in <output> create a UI that will best display the space flight information. The developer will provide the data as a parameter and it will be in the format defined in <output>.
    
<output>${JSON.stringify(schemeDescription)}</output>`;

document.body.appendChild(spaceUI(spaceData));

Fun!

I don't know if this is the future. You are heavily reliant on the LLM being good (Claude has consistently good results) - Gemini Nano and Code Llama struggle to generate valid results. Outside of simple functions it's also hard (for me) to get consistent results, so each time that you run the function it might produce a different program.

Full example:

import { create } from "@paulkinlan/f";
import {
    prompt,
    ClaudePromptConfiguration
} from "@paulkinlan/reactive-prompt/claude";

const config = new ClaudePromptConfiguration({ debug: true });

config.dangerouslyAllowBrowser = true;
config.key = window.prompt("API Key");

// Because we can use many different LLMs we need to pick one.
const f = create(
  prompt,
  config
);

const fetchNews = await f`fetch JSON from https://api.spaceflightnewsapi.net/v4/articles/`;

// Get the news.
const news = await fetchNews();

// If we can describe the object UI gnereation is a bit easier.
const schema = await f`Return a JSON Schema for a given object. The schema should be in the format defined in https://json-schema.org/understanding-json-schema/reference/object.html and should include all the properties of the object. The schema should include the type of the property, the format of the property, the required status of the property, and the description of the property. The schema should include all the properties of the object. The schema should include the type of the property, the format of the property, the required status of the property, and the description of the property.`;

const schemeDescription = schema(news);

const spaceUI = await f`Using the data defined in <output> create a UI that will best display the space flight information. The developer will provide the data as a parameter and it will be in the format defined in <output>.
    
<output>${JSON.stringify(schemeDescription)}</output>`;

document.body.appendChild(spaceUI(news));

Code is here - give it a go and let me know if you have any questions or ideas how you might use this (or not use it)

I really wanted a way to get quick summaries of the newsletters I read, so I built one. Val.town is an amazing platform; you can quickly create an HTTP endpoint, a cron job, or an email handler and publish it to the web in milliseconds.

The email handler alone is incredibly powerful, it's something that App Engine used to do and you can do with SendGrid if you have the time to set it all up. With val.town, it's just a function and deploy.

Send an email to paulkinlan.emailSummaryHandler@valtown.email, and in a couple of seconds, you'll get back a summary of its contents.

Given the asynchronous, text-based nature of email, I'm surprised there haven't been more tools built that interact with it using LLMs.

https://full-rss.deno.dev was created to partially solve this. If there is a feed that you really wish was full-content and isn't then you can replace that feed with https://full-rss.deno.dev/?url=https://developer.chrome.com/static/blog/feed.xml and it will get the 10 most recent posts, scrape the linked page and replace the content with a stripped down version of the full HTML page.

There are some caveats though:

1. if the feed is an ATOM feed it will accept it but the output will be RSS.

2. if the linked page uses JS to render content, it will not be included. I didn't want to spin up a puppeteer instance

3. if a post is updated after the entry has been fetched and parsed by a user it will not be fetched again (I need to work something out here)

Source: https://github.com/PaulKinlan/full-rss

If you are interested in how it was built, here is a rough outline. It uses Deno and Deno Deploy. On the first fetch of a post the system hasn't seen before it will fetch the html, convert it to markdown and then gzip compress it so it can be stored it in Deno KV and not breach the 16kb limit. Then for each entry it will pull the content from the Deno KV store, decompress it and render to HTML.

Last week on the train back from London I embarked on my largest project yet, https://tldr.express. I've been amazed by Agents like https://replit.com/'s that can scaffold out full working experience that have user account registration and deploy in minutes. But how far can I push it?

I love blogs. It's one of the reasons that enabled me to get in to Developer Relations. I could connect with people and learn from them and I could share my own learnings (I think I've helped folks)... When I was younger and the blogging scene predated social media, I would trawl Technorati trying to find new feeds and I would refresh my feeds every hour to see if anything new had been posted. Alas, times change, my own time to consume content is getting limited but I still try and make sure that I can track what web developers in the community are creating.

tldr.express is a site meant just for me (but anyone can use it) that tries to create a dashboard of the feeds that you care about the most and send you a summary every morning. It's a tool that I've always wanted. But this isn't the important bit.

I was amazed how far my first prompt got me.

It created this plan which looked decent.

It scaffolded out a system that would let me register a user, add feeds and have it summarize the content and display them in a nice overview.

It wasn't all plain sailing.

• The email didn't work, I don't want to think about SMTP etc. Huh. You know, I didn't specify it. Please use resend.com (boom!)

• It kept asking to use Open AI... Huh. You know, I didn't specify clearly to use Gemini (long context windows and price)

• It output raw markdown in the UI. Huh. You know, I didn't specify clearly what the output should look like.

• It displayed in processing order and not date of creation.. Huh You know...

All of this without me touching a single line of code. After a day of use, I realised that if anyone found this site and signed up with an email address, it would be easy for them to spam folks. I probably should have specified that we need to validate email addresses.

... and it worked pretty much straight away.

On monday this week I thought I would check the user database... wow 50 sign-ups. That's weird the usernames are random.... Bots! Hmm I probably should have added something like Recaptcha in to validate.

Now the bots have stopped.

Reflecting back on this project, as spent a couple of hours prompting replit and configuring services like Google Cloud and Resend, I noticed that configuration more than I did the prompting, and it hit me that I was building the spec I was going along... My chat log is the development of what I probably should have thought about at the start. I have a strong sense that as these tools develop, while it's mind-blowing that we can use a pithy one-line prompt to generate an entire app, we should be spending a lot more time up front designing the spec so that we are able to get further and more accurate output.

I added some middleware to my site to log the user agent of every request while using Vercel's KV to store the user agents and their counts.

If you are interested in the code, the middleware and the api are both on GitHub.

User Agents in the last hour

Following my focus on Generated Web Apps where launch sites and services without touching a single line of code, I decided to build a simple service that didn't require anyone to sign-up or sign-in, but could also share the time with their friends and family.

https://countdown-timer.replit.app/

I'm pretty happy with the output. Earlier versions used Dall-e for the background image, but the quality wasn't that good. I replaced it with Black Forrest Labs' API which I think creates far better images. Black Forrest Labs has an API with an OpenAPI spec, but they on don't have any generated client libraries which I thought was going to be an issue. Nope. Replit's Agent could take the OpenAPI spec and directly implement the code to request the image and poll for the response. My mind was kinda blown by this.

The source is here if you are interested: https://github.com/PaulKinlan/CountdownCrafter

I've a hypothesis that something like these Agents will be how we build software in the future, so as I build these apps I try to never adjust the output, I want to see how far that I can get with the machine creating all the code and so see how far away we are from this future.

Replit has been my current tool of choice because while it's a normal IDE, the "Progress" view gives me a diff of all the changes it has made for the current prompt. Because in the most part I know what I am doing I can quickly see if the software has made an error and correct it.

As I watch the code pass by in Replit, I'd noticed that the Python and JavaScript it produced was vanilla and it would frequently duplicate the logic on different screens for the same functionality. It certainly wasn't that type of code that I would craft. I probably would have planned for the removal of repetition. I would have planned for the ability to extend and inherit. I would have planned for testability. Other than the Flask backend, it didn't use any other Frameworks.

Frameworks are abstractions over a platform designed for people and teams to accelerate their teams new work and maintenance while improving the consistency and quality of the projects. They also frequently force a certain type of structure and architecture to your code base. This isn't a bad thing, team productivity is an important aspect of any software.

I'm of the belief that software development is entering a radical shift that is currently driven by agents like Replit's and there is a world where a person never actually has to manipulate code directly anymore. As I was making broad and sweeping changes to the functionality of the applications by throwing the Agent a couple of prompts here and there, the software didn't seem to care that there was repetition in the code across multiple views, it didn't care about shared logic, extensibility or inheritability of components... it just implemented what it needed to do and it did it as vanilla as it could. I was just left wondering if there will be a need for frameworks in the future? Do the architecture patterns we've learnt over the years matter? Will new patterns for software architecture appear that favour LLM management?

I dunno know, but it will be a lot of fun to find out.

I first started out on kinlan.co.uk which was powered by Blogger and the FTP deploy. I had a brief foray in to posterous (I liked the idea of email publishing), and then settled at some point on paul.kinlan.me and Hugo (I think i also used Jekyll at some point).

Looking back through my archives, I've written some really rubbish things.... I was alway terrible at spelling and grammar. But they're my things, and I like that.

I can also say that I wouldn't be doing what I do today without my little place on the Internet.

The web is my home and I hope I can help it stay everyone's home in the future. I'm thankful to Sir Tim Berners-Lee for inventing this thing and all the people that have built on top of this platform to make it what it is today (warts and all).

For as much as possible, I try not to change any of the code.

Repl.it

• Image Analyzer [code] - I sometimes need to extract information from images and I just wanted a tool I trust (and also see how well it works with Google Cloud APIs - quite well)

• TimeZone Tracker [code] - This is simple tool that lets me set up time zones so that I can plan meetings. There are sometimes that I had to step into intervene, like when I asked it to make it a PWA and it kept auto generating the icons (I had my own), or when I couldn't get the log into persist (turns out it was the WebView iframe)

• Rude name checker - I've launched products that have names that might mean something rude in another language. I just wanted to see if I could build something simple that might help people. I still remember launching FriendBoo and being told that in some languages Boo is the sound of a fart!

• Image Generator from Prompt in a URL - I really like placekitten, where you can just put in url and get an image. I hadn't seen anyone create a thing where you include the URL + prompt and get an image e.g, https://image-gen-paulkinlan.replit.app/generate/a+beautiful+landscape+with+mountains+and+a+lake (presumably, because it costs money)

• BloodPressureTracker [code] - A recent health scare has made me need/want to track my blood pressure. I'm not ready to use a full app yet, so this simple interface works for me. It's more robust than a spreadsheet.

• Media Logger Extension - This is a Chrome Extension that records when the user navigates to a page with Audio or Video media and allows you to go back to it and interact with it. I'm a visual and aural person so I wrote this because I frequently want a simple way to quickly discover embedded podcasts or videos and quickly get back to it.

• The Critic v2 [code] - I converted my original "The Critic" that was written with Breadboard to one that was built entirely by the Replit Agent. It's a lot more comprehensive, it includes account management, templates and histories.

• Countdown Timer [code] - I'm taking my parents on a trip to Japan and I wanted a simple home screen installable web app that lets me configure a countdown timer and share it quickly and easily.

• tldr.express - Daily RSS summaries

• SendVia.me [code]- A service that allows you to send PDF's directly to your reMarkable

• blog-craft-editor-paulkinlan.replit.app [code]- a simple UI for editing my Hugo based Blog.

A general note, repl.it seems to prefer Python, Flask and sqlite. It's not the end of the world with regard to Python and Flask, but I don't quite understand why it prefers sqlite, as I understand it, every time you deploy it will overwrite the sqlite file, which seems sub-optimal. I prefer to use postgres and I've been delighted with the agents ability to migrate databases.

WebSim

I really like Web Sim for just spending time browsing around things. I think it highlights the power of the web, in that anyone can create something interactive and just publish out there.

• 3d globe - One of our first webgl demos was a spinning globe with pins on it. I wanted to see if it could do this.

• Lake Toya - I was showing my wife how easy it would be for us to create a site about a recent trip that we had.

• 2d Space Gravity Simulator - Something that I always wanted to build but never had the time.

• 3d Space Gravity Simulator - I wanted to see what o1-preview could do, it was based on the 2d version.

My dad saw this and suggested that I actually learn to program, in fact I should look at loops and variables... I had no clue what he was talking about.

The magazine ended and a while later I got access to the Amiga 500 because my dad upgraded to a 386DX66. With access to this Amiga, not only could I "swap" disks with enthusiast in the Birkenhead computer club, I could see that people were making demos at the start of these disks... Many of these disks had the name "Pirate Pete" bouncing around the screen in ways that I'd never seen before. I can do that! and before long I found a little window in Workbench that said "Basic" and much like today, I thought maybe if I just mash my hands in style on the keyboard I would get a game out of the back of it.

I don't know why, but it didn't work. But by then Amiga was not much in my mind, I saw a new demo called DOOM and it looked awesome.

At the same time in high-school, our advanced suite of BBCs and Nimbus's (Nimbusi?) didn't fulfil me. I could see some kids writing BASIC to change the sides of the screens, and my friend Bob had written his magnum opus: "Bird pooh's", and I still didn't get it.

One eventful day on a school trip in Chester, by the River Dee there was an arcade where I saw Streetfighter II, and things clicked. Movements of the joystick and buttons would change the state of the program and the graphics. I'd have to loop around a lot of times to keep thing going... Hey, I knew how DOOM worked too...!

By fortune, my grandfather was a tinkerer. Heswall Computers sold him a top of the line 286 (don't ask...) that had QBasic on. My grandad had a problem. He couldn't pick his National Lottery numbers, and so was born my first actual computer program (btw - I nearly quit because I had no clue our chums in America spelt colour incorrectly).

From then until now I've spent huge amounts of time building software for businesses and myself. I tinker. I learn. Software let's me do mostly whatever I want.

What does this all have to do with "the disposable web" I hear you ask?

A lot of the software I've written in my life has been for me and only me. While I've improved my skills a lot of these things still take quite a lot of time to build and so there is always this thing that stops me starting.

Well, I'm back to mashing my hands on the keyboard but this time actually getting things out of it. I wrote the other day about websim.ai and this week I've been playing with repl.it's agent and I was able to build a full-stack application that is a PWA, with a UI, authentication, a Python back-end and a Postgres database that I can deploy with one-click, all in about one hour.

Scott Jenson and I were exchanging a chat on mastodon and he said the exact same thing that I was thinking:

"@paul that's what I'm using llms for these days. I'm actually writing all sorts of little web pages that I could do myself but I just wouldn't bother. They're just so easy to put together in minutes and then just throw them away."

Tools like websim.ai and repl.it are enabling me to create the things that I need and I've always wanted but didn't feel that I had the time to do... But what happens to that software? Do I scale it? I don't necessarily want other people to use the tools, they're really just meant for me. Maybe they will be useful.... It's not something that I always want to think about.

When I hand make something and put time into it, I have an attachment to it. I don't want to lose it. Maybe it's a sunk-cost fallacy thing, or just my ego... When I prompt it.... It doesn't matter, it's disposable.

I really believe that we're at a point where software can be disposable. You can now write once, run everywhere once, and that's ok. And for me the web is the best platform to do create and run software on even if it is only just for me.

This new tooling is stopping me from stopping starting.

ps - I know there's a lot of preamble, but that history of Paul has been on my mind for a while and I wanted to get it out.

I spent the evening exploring a web that is full of applications and sites and only limited by URLs that I could think of (heh - this web never has a 404 or an unregistered domain). WebSim provides a simulation of the web via a faux Web Browser. It's a web that doesn't actually exist, but one that works incredibly well. I obviously went to my site first (note - I re-did this when I published it).

I then created a clone of everytimezone (I needed to arrange a meeting in the NYC and Mountain View)

And then I built an interactive globe showing population of some major cities

And then I wanted to see if I could create a simple site for a trip to Toya in Hokkaido

My wife and I created a site that showcases the beauty of North Wales to a Japanese audience (we didn't publish it)... and I just explored and explored. I played with simple games, interactive experiences, I even got on a plane.... It's like the Web's Roblox.

The entire evening reminded me of when I first discovered blogging and would just go from site to site, reading and playing with the things people built and just having a lot of fun. On one hand this was demonstrates an entire virtual world that I just got lost for hours in this new virtual world, on the other the fact that entire sites and functioning games and apps work is just mind blowing.

I really do encourage everyone to try and play with https://websim.ai even if it takes a little while to get the hang of the UI for generating sites.

SELECT
  COUNT(*)
FROM
  `httparchive.response_bodies.2024_08_01_desktop`
WHERE
  url LIKE '%manifest.json'
  AND response_body LIKE '%"short_name": "React App"%'

There are 551037 urls that end 'manifest.json' and 22303 of those manifest files have the default manifest file generated by Create React App.

It's probably worth exploring how many manifests are the default manifest created by build tooling.

An Agent is a tool that given an input and a way of working will try to perform all the actions needed to complete the task. reactive-agent is my first attempt at a toolkit for building browser-based applications with Agents using Chrome's prompt API.

The general gist is that each "Agent" has a persona (How it should think or act), a task (What the user needs it to do) and a context (That data that it should work on). Once it is supplied with data it should try to run to complete the task it was given.

In this framework, each Agent will only run (or react) when their input changes. This allows you to chain the output of one Agent into the input of another and build complex chains of agents that might only partially update as the state of the application changes.

import { effect } from "@preact/signals-core";
import { Agent } from "@paulkinlan/reactive-agent";

const interviewer = new Agent({
  persona: "You are a pirate and you speak like a pirate",
  task: "You need to find out how old the user is"
});

interview.context.value = "Paul Kinlan";

effect(() => {
  // This is where the agent starts to get resolved.
  console.log(interviewer.response.value)
})

This Agent isn't particularly useful, all it can do is come up with a question. So once the agent has decided on a question, you need to get an answer from the user. This is where the Human Agent comes in. In the code below we are connecting the input context of the Human to the output of the Pirate Agent.

import { effect } from "@preact/signals-core";
import { Agent, Human } from "@paulkinlan/reactive-agent";

const agent = new Agent({
  persona: "You are a pirate and you speak like a pirate",
  task: "You need to find out how old the user is"
})

const human = new Human({});

effect(() => {
  human.context.value = agent.response.value;
});

effect(() => {
  console.log(human.response.value)
});

agent.context.value = "Paul Kinlan";

The Human agent is a representation of the user in the flow of data through the Agent. The more important part of this is we are chaining the output of one agent into another.

A more interesting Agent would be one that perform actions, or more specifically can call existing JS functions. A Tool calling agent can work out which function to call and what parameters to provide based on the input context.

In this case, the persona and task are pre-configured and can't be changed.

import { effect } from "@preact/signals-core";
import { ToolCaller } from "@paulkinlan/reactive-agent";

const toolCaller = new ToolCaller({
  tools: [
    {
      func: function getWeather(location) { return `It's Hot in ${location}`; },
      description: "Get the weather for a given location"
    },
    {
      func: function getTime(location) { return Date.now(); },
      description: "Get the time for a given location"
    }
  ]
})

effect(()=> {
  // Log the result of the function call.
  console.log(toolCaller.context.value)
});

toolCaller.context.value = "What is the weather in London?";

This project is just an experiment, and like with Breadboard, I love the idea of describing LLM based applications as graphs of data-flow. This might not be the way to build applications in the future, but it feels pretty powerful. I also think that Preact's Signals (well, Signals in general) are an incredibly powerful mechanism for managing data flow in an application and they don't have to be used just for updating UI.

I thought it would be neat to experiment with:

1. Prompt responses should rerun (aka react) as the inputs to the prompt change (like a Web App with React)
2. You should be able to chain responses easily, that is the output of one response can be used in another prompt.
3. It should integrate with Chrome's (very experimental)

Preact's Signals seemed like an ideal way to manage this.

The reactive-prompt library exports a single function called prompt. It's a tagged template literal which allows you to substitute any variable including Signals. When a Signal is referenced and updated, it's prompt will be recalculated.... and now we have reactive prompts.

Simple Demo

import { prompt } from "@paulkinlan/reactive-prompt";
import { signal, effect } from "@preact/signals-core";

const name = signal("Paul");

const response = prompt`Say "Hello ${name}".`;

effect(async () => {
  console.log(await response.value);
});

setTimeout(() => name.value = "Serene", 2000);

Prompt Chaining

You can chain multiple prompts together, that is the output of one prompt can be the input of another prompt. For sufficiently complex data flows this means that you only the prompts that need updating will be re-run.

import { prompt } from "@paulkinlan/reactive-prompt";
import { signal, effect } from "@preact/signals-core";

const nameSignal = signal("Paul Kinlan");

const prompterSignal = prompt`Using "${nameSignal}", extract the following data:

+ First name
+ Surname
+ Date of Birth

Return as valid JSON
`;

const uiBuilderSignal = prompt`You are an expert web developer, and you have been tasked with creating a form for a client. The form should have the following fields: "${prompterSignal}".

Return the required HTML for the form only and populate the default values.`;

effect(async () => {
  output.innerHTML = parseCodeFromMarkdown(await uiBuilderSignal.value);
});

setTimeout(() => name.value = "Jack Jones, 18th May 1967", 5000);

Chrome's experimental prompt API

This library relies on Chrome's experimental prompt API.

To use this, you need at least Chrome 127 (Dev Channel) and to enable the following flags.

• chrome://flags/#prompt-api-for-gemini-nano
• chrome://flags/#optimization-guide-on-device-model "Enable Bypass"

Then go to chrome://components and click "Check for updates" on "Optimization Guide On Device Model". After some time the model will be available.

What about other prompt APIs?

The prompt tagged template is just built for Chrome's prompt API, but there is nothing stopping this being being ported to other APIs like OpenAI or Gemini's REST APIs.

You can find the code here and if you are using breadboard you can install it as npm i @paulkinlan/transformerjs-breadboard-kit

To create an Breadboard agent you can do it as follows:

import { board } from "@google-labs/breadboard";
import { sentiment } from "@paulkinlan/transformerjs-breadboard-kit"

export default await board(({ text, model }) => {
    text.isString();
    model.isString();

    const summarynode = transformersjs.summarize({
      $id: "summary",
      input: text,
      model,
    });

    return summarynode.to(base.output());
  }).serialize({
  title: "Summary board",
  description: "Runs the summarization analysis with transformer JS",
  version: "0.0.2",
});

I spend a lot of time reading proposals for new APIs and initiatives and then providing feedback to the authors to help them make sure that they work well for the ecosystem. A lot of the feedback follows a pattern of "Have you thought about X?" (in many cases people have, but it's just not mentioned clearly in the text)

I wanted a tool that would help me critique articles, Web specs and API explainers from a variety of different perspectives and help me to provide feedback to the teams writing them so that they can be improved.

The Critic is a basic UI that lets you configure a number of "agents" who take on a persona whose job it is to read the input text and provide a generated "interpretation" of the text with areas that should be addressed.

It's also not doing anything that you can't do with an LLM already (i.e, adding preamble to your question like "You are an expert in Web Accessibility"), but it adds a small layer of convenience over an LLMs UI by making the requests for each expert agent at the same time and then creating a report at the end (note, the full report is in the console, but each Agent will have a response).

The UI is very rough, but the tool works pretty well. It's built using Breadboard (again :)) where a Critic is defined as a board and the Panel board will map the list of inputs against each critic and article pair.

At the end of the day, it's an LLM, it doesn't replace what people are supposed to do or absolve the authors from thinking about the critical areas up front, and likewise, just because an LLM doesn't reply with something doesn't mean the input is perfect either. I found it useful for starting conversations though.

In August 2023 I built this "tldr-site" as an experiment to see if I can get useful information out of the summaries provided by search and news feeds, with the goal of giving me a high-level overview so that I can then go and deep dive into the actual results.

• Summarize a search

• Summarize the News

I use this quite frequently, for example I needed to get a quick overview of what people thought of the Web Environment Integrity API so that I could make some recomendations internally.

The Code uses Breadboard as the engine to manage the flow of data through the query to the Google Search API or the News feeds and then on to the LLM.

It works pretty well, but clearly it doesn't have enough context because the snippets in search and news are very limited. A future iteration of this would go and fetch the articles in returned for each result, add that to the context and summarize the results.

• Removed the journal - I stopped personal journalling in the middle of the year (I still do it for work) - I don't think there was a huge amount of value in the bulleted lists for everyone else, so I've removed it from the blog.

• Added projects to the RSS feed. I've had a pretty productive end of 2023 and I did a lot of work related to Generative AI, and I'd like to share them a little more broadly.

... Also, Happy New Year, while I have you reading this.

It offers just one node: generateCompletion.

You can integrate it into your breadboard runtime by adding it as a kit using addRuntimeKit(Claude) and then reference the generateCompletion node.

I built this tool because as part of a DevRel team it's important to understand how the people that we work with (developers) feel about our work and the platform as a whole. It can take a lot of time to go through each of the comments to understand what the issues are, so I built this tool to help me find the most important comments.

This tool isn't a replacement for spending time in the ecosystem and understanding needs, but helps to identify critical challenges and how teams might address them.

The UI is a simple Hugo static CMS. The Generative AI is managed by Breadboard (a project that I work on) and Anthropic's Claude using the Breadboard "Claude Kit".

I like to experiment and break new mental ground, so when I saw that Chat GPT had a code interpreter, I was was interested and yet had no clue what I would do with it.

I had a bit of a think, and my side-passion is querying the BCD (Browser Compat Data) project for interesting information. BCD is a repository of features that are available to web browsers and their availability in them, for example: CSS Grid and Flexbox support.

The BCD project is accessible as a large JSON file and in many previous projects I create scripts or websites to parse the data, for example:

• BCD Training (source) - a web page with human readable versions of the data so it can be used in the LLM attached to Ask Paul

• Time to Stable (source) - a web page that finds interesting stats about feature availability across browsers. Which browser is a sprinter and which is a plodder? or Which APIs are experimental, etc

• Baseline (source) - a web page that lists all the APIs that came to a the web in a given year. I use it to get a picture of what the Baseline project might look like each year

These projects can take a little while to create as I build a parser and display logic and then a website around it. I thought it might be neat to see if the Code Interpreter could take some of this burden off me.

TL;DR - It can.

I'm very interested in Browser velocity, that is how quickly do browsers update, so I wanted to see if it could build some tools to analyse this data.

First up, I downloaded the JSON file and uploaded it to the new Chat GPT model.

I know the file format so I had a bit of head start, so I asked it something simple. "Find me the most recent versions of each browser."

It's wrong, but it's kind of incredible to watch it build the code that parses the file format and produces something that could work.

I suggested that it was wrong because Chrome is already a different version

It was incredible to see it adjust the algorithm to change how it parses the version number, however it was still wrong because it was showing future versions of browsers that haven't hit stable yet, so I simple suggested an improvement "Close, but some of those have a 'release_date' after today. Can you get only the latest released versions of the browsers?"

Damn!

All in all it's pretty great. Something that would have taken me about 30 minutes to make was created in about 2 minutes and a great thing is that it has the script so that you can run it locally too.

Yes, technically there are some errors for example if you check the code below you will see it tries to convert the browser version to an integer, yet some browsers have x.y.z versioning.... Yet, I'm still blown away.

from datetime import datetime
import json

# Load JSON file
with open('/mnt/data/data (1).json', 'r') as f:
    data = json.load(f)

# The issue might be related to the version numbers being treated as strings rather than numbers.
# This can result in "99" being considered larger than "110" because "9" is larger than "1" in string comparison.

# To fix this, we need to convert the version numbers to integers where possible for the comparison.
# However, we need to handle cases where the version number is not a simple integer (e.g., "9.3.0").

def convert_version_to_int(version):
    # Try to convert the version to an integer
    try:
        return int(version)
    except ValueError:
        # If that fails, convert the first part of the version to an integer
        try:
            return int(version.split('.')[0])
        except ValueError:
            # If that still fails, return the version as is
            return version


# Function to convert a string to a datetime object
def convert_string_to_date(date_string):
    return datetime.strptime(date_string, "%Y-%m-%d")

# Get today's date
today = datetime.now()

# Let's inspect the 'browsers' key
browsers_data = data['browsers']

# Initialize an empty dictionary to store the most recent version of each browser
recent_versions = {}

# Loop over each browser
for browser, details in browsers_data.items():
    # Get the 'releases' field which contains version information
    releases = details.get('releases', {})

    # Filter out versions where the release date is in the future
    releases = {version: details for version, details in releases.items()
                if 'release_date' in details and convert_string_to_date(details['release_date']) <= today}

    # Convert the versions to integers where possible
    releases = {convert_version_to_int(version): version for version in releases.keys()}

    # Get the most recent version
    recent_version = max(releases.keys(), default='No releases found')
    # Map the recent version back to its original string representation
    recent_version = releases[recent_version]
    recent_versions[browser] = recent_version

recent_versions

Absolutely amazing! I think the summary is great too. The only nit right now is that the colours are hard to distinguish.

It kept all the context amazingly well, but as I was reading this, but the IE outlier make it hard to see what's happening today, so I asked it to "Remove some of the outliers"

Much clearer, but also WOW! Just by looking at the data there are stories that I can see :D

I'm not sure this post does my reaction any justice. I was completely blown away! Yes it's not an amazingly complex example, but I got to an output that I found incredibly useful in minutes and it's now left me thinking what else can I do with it.

If you are interested in the final code it generated check out this gist.

Let me know if you've played with the Code Interpreter, I'm certainly keen to learn more about how you are using it so that I can work out where I can take better advantage of it.

The other week I spent some time building "Vector IDB" (source) as an experiment for making something similar to the structure that Pinecone has. The API surface is relatively plain, there are all the standard utilities: insert, delete, update, query and they can be used as follows.

import { VectorDB } from "idb-vector";

const db = new VectorDB({
  vectorPath: "embedding"
});

const key1 = await db.insert({ embedding: [1, 2, 3], "text": "ASDASINDASDASZd" });
const key2 = await db.insert({ embedding: [2, 3, 4], "text": "GTFSDGRG" });
const key3 = await db.insert({ embedding: [73, -213, 3], "text": "hYTRTERFR" });

await db.update(key2, { embedding: [2, 3, 4], "text": "UPDATED" });
await db.delete(key3);

// Query returns a list ordered by the entries closest to the vector (cosine similarity)
console.log(await db.query([1, 2, 3], { limit: 20 }));

Because it is just a wrapper over IndexedDB you can throw JSON documents at it, and as long as it has an instance of an Array on the property referenced by vectorPath all should just work. It will create a IndexedDB for you with an objectStore and an index that is based on the defined vector too.

Now, this is no way a complete solution. There are no optimisations of the index; it doesn't do any pre-filtering to optimise they size query space; it doesn't do post-filtering of results (outside of the [limit] argument) etc etc. The goal was to be a simple wrapper to get you started quickly, if you already have a relatively complex IndexedDB integration for your site you will see by checking out some of the code that this is something that you can do you without too much hassle.

I enjoyed building this creating this project because it I got to learn a bit about Vector Databases and how they can be used when storing and querying embeddings from APIs like Open AI directly inside a browser without having to use a hosted solution.

If you have experience building these types of databases, I would love to hear from you and learn what I might be missing.

const e = new EyeDropper();
e.open().then(d => {
  alert(d.sRGBHex);
}).catch(console.error)

EyeDropper <— Just drag this to your bookmark bar.

And if you are interested in a Chrome Extension, check out this post by Patrick Brosset.

I build a lot of sites and speak to a lot of Web Developers and a huge problem we have is knowing what APIs are supported so that I can use and rely on it in my sites without having to worry about compatibility as much. There are a number of sites that have this information (canisuse and MDN), however if the LLM isn't up to date on the latest state of browsers then we can't query compatibility information.

Luckily, the raw Browser Compat Data by MDN is here to the rescue (again), and the team build and maintain the BCD data as an ongoing and always up to date resource in JSON. This gave me an idea - if I can load this data into my Polymath instance then I might be able to ask a question like:

• I need to use Safari, Firefox and Chrome - is CSS Grid ok to use?
• When did CSS Grid become useable in Safari, Firefox and Chrome?

The hypothesis I had was that we have all the data so an LLM might be able to infer decent results to questions like the above.

The first step I tried was to pass some raw JSON data into GPT-4 and see what it could infer - It worked okay but it doesn't have a clear comprehension of the data format so it made a lot of mistakes, for example if it saw support value "mirror", it outputted "supported in Chrome" and not the base engine (i.e, Safari on iOS mirrors Safari or WebKit). The answer was good enough for me that I decided that I wanted to flesh it out a bit more and try and massage the input data into something the LLM might better work with.

My hypothesis was that the LLM might parse written English better, so I quickly threw together a complete list of all the APIs tracked by BCD with an English description of the support matrix that expanded on the data in the JSON file. For example, here is the support data for acos (you can see the code in my github repo).

I then ingested all the data into my Polymath instance (creating the Embedding vectors) and uploaded it to the data store so that you can now query it like so: When did CSS acos arrive in Chrome? and I need to use Safari, Firefox and Chrome - can I use css.acos?

A fun experiment and it seems to work well, but it's only as good as the data I put in and the quality of the LLM (I imagine it can make up things so I wouldn't really trust the output just yet).