For years, building interactive widgets in Python notebooks meant wrestling with toolchains, platform quirks, and a mountain of JavaScript machinery.

Most developers took one look and backed away slowly.

Trevor Mance decided that barrier did not need to exist.

His idea was simple.

Give Python users just enough JavaScript to unlock the web's interactivity without dragging along the rest of the web ecosystem.

That idea became anywidget, and it's quickly becoming the quiet, connective tissue of modern interactive computing.

Today, we dig into how it works, why it's taken off, and how it might change the way we explore data.

This is Talk Python To Me, episode 530, recorded November 25th, 2025.

Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists.

This is your host, Michael Kennedy.

I'm a PSF fellow who's been coding for over 25 years.

Let's connect on social media.

You'll find me and Talk Python on Mastodon, Bluesky, and X.

The social links are all in your show notes.

You can find over 10 years of past episodes at talkpython.fm.

And if you want to be part of the show, you can join our recording live streams.

That's right.

We live stream the raw uncut version of each episode on YouTube.

Just visit talkpython.fm/youtube to see the schedule of upcoming events.

Be sure to subscribe there and press the bell so you'll get notified anytime we're recording.

Look into the future and see bugs before they make it to production.

Sentry's Seer AI Code Review uses historical error and performance information at Sentry to find and flag bugs in your PRs before you even start to review them.

Stop bugs before they enter your code base.

Get started at talkpython.fm/seer-code-review.

And this episode is sponsored by JetBrains and the PyCharm team.

This week only through December 19th, 2025, get 30% off of PyCharm Pro, including renewals, and PyCharm will donate all the proceeds to the Python Software Foundation.

Support the PSF by getting or renewing PyCharm.

Visit talkpython.fm/pycharm dash PSF dash 2025 and use the code STRONGERPYTHON.

Both of these are in your podcast player show notes.

Trevor, welcome to Talk By Than Me.

Awesome to have you here.

Thanks for coming.

Yeah, thanks for having me, Michael.

We're going to talk about building Lego blocks for data scientists.

Is that maybe a good way to put it?

Yeah, definitely.

Yeah, so we're going to talk about your project, AnyWidget, which is a super cool project that allows people to build more adaptable, more reusable widgets, rather than just saying I'm going to build it for Jupyter or Remo or whatever.

but I'm going to build something that can be used broadly through your platform and a lot simpler deployment as well.

So I know a lot of people out there are excited.

Not everyone necessarily wants to build widgets, but this also makes more widgets available for people, right?

So super cool project.

Yeah.

And before we get into that, of course, maybe just tell us a bit about yourself.

Yeah.

So I'm Trevor.

I'm a software engineer at Marimo, but prior to being at Marimo, I was doing my PhD in data visualization at Harvard Medical School.

So I got into this whole like Python web world from working on tools for biological scientists to explore like large genomics or spatial genomic data sets.

That is a super interesting topic.

I'm sure

there were some really niche things you had to build, right?

Like, you know, we have this crazy research machine.

There's three of them in the world and here's the data that comes out of it.

how do I put that into notebooks or whatever, right?

Yeah, yeah, exactly.

And it's funny you mentioned that.

I think starting off in more like the visualization side, we'd build these very bespoke and custom applications for looking at large biological data sets.

And then I think a motivation for me was realizing a lot of the folks that I was working with to build these tools for worked in Python and worked in notebooks specifically.

And so there was sort of this gap between the research that we were doing to build these specialized tools and trying to meet users where they were at to actually use those tools in their research and as a part of their data exploration workflows.

- And this was your PhD work?

- Yes, yeah, this was my PhD work.

- Incredible.

So I'm sure it wasn't just Python.

- No, so-- - What was involved with it?

- So yeah, I'd say the research community, at least in bio, is sort of split between R and Python, but specifically some of our closest collaborators were in the Python ecosystem.

And then my team was building a lot of user interfaces for visual exploration of data sets.

And I think this notebook sort of became this space and specifically Python notebooks where you can really blend those programmatic and user interfaces together.

That's sort of why I centered on trying to solve some of the rough edges about bringing these interactive tools inside of notebooks.

- That's cool.

Did you do any other platforms?

I'm thinking like Unity or Reel, a real engine for like flying through data or what else did you all do?

Yeah, there were some folks on my team that ended up or are currently working in more like spatial, like AR, VR type scenarios.

And that I think is based on the Unity engine.

Most of my work was like web-based and we, and specifically, and we'll probably get into it.

I think the web is just a really important platform to develop for in the sense that, I mean, we're recording right now in a web browser.

It's a very capable platform that everyone sort of has an entry point to on some sort of device.

And so developing for the web often means that you can reuse a lot of that application amongst different devices and in different contexts.

It's unbelievable what the web can do these days.

I made the comment before we started, like, I can't believe this is a web browser that we're building, that we're doing this live streaming, video sharing, local recording.

All this stuff is just like, it's so wild.

And I built an app recently that I'm using to kind of help out with some of the interview stuff.

And it's on the web.

It just runs on my iPad.

I mean, it goes underappreciated some of the time, I think, of just how far you can push it.

It's not just documents and Ajax.

Yeah.

Yeah.

The fact that a version of Photoshop runs in the browser is pretty amazing.

And Figma itself is all running in the web browser.

So it's definitely a capable platform.

But one thing it's not very good at is, or doesn't have the ecosystem for, is a lot of data work.

And I think that that's really the big divide.

So I see the web is really like one of the most accessible platforms for building like user interfaces and like applications.

But then there's this whole other world, which is like tools that you actually do data science stuff in.

And that is not the web whatsoever, but has like a similar amount of maturity in terms of being very ergonomic and good at doing that type of work.

- Right, and those two worlds meet in, they meet in the web, right?

But the people doing the Python work, they aren't necessarily web developers.

You gave a talk a year ago about anywidget that I'll definitely link to.

And you have this graphic here like, okay, we've got the front end, which often is Jupyter.

Not always, as we'll see in a minute.

But often is Jupyter with the way you build for it is with all these web front end tools that even me doing web development is a lot of times I'm like, what is this?

And why is it so complicated?

I just don't even know.

And I do web stuff all the time.

And then you've got the backend stuff where Python people live doing NumPy, pollers, AppLotlib, et cetera.

Do you want to riff on that challenge a little bit?

Because I know your project is really here to kind of solve some of this disjointedness.

Yeah, I think one interesting thing, like taking a step back, and I mentioned this in the talk that I gave a while back, but like the web and Python ecosystems have been around for almost the same exact amount of time.

Like I think like the first webpage was around the same year that the first release of Python came out.

And so they sort of have been evolving in their own respective, or developing their own respective ecosystems for that period of time.

And then as the web became really this platform for building user interfaces, I think that some pretty visionary folks saw that you could connect these backend resources to these very interactive applications that could be developed very quickly.

So over the years, these things that started off very far apart have now come very close together.

And now with WebAssembly, sometimes it's just all the, like turtles all the way down, it's all actually running in the browser.

So it's pretty amazing.

But I think that there definitely is this friction.

And one thing I've also noticed from being in both these, the web and Python ecosystems for so long is sort of these like ebbs and flows of like maturity or like places that need to catch up to one another.

And so I came from definitely like the website originally.

