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).

You can try it with a couple more queries:

• How do you centre a div?
• Can you use CSS Grid with Safari and since when?
• What is the code to connect to device with Web USB?

I'm very happy with the results, and I thought it would be nice to document how I built it because I believe that the technology is a lot more accessible than it was just 6 months ago and it can be integrated into any site.

Goals:

• I wanted a search function that could easily index content that I gave it
• I wanted the search to be able to understand related concepts e.g, "PWA" and "Progressive Web App" are the same thing.
• I wanted to see if I could get the machine to generate a summary that would answer the person's question
• Did not require JavaScript, and rendered a UI instantly

I used the Polymath-AI project as the main infrastructure for this project. Polymath-AI is pretty great (I've now contributed some fixes) and it's interesting to me not because of how I integrated it to my site, but rather it's a protocol to query and interrogate a web of repositories of knowledge. If you check out the CLI you can see that you can query any polymath instance ( e.g, npx polymath ask "What happened to Web Intents?" --servers https://paul.kinlan.me/polymath --openai-api-key [YOUR OPEN AI API KEY] ). I thought that this was incredibly powerful because I can ACL my own data and give you complete access to my public data, and selected people access to private data (I'm a big logseq user and I have a private repo that I would like to be able to interrogate).

It's worth giving a quick overview of Polymath because it does three things:

1. It ingests data from the owner of the instance (me in this case), and for each piece of content creates an embedding vector which is then stored in a pinecone database.
2. It finds content and links that are related to a persons query. First by creating an embedding vector for the persons query and then use cosine-similarity to compare the query vector against all the known contents embedding vector.
3. It discovers the most similar piece of content to the person's query to insert directly into a query to the Open AI API, with a question of the form: Answer the question as truthfully as possible using the provided context, and if the answer is not contained within the text below, say "I don\'t know".\n\nContext:{context}\n\nQuestion: {query}\n\nAnswer:. context is the most similar document, and query is the person's query.

And it works incredibly well. My mind was completely blown the first time that I saw it working.

I won't cover the ingestion process in this post as it's basically npx polymath ingest rss [url] .

It turns out that the plumbing to get this working is achievable and can be hooked up relatively quickly. If you want to host your own instance, you can do something similar to what I've done with the three components that I created.

1. A UI - Renders an HTML streaming response from the Polymath Client - that is all. [direct link] ( about 30 lines of HTML and a fetch request)
2. A Polymath Client - takes a person's query and interacts with any Polymath host - it's configured to connect to my Polymath Host and once it has the data, then queries Open AI with the above request. [direct link]
3. The Polymath Host - the implementation of the protocol defined by Polymath - this directly queries my configured pinecone database and will return embeddings that are closest to your query [direct link] - They great thing is that you don't need to use my UI to query it, you can use your own client (or CLI) npx polymath ask "Why is Paul so handsome?" --servers https://paul.kinlan.me/polymath --openai-api-key [YOUR OPEN AI API KEY]

Just a note if you are implementing this: I had to split it into three pieces because the Polymath client currently only supports the Node runtime and my UI needed to be able to stream a response from Vercel (which at the time was only available on the "Edge Server"). If I can get Node streaming working, then the UI and Client code would be be merged.

And that's it. I'm just at the start of an ML assisted journey and I still struggle to know what I can do with LLM but it's been a wild couple of weeks trying to learn how it all workings.

It's also wild to me that I can quickly build Generative ML experiences that work directly into my site easily. That I can implement your own site search++ quickly and it's a solved problem. There are database companies that just focus on Vector search :mind-blown:

Interesting links:

• Client
• CLI
• Host

I had a lot of fun creating this talk where I could go from the earliest computing with the Difference Engine all the way to today and try and talk about the evolutions of computing and possibility at every transition (I tied the transitions to delivery of content/data).

I wanted to try and hit a note that when I was coming out of University in the early 2000's we were able ride on the ascendancy of the Web and students coming out of university today are at the foot of potentially a couple of new waves that today's students can take advantage of.

I placed my bet on ML being the next wave, specifically the Generative aspect as a step change in the way people use computers. I could be totally wrong, but it's an area that I am personally investing a lot of time re-learning (heh - it's almost 20 years since my AI based dissertation) and to me it feels that we are at the start of a significant shift where I am in a lucky position that the web is the best medium to deliver this change.

Interestingly, earlier in the day I had a discussion with Carwyn Edwards and Joseph Mearman made an interesting point about a new potential Industrial Revolution where instead of Mechanising physical labour, we're at a point where mental labour is now Mechanised. I thought it was a such an evocative statement - in the same spirit as a "Bicycle for the mind" 40 years ago. I asked Chat GPT4 something similar the day before and it said:

Heh. Thinking a lot of itself...

I wrote this talk before I had seen what was happening at the University and as the speaker at the event I also got invited to the Student Expo earlier in the day. The Expo was great, it was full of the Final year students projects and it was great to see what the students are up to and they are solving interesting challenges. It was also very interesting to see how many students are applying many different aspects of AI to practical problems (I'd say 1/3rd to a 1/2 of the projects). On one hand there were high-level Music and Lyric generators with Chat GPT; practical developers tools like a Unity plugin with Stable Diffusion; to the very low-level Fibre Optic fault detection with Convolutional Neural Networks. It was great to see the entire spectrum and it was interesting to see how many of the students were focusing on this new area.

The students might have just picked up on the zeitgeist and worked on that, but I think there is something far more fundamental happening given the breadth and the depth of learning. Either way, it was great to see and I left excited for the future.

I added a new page to the site which lets you discover the APIs across a selected list of browsers that are still marked as experimental in BCD (Browser Compat Data).

Why is this important? For me at least it is useful to know when an API is not something that I can rely on across because it's not in all browsers, and at the same time an API might be considered experimental for an incredibly long time (6 years in the screenshot above) - that gives you an idea about the potential importance of other browser vendors to standardise on this.

It is fair to ask the question: If it's just in browser X and it has for a long time, is it something that will get deprecated?

Now, there might not be an answer to that, but at least you have more data to help you make a decision on if it is something you want to integrate into your site and have productive conversations with your stakeholders and team.

Let me know what I can do to improve this.