To save anyone else wondering what is Datasette a search:
“Datasette is a tool for exploring and publishing data. It helps people take data of any shape, analyze and explore it, and publish it as an interactive website and accompanying API.
Datasette is aimed at data journalists, museum curators, archivists, local governments, scientists, researchers and anyone else who has data that they wish to share with the world. It is part of a wider ecosystem of 44 tools and 154 plugins dedicated to making working with structured data as productive as possible.”
Multiple projects are coming to the same point it seems. Motherduck has been marketing "dives" since the beginning of the year (https://motherduck.com/blog/duck-dive-and-answer/) and in the Louie.ai team, we have been iterating on different patterns for similar needs. I'm getting the feeling that the answer to SaaS apps as fixed UIs over databases being dead because of coding agents means just the fixed dashboard pattern is dead, not SaaS, and BYO UI is part of the new table stakes.
I'm curious where the pattern will go. My sense is there is a split between cathedrals vs bazaar for approach here, where cathedrals are quite rigid app builders, think framer/wix, while bazaars focus a layer below for more flexibility but less integrated.
Absolutely, plus if you control the coding agent you can enforce certain guarantees and have it wrap your services with a custom sdk. I've been exploring this pattern in a couple of different domains where it's just a vite react app wrapped in an iframe with a JWT bridge giving auth, hosted on a separate domain.
At the enterprise level this feels a lot like Snowflake buying StreamLit to try and have a similar experience, and keep you in the Snowflake ecosystem burning credits.
When I've needed something like this in the past I've spun up simple HTML pages and used the json endpoint that all datasette instances come with [0]. I like this new pattern much better, as it keeps your app and data in one place (I remember having some issue with this at the time, though I can't remember what the actual issue was)
So I imagine we could now load some data in to sqlite, design some HTML also loaded in to the db, and deploy. Although looking at the source, it seems like stored apps are expected to be managed by the plugin itself, but I'm sure there's a way around that
I'm going to think about how Datasette Apps can work with the apps themselves stored on a filesystem so they can be revision controlled using Git.
I have an idea for a way to edit them through Datasette and have them backed up to Git via a separate mechanism, but having them on disk would be a whole lot more convenient.
Interesting idea, I know there's the fsdir [0] table-valued function / module that allows loading from disk, so it should be possible to modify that or hard-code base list of paths or something
I think you might be right, that rings a bell. There's an item on the front page about this right now, and I'm guilty as charged - I don't understand CORS at all
It is pretty cool that we have browser features like this to rely on.
I remember writing code in the bad old days to parse HTML tags and allowlist specific attributes. Now browsers have a much better solution baked in.
But it still makes me a bit nervous. Seems like a very small bug could sneak in. This is a good example of where I would reach for Fable to double check the implementation and have a lot of extra tests.
(nit: would be nice if the chat box treated Enter and Shift+Enter the way these other companies have trained my brain, but maybe that is a deliberate choice.)
In the three short days we had access to Fable I did have it run a review, and it spotted an issue for me to fix.
Thankfully GPT-5.5 is really strong on security stuff too. I wouldn't have dared build this without a whole lot of Opus/GPT-assisted prototyping and testing along the way.
I never understood why someone hasn't made a framework that makes it stupidly easy to fill an HTML page with SQLite database tables, with all the usual display controls, and with as much "liveness" as desired, and with a protocol (over HTTPS) to manage comms to a server-side instance. SQLite is robust, lightweight, bulletproof - a WASM build belongs on ALL the webpages !
As mentioned below I have been building the 'read' side of this: a data publication platform. I wanted to avoid any server side components. The communication / write part and updating the server-side sqlite database would need running components on the server which I wanted to avoid.
The 'write' part would technically be very doable and not that different from other back-ends.
You almost never need just a basic list of all the data in your table, even if you're able to filter and sort it. There's no moat there at all. People need serious BI tools, and that throws simplicity out of the window (PowerBI, QuickSight, etc.).
I disagree, a lot of the time people buy "serious BI tools" precisely because they think they need all that power and complexity.
In reality, what most people need is much simpler, a mini app with some curated datasets and simple filters, maybe some AI querying if we want to get fancy. There's some companies out there that work with big data, but for the rest of us small data is ok.
I've used that with companies I consult for, everyone thinks they should do what Google does, so sometimes I'll drop them the "your whole company data fits in my phone/laptop" line to make them understand the (lack of) scale
I have a version of Datasette that runs entirely in the browser (using Pyodide and WebAssembly) and it's smaller than a lot of modern React homepages (12.35MB):
Looks like a good addition to the datasette ecosystem. I have been working on a similar idea with cusom html around sqlite databases. By default a faceted search interface is generated but by reusing the client side data layer, custom apps are made easy.
The design keeps data and presentation together and even maps do not rely on external services.
although I'm coming from a different starting point, it seems like some of our thoughts have aligned. I'm building https://caipi.ai/ as a workspace for agents to build simple data driven apps. The agent edits through MCP and the user gets an interactive app in the browser.
If you're interested picking each others brains around this topic, I'd be psyched to have a chat. gh:pietz.
How does this work, does some mechanism replace the actual tape drive in the Datasette? Can you just use the tape port with the gadget or does it somehow need the tape drive? How do you access the HTML applications, how is the translation to PETSCII handled?
I have no idea how this could work but as a long time Commodore 64 fan I'm interested. The link won't load for me, sadly. Can somebody give me a quick rundown on how I can host HTML apps inside my Commodore Datasette tape drive?
You can protect it with CSP headers, but you can't also protect it with the sandbox="" attribute (should a user visit it directly)
If you want both sandbox= restrictions and CSP headers at the same time the only way I've found that works cross all major borders is the iframe plus srcdoc="" with injected CSP meta headers patterns.
Note that a lot of sandbox implementations serve their iframe content from a separate domain, to ensure cookies and localStorage and other same origin things are robustly protected.
I can't do that easily for Datasette because it's open source software that people can run on their own laptops, so I didn't want to block people on "now register a domain/subdomain and set this up in DNS".
CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.
Right, which is why I'm combining it with <iframe sandbox=""> - which really is designed to be used as a sandbox (if you can figure out the right way to implement it.)
> <iframe sandbox=""> - which really is designed to be used as a sandbox
Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written.
(There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)
That's why I'm careful not to include allow-same-origin in the sandbox attribute - without that the iframe content is treated as a separate origin from the parent.
And I serve the content in srcdoc= to ensure there's no URL a user can visit which would directly execute the content outside of that iframe sandbox.
If that's true then my project is fatally flawed and I need to stop distributing it.
I'm not convinced it's true - I've been thinking about this for months, and building experimental prototypes to help me get to the combination that I think makes sense.
Can you describe an exploit that the combination I'm using of iframe sandbox= srcdoc= with an injected meta CSP tag doesn't handle?
Would moving the untrusted content to be served from a separate domain entirely close the hole?
(In case it's not clear the iframe sandbox= is the bit that's doing most of the work here - the CSP stuff is there mainly to protect against malicious apps that deliberately exfiltrate stolen private data.)
nice pattern with the stored queries for writes. but who defines them? if the app author can create their own stored queries, the write restriction is basically honor system.
There are actually two types of stored query: regular and "trusted".
Any query you save is a regular query. It operates under the permissions of the viewer, and checks that the viewer has the necessary permissions - read access to the database, or more finely grained write access which checks the individual tables they will be writing to.
The problem with that is that it means you can't build an app which other, signed out or unprivileged users, can use.
So there's a second category: "trusted" queries. These are current only configurable by the site administrator who controls the Datasette deployment, as they go straight in the configuration file: https://docs.datasette.io/en/latest/sql_queries.html#trusted...
I'm planning to add a way for trusted users to create these through the UI via another permission, with a very strong UI warning to only use this feature if you understand the implications.
1. Love the addition. Everything becoming its own self-serve artifact factory is great. Malleable software's been a dream a long time, it's supposed to be soft and this concept helps get it there.
2. Since Claude goes on and on about surface, now everyone is using it. Or was everyone using it already?
FTA: “I quickly realised that the sandboxed pattern is interesting for way more than just adding custom apps to the interface surface and promoted it to its own top-level concept within the Datasette ecosystem.”
For decades that sentence would have parsed without the word surface in it. What does it mean that's suddenly so – um – load-bearing?
Huh... not sure how that got in there, I wrote this without LLM assistance (aside from a proof reading run, but I do that in Claude so it doesn't have the ability to edit my own text).
It's quite possible I've been subconsciously influenced into thinking in terms of "surfaces" though!
I just edited that to this, which is a bit cleaner:
> I quickly realised that the sandboxed pattern is interesting for way more than just adding custom apps in a chat interface and promoted it to its own top-level concept within the Datasette ecosystem.
I just went through the github project repository.
It has 119 repositories.
Is this how AI slop looks like in code? Made for the agents, by the agents?
Is this separation of concerns or context management with agents as a first class residents and humans merely acting as custodians?
I'm at 205 today (some of the repos on GitHub aren't plugins, and some in the datasette org were written and released by Alex Garcia which excludes them from my own releases database).
Most of the plugins I wrote this year have been heavily AI-assisted, but that wasn't the case for the older ones. Here's my post from October 2025 when I first realized Claude Sonnet 4.5 could one-shot a plugin for me: https://simonwillison.net/2025/Oct/8/claude-datasette-plugin...
The reason there are so many repos is that Datasette uses a plugin architecture, which makes it much easier to try out different features without risk of corrupting the core project with things that turn out to be bad ideas.
Well, thank you for clarifying. The signal is getting lost in the noise. I assumed too soon after looking around just the datasette org github account and seeing so many repos and code being built so fast.
Simon needs to resist the pelicans(and the django mindset) and Garry needs a new loop which can loop on itself without any human trigger so that the agents can "dream" better. Who knew that it was not just the models which could hallucinate.
I learned to program on a C64 and one of the first programs I wrote myself was an incredible basic "database" (really just a program that could store and then return simple fielded data.)
I named my database management software Datasette as an homage to the C64. I also figured it would be a unique name that would be easy to search for...
... jokes on me, it turns out the retro computing C64 community is way more active than I expected and there are still plenty of people taking about Datasette tape drives online, 30+ years after they stopped being manufactured and sold.
Wow this is very similar to the direction im taking with my new project https://github.com/hank-bond/uix (warning the code base is certainly not messy but the application is barely usable for anything as of this post).
Here the goal is to be a self-assembling harness (akin to pi) but focusing on duplex human-agent interactivity over rendered HTML "apps". To start, it's focused more on the "please review this PR and then generate a one-page report" with the ability to write comments in the actual report that automatically get sent back to the agent. The end goal is closer to offering a substrate for less technical people to be able to build personal applications like
- an interactive wiki maintainer: chat with the agent about an article, pull out sections, append/create concepts in the wiki with the new info
- agent code harness: agent tabs to the left, chat in middle, code diffs on the right (like the superset/commander class of apps)
Anyway, I'm really into the "self assembling" class of software where everything is basically just an SDK + Agent. I think we might actually be ushering in a new era of "personal computing" in that it's less friction than ever to personalize your setup to your whims. Anyway, thats the goal I'm reaching for.
It seems many others are coalescing on this idea at the same time, so it must just be in the aether.
People that overuse LLMs I notice all build the same things and have the same ideas. Its one of the many reasons I avoid them, it kinda leads people into this average group where creativity is dead and there's a kinda hive mind controlling them.
Ive witnessed it many times now, im positive this phenomenon exists.
People also build the same things if they have the same needs. That doesn't mean creativity is dead. My life as a software engineer is not that unique of others. This isn't really something to lament. There's nothing wrong with exploring similar ideas.
To save anyone else wondering what is Datasette a search:
“Datasette is a tool for exploring and publishing data. It helps people take data of any shape, analyze and explore it, and publish it as an interactive website and accompanying API.
Datasette is aimed at data journalists, museum curators, archivists, local governments, scientists, researchers and anyone else who has data that they wish to share with the world. It is part of a wider ecosystem of 44 tools and 154 plugins dedicated to making working with structured data as productive as possible.”
I’ve been using the Observable Framework[1] for this kind of work but it doesn’t appear to be actively developed anymore so will look into Datasette.
[1] https://github.com/observablehq/framework
Multiple projects are coming to the same point it seems. Motherduck has been marketing "dives" since the beginning of the year (https://motherduck.com/blog/duck-dive-and-answer/) and in the Louie.ai team, we have been iterating on different patterns for similar needs. I'm getting the feeling that the answer to SaaS apps as fixed UIs over databases being dead because of coding agents means just the fixed dashboard pattern is dead, not SaaS, and BYO UI is part of the new table stakes.
I'm curious where the pattern will go. My sense is there is a split between cathedrals vs bazaar for approach here, where cathedrals are quite rigid app builders, think framer/wix, while bazaars focus a layer below for more flexibility but less integrated.
Absolutely, plus if you control the coding agent you can enforce certain guarantees and have it wrap your services with a custom sdk. I've been exploring this pattern in a couple of different domains where it's just a vite react app wrapped in an iframe with a JWT bridge giving auth, hosted on a separate domain.
At the enterprise level this feels a lot like Snowflake buying StreamLit to try and have a similar experience, and keep you in the Snowflake ecosystem burning credits.
When I've needed something like this in the past I've spun up simple HTML pages and used the json endpoint that all datasette instances come with [0]. I like this new pattern much better, as it keeps your app and data in one place (I remember having some issue with this at the time, though I can't remember what the actual issue was)
So I imagine we could now load some data in to sqlite, design some HTML also loaded in to the db, and deploy. Although looking at the source, it seems like stored apps are expected to be managed by the plugin itself, but I'm sure there's a way around that
[0] Eg from one of the examples - https://datasette.io/legislators/-/query.json?sql=select+*+f... . If you strip the '.json' you get the html view. For what it's worth there's also a '.csv' version.
I'm going to think about how Datasette Apps can work with the apps themselves stored on a filesystem so they can be revision controlled using Git.
I have an idea for a way to edit them through Datasette and have them backed up to Git via a separate mechanism, but having them on disk would be a whole lot more convenient.
Filed an issue here: https://github.com/datasette/datasette-apps/issues/30
Interesting idea, I know there's the fsdir [0] table-valued function / module that allows loading from disk, so it should be possible to modify that or hard-code base list of paths or something
[0] https://sqlite.org/src/file/ext/misc/fileio.c, it allows you to read a directory recursively in the cli (`select * from fsdir("./");`)
Edit: It allows upwards traversals (`select * from fsdir("../../../../etc/passwd");`), so beware
Wow, I didn't know about that one. SQLite never ceases to surprise.
I'm sticking with the Python bundled sqlite3 though so I'm not in a good place to take advantage of that one.
It's probably out of scope for you, but I've used the 'vtfunc' module [0] for a similar purpose actually.
[0] https://github.com/coleifer/sqlite-vtfunc
nee: couchapps
https://railsware.com/blog/couchdb-and-couchapp-part-1/amp/#...
https://couchapp.readthedocs.io/en/latest/couchapp/gettingst...
https://couchapp.readthedocs.io/en/latest/user/list-of-couch...
> it keeps your app and data in one place (I remember having some issue with this at the time, though I can't remember what the actual issue was)
CORS headers?
I think you might be right, that rings a bell. There's an item on the front page about this right now, and I'm guilty as charged - I don't understand CORS at all
https://news.ycombinator.com/item?id=48614844
This seems to attractive side of seeing it, however the striping Json would not be suitable i believe
[flagged]
It is pretty cool that we have browser features like this to rely on.
I remember writing code in the bad old days to parse HTML tags and allowlist specific attributes. Now browsers have a much better solution baked in.
But it still makes me a bit nervous. Seems like a very small bug could sneak in. This is a good example of where I would reach for Fable to double check the implementation and have a lot of extra tests.
(nit: would be nice if the chat box treated Enter and Shift+Enter the way these other companies have trained my brain, but maybe that is a deliberate choice.)
In the three short days we had access to Fable I did have it run a review, and it spotted an issue for me to fix.
Thankfully GPT-5.5 is really strong on security stuff too. I wouldn't have dared build this without a whole lot of Opus/GPT-assisted prototyping and testing along the way.
I never understood why someone hasn't made a framework that makes it stupidly easy to fill an HTML page with SQLite database tables, with all the usual display controls, and with as much "liveness" as desired, and with a protocol (over HTTPS) to manage comms to a server-side instance. SQLite is robust, lightweight, bulletproof - a WASM build belongs on ALL the webpages !
As mentioned below I have been building the 'read' side of this: a data publication platform. I wanted to avoid any server side components. The communication / write part and updating the server-side sqlite database would need running components on the server which I wanted to avoid.
The 'write' part would technically be very doable and not that different from other back-ends.
https://github.com/GhentCDH/Pihka
Did you have a look at https://evidence.dev
Because it's pretty much worthless.
You almost never need just a basic list of all the data in your table, even if you're able to filter and sort it. There's no moat there at all. People need serious BI tools, and that throws simplicity out of the window (PowerBI, QuickSight, etc.).
I disagree, a lot of the time people buy "serious BI tools" precisely because they think they need all that power and complexity.
In reality, what most people need is much simpler, a mini app with some curated datasets and simple filters, maybe some AI querying if we want to get fancy. There's some companies out there that work with big data, but for the rest of us small data is ok.
I think of Datasette as a "small data" platform, where small data is anything that would fit on my phone.
My phone has 1TB of storage.
I've used that with companies I consult for, everyone thinks they should do what Google does, so sometimes I'll drop them the "your whole company data fits in my phone/laptop" line to make them understand the (lack of) scale
duckdb -ui
Data engineers hate this one simple trick
Something like sync engines? I think there are a bunch nowadays.
https://syntax.fm/show/924/sync-engines-and-local-data
It's not specific to SQLlite per se, but that's what most dashboard builders are
Like MS Access on web?
Imagine if this were built into browsers and you only had to serve a SQLite file.
I have a version of Datasette that runs entirely in the browser (using Pyodide and WebAssembly) and it's smaller than a lot of modern React homepages (12.35MB):
https://lite.datasette.io/
My more recent prototype shrinks that to 10.47 MB transferred: https://simonw.github.io/research/pyodide-asgi-browser/datas...
From TFA:
> a Datasette-style backend to a self-contained HTML frontend is an astonishingly powerful combination.
1000% agree. And datasette is a terrific framework to build any kind of data exploration or visualization on.
This sounds like an awesome feature and a good excuse for me to dive back into playing with Datasette.
Looks like a good addition to the datasette ecosystem. I have been working on a similar idea with cusom html around sqlite databases. By default a faceted search interface is generated but by reusing the client side data layer, custom apps are made easy.
The design keeps data and presentation together and even maps do not rely on external services.
I have called it Pihka: https://ghentcdh.github.io/Pihka/ https://github.com/GhentCDH/Pihka
Hey Simon,
although I'm coming from a different starting point, it seems like some of our thoughts have aligned. I'm building https://caipi.ai/ as a workspace for agents to build simple data driven apps. The agent edits through MCP and the user gets an interactive app in the browser.
If you're interested picking each others brains around this topic, I'd be psyched to have a chat. gh:pietz.
How does this work, does some mechanism replace the actual tape drive in the Datasette? Can you just use the tape port with the gadget or does it somehow need the tape drive? How do you access the HTML applications, how is the translation to PETSCII handled?
I have no idea how this could work but as a long time Commodore 64 fan I'm interested. The link won't load for me, sadly. Can somebody give me a quick rundown on how I can host HTML apps inside my Commodore Datasette tape drive?
[dead]
I didn't quite get the CSP part. Why use and srcdoc and <meta http-equiv="Content-Security-Policy"> instead of a real server header? Static hosting?
If you host iframe apps at a fixed URL like:
You can protect it with CSP headers, but you can't also protect it with the sandbox="" attribute (should a user visit it directly)If you want both sandbox= restrictions and CSP headers at the same time the only way I've found that works cross all major borders is the iframe plus srcdoc="" with injected CSP meta headers patterns.
Note that a lot of sandbox implementations serve their iframe content from a separate domain, to ensure cookies and localStorage and other same origin things are robustly protected.
I can't do that easily for Datasette because it's open source software that people can run on their own laptops, so I didn't want to block people on "now register a domain/subdomain and set this up in DNS".
CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.
Right, which is why I'm combining it with <iframe sandbox=""> - which really is designed to be used as a sandbox (if you can figure out the right way to implement it.)
> <iframe sandbox=""> - which really is designed to be used as a sandbox
Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written.
(There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)
That's why I'm careful not to include allow-same-origin in the sandbox attribute - without that the iframe content is treated as a separate origin from the parent.
And I serve the content in srcdoc= to ensure there's no URL a user can visit which would directly execute the content outside of that iframe sandbox.
> That's why I'm careful not to include allow-same-origin in the sandbox attribute
It doesn't matter. I just said there is no combination of CSP or the iframe sandbox attribute that can be relied upon here.
If that's true then my project is fatally flawed and I need to stop distributing it.
I'm not convinced it's true - I've been thinking about this for months, and building experimental prototypes to help me get to the combination that I think makes sense.
Can you describe an exploit that the combination I'm using of iframe sandbox= srcdoc= with an injected meta CSP tag doesn't handle?
Would moving the untrusted content to be served from a separate domain entirely close the hole?
(In case it's not clear the iframe sandbox= is the bit that's doing most of the work here - the CSP stuff is there mainly to protect against malicious apps that deliberately exfiltrate stolen private data.)
> Would moving the untrusted content to be served from a separate domain entirely close the hole?
Yes.
[dead]
nice pattern with the stored queries for writes. but who defines them? if the app author can create their own stored queries, the write restriction is basically honor system.
There are actually two types of stored query: regular and "trusted".
Any query you save is a regular query. It operates under the permissions of the viewer, and checks that the viewer has the necessary permissions - read access to the database, or more finely grained write access which checks the individual tables they will be writing to.
The problem with that is that it means you can't build an app which other, signed out or unprivileged users, can use.
So there's a second category: "trusted" queries. These are current only configurable by the site administrator who controls the Datasette deployment, as they go straight in the configuration file: https://docs.datasette.io/en/latest/sql_queries.html#trusted...
I'm planning to add a way for trusted users to create these through the UI via another permission, with a very strong UI warning to only use this feature if you understand the implications.
Here's a demo of an app that runs against trusted stored queries: https://agent.datasette.io/-/apps/01ktw6fpag19dnnga85t2ced3p
Source code here, showing how those queries are called: https://gist.github.com/simonw/6e6a3760fa0528ceda1f65d789069...
It uses these queries: https://agent.datasette.io/content/timeline-filtered and https://agent.datasette.io/content/timeline-count
A compliment and a curiosity:
1. Love the addition. Everything becoming its own self-serve artifact factory is great. Malleable software's been a dream a long time, it's supposed to be soft and this concept helps get it there.
2. Since Claude goes on and on about surface, now everyone is using it. Or was everyone using it already?
FTA: “I quickly realised that the sandboxed pattern is interesting for way more than just adding custom apps to the interface surface and promoted it to its own top-level concept within the Datasette ecosystem.”
For decades that sentence would have parsed without the word surface in it. What does it mean that's suddenly so – um – load-bearing?
Huh... not sure how that got in there, I wrote this without LLM assistance (aside from a proof reading run, but I do that in Claude so it doesn't have the ability to edit my own text).
It's quite possible I've been subconsciously influenced into thinking in terms of "surfaces" though!
I just edited that to this, which is a bit cleaner:
> I quickly realised that the sandboxed pattern is interesting for way more than just adding custom apps in a chat interface and promoted it to its own top-level concept within the Datasette ecosystem.
I just went through the github project repository.
It has 119 repositories.
Is this how AI slop looks like in code? Made for the agents, by the agents? Is this separation of concerns or context management with agents as a first class residents and humans merely acting as custodians?
https://github.com/datasette has 119 - but there are also 232 under my simonw account from before I started the Datasette org: https://github.com/simonw?tab=repositories&q=Datasette-&type...
Most of them predate coding agents. I started the Datasette project in 2017.
In fact we can answer this with Datasette! Here's a query showing the 111 packages with at least one release prior to ChatGPT on Nov 30 2022: https://datasette.simonwillison.net/simonwillisonblog?sql=wi...
And this is that same query for Claude Code (Feb 24 2025) - which returns 172:
https://datasette.simonwillison.net/simonwillisonblog?sql=wi...
I'm at 205 today (some of the repos on GitHub aren't plugins, and some in the datasette org were written and released by Alex Garcia which excludes them from my own releases database).
Most of the plugins I wrote this year have been heavily AI-assisted, but that wasn't the case for the older ones. Here's my post from October 2025 when I first realized Claude Sonnet 4.5 could one-shot a plugin for me: https://simonwillison.net/2025/Oct/8/claude-datasette-plugin...
The reason there are so many repos is that Datasette uses a plugin architecture, which makes it much easier to try out different features without risk of corrupting the core project with things that turn out to be bad ideas.
I gave a talk about plugin architecture at DjangoCon a couple of years ago: https://2024.djangocon.us/talks/how-to-design-and-implement-...
Well, thank you for clarifying. The signal is getting lost in the noise. I assumed too soon after looking around just the datasette org github account and seeing so many repos and code being built so fast.
Datasette pre-dates agentic AI
[flagged]
Our leader is Boris Cherny.
Simon needs to resist the pelicans(and the django mindset) and Garry needs a new loop which can loop on itself without any human trigger so that the agents can "dream" better. Who knew that it was not just the models which could hallucinate.
[dead]
[dead]
Why people feel the need to overload terms like "datasette" I'll never know
I think the current meaning has quite successfully replaced the original usage. Unless you typed this on a Commodore VIC-20, I suppose.
For you maybe, but I've never heard of this site, my only reference for "datasette" is the commodore 1560
Me too, and also I've never used one and it was discontinued before I was born
I learned to program on a C64 and one of the first programs I wrote myself was an incredible basic "database" (really just a program that could store and then return simple fielded data.)
I named my database management software Datasette as an homage to the C64. I also figured it would be a unique name that would be easy to search for...
... jokes on me, it turns out the retro computing C64 community is way more active than I expected and there are still plenty of people taking about Datasette tape drives online, 30+ years after they stopped being manufactured and sold.
I can’t even parse what you’re complaining about. Could you elaborate?
I'm assuming he's talking about the old hardware data cassette vs the software project of the save name?
https://en.wikipedia.org/wiki/Commodore_Datasette vs
https://datasette.io/
My favourite Datassette is the electronic artist.
https://datassette.bandcamp.com/
https://musicforprogramming.net/
I’m assuming they’re just taking about the word dataset.
Either way feels ridiculous, but the human in me wants to know which it is ^_^
This comment was posted after my comment was…
Just read for the first time.
Thank you for the disambiguation for me - and the other readers.
Please hold the snark, lol
Why would / could i host data this large on a tape? Or did someone mis-use and re-label its meaning? Maybe for some tech hipster product?
Wow this is very similar to the direction im taking with my new project https://github.com/hank-bond/uix (warning the code base is certainly not messy but the application is barely usable for anything as of this post).
Here the goal is to be a self-assembling harness (akin to pi) but focusing on duplex human-agent interactivity over rendered HTML "apps". To start, it's focused more on the "please review this PR and then generate a one-page report" with the ability to write comments in the actual report that automatically get sent back to the agent. The end goal is closer to offering a substrate for less technical people to be able to build personal applications like
- an interactive wiki maintainer: chat with the agent about an article, pull out sections, append/create concepts in the wiki with the new info - agent code harness: agent tabs to the left, chat in middle, code diffs on the right (like the superset/commander class of apps)
Anyway, I'm really into the "self assembling" class of software where everything is basically just an SDK + Agent. I think we might actually be ushering in a new era of "personal computing" in that it's less friction than ever to personalize your setup to your whims. Anyway, thats the goal I'm reaching for.
It seems many others are coalescing on this idea at the same time, so it must just be in the aether.
People that overuse LLMs I notice all build the same things and have the same ideas. Its one of the many reasons I avoid them, it kinda leads people into this average group where creativity is dead and there's a kinda hive mind controlling them.
Ive witnessed it many times now, im positive this phenomenon exists.
Or, your know, people who are exploring the limit of current tools come across the lack of certain solutions and start building them.
People also build the same things if they have the same needs. That doesn't mean creativity is dead. My life as a software engineer is not that unique of others. This isn't really something to lament. There's nothing wrong with exploring similar ideas.