And there's a lot that I took for granted, I guess, and that ecosystem of tooling that for a while, I think, gave the language a very bad rap because it was sort of the scripting language that was invented, I think, famously in two weeks.

And now people are trying to build applications in it.

But over the years, there have been standards and things have matured.

And actually, the web is very backwards compatible and has some of these properties that are kind of amazing for something that's been around for that long.

And then I'd say in the last couple of years, we've seen a bunch of new developer tool work going into the Python ecosystem that in some part is also inspired by some of the tooling in the web ecosystem.

So I love to see how these things go back and forth.

And I think if you haven't checked in on the ecosystem for a while, you might think it isn't what it was five years ago as it is today.

And one of the goals of AnyWidget is to try to demystify some of maybe those prior bad experiences folks had developing and just you know, get back to like opening up some HTML and writing some JavaScript and getting your Python

data in the browser.

Yeah, absolutely.

You know, I wonder, as you describe it being made in two weeks, which I also think this is true, when it was made, I think, at Mozilla, right?

Yeah.

Anyway, one of the JavaScript's real issues is it doesn't have a real numerical system, right?

Everything is afloat.

That has a lot of problems for data science when it really, really has to be integers or whatever, right?

Like you need more control over the numbers.

I wonder how much of Python's benefit in the data science space originates from people going, JavaScript's super popular, but can't do numbers there.

I do science, can't do JavaScript.

What am I doing now?

You know what

I mean?

What do you think about that?

It just occurred to me.

Yeah, it's interesting.

Like that is originally like a constraint of the language.

And maybe, you know, when you're picking ecosystems on.

Also, there was no server way to run JavaScript until 2010.

So the idea of just running this without a browser was also not very good.

So yeah, I'm not quite sure, but it's funny because JavaScript has sort of reacted to that by adding some big ints as a data type.

But also now there's sort of like a fourth language for the web, which is WebAssembly, and there are proper data types in WebAssembly.

So I guess it is sort of reactionary, but I haven't really seen.

So now you can run Python in the browser.

And, but you'd have to have all this like ecosystem grift or migration that I just don't think anybody wants.

So it's more, maybe these ecosystems can play a lot nicer together.

Yeah.

Yeah.

And certainly they are with things like Jupyter and stuff, right?

Like most users

of Jupyter don't write JavaScript.

Yes.

And I think that everyone's happy about that.

So

exactly.

That's true.

There's a lot of people are like, you know what, that's not for me.

So, you know, you were at Harvard doing your work and now you're at Marimo?

Marimo?

I always mess up saying this.

Tell us how to do it.

It's Marimo.

Marimo.

Okay, Marimo.

Yeah.

And I'd actually on, and I know we talked a lot about it and he set me straight and then I drifted, I'm sure.

So what's your experiences here?

Like, how's it coming from academia to this world?

It's been great.

I think that having worked with, so part of AnyWidget was trying to address some user needs working inside of Notebooks.

And there's only so much that you can do as a plugin to get that extra bit to help users.

And so I think one really exciting thing about working on this team with Marimo is they got very involved, or they were aware of AnyWidget a while ago, and they kind of actually legitimized AnyWidget as, hey, this is a standard because we were able to implement around this specification.

And so that got us together.

And then from there, it's just been super exciting to work with a team that is so passionate about notebooks and thinking about this next generation of notebooks and what that environment needs to look like.

And so there's much more that we can do inside of Marimo beyond the AnyWidget specification, but also AnyWidget is an important component of that.

So I like to be able to sort of think about both of these two worlds.

That's cool.

So when I use widgets in Marimo, it's often an AnyWidget?

Yep.

Yeah, exactly.

So if when folks usually come and they want to like extend Marimo with their own custom UI elements, like our answer is you should make an AnyWidget.

So that's pretty exciting.

But then if you're using things in like the sidebar or things that like sort of integrate outside of like the notebook view, those aren't more custom elements that we've created at Marimo that aren't necessarily based on AnyWidget.

This portion of Talk Python To Me is brought to you by Sentry.

Let me ask you a question.

What if you could see into the future?

We're talking about Sentry, of course, so that means seeing potential errors, crashes, and bugs before they happen, before you even accept them into your code base.

That's what Sentry's AI Sears Code Review offers.

You get error prediction based on real production history.

AI Sear Code Review flags the most impactful errors your PR is likely to introduce before merge using your app's error and performance context, not just generic LLM pattern matching.

Seer will then jump in on new PRs with feedback and warning if it finds any potential issues.

Here's a real example.

On a new PR related to a search feature in a web app, we see a comment from Seer by Sentry bot in the PR.

And it says, potential bug, the process search results function, can enter an infinite recursion when a search query finds no matches, as the recursive call lacks a return statement and a proper termination condition.

And Seer AI Code Review also provides additional details which you can expand for further information on the issue and suggested fixes.

And bam, just like that, Seer AI Code Review has stopped a bug in its tracks without any devs in the loop.

A nasty infinite loop bug never made it into production.

Here's how you set it up.

You enable the GitHub Sentry integration on your Sentry account.

Enable Seer AI on your Sentry account.

And on GitHub, you install the Seer by Sentry app and connect it to your repositories that you want it to validate.

So jump over to Sentry and set up code review for yourself.

Just visit talkpython.fm/seer-code-review.

The link is in your podcast player show notes and on the episode page.

Thank you to Sentry for supporting Talk Python To Me.

Why Marimo?

I know I had Axion people talked about.

When I look at this, it feels like a super modern UI that is just, it's got a lot of polish and a lot of, it feels 2025 and working with it, right?

And it solves some of the, I consider Jupyter Notebooks like the world's most insane, not the world's most insane, the second most insane series of go-to statements that have no record of how you got the go-to, you know, it doesn't even say go to 10.

It's like, well, what did you go and run?

I don't know, like, look at the numbers, but there's like potentially, you know, some lost as you rerun them.

And it solves that problem as well.

But like, you know, what's the elevator pitch for Marimo?

Yeah, my elevator pitch for Marimo is that I think notebooks are incredibly important and that it's hard to deny that like they're a tool that many folks use to do their daily work.

But there are very few like guardrails to help you do that work and work on a team with other folks.

And so I think one of the big selling points to me with Marimo is just that you sort of get to free yourself from thinking about those go-to statements, and instead you have this very deterministic execution that sort of just feels natural.

As you write cells, they will re-execute.

And then on top of that, I think that Jupyter and Marimo have slightly different goals.

So Jupyter, when I showed that diagram, we had that diagram before, you have this split between these diversity of front ends.

So that's like you could use it in Colab, you could use a Jupyter kernel inside of VS Code, you could use a Jupyter kernel sort of within the Jupyter CLI.

But then there's all another requirement of that ecosystem is to support many different kernels.

So it's not just Python, it could be an R kernel, it could be a Julia kernel.

And so I think ultimately attention that ends up happening is like a priority of that ecosystem is to support all these languages and all these different front ends.

And instead, by just focusing on Python, we can really try to develop a really integrated and rich experience specifically for Python notebooks.

So the trade-off there being some folks come and they say, oh, we'd love Marimo, but for R.

And we're like, well, we can't really do that.

It's called JupyterLab.

Yeah, but we are hyper-focused on Python and that lets us integrate with other trends within the ecosystem too.

So we're a huge fan of all the work from the astral folks.

