Live data from Hacker News

Show HN: Showboat and Rodney, so agents can demo what they've built

simonwillison.net

51–60 of 64 posts

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#51
post #46

Earlier quoted context omitted.

First time someone's asked for the site to be wider! I have it setup so on a wide screen the text is still a readable width, do you think it needs to bump up that max width a bit more? I've found the models are so good at Playwright that I don't consider Selenium any more. Rodney is my first experiment not using Playwright.

I second the request to make the site responsive. When I load the page the CSS constrains the main content to 560px and the whole page is constrained to 940px. Here's how it displays on my system: https://i.postimg.cc/zDMD9nYD/Simon.png

Can you take a screenshot of some other site that is wider but has a comfortable reading width for you?

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#52

Great to see you doing red/green TDD Simon! Passing tests in your repo are great documentation of the tool at a microscopic level. And rerunning tests only burns tokens on failures (since passed tests just print a dot) so it’s token efficient too. Some other neat tricks: - For greater efficiency configure your test runner to print nothing (not even a dot/filename) for test successes. Agents don’t need progress dots,…

That timeout trick is very neat!

I'm OK with longer running tests because I always have them run against a real database (often SQLite, sometimes PostgreSQL) and real files created in temporary directories but I can see how the time limit might be useful for tests that don't need those kind of components.

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#53
post #52

Great to see you doing red/green TDD Simon! Passing tests in your repo are great documentation of the tool at a microscopic level. And rerunning tests only burns tokens on failures (since passed tests just print a dot) so it’s token efficient too. Some other neat tricks: - For greater efficiency configure your test runner to print nothing (not even a dot/filename) for test successes. Agents don’t need progress dots,…

That timeout trick is very neat! I'm OK with longer running tests because I always have them run against a real database (often SQLite, sometimes PostgreSQL) and real files created in temporary directories but I can see how the time limit might be useful for tests that don't need those kind of components.

You could probably still hit the timeout with an in-memory sqlite!

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#54
post #32
post #29

Out of curiosity, what is the advantage of using Rodney when Playwright has the same set of features and AI understands how to write a Playwright script very well?

Maybe not a lot. Showboat documents look neater if there are single one-line commands that do something useful. Dumping a full Playwright script into a cell is less readable. Showboat also has a special feature where you can embed an image directly in the document by running: showboat image doc.md 'rodney screenshot' The command you call should return a path to an image file as the last line of output. Rodney does ex…

Showboat does look neat -- though I feel like I don't fully grasp the use case yet! Maybe I just need to use more AI :)

As for rodney, I was thinking that although Playwright is good, there are a lot of cases where AI can't really understand things that a human would grasp instantly. For instance, often a broken e2e test will get stuck at some point. AI never seems to grasp this - it always thinks it's a timeout and goes down latency rabbitholes. If there was some way to give AI a log of "this line was reached at this point", you could really improve the state of the world :)

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#55
post #21
post #9

If agents can generate text so easily, why would they be limited to Markdown instead of reStructuredText, AsciiDoc, or LaTeX which have rich features that help users understand text? I can understand developers refusing to adopt proper formats for documentation, but this seems odd for the bots. It doesn’t even generate the correct syntax block in Markdown using “bash” instead of “sh-session”.

Markdown has the widest tool compatibility - GitHub renders it, so does VS Code and many other editors and file hosts. I didn't know about sh-session, is that documented anywhere?

MS GitHub can not only render rST & AsciiDoc (albeit pretty poorly since they the CSS is bad), but it also is employing its own fork of Markdown that isn’t compatible with other forks. “Just Markdown”, like the base spec, is so feature poor that everyone has their own incompatible fork which don’t make it render properly.

console/shell-session/sh-session (parsers call them different names) are for shell sessions, terminal sessions. Bash syntax is for Bash scripts, & these aren’t scripts but something you run in your terminal session.

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#56
post #23

Earlier quoted context omitted.

Winning a popularity contest doesn’t mean it’s good. That is the worst part of about these things as they just generate the most common denominator type code/tooling while also repeating anti-patterns/mistakes like the bash vs. sh-session/console issue I pointed out. Garbage in has been so much garbage out unfortunately.

Never said it was good, just making an observation that Markdown is most likely to be available to render OOTB in more editors. I don't think Markdown is bad necessarily either. It's "good enough" for simple document.

Documentation isn’t as simple document. There are tons of rich elements missing from the spec specifically for documentation… which is why so many resort to adopting one of the many incompatible forks of Markdown to try to get features that were missing (but are a part of reStructuredText & AsciiDoc for instance). That has a real tradeoff since these forks are not going to be compatible & they aren’t going to be as well defined as the specs for these richer lightweight markup syntax choices.

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#57
post #55
post #21

Earlier quoted context omitted.

Markdown has the widest tool compatibility - GitHub renders it, so does VS Code and many other editors and file hosts. I didn't know about sh-session, is that documented anywhere?

MS GitHub can not only render rST & AsciiDoc (albeit pretty poorly since they the CSS is bad), but it also is employing its own fork of Markdown that isn’t compatible with other forks. “Just Markdown”, like the base spec, is so feature poor that everyone has their own incompatible fork which don’t make it render properly. console/shell-session/sh-session (parsers call them different names) are for shell sessions, ter…

I'm not convinced Markdown's various flaws matter for the way I'm using it here.

I want a simple, widely-enough supported format for mixing text, code samples and images. The non-standard (because what even is a standard when Markdown is in play?) subset of Markdown I've picked for this project works fine for what I need in Showboat.

If it turns out to need more I can expand the format in the future - likely though embedding YAML in frontmatter but I could add sidecar JSON files instead if that proves to be more robust.

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#58
post #37

A bit like jupyter notebooks, isn't it?

Yes, very much so. It's a much thinner, less feature-rich alternative. It would be interesting to experiment with Jupyter notebooks as an alternative that could work in Claude Code for web. I had a poke around just now and couldn't find an existing CLI tool that lets you build those up a section at a time in the same way as Showboat. I did find this Python library though: uv run --with nbformat python -c ' import nbf…

I think you had a post about marimo notebooks at some point? I think they would be better suited for that. Their representation is just Python, they can run as scripts, and they have native HTML output. But of course, it only works for Python.

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#59
post #58
post #37

Earlier quoted context omitted.

Yes, very much so. It's a much thinner, less feature-rich alternative. It would be interesting to experiment with Jupyter notebooks as an alternative that could work in Claude Code for web. I had a poke around just now and couldn't find an existing CLI tool that lets you build those up a section at a time in the same way as Showboat. I did find this Python library though: uv run --with nbformat python -c ' import nbf…

I think you had a post about marimo notebooks at some point? I think they would be better suited for that. Their representation is just Python, they can run as scripts, and they have native HTML output. But of course, it only works for Python.

That's a great idea.

Re: Show HN: Showboat and Rodney, so agents can demo what they've built

#60
post #33
post #31

Earlier quoted context omitted.

That's actually one of the things that has kept me from using Claude Code web (that, and I often need a Chrome browser for the agent). But they must be working on it. I saw an MCP I've set up on claude.ai show up in my local Claude Code MCP list the other day, it seems inevitable that there will be skills integration across environments as well at some point.

In working on Rodney I found out that the Claude Code for web environment has a Chrome browser installed already. It's a shame you can't see its output directly - even if it takes a screenshot there's no easy way to view it other than having it commit and push that to a branch in GitHub.

Oooh, I didn't know that.
Post reply on HN