And we have a tight integration with uv, for example, to allow you to sort of use that PEP 723 script metadata.

And as you're working, we'll like install packages for you and write that metadata so that at the end, you can send that document to someone else and they can like bootstrap their notebook and get all their dependencies and have their environment set up.

And I think that type of like last mile with these notebooks is something that's been hard to get at without really focusing on like an ecosystem.

That last mile though, that's a lot of polish.

And that's often what kind of gets lost in projects where, I don't know, it's not exactly the focus, right?

It's something where you want to take on the most interesting features and it's not like it's necessarily a company and there's somebody who's like, no, we're polishing every little rough edge, period.

You know what I mean?

And I think you mentioned Astral and uv.

I think that is an example of they got funding and it's like, okay, we're not going to do 95% of the packaging.

We're going to do 99.9% of the packaging.

You know what I mean?

And it's made a tremendous difference.

Yeah.

Yeah, I mean, I have plenty to say about Astro.

We love all their tooling over here too.

Yeah, so do I.

I switched all my stuff to Astro and it's to uv and rough and yeah, super, super neat.

Okay, so another thing that you all just released is a new VS Code plugin.

So I guess one of the aspects of Marimo that is not necessarily apparent from looking at it going there is that it's backed by a Python file, not a JSON file that contains both the inputs and outputs, which is like one of the big shortcomings of Jupyter.

Like how much of Jupyter would have benefited if it just had an input in an output file?

So you don't check in the output

file potentially.

You know what I mean?

Yeah.

Yeah.

We, I think that was pretty visionary or maybe it was just, it's more that we have this ability to observe what's happened in the Jupyter ecosystem

and make adjustments from there.

A little bit of a second mover benefit of like, we saw that, That was 80% good.

Definitely.

Yeah, it was surprising.

I mean, I think to rip more on Marimo, just there are all these, when people ask that question of like why Marimo, I think there are all these like very small things, but like that in net, I think are certainly like a order of magnitude kind of like richer experience for our users.

But it's funny how many times just the fact that like our notebooks are get diffable, that's like one of the first things that folks like really latch onto and love about Marimo notebooks.

Yeah, yeah, very cool.

And so the VS Code extension, what's the, like, how's this, how's this help us?

Yeah, so I see this as, I think the best experience with using Marimo will always be sort of our CLI or like our, our web interface that we've like really curated around this experience.

But we have a broad range of users that want to collaborate or work on Maremo documents.

And so some of them are like, you know, I live in my VS Code, my cursor, my Windsurf, my IDE, and like I never want to leave this environment.

And so getting them to come and like collaborate on these documents has been a little bit of a barrier there.

So they could, of course, edit a Python file on disk, but having like a native notebook view like they do for Jupyter was something that we sort of lacked in those environments.

And so we made it a priority shortly after I joined the team where we really wanted to address that user base of folks that want to live in that editor environment.

And sort of from the ground up wrote this new extension where we have a very integrated view with sort of reactive outputs, similarly to what we have in our user interface.

But it sort of lives inside of the VS Code ecosystem and uses the VS Code APIs.

Yeah, that makes a lot of sense.

and it's available on the, what is it?

VSX open marketplace for like cursor and anti-gravity.

That's a thing as of like three days ago.

Yes, all these different skins of VS Code,

our extension should work as well.

And we publish it to both marketplaces.

So folks should be able to install it and get started.

It's a weird time for editors.

Yes.

It was really kind of straight.

When I first started Talk Python 11 years ago or whatever it was, I would ask people what editor they use at the end of the show I didn't know what they were going to say.

It could have been anything.

And then it just narrowed down to VS Code, PyCharm.

Those are the answers.

And now it's kind of back to a lot of options again.

But it generally works in the VS Code variants as well.

All right.

Super cool.

Okay.

Let's talk about just what is a Jupyter widget?

Yeah.

So like I mentioned before, Jupyter really

reaches, and Marimo also, reach across this chasm between your Python code that's running in some, we call it like a kernel environment that's like a stateful environment that has your variables and when you run cells like things update there and then on the front end there's like the cell outputs that um are reflection of like whatever is sort of like living in the kernel and a jupiter widget is like a very interesting part of that like uh of that uh crossing of that chasm and that you can actually author both the front end code and the back end code to talk to one another so typically it's like you're if you write a python library you're only writing something that runs on the server.

And then if you're making a Jupyter extension, for example, that's something that only lives in the front end.

But a widget allows a library author to connect those two worlds together.

And so for your small object that lives in the Python kernel, you can define ways that it can render itself and also be updated from that front end.

And so it's a very powerful mechanism that's officially a part of Jupyter that allows you to extend your output cells with, I like to think of it as these web-based superpowers to be able to update your code in the kernel.

You have a really interesting point that you made in your SciPy talk, saying basically, we can do lots of UI stuff in notebooks, but often those are kind of like isolated snapshots, right?

Maybe you have a graph and there's like outliers or something along those lines, but you can see them, but you can't like programmatically interact with them in the way that you could a widget, whereas you might drag and select to get a zoom area that actually becomes a data frame, or you could move some widgets that then redraw the picture, but also becomes something you could program against in like a machine learning algorithm or whatever, right?

Maybe I think that's a pretty powerful distinction that people want to have in mind as

we dive into anywidget.

Yeah, definitely.

I like to think of it as like in a traditional like REPL kind of environment, like your two modes of input are sort of like writing code and running so you can write the code and you can run the cell and then you can observe the output but in order to like act on something that you see in that output you have to write more code so um if you have a plot for example that you produce from one of those outputs if there's some outliers or something a very natural thing to think is what is that point and you want to like circle that point and that is much easier to do with a gesture than it is to express as some sort of like query in in uh typing out some program and kind of looking at the axes to say like what are those points there.

And so I think widgets really allow for you to be creative in terms of how you might like another mode of input for adjusting things that might be in the kernel.

And like you're saying, now you can transform a selection into just a data frame that you get out and now, and then you're off to the races with running the next part of your program.

And so I think it, it adds this degree of freedom to like let the algorithms and data, like use code when that's useful.

And then for those pieces where you want to step in as a human and maybe use a gesture and that's easier to express as a gesture, then we have that mechanism now to allow you to extend your analyses.

Right.

If you don't need pictures and interaction, just do it in Python straight.

You know what I mean?

You don't need notebooks.

And part of the value of notebooks is this mix of like a visual plus code plus visual and this sort of iterative back and forth between those.

And widgets reconnect the visual back to the code, I guess, right?

Yeah, exactly.

I like to think of it as the types of workflows in notebooks are not typically batch scripts.

I mean, in Marimo, you can write your notebook and run it as a script because it's just Python.

But often when people are working and really getting their hands on data, these are long-lived sessions where you have a lot of data in memory and you really want to get your hands on that data.

And I think if you only had the ability to write and run cells and not add that extra dimension, it would be pretty limited to what you could actually do.

And so something like widgets allows you to really extend and be creative with how you'd like to explore that data and sort of like debug your data as it's in memory and get your hands on it.

Yeah.

Yeah.

I mean, that's what blew the world open when all that came around, right?

Yeah.

So that brings us to anywidget.

Why a new widget framework?

Why not just IPy widgets or whatever?

Yeah, it's a great question.

And it's something that when I started my PhD, like I was not, I guess I didn't really have a hand on either.

But AnyWidget was definitely born out of a need of myself to like solve a problem that I was running into during the PhD.

So as I mentioned before, we had all these visualization tools that we were building sort of in.

And specifically, one of the tools I was building was a like a web-based genome browser.

And so this is something that people put their genomes into and you can align different tracks and you can zoom in and try to understand like different types of things.

types of functional assays in genomics.

And then we had users that wanted to use these inside of computational notebooks.

And one thing that immediately happened when we tried to build these integrations for notebooks is that you'd spend all this engineering effort trying to build an integration for a specific notebook.

But then someone would come in and say, oh, I'd actually want this to work in Google Colab, or I need this to work in VS Code, or I need this to work in this other environment.

And all of those environments are very similar on the back end but they're very different on the front end in terms of the way that you can register like front end code.

And so it ended up putting a lot on a library author like myself to try to build those adapters for each of those environments.

And so anywidget was sort of an attempt to standardize maybe how we can write that front end code such that it's more, and then we can build those adapters in one place that then we can support all those different environments.

Right, right.

We talked about building the widgets largely in JavaScript earlier already, but I think what people maybe who haven't tried this don't realize is how many variations you would have to build to say, have I also, I wanted to work in Jupyter and I wanted to work in Colab and you've got to build and publish the PyPI and NPM and right.

There's like, so everyone who built one of those had to, and wanted to cross use, they had to do all those adaptation, adaptation.

So, and your thought was basically, well, I could create an adapter that everyone could use and then we don't have to do this ever again.

Yeah, exactly.

And to what you're saying as well, I think that adapter craziness that's in the web ecosystem of like, oh my gosh, I had to transpile my code into all these different formats.

It's kind of a nightmare in terms of tooling.

And it's something that came as a result of the state of the JavaScript ecosystem being pretty immature before 2018.

And basically because JavaScript didn't have a module system.

And so everyone had to come up with a way to bundle code.

And there are all these third-party adapters.

They're figuring out a way that they could load JavaScript modules.

And so whatever these tools chose and the way that they chose to load their front-end code would affect the way that me as the library author would need to package up the code.

By modules and loading, you're talking where people might see the word require at the top or something like that.

Kind of like our import.

Yes, exactly.

It's very much like import statements in Python.

And in fact, the official, if you open up your browser, you can just type, you can use a syntax that's called ES modules and type in import.

And you can import a bit of JavaScript code via URL.

And this just works natively in the browsers like today, but wasn't sort of standardized until late 2015, or late 2018.

So you mentioned require, that's actually a different module system that's not based in browsers.

And if you were to type require in your browser, that would not work.

And that is sort of like the tension that was the JavaScript ecosystem.

So I was aware of some of the trends and things that have happened post this new module system because I've been working in the web ecosystem.

And yet when I came to work on like Jupyter widgets specifically, there was like, I felt like I was writing code like I had been like a while ago for the browser.

And so the idea behind anywidget was to like, let's just simplify this so like that my source and the code that I publish is more like what the browser understands natively.

And then we take care of this like transpilation stuff once for everybody and package that up inside of anywidget to deal with sort of like the legacy module systems of like JupyterLab, VS Code, and a Google collab.

This portion of Talk Python To Me is brought to you by JetBrains and the PyCharm team.

The PSF, the Python Software Foundation, is a nonprofit organization behind Python.

They run or oversee the conferences, handle all the legal business to do with Python, oversee the steering council and other groups, and much more.

But let's focus in on one key word here, non-profit.

Unlike some software ecosystems, which grew out of and are supported by a single tech giant, think.NET and Microsoft or Swift and Apple, Python is by developers for developers.

That makes it a truly special place.

Everyone here is here because they chose to be here.

It's our garden.

and we have to tend it.

That means supporting the ecosystem, and a big part of that is supporting the PSF.

That's why I was thrilled when JetBrains and the PyCharm team in particular reached out to me to help spread the word about their PSF fundraiser.

Here's the deal.

You can purchase PyCharm Pro for 30% off this week until December 19th, 2025.

And when you do, not only do you get a deal on PyCharm, but the PyCharm team will donate all the proceeds to the PSF.

Let me say that again because it's easy to miss.

They will donate all the proceeds to the PSF.

And a positive addition this year is that this also applies to renewals, not just new customers.

So if you're already a PyCharm fan and customer, renew this week and you get a discount plus you support the PSF.

To take part in this, you'll need to be sure to use Talk Python's exclusive promo code, STRONGERPYTHON, all caps, two words.

That's STRONGERPYTHON for the code and the link is talkpython.fm/PyCharm dash PSF dash 2025.

Both of these are in your podcast player's show notes.

Thank you to PyCharm for supporting the show.

I'm trying to decide if I feel like it's in the interest, if the motivation of any of those platforms would have been to create something like this, right?

Like the Jupyter people are like, I don't know the problem.

You just write for Jupyter and it works.

And the Colab people are like, I don't see a problem.

You just write for Colab and it works, right?

Like what is the platform people's motivation to create integrations and smooth the transition to the other ones?

That's one tension.

On the other though, they might have more stuff come to them if they make it more reusable across them, right?

So it's interesting that none of them

actually did that.

Yeah, I think, I mean, in hindsight, it makes sense why someone in my position, like, I guess, focused on this because it was like, I had two widgets and then times the number of platforms.

And then if something broke, you'd have to go fix it a bunch of different places and it just becomes a maintenance nightmare.

But one thing that's been really interesting is I think that there is a good pressure to support a healthy ecosystem.

So I'd say before anywidget, it was pretty complicated to create custom widgets.

And so one of my goals was I want the feeling of being able to author a widget to be very similar to the way that you can copy and paste code into a notebook, but move it into a file.

And then you could publish that to PyPI.

And that workflow always worked for Python, but there was no way to start prototyping a widget inside of a notebook before and then move it out.

And I really wanted to bring sort of, to lower that barrier to entry.

And then what I think came out of that is you get a much richer ecosystem of people that are willing to try and make things.

And then when there's a cool widget that comes out, then that's a good positive pressure for other ecosystems, because then people are trying to request, they go, hey, I want this widget to work in your environment.

And that puts more pressure on various environments to implement sort of a more standardized approach.

Or adopt a adapting layer like anywidget.

Yep.

Yeah, exactly.

Yeah, to sort of back you up here, Kostal says, thank you for building anywidget.

Having gone through creating an IPy widget, it was a lot of work.

So yeah, exactly.

Let's just take a tour through the widget gallery.

Like what widgets are available here?

Got some favorites?

Yeah, we definitely have some favorites.

I would say that one of the early adopters of AnyWidget is a fairly popular plotting library called Altair.

And it allows to do exactly what you were talking about earlier with selecting points and allowing you to get those back as data frames in the kernel.

So for a while, the way that Altair worked, and I think it still by default works inside of a Jupyter environment, is that it creates sort of an interactive output that isn't connected back to the kernel.

So you can get your output.

It feels interactive because you can zoom in and you can select and you can do all the things, but it's just a view.

Exactly.

That state, I like to think of it as like is trapped in the output and you can't get it back in the notebook.

And so what the AnyWidget does behind the scenes is it allows for that output to communicate back with the kernel, which then allows you to update an object or a selection and then run your cell again and view some output.

And just that bi-directional communication between your kernel and your front end allows you to do things like create a data frame that is updated when you select.

Yeah.

Nice.

Yeah, it's sort of that example we talked about the outliers before, right?

Yeah, exactly.

Altair's super cool.

You know, I talked to Jake Vanderplass about it when it first came out and it's very beautiful.

Yeah, Altair was actually, I think, how I got into open source contributions forever ago.

Like I made like documentation examples and it was very like, it was very fun to come full circle to actually have like a dependency that somehow like got back into that library

many years later.

Now you build something that makes it more, that supercharges Altair because now it has like bidirectional data integration sort of thing.

Yeah, yeah.

Yeah, that's wild.

Yeah, maybe just talk to people really quick about that.

Like you don't have to write a revolutionary feature to be part of open source.

Yeah, yeah, definitely.

I think my entry to open source was just I got interested in a plotting library and they had some open tickets for making examples for their documentation.

And I wanted to learn how to use the plotting library.

So then I started contributing to them.

And it was really like those interactions, I think, with maintainers that kind of got a tick in my head where I was like, oh, I think I like this way of working and communicate.

Like there's a lot of, I don't know, oftentimes the challenges in open source aren't so technical as they are just social and figuring out how to communicate expectations to different users.

And I think specifically interacting with Jake Vander Plaats and some of those issues, I think I learned a lot about that and I was attracted to trying to find new ways to work on problems in open source.

Yeah, awesome.

All right, well, that's number one with 10,000 favorites out of the community.

What are some others?

Some of the other, I would say like, so Vincent Womerdam, who is one of my colleagues and you've had it on the podcast any times before.

A couple times, yeah.

Yeah, it's created this draw data widget.

And I would say when this widget came out, this was very much, there are many different, it demos very well.

So the idea is that you have like a canvas that you can draw some points and you get those points back out as a data frame.

And yes, so Vincent has a nice Marimo notebook that's running in the browser.

Yeah, that's right.

There we go.

And I believe if you draw some points.

I don't like the brush.

I'm going to change the brush.

We've got precise data.

So you could have one kind of data set here and then you could go like, okay, we're going to do, you know, this is super interesting because maybe you say like the data kind of looks like this and I want to run an algorithm against it, but there's a ton of work to get the data in the right format.

You could just start, you know, kind of just visually doing these things.

And then you can go on and analyze it and do all sorts of stuff by just literally by drawing.

Yeah.

We found this is like educators are quite excited about like this kind of widget.

because it's like, hey, here's this, how does a random forest algorithm work?

It's like, okay, we can just draw a data set and then we can actually view how a classification would work over a specific type of data set.

And I think it's really that type of interplay between something that you can play with to create something with the data and then maybe you take scikit-learn or something and apply an algorithm and you can help build intuition for how these algorithms work just by plugging in with the actual workhorse of doing the operations and like computing, like your classifier.

But instead you have this new input, which is like allowing for a bit more play with like learning how those algorithms work.

Yeah, you have an algorithm and you say, I want to see how, if the data looked like this, what would happen?

If the data looked like that, what would happen?

And a lot of times people will result to generating that data with code, either by writing it themselves, using a library like Faker or something like that, you know, like, how am I going to get it?

What if it looks like this?

And here you just say, whatever looks like this, and you draw it.

And then you run your algorithm based on the output of it because it's a widget, an AnyWidget widget.

And then you just keep going.

It's super neat, actually.

Yeah.

Yeah.

So to go back to, I think, something you mentioned before as well, AnyWidget sort of serves two communities.

So I think for one, there are folks that never will ever need to touch or learn any JavaScript, but can just use these libraries like they would Python packages.

So the idea is, hey, I can pip install draw data, and now I get to use a scatter widget.

And I don't care at all how it works, but now I get to understand how this algorithm works.

But for those that are interested, they can go and learn maybe a little bit of JavaScript or progressively a little bit more JavaScript to create something and package it up for many different platforms.

So you sort of have people that want to make libraries and then you have library consumers.

And depending on how much front-end stuff you want to learn, that's how deep you can go into either of those sides.

But I'd say probably many more people are just widget users and happily wire them together and don't worry about it and move on with their day.

And then there's some folks that maybe go a little bit deeper on the JS side and

learn how to create these interactive experiences.

When you say wire them together, do you mean like put one in a notebook in one cell and then another in another cell, but then say the input of it is the output of the other, that kind of wire together?

Exactly.

Yeah.

So you can really think of these as

like building blocks that you can like compose inside of a notebook environment.

And I think specifically in marimo a really cool thing is that when you update that value that lives in the kernel that cell below will rerun so now it's not just like you do the thing and then you have to manually rerun the cell you actually start to build up based of our reactivity graph like a little bit of an application of like i select some cells and now that reruns this python code and and if i have more cells that run after that it all is sort of wired up from this new input which is your widget

Yeah, I kind of riffed on this a little bit when I said like the world's craziest go-to.

And I said the second craziest because the most crazy is Excel.

But that's because the way Marimo solves that is it actually understands the way these variables used across cells.

So when I move a widget in one, it redraws.

It's like, oh, the thing that depended upon it also now has to change.

And then like you can, it cascades that execution across the widgets, right?

Exactly.

And that would normally just happen if you use our built-in UI elements or if you rerun cells.

And because it's just this reactive model where we trace the dependency, we just track what the dependencies are statically between your cells.

We know that when you update this property on a widget, we know it sells that you have to update that depend on that widget.

And so, yeah, it just sort of all falls out of this simple idea of your notebooks are a graph.

They're not just like this manual.

I think of it as like a lot of like running cells is like manual callbacks.

Like you, you like do something and you're like, oh, I have to click a callback and run it.

And by modeling it as a graph, we can run those for you.

And so that we know exactly what needs to update when this dependency of that part of the graph is invalidated.

I've talked to some data scientists who are like, that is both a feature and a problem that you can just be so freeform in Jupyter Notebooks, right?

Like I can just iterate and play.

And I think while you're iterating and playing, that freedom is great.

But as soon as you want to start making decisions, then it becomes like a real danger point, right?

Yeah, I think there's kind of a nice balance.

So specifically in Marimo, there are some requirements for how you have to write your Python code that are slightly more limiting than within a Jupyter environment.

And one that often trips folks up is that you can't redeclare variables across cells or else it would be ambiguous.

Like, is this the cell that defines X or is this the cell that defines X?

But I like to think of it as- Which order did you run it in?

That's the one.

Yeah, exactly.

That's tricky.

So we're fairly strict on that.

But what we believe is if you buy into this constraint, then we can give you all these properties, which are deterministic execution order and the ability to turn these scripts into reproducible, or turn these sort of open-ended workflows into more reproducible artifacts that have a deterministic execution order.

And so I like to think of it a little bit as like, I used to type Python code without type hints.

Then I started using type hints, and now I can't imagine not having any autocomplete.

And now I think like maybe our type, like when you start working with data in long-lived sessions, having some of these guardrails actually help you keep on track such that if you accidentally delete a variable, we'll let you know that you deleted it, and it's not something that the next time you boot up the notebook, you're just missing that variable.

So it's something that you buy into, but then I think has all these nice consequences that come out that--

- As a newbie, you'll see like, these things are not defined, or this library doesn't exist.

And you know what it does exist, you just skipped running the top import cell, or you know, that stuff's a little frustrating.

So during this talk you talked about, during your talk previously, you talked about like how anywidget allows you to write just enough JavaScript.

What do you mean by that?

- What do I mean by just enough JavaScript?

- Yeah, like, so one person's just enough JavaScript, another person's like, whoa, way too much JavaScript.

Sure.

So when I first started learning any front-end code, my experience was I opened up an HTML file and I just wrote some JavaScript on the page.

And I completely love this workflow for playing and learning how to write code for the first time in the browser.

But I think over the years, as people have started to build things like Figma and Adobe in the browser, there's a ton of tooling that has come up to help build those types of applications.

So many people's first experience with writing JavaScript is someone telling them that they need to learn React or learn a specific framework.

And then it's a bit like, well, this isn't technically JavaScript.

This is a flavor of JavaScript that we transform.

And so the experience that I wanted for anywidget was to write this standardized JavaScript code as sort of the entry point to your widgets.

So it should feel as simple as you could just open up browser console and start typing in code.

And the code that you write is exactly what the browser understands.

And so it should be dead simple from the beginning.

Just learning some APIs and probably pattern matching between, okay, this is some syntax.

But it should feel pretty familiar.

Should you want to learn those frameworks or use those frameworks, those all have the ability to be transformed into this standardized JavaScript.

And in fact, they have to be in order to run in the browser.

That's how that all works.

So I wanted that initial experience to be, if you want to learn and you've never tried it out before, send a variable and you can console log that variable and it just works.

But should you want to build something very ambitious and a lot of our most popular complicated widgets do use some of these frameworks, that's something that you can learn.

So I could do a view or an AlpineJS or I could do a React and all of that kind of stuff if I want.

Yeah, so in our documentation, there is like a, I think it's, I call it, we call it, we have like a little CLI to bootstrap a project that's like ready to be used with React.

And I think we had a contributor contribute one for Vue and Svelte as well.

And the whole idea there is like, yes, in order to, like, the tradeoff is that now you are introducing like some JavaScript build tooling into your, like into this process.

But hopefully if you're familiar with those frameworks, that isn't like a big overhead to trying out some of those things.

Versus like for the Python beginner that wants to learn something in the front end and they're just trying to get their data into the front end.

I just don't want them to have to worry about TypeScript or React or any of these things that they might hear about.

And instead they can just get started with trying to paint some pixels on the screen and then progressively learn outside of that ecosystem.

So the entry point will always be sort of this simple front end standard.

And then how far you want to go into that ecosystem, then you can experience more of like the tooling there to help with reactivity and things in the front end.

Yeah, that's super interesting to think of injecting little miniature view applications and stuff to allow that work.

But they are super powerful if you're willing to go through the build steps and all the hoops that those different frameworks ask you to do to get it to run.

And once you get it set up, it's like, okay, these things all bi-directionally data bind to each other internally.

And so I can see how that plays just like perfectly naturally with the already binding of the dynamic interaction here.

Yeah, exactly.

So we model this as like we have the standard, which is like this ECMAScript standard, which is the JavaScript code that you write.

And then all of the libraries are modeled as like adapters on top of that standard.

I think we call them bridges.

So in React, you get hooks that you can call, and then you're writing code that looks like idiomatic React, but behind the scenes, it's calling anywidget APIs.

And our Vue bridge does the same thing, but with Vue APIs.

So you get to write front-end code that feels like it's Vue-like or React-like, but behind the scenes, you have these custom bridges that are written by folks that are familiar with those frameworks for how they should interface with our standard specification.

Yeah, wild.

Let's talk about not using one of those, but instead talking through building a simple widget.

Now, just to be clear, I know we can't read all of the code audio version because most people just listen to the show, but maybe just give us a sense going through this.

You have a build a counter widget.

Yeah.

Or I can click a button and it counts or something.

Yeah, just walk us through, just to give people a sense of what does it mean to build one of these AnyWidget widgets.

Yeah, so the idea within AnyWidget is that you create a class that extends from a single class that's in anywidget called anywidget.

And that is what you define both your view, so the front end part of that code, and then also the back end code for that.

So it fully encapsulates the idea of a widget that has both a back end and a front end component.

Yeah, and just to be clear for people, let's say when you say a class, it's not one of those weird prototype JavaScript type things.

It's the more modern class keyword, but in ECMAScript, is that right?

Oh, sorry.

So right, what we're looking at here is just a Python class that's extending.

Oh, this is a Python class.

Okay.

Yeah.

A Python class.

Great.

And so you create a Python class, but then it has the JavaScript.

Exactly.

So ESM is like a private field that defines a front end module.

And the whole idea there is that you define a function that's called render that takes in two arguments, a model and an element.

So the model is like this object that talks back to the kernel.

And an element is whatever the front end, like Jupyter or VS Code gives you as like the output on the screen.

And so those two things combined, you can call methods on that model to set a value or get a value.

And then you can update some part of the UI.

I see.

So you're past like a DOM element, which might be a div or whatever.

And then you can just inject JavaScript, like a pen child and other stuff and set a class and whatever.

And that builds out the little, the part of the DOM that you control or it's given to you?

Exactly.

And then you can style that however way that you want.

And then the key thing is that as a part of this adapter, when you call methods on this model object that you get, I think there's only a few methods that are on it, like get, set, and save changes.

And that just synchronizes values back and forth between the front end and the back end.

And that same sort of API is on the Python side as well.

And so you can react to those values as they update or set them as well on the Python side.

And then we'll deal for the most part, like with serialization of simple data types to one.

So if you have a float or an int in Python, we'll just map that to a number data type.

We have that mapping in our documentation.

If you want to serialize to something like JSON, that's totally fine too.

And then you just send that over the wire.

Yeah, that's wild.

So how does it actually, so we've got a Python class, which I guess probably lives in the kernel.

And then it's got HTML JavaScript stuff it's doing that it's setting values.

What's this exchange?

Where do different pieces run?

How do they communicate?

Sure.

So that is up to the implementation.

So whoever builds an adapter for anywidget.

But the idea is that the front-end code that you write is in the standardized form.

So you can just call import and import this JavaScript module that you have.

And then the front-end is responsible for when these different methods get called on model for sending that data back and communicating over some sort of mechanism to the backend.

Jupyter already has defined something like that.

Yeah, so Jupyter has a notion of something called a com,

and that is implemented over a web socket to communicate back and forth.

And similar in Marimo, we're not based on Jupyter at all, but our any-witted adapter just talks over a web socket with some different messages.

But basically, we call this a host platform that takes care of that implementation and wires up those two ends.

But then as the widget author, you just care about like, here's my JavaScript module, here's my Python code.

And they use these APIs.

And then it's someone else's problem to figure out how to wire those up together.

Yeah, super neat.

Kasaasa, interesting thought here.

I'd be super interested to see this working purely in Python.

Front end running in Wasm.

No need for JavaScript streams in Python.

What do you think here?

Yeah, yeah.

I haven't played around with some of the PyDide or the PyScript APIs.

I think that that would probably be possible.

the example that you had of draw data before for the Marimo notebook that Vincent had that is entirely running in the browser so that is like the Marimo Python kernel is running in Wasm and then we're also loading the JavaScript code so we do have folks that just create a Marimo notebook and then compile it to WebAssembly and then they have a static website that has both of these bits together

Okay, that's actually pretty wild, isn't it?

So I've seen that there's some other places that I can, anywidget, like Myst.

Yeah.

And also Mosaic.

Tell us about these.

Yeah, yeah, definitely.

So Myst, I think on our community page, we have a notion of widgets, and then we have a notion of host platforms.

And so the two primary host platforms right now are things that are Jupyter-based, so like VS Code, Notebooks, Google Colab.

binder, like all these things that are based off of a Jupyter kernel and run Python behind the scenes.

Then Marimo is another host platform and Mist is currently working on an integration around that specification for the front-end code.

And so the idea is like as long as they have a way to, and I'm not sure how far along that is at the moment, but as long as there is a way to run Python code and sort of maintain that relationship between that front-end code and back-end code, then And you could drop anywidgets within your MIST markdown, for example, as well.

Yeah.

MIST is wild.

I had that team on the podcast a while ago.

It's like, you want to create an e-book based on notebooks or whatever, LaTeX paper, or you name it, right?

Yeah.

And yeah.

I haven't done anything with Mosaic.

Yeah, Mosaic.

I think this is a really cool project.

So at its core, Mosaic is a bit more of like an architecture.

And this is probably one of the things that I'm most excited about, like the ability that anywidget is bringing to folks to experiment with new types of architectures for building high-performance visualizations.

So inside a Mosaic, you have a notion of some database source that I believe is typically DuckDB.

And then you write a bunch of front-end code that basically expresses all of the data that it needs as queries to that database.

And then there's a lot of optimizations that can happen between those individual views and the database that can all be coordinated and allow for very scalable data visualizations.

One cool thing about Mosaic is that this architecture lends itself very well to notebooks because you can keep that database, that DuckDB running completely in the kernel, and then you just have your front-end client.

But then there's also an option where you just completely compile everything into WebAssembly, and then that DuckDB is running in the browser as well.

And so you get to reuse a lot of this architecture and allows just a lot of code reuse and you're just kind of moving that lever of like okay do i need like high performance compute okay let me put my database in my hpc and then i'll just have a thin client on top of it versus okay actually i want to look at everything in the browser like maybe we can just compile to web assembly and let someone drop in a csv and then we can use reuse the same visualization so yeah

this is super yeah that's super flexible duckdb has a very interesting WebAssembly story as well so yeah definitely it's definitely catching a lot of attention and people you know it's It's the data science SQLite, right?

Yeah.

And I'd say like a growing trend that I've seen by being able to, like one thing I didn't, that didn't fully, I wasn't fully aware of when I started on anywidget, but it has been fun to see is because it became easier to sort of start playing with like both front end code and Python code in the same environment.

Like there've been a lot more, I think, like experimentations around, like trying out new types of architectures for building like visualizations.

And so one trend that I've noticed in our community gallery is that a lot of our most popular widgets are taking advantage of new data formats like Apache Arrow to be able to send lots of data to the browser to put on the GPU and render very quickly.

And so basically, there's a really cool example of a widget called Lawnboard, which is a geospatial visualization widget, which is a wrapper around a front-end library called DeckGL that was made by Uber to do geospatial visualization.

And the previous Jupyter integration, like serialized data to JSON to be able to like render inside of DeckGL.

So the moment that you had to render maybe a few million points, it's like you're spending a ton of time serializing that data to be able to put it in the browser.

Right.

It's like using an ORM.

They're great until you try to do a query with 100,000 records.

You're like, why is this so slow?

Exactly.

And so I think there's an example with Lawnboard where some data set with like 3.5 million rows just like crashed in the previous, or never rendered, maybe it took a few seconds to render, or a minute to render.

But Lawnboard uses Apache Arrow and grabs that data from either Arrow, Parquet, or all these different file formats.

And that's very fast to do, because you just copy that buffer and ship it to the front end and put it on the GPU.

And so it can do that same example in, I think, one or two seconds on modern machines.

And so it really is this, get your data into a data frame and dump it on the GPU and visualize it.

And that whole idea of, oh, what format do I need to convert to to be able to use this tool, this visualization tool that I've heard?

It's like, no, no, no, just load it as a data frame.

And then as long as you get your data as a data frame, we can throw it into the web browser.

Yeah, super neat.

That's the kind

of stuff that normal web people don't think about, right?

You're like, well, how much is it to serialize a little JSON response?

Or, you know, we're talking about a million of them.

Oh.

Yeah, yeah, exactly.

And I guess one thing I've been impressed with is just at times where my understanding of how good computers have gotten is like, it's just shocking.

It's more like, oh, I think we're holding ourselves back at times by maybe some of the standard practices versus like, yeah, hardware has gotten very good.

And if you can make use of that hardware efficiently, there's quite a bit that you can do on very low powered devices and visualize a ton of data.

Yeah.

Quite a while ago, like really long time ago, I did some OpenGL programming and you see, you know, like here, we gave this, the scene a hundred thousand triangles and it's rendering at 200 frames a second.

You're like, how, how many operations is that?

Like, that is insane.

You know, this is like 30 years ago.

You were just like, that just blows my mind.

Yeah.

I think people underestimate what computers can do sometimes, especially if you work with them, right?

You're not doing three levels of serialization and deserialization and, and so on.

Yeah.

Yeah, exactly.

That's wild.

So what about publishing one of these things?

If we go and write, I've created an AnyWidget and it's amazing for me to use, but I want to put it on PyPI so people can UVPIP install it or whatever in their notebook.

Yeah.

So I have a couple.

One, I would recommend if folks are really interested in it, there's a couple of videos I have on my YouTube of just like publishing some widgets and they're linked in the AnyWidget documentation.

But that file that you see there, that's open in the current view that we have.

If you know how to publish a Python file, you can just publish that to PyPI.

and it should just work.

So yeah, the one caveat I'd have is like, you're looking at an inline string here, and that's not always the nicest way to write your front end code.

So you can also just import, like you can require that as a file instead.

And so you can put that code into a separate file, type check that or like lint it or like format it as JavaScript.

- So write a JavaScript file, and then somehow set just, would I just read that in Python?

And then just set the text result, like use path and say read text and then jam it in there?

Yeah, we support if you just pass a path, lib path to ESM, we'll read it for you.

Oh, okay, perfect, yeah.

So as long as I have a package and the package points out that these JavaScript files are to be included at build, then you're good to go?

Yep, and our starter kit template is all configured with Hatchling to do that for you.

Yeah, very nice.

Okay, and I've been using uv build, uv publish these days, and it's pretty seamless.

Yeah, yeah.

I think maybe we might need to update the build script to have uv build as the backend.

So, yeah.

Yeah, even if you do uv build against something with a different backend, I think uv just runs that backend instead.

So not a big deal.

Not a big deal.

So what are maybe some of the rough edges that people need to look out for these days?

It's got a lot of stuff that makes things easy, but what should they be maybe on the lookout for?

I think the thing that if folks are getting, Hopefully if you want to try out a widget, it should be as simple as installing any other Python package.

And that is really a goal that we've had for the project, is that if you want to use this like you would some algorithm library that just does computation, we want that to be as simple as pip installing and getting started.

I would say probably the highest barrier to entry is that it is just this idea of just enough JavaScript.

And so one thing that I try to emphasize in the docs is that I'd really start with a very simple example if you've never played around in the browser and get used to opening up your developer tools and logging things and just understanding how to develop maybe a little bit in the front end.

If you're coming from the front end side, then it would be learning a little bit more of how does Python work and how do I debug things on the Python side.

And what is PyPI and how do I even work with that thing?

Exactly.

So it's really, I'd say, most of the rough edges are just these problems of working with two language ecosystems.

But that's also been a very important part of AnyWidget because we don't want people that are ambitious to build things that sort of bridge this gap to feel restricted from either using things in the Python ecosystem or the web ecosystem.

Because we could always write wrappers to make things easier for authors, but then we'll probably get a bunch of issues that

then say, hey, I want to use this API and you haven't exposed it.

And they're like, hey, we'd like to use view, you're like, well, you use our Python thing that defines the DOM.

Like, oh, okay.

Yeah, exactly.

So with great power comes great responsibility, but we want to give that to people that want to build these types of integrations.

Yeah.

So what about agentic AI for this kind of stuff?

I know five years ago, you have to learn every step of the JavaScript.

How much can I say, take my inline JavaScript, put it into a JS file, and then point it at, you know, ask Claude Sonnet, hey, this is an AnyWidget widget, and this is the JavaScript.

and here's what I'm trying to accomplish.

I bet you could go pretty far with a marginal understanding of JavaScript as a Python person, plus some kind of AI.

What do you think?

Oh, yeah, absolutely.

I think, like I mentioned earlier, Vincent works and I work very closely together.

And his joke that he likes to tell is that I created anywidgets so that he could make anywidgets.

And the ability to vibe code sort of the front end for an object really is eye-opening if you've never tried it.

before if you're working with your data.

And I think one of the barriers maybe of trying out or of thinking about how to use anywidget is knowing when it might be useful.

And really, it's like anytime you have an object that you might want to visualize in a particular way or maybe extend with some extra capabilities in your notebook environment, that's a perfect time to open up some agentic tool and start trying to explain what you're thinking about.

because it's just JavaScript and not like a custom framework that we wrote or, and it's not like, they're very good at like writing this type of code.

And so sometimes you might need to, we have a set of rules to try to like help it, make sure it doesn't like try to do React or something, but it can go very far.

And because it's just like a view on top of like your data, it's like, it's kind of the perfect thing to play around with vibe coding, I think is.

It's incredible how far you can go with this stuff.

You can, you can give it your data source and say, here's the data source, here's what I'm trying to do.

And because the data sources often can be really foundational like CSV or whatever.

And then importantly, because it's just pure JavaScript, AI goes crazy on pure JavaScript and pure Python, right?

It's unleashed.

Yeah, it's crazy.

So to plug it back to Marimo for a second, I think because it's just Python and just JavaScript, it's a really fun environment to actually create anywidgets in.

And we have some integrations with like AI chat within our editor where we actually will inspect some of your Python variables and include that in the prompts as you're trying to work on things.

So if you're saying, "Hey, I want to make a widget and I want to visualize this data frame," you can actually tag the object that you want to start programming around.

And that will include things like the schema and stuff as it gives it to the model, such that then you get that sort of grounds it at least when it's writing that JavaScript code to grab the right columns and things off the data set and get to the ground running without you having to procure those things as well.

So it's a pretty fun environment to create these things.

It's a weird time, isn't it, that we live in?

Kind of magical and also scary, but just weird.

Yeah, definitely.

But very much fun as well.

I would throw out there, if people are interested, check out the Matt Makai episode I did on HHC programming three or four episodes ago.

And choose a good model.

I find people are like, I tried this.

It did a bunch of junk.

It's like, yeah, but use the free tier, right?

I see.

There's a big difference between the top tier models and the cheaper ones.

So, all right.

Where are we going?

What's the roadmap look like for anywidget?

Yeah.

So the roadmap for anywidget, I think looks a lot like trying to iron, like trying to get users to, or authors to understand some of these patterns that are like emerging in the ecosystem for like building some of these, maybe more like high performance, like visualization tools.

In terms of the library itself, there may be a few features that we want to add for users.

But I think one of the most important things is that we just ensure that we stay backwards compatible now that we have something that people are building around.

And so my call to action is just to try to get more folks, if they are curious, to try out building new widgets and let's keep this ecosystem pretty healthy.

And then on top of that, if there are places where folks are like running into limitations of like the specification as is, then getting like invested parties either from, you know, the implementers to try to understand like what APIs we need to add to support things in the future.

So, yeah.

Amazing.

It was up my mind, but I forgot to ask it when we were talking about this, where things run.

If this is running in the kernel and you're doing HPC type stuff, I could potentially use Rust or C++ as part of building my widget.

Is that right?

Yeah, definitely.

So one pattern we've seen is like, you know, you just try to do as little as you like just the interactive bits that you want in the front end.

And then you have the full resources of anything that you can do in Python on the on the back end side, right.

And because Python is such a language that has sort of grown to be able to be extended with all these like systems level programming languages, there's like a lot that you can tap into there in terms of like, yeah, high performance compute or like.

So my hope is that really we push user or push anywidget authors of creating like interesting interactive elements that then allow us to really like have that extra input into these like really scalable like ecosystem, data ecosystem that we have on the Python side.

Awesome.

PR is accepted?

Absolutely.

Yeah.

Yeah.

Yeah.

Okay.

So yeah, people can check it out here on GitHub.

Of course, we'll link to that.

And yeah, you got ideas.

All right.

Get in there and add it.

Yeah.

And we also have a Discord.

So folks, like you open up a notebook and you run into something or you just, you have an idea, like there's plenty of folks or I'm in there.

And I love to try to get people for their first bit of JavaScript ever.

I think it's pretty fun when someone has an idea and you just, we help them get there.

So like, but it's JavaScript.

Like, no, no, you're going to be okay.

It's not that much.

It's just enough JavaScript, right?

Exactly.

Whatever that means to you.

Exactly.

Just enough is so that my thing works.

All right.

Trevor, thank you so much for being on the show.

I really appreciate it.

And congrats on anywidget.

Looks super cool.

It definitely looks like it's all of any need and easy to work with.

Yeah, thanks so much for having me.

Yeah, you bet.

See you later.

See ya.

This has been another episode of Talk Python To Me.

Thank you to our sponsors.

Be sure to check out what they're offering.

It really helps support the show.

Look into the future and see bugs before they make it to production.

Sentry's Seer AI code review uses historical error and performance information at Sentry to find and flag bugs in your PRs before you even start to review them.

Stop bugs before they enter your code base.

Get started at talkpython.fm/seer-code-review.

And this episode is sponsored by JetBrains and the PyCharm team.

This week only through December 19th, 2025, get 30% off of PyCharm Pro, including renewals, and PyCharm will donate all the proceeds to the Python Software Foundation.

Support the PSF by getting or renewing PyCharm.

Visit talkpython.fm slash pycharm dash PSF dash 2025 and use the code strongerpython.

Both of these are in your podcast player show notes.

If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from complete beginners to async code, Flask, Django, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML, HTML.

And if you're not already subscribed to the show on your favorite podcast player, what are you waiting for?

I'm out.