New course: Agentic AI for Python Devs

PyView: Real-time Python Web Apps

Episode #535, published Fri, Jan 23, 2026, recorded Fri, Jan 9, 2026
Building on the web is like working with the perfect clay. It’s malleable and can become almost anything. But too often, frameworks try to hide the web’s best parts away from us. Today, we’re looking at PyView, a project that brings the real-time power of Phoenix LiveView directly into the Python world. I'm joined by Larry Ogrodnek to dive into PyView.

Watch this episode on YouTube
Play on YouTube
Watch the live stream version

Episode Deep Dive

Guest introduction and background

Larry Ogrodnek is a seasoned software engineer with a deep background in distributed systems and web development. He describes himself as a "recovering Java and Scala developer" who found his way to Python and fell in love with its ecosystem. Currently, he works at a healthcare technology company called Fathom, where he deals with medical coding automation.

Larry is the creator of PyView, a project that aims to bring the server-side rendering magic of Phoenix LiveView to the Python world. His motivation stems from a desire to simplify the modern web stack, moving away from the complexity of managing separate Single Page Application (SPA) frontends and returning to a model where the server drives the state and logic, while still maintaining the rich interactivity users expect.

What to Know If You're New to Python

If you are just starting with Python, this episode dives into some advanced web development concepts. Here are a few things to keep in mind to help you follow along:

  • Async and Await: The guest mentions using async and await heavily. This is Python's syntax for writing concurrent code, allowing the server to handle many connections (like WebSockets) efficiently without waiting for each one to finish before starting the next.
  • WebSockets: Unlike standard HTTP requests where you ask for a page and get a response, a WebSocket is a persistent, two-way connection between your browser and the server. This is how PyView pushes updates to the screen instantly.
  • Server-Side Rendering (SSR): This means the HTML for a webpage is built on the server before being sent to the browser. PyView takes this a step further by updating that HTML dynamically from the server.
  • Starlette: You will hear references to Starlette, which is a lightweight implementation of the ASGI (Asynchronous Server Gateway Interface) standard. It serves as the foundation for many modern Python web frameworks, including FastAPI and PyView.

Key points and takeaways

1. The Core Philosophy of PyView: LiveView for Python The central theme of the episode is the introduction of PyView, a Python implementation of the Phoenix LiveView paradigm. The core idea is to enable developers to build rich, interactive web applications without writing client-side JavaScript. Instead of creating a separate React or Vue frontend that talks to a JSON API, you write Python code that manages the state on the server. When that state changes, the server calculates exactly what HTML needs to update and pushes those changes to the browser. This drastically reduces the "cognitive load" of switching between languages and managing two separate codebases.

2. How It Works: The "Mount" and "Render" Cycle Larry explains the lifecycle of a PyView component. It starts with a mount function, which initializes the state (a simple Python dictionary). Then, a render method uses a template to turn that state into HTML. The magic happens when an event occurs, like a user clicking a button. This event is sent over a WebSocket to the server, which runs a handler function (e.g., handle_event). The server updates the state, re-renders the view, diffs it against the previous version, and sends only the changes back to the client. This makes the payload incredibly small and the updates very fast.

3. Leveraging the Battle-Tested Phoenix JavaScript Client One of the smartest decisions Larry made with PyView was not to rewrite the client-side library. Instead, PyView implements the server-side protocol required to talk to the existing, mature Phoenix LiveView JavaScript client. This means PyView benefits from years of optimization, edge-case handling, and reliability engineering that the Elixir community has already poured into their frontend library. It allows Python developers to stand on the shoulders of giants while staying firmly in their preferred language.

4. Escaping the "JSON API Churn" A major pain point discussed is the "churn" involved in maintaining SPAs. In a traditional setup, if you want to add a new field to a form, you have to modify the database model, the API serialization layer, the API client in the frontend, and finally the frontend UI component. With PyView, because the HTML is rendered on the server where the data lives, adding a field is often just a matter of updating the template and the database query. This unification of the stack can significantly speed up development iterations.

5. PyView vs. HTMX: Stateful vs. Stateless The conversation draws an important distinction between PyView and htmx. While both aim to reduce JavaScript usage, htmx is primarily based on stateless HTTP requests, you click a button, it fires a request, and swaps HTML. PyView, however, maintains a stateful WebSocket connection. This makes PyView better suited for high-frequency updates (like a stock ticker or a chat room) or applications where the server needs to push data to the client without the user initiating an action (like a multiplayer game).

6. The "Just" Command Runner Larry shares his enthusiasm for a tool called just, which he uses to manage tasks in his projects. It is described as a modern alternative to make. It allows you to define a justfile with recipes for common tasks (like just run, just test, or just lint). Unlike make, which has idiosyncratic syntax (like requiring tabs), just is designed to be a command runner first, with support for arguments, different shells, and .env file loading. It is a great productivity booster for Python projects.

7. Templating and the Promise of PEP 750 Currently, PyView uses a template engine called ibis (created by Darren Mulholland), which feels similar to Jinja2 or Django templates. However, Larry and Michael discuss the excitement around PEP 750 (Template Strings). This proposed feature for Python would allow for tagged strings (e.g., html"<div>...</div>"), which could enable a developer experience similar to JSX in React. This would allow templates to be type-checked and validated by Python tools, potentially revolutionizing how HTML is generated in Python web frameworks.

8. Real-World Complexity: The Map Example To prove that PyView isn't just for simple counters, Larry built a map integration using Leaflet.js. The challenge was: how do you control a complex, client-side heavy library like a map from the server? He utilized a feature called "hooks" in LiveView. This allows the server to push data (like a set of coordinates) to the client, where a small snippet of JavaScript picks it up and updates the Leaflet map. This demonstrates a hybrid approach where you write minimal JS only for specific DOM interactions while keeping the business logic on the server.

9. Deployment is "Just Python" Despite the advanced real-time capabilities, deploying a PyView app is surprisingly standard. Because it is built on top of Starlette and runs via Uvicorn, it can be deployed exactly like a FastAPI or Django app. You don't need a separate Node.js server to host the frontend. You can containerize it with Docker, throw it on a VPS, or use a Platform as a Service (PaaS). The discussion highlights how using uv (the fast Python package manager) further simplifies the setup and dependency management.

10. Managing State and Sessions A critical technical detail covered is how PyView handles state. Each user's connection spawns a lightweight process (or coroutine in Python's case) on the server that holds their specific state. This is different from a standard "stateless" web app where the database is the only source of truth. Larry explains that while this uses memory on the server, modern servers can handle thousands of concurrent WebSocket connections easily. For scaling horizontally, you would use a Pub/Sub system (like Redis) to synchronize events across multiple server processes.

Interesting quotes and stories

"Building on the web is like working with the perfect clay. It’s malleable and can become almost anything. But too often, frameworks try to hide the web’s best parts away from us." -- Michael Kennedy

"I consider myself a recovering Java and Scala developer. ... I was doing a lot of distributed systems work and then I found Python and just really fell in love with the ecosystem and the community." -- Larry Ogrodnek

"Every time you change the shape of your data, you're changing it in the database. You're changing the API. You're changing the serialization. You're changing the client-side model. You're changing the client-side validation." -- Larry Ogrodnek (on the "churn" of SPAs)

"It's basically just a Starlette app. So anywhere that you can run a Python Starlette app or Uvicorn, you can run this." -- Larry Ogrodnek

Key definitions and terms

  • Diff/Diffing: The process of comparing two versions of a document (or data structure) to find the differences. PyView uses this to send only the changed parts of a webpage to the browser, rather than reloading the whole page.

  • Pub/Sub (Publish/Subscribe): A messaging pattern where senders (publishers) do not program the messages to be sent directly to specific receivers (subscribers). This is used in PyView to allow different users (or different parts of the app) to talk to each other in real-time, like in a chat room.

  • HEEx (HTML + Embedded Elixir): The templating language used in Phoenix LiveView. PyView implements a similar concept using Python templating to ensure it can efficiently track changes in the dynamic parts of the HTML.

    +1

  • Latency Simulator: A tool (often built into browser dev tools or the framework) that artificially delays network requests. This is crucial for testing real-time apps to see how they "feel" for users with slow internet connections.

Learning resources

Here are some resources to learn more and go deeper into the topics discussed in this episode:

Overall takeaway

PyView represents a compelling shift in how Python developers can build modern, interactive web applications. By porting the proven architecture of Phoenix LiveView to Python, Larry Ogrodnek has provided a way to escape the complexity of the "frontend vs. backend" divide. It empowers developers to build rich, real-time user interfaces while keeping their logic, state, and data securely on the server, all within the language they love. Whether you are building internal tools, dashboards, or full-scale products, PyView suggests a future where "Full Stack" doesn't have to mean "Full Complexity."

Guest
Larry Ogrodnek: hachyderm.io

pyview.rocks: pyview.rocks
Phoenix LiveView: github.com
this section: pyview.rocks
Core Concepts: pyview.rocks
Socket and Context: pyview.rocks
Event Handling: pyview.rocks
LiveComponents: pyview.rocks
Routing: pyview.rocks
Templating: pyview.rocks
HTML Templates: pyview.rocks
T-String Templates: pyview.rocks
File Uploads: pyview.rocks
Streams: pyview.rocks
Sessions & Authentication: pyview.rocks
Single-File Apps: pyview.rocks
starlette: starlette.dev
wsproto: github.com
apscheduler: github.com
t-dom project: github.com

Watch this episode on YouTube: youtube.com
Episode #535 deep-dive: talkpython.fm/535
Episode transcripts: talkpython.fm

Theme Song: Developer Rap
🥁 Served in a Flask 🎸: talkpython.fm/flasksong

---== Don't be a stranger ==---
YouTube: youtube.com/@talkpython

Bluesky: @talkpython.fm
Mastodon: @talkpython@fosstodon.org
X.com: @talkpython

Michael on Bluesky: @mkennedy.codes
Michael on Mastodon: @mkennedy@fosstodon.org
Michael on X.com: @mkennedy

Episode Transcript

Collapse transcript

00:00 Building on the web is like working with the perfect clay.

00:02 It's malleable and can become almost anything.

00:05 Too often, frameworks try to hide the web's best parts away from us.

00:10 Today, we're looking at PyView, a project that brings real-time power of Phoenix LiveView

00:15 directly into your Python world while keeping the web elements front and center.

00:21 I'm joined by Larry Ogrenek to dive into PyView.

00:24 This is Talk Python To Me, episode 535, recorded January 9th, 2026.

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

00:52 This is your host, Michael Kennedy. I'm a PSF fellow who's been coding for over 25 years.

00:58 Let's connect on social media.

00:59 You'll find me and Talk Python on Mastodon, BlueSky, and X.

01:03 The social links are all in your show notes.

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

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

01:13 That's right.

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

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

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

01:26 Hey, everyone.

01:27 A quick announcement.

01:27 I recently added a pair of features to talk Python to me to make it work way better with AI.

01:32 For example, you can ask questions such as, what was the last episode?

01:36 Or which episodes featured David Lord?

01:38 The AI can use a couple of endpoints, a new MCP server implemented in Quart,

01:43 and the emerging llms.txt standard to answer those questions with 100% accuracy and real-time data.

01:50 If you use an AI that supports MCP, then take just a moment and install our MCP server.

01:56 If not, you can always point your AI at talkpython.fm/llms.txt to get it started talking about the show.

02:04 Weirdly, ChatGPT says it can't read that file on our website and it gets a 400 response code,

02:09 even though asking it to do so results in a 200 okay from the open AI bot in our logs.

02:16 Oh well, for chat, you'll just have to copy the contents into your prompt until they fix whatever weirdness this is.

02:22 I did a write-up for this on the Talk Python blog called Announcing Talk Python AI Integrations at talkpython.fm/blog.

02:29 The full link is in your later show notes.

02:31 I hope you enjoy this new way to interact with our over 7.5 million words of content at Talk Python To Me.

02:38 Thanks for listening. Now let's get on to the show.

02:41 Larry, welcome to Talk Python To Me. Awesome to have you here.

02:43 Yeah, thanks, Michael. It's great to be here.

02:45 I saw your project, PyView, and you're like, oh, hey, maybe you could just give it a little shout-out.

02:51 And I'm like, this is super neat, the way this thing works.

02:54 And as most people know who listen, I'm a big fan of web development.

02:58 The last episode that we just released, not actually the one,

03:03 time shifting because of recording podcasts, was with all the creators of the popular Python web frameworks as a panel.

03:09 And that was super popular.

03:11 So here we are back with another web topic, PyView.

03:14 And it's got a really, really unique twist.

03:18 And I think people are going to dig it.

03:20 It's quite interesting.

03:22 Gosh, I've been doing technology for a long time now, and I think the web has always just been amazing, right?

03:26 It's an amazing platform, and so I think that's why people

03:28 kind of gravitate towards web frameworks and interesting web technologies and what can you do now

03:34 and how can we make it easier?

03:35 Yeah, it's funny.

03:36 I did think PyView would resonate with you a little bit

03:37 just because I know that, I don't know if this is true,

03:40 but it seems like you do appreciate really not just like,

03:43 you know, obviously Python, but web technologies and especially like embracing web technologies

03:47 and maybe not necessarily kind of hiding them.

03:50 Yeah, exactly. That is one of the things that really appealed to me because there are some Python frameworks that build webmaps, but their goal is to pretend that HTML and CSS is really bad. It's like, you don't want to write a simile. We're going to put that away from you. You don't need to see this HTML or the CSS or any of those things. Get it away. And I feel like something is lost there.

04:14 Like building on the web is just, it's like the perfect clay, right?

04:19 It's, it is so malleable and it can become almost anything that you want it to be.

04:24 And a lot of those frameworks, I think they just miss that.

04:26 And I don't feel like what you built does.

04:28 So I'm going to be, I think we're having a good time talking about it.

04:31 No, thanks.

04:32 Yeah, I'm excited to get into it.

04:33 But quick introduction, Larry, who are you?

04:36 Thanks.

04:37 Yeah.

04:37 So my name is Larry Ogranik.

04:39 I've been a software developer for, you know, I guess let's just say over 25 years now.

04:44 I don't age myself too much. But through that time, obviously, I've done a bunch of different

04:48 things and worked at startups. I worked at big companies. I've worked at freelancing for a few

04:54 years even. And so my early career, it was more kind of on the C pro side, a lot of backend work,

05:03 diving into Java and then Scala. And when I was doing freelancing, obviously the language of the

05:09 tech kind of depended on the client wanted to do and what the project entailed. But that's kind of

05:13 to get more serious about using Python.

05:16 And nowadays, I work at a startup in the construction industry.

05:20 And we think of ourselves--

05:21 JOHN MUELLER: Oh, really?

05:21 Yes.

05:22 But we're really trying to invest heavily in technology

05:26 and software.

05:27 We're trying to be a technology-enabled home builder.

05:29 And so we have a huge investment.

05:31 And we have-- I mean, not necessarily a huge tech team,

05:34 but spending any money and employment on tech is kind of a big deal in this industry.

05:41 And I think it's an industry that hasn't really had technology get great adoption.

05:48 Different people are doing different things, but overall, there's been a hard time to kind of get it in that process.

05:53 But there's a lot of areas for improvement.

05:54 And so, you know, we're trying to make that process better, faster, smoother.

05:59 I think there's a lot of possibility for pick your underserved by tech specialization and build businesses around there.

06:08 If you're a Python developer or any kind of developer.

06:10 But if you really have the skill to build things like connecting APIs and automations and stuff,

06:18 it's just such fertile ground.

06:20 It's like, wow, there's nobody building stuff here that is like, good.

06:23 Let's go.

06:24 I could do this, right?

06:26 100%.

06:26 And I think, yeah, like, Tim, maybe to your point, there's a lot of kind of low-hanging fruit

06:30 where it's just like just even getting some of the information in people's heads in a structured

06:34 way and even having, like, different processes defined in a structured way.

06:38 Like, you get huge improvements from that.

06:40 And this is kind of just like why we love technology, right?

06:42 Is you have these building blocks and it's like, oh, now that we have this in a structured

06:45 format, we can actually do these interesting things with it that we couldn't do before

06:48 because it was just on someone's notepad or whatever.

06:51 And so, yeah, you're right.

06:52 I think there's still a lot of issues like that.

06:54 And home building is for sure a big one.

06:58 And yeah, it's been interesting.

06:59 I mean, our main, actually, construction platform that manages our construction projects.

07:05 So we have an interesting part of that, what you were saying, is it can be hard in underserved

07:10 There are underserved areas to sort of have that domain expertise.

07:14 And so you have to find a good partner.

07:15 And one of the things we've done is we actually build the homes.

07:18 So we're not just writing software for other builders to use, but we're building homes ourselves.

07:22 And that's been a huge benefit because we have people building homes that we can sit down with and say, like, does this make sense?

07:28 Like, does it not make sense?

07:29 Like, why, why not?

07:30 And, you know, we have to obviously push on both sides sometimes because we are trying to change things.

07:35 Right.

07:36 But that's been, I think it'd be almost impossible to do without.

07:41 It's the dog fooding equivalent, the software dog fooding, right?

07:45 Exactly.

07:46 You're building.

07:47 They're building, you're building.

07:48 So then you can.

07:50 I know.

07:50 And it can be frustrating to get these phone calls like, why is this working?

07:54 Like, you're going to make me late for this or that.

07:55 But, you know, again, like those having those really strong partnerships, like, I don't know, it's critical to be able to get something that actually works.

08:02 Yeah.

08:02 Well, it sounds actually super exciting.

08:04 I mean, I know you sold it.

08:05 It's like, oh, we're just building.

08:06 Just working in a building.

08:07 No, this is cool.

08:09 It's cool, yeah.

08:10 And for the last couple of years, I've been doing a lot on our kind of more AI services team.

08:15 And I'm not a machine learning researcher, but most of the work I've been doing has been around kind of productionizing that work and building services around it.

08:24 And we've done really cool stuff like with, I mean, just like pricing models for the homes, which is kind of more traditional machine learning stuff.

08:30 and then like schedule simulation stuff.

08:33 And more recently, a lot of LLM-based stuff, both for kind of like, you know,

08:37 rag style chat workflows.

08:38 Like you can imagine you're in the field and you're like, you know,

08:40 is this the right tile pattern?

08:42 And maybe that's buried on like page 500 of a Google spreadsheet or something like that.

08:46 And being able to pull up quickly is huge.

08:49 And now some of the stuff we're trying to do is more around automating schedule updates.

08:53 So someone can kind of walk through a home and just, you know,

08:56 do kind of stream of consciousness.

08:58 Like, you know, this is the status of like this, like, you know, this is running late, whatever.

09:04 And then we kind of, we have a multi-stage process, but we kind of, you know, turn the video into images and turn the transcription into notes and then try and like see what we can, what's in the photo, right?

09:14 Like, is that the right tile pattern? Is that the right stove? And use LLMs for different parts of this process to kind of, you know, come up with recommendations at the end.

09:23 like, oh, it actually looks like the drywall is totally installed and we can mark that as done

09:27 or whatever. And, you know, having the automation is actually super helpful because having up-to-date

09:33 schedules drives a lot of stuff, right? It's just like the efficiency of making sure people are on

09:38 site and not delayed is huge. So that's been really-

09:41 There's so many touch points of so many subcontractors and things, right? Like,

09:46 when is the plumber going to be here? Well, they need to be here when the inspection for plumbing

09:49 is here but that got you know like it's people who haven't gone through like somehow some kind of

09:55 a house like i had a big home home improvement it's not quite the right word but like this big

10:00 outside project with like a barbecue thing and so on done and wow after doing that i'm like there's

10:05 i've got a lot of ideas for making this better this is bad no i know right and some of those

10:11 delays are like super costly and it's funny because like a lot of things even in terms of

10:14 like budgeting like right like if you buy too much material that's bad because you're wasting money

10:19 But if you buy too little, that's actually even worse because like maybe, you know, you need more whatever lumber and maybe there's, you know, two weeks, you know, turnaround time to get it.

10:28 And so and again, if you have to reschedule things like inspections, who knows when the next available one is, it might push the project out, you know, weeks.

10:34 And so, yeah, there's a lot of interdependencies, a lot of, like you said, people and communication remains a very tricky problem.

10:43 That's always one of the things.

10:44 Well, it sounds awesome. And I'm also interested to see if your project at all touches on that. But let's dive in. Let's dive into PyView. Now, the first thing I want to point out here with PyView is it is not PyWebView, which has been around for three or four years at minimum. And I imagine that like a lot of people have seen this. PyWebView is a way to embed basically a browser into something that you can wrap as a desktop app. PyView, totally different. What's the elevator pitch on PyView?

11:13 Totally different. Yeah. So the later pitch in PyView is basically, you know, it's one of those self-referential things. Hopefully I won't try and say Phoenix LiveView, but, you know, when you're building, when you're building modern web apps, and this is one of the things that I've seen, right, is, you know, if you want to have this rich interactivity, you want to have like a really rich client experience, maybe you reach for something like React or Vue. And, you know, those are great frameworks.

11:38 But then you also have your backend server maybe managing the state and the database and those relationships and maybe talking to other servers.

11:44 Maybe that's in Python or another language, whatever.

11:47 And you kind of have to manage these two different pieces and they each have their own state.

11:51 And it's very, you know, there can be a lot of complexity when you, yeah, the client is showing something slightly different than the server or vice versa and having to synchronize that state and keep them in sync.

12:02 Plus, often there's a lot of glue code in between them, right?

12:05 Like having to just go from the Python backend to the JavaScript frontend and back and forth.

12:11 Even when things are in the same language, like I've worked on TypeScript apps where it's TypeScript backend and frontend,

12:16 it's kind of rare that you actually share a lot of code for that layer.

12:20 Things end up kind of drifting anyway and being different.

12:23 And so PyView, the idea is, you know, what if you can have your backend server manage all your state, you're writing all your application logic in Python, you're just rendering HTML like you would for a static site.

12:38 But when different interactions happen, like when you just click a button or enters a form field or, you know, different things happen on the friend end, we send an event to the server.

12:48 The server processes the event and changes its state.

12:50 So for example, maybe, I mean, this is a simple counter example, but you press plus on the counter.

12:55 Then the server increments the count by one.

12:57 It does a full re-render, but it does kind of a diff and says, oh, actually, looking at this full page, all I need to do is tell the front end to change zero to one.

13:06 And so it efficiently sends that over a WebSocket connection.

13:10 And I feel like there's already a lot there that maybe that wasn't the clearest description.

13:13 But the idea is kind of more like, can we get SPA level interactivity, you know, including things like multi-user presence stuff, server push, really fast UI updates, you know, really fast local navigation, not doing full page reloads.

13:27 But on the back end, our mental model really is something like a traditional static, you know, not static site generator, but like a static rendering thing.

13:36 So I don't know.

13:37 Was that clear?

13:39 I think.

13:42 Yes.

13:43 It sounds like a lot.

13:44 And what I think is cool about PyView is that it takes a lot of that

13:49 and it just makes it automatic over a simple programming API, right?

13:52 Yeah, exactly.

13:53 So that's the thing is you don't have to think about a lot of this kind of plumbing.

13:57 And this is the one kind of, I mean, we'll get into this more.

13:59 Like this is something that I, an idea that I came up with.

14:01 This is something that has been around for a little while on,

14:05 in the Elixir side.

14:06 It comes from this, this thing called Phoenix Live View.

14:09 But yeah, you know, a framework actually can take care

14:11 of a lot of this for us.

14:13 And so as developers, all we really need to worry about is updating our state when events come in

14:19 and rendering, doing a render of this.

14:22 Given the state, what should we render to the back end?

14:24 And the framework manages the Webseq connection.

14:26 It manages the messages.

14:28 It manages doing the diffing.

14:30 And so we don't have to think about any of that.

14:32 We really just need to think about how do I update my state

14:35 and how do I render the website?

14:37 And so it ends up being really powerful just having these very simple building blocks.

14:41 And this is the kind of thing that--

14:43 I mean, I'm not anti-JavaScript in general, but obviously we're using JavaScript on the front end.

14:47 But by having this very generic JavaScript layer that just

14:51 knows really simple things like, here's how I send messages when a button is pressed

14:58 or when a text field changes.

15:00 There's very simple building blocks, but you end up being this very powerful system

15:04 when you bring them together.

15:05 And you don't really have to write JavaScript for these interactions because, again, most of the things

15:10 are very simple.

15:11 It's like, you know, I need to change whatever.

15:14 Your project is pretty new, which I'm hoping to shine a light on it because I think it's going to get a lot of attention.

15:20 Out in the audience, Alessio points out that, hey, this is kind of like HTMX and Django with fragments, but over WebSockets.

15:29 And yeah, I feel like it does have some HTMX vibes.

15:34 And for those of you who haven't tried it, HTMX is like, you sprinkle just a couple of extra attributes on there.

15:39 And then somehow behind the scenes, there's additional communication that you don't worry about.

15:44 It's just say, oh, if somebody clicks this image, actually do this server thing and replace part of the page--

15:49 maybe the image, maybe something else--

15:51 with the server HTML response.

15:54 How do you feel that PyView, Phoenix LiveView sort of

15:57 relates to that and like Datastar, who I'm going to have on the--

16:01 Yeah.

16:02 No, I think that's right.

16:03 I think that's a very thoughtful comment, because I think that is a lot of it.

16:09 And if I had to think in terms of comparisons to different frameworks, I think doing something with HTMX

16:16 probably is the closest comparison.

16:18 Because again, it's HTML based.

16:21 We are responding to events and wiring up to the server

16:25 and processing them and sending back HTML fragments.

16:28 I think the difference is that PyView is a little more structured, right?

16:32 Because with HTMX, you have a lot more control, which can be a good thing.

16:38 But it's a little more--

16:40 you're kind of wiring up these things yourself to a certain extent, saying like, when you click on this,

16:45 call this back end route and replace the contents of this

16:51 element with the response from that.

16:53 And on the back end, you're sending full HTML and things like that.

16:56 So that's one difference.

16:58 So yes, it is over WebSockets with PyView versus HTMX.

17:01 The other thing is we do have this kind of diffing technology

17:05 where we're only sending what actually changed.

17:08 So I mean, we can go into more detail at some point about how the templating works.

17:15 But for something like changing the encounter from 0 to 1,

17:17 it's like we're really just sending back the 1.

17:21 And obviously, as the page gets more complex, the diffs get more complex.

17:25 But we're just sending the diffs.

17:26 And again, the framework kind of handles--

17:28 no, you don't have-- as a developer, you don't have to think about what part of the page

17:31 do I update.

17:32 And it's kind of encoded to a certain extent in your template.

17:34 you know, it's kind of more hands-off.

17:38 And so you do give up some flexibility, but then, you know, the framework kind of gets to handle

17:43 a lot of things for you in a smoother integrated way, I would say.

17:47 Just handles it.

17:48 Yeah.

17:49 With HTMLX, which I am a fan of, you have to think about every little piece.

17:53 And you say, if somebody interacts with this part, then I want this action to happen.

17:58 And then this thing over here, you know, these parts of the pages are going to be

18:02 where the response of the server gets redirected back into.

18:06 And it seems like it's more just handled a little bit here.

18:10 Let's talk a little bit about Phoenix Live View, because while your project is pretty new, Phoenix Live View has,

18:17 I don't know how old it is, a couple of years, it looks like,

18:21 but it's got 6,700 stars.

18:24 So it's a really solid foundation.

18:26 And your project, what's the relationship between PyView and Phoenix LiveView?

18:32 Right.

18:32 So LiveView is obviously the inspiration for PyView.

18:35 I think, you know, when I mean, I don't know, when I started thinking about like,

18:40 you know, there's got to be a better way to building these kinds of apps in Python, I came

18:44 across Phoenix LiveView and kind of really loved this model, especially just, I don't

18:48 know, I kind of, I do like thinking this event kind of base system.

18:52 And it seemed like, yeah, you get all the really nice things for free.

18:55 So definitely was the inspiration.

18:57 And then when I started working on PyView, I had the thought like, well, they've already kind of figured out a good model for how this works and how things fit together.

19:04 And they already have a good client side story for implementing the client side component of this.

19:09 So what I tried to do with PyView is actually use, you know, I ship their Phoenix LiveView front end client JavaScript is what you're running in a PyView app on your front end.

19:20 And I kind of implemented a Python backend.

19:23 So if you think about LiveView as a protocol, which to be clear, it is not.

19:28 There's sort of just some, you know, have to do some reverse engineering of how things work.

19:32 It's not really documented because I think, you know, on their end, it really is an internal implementation detail about how the front end communicates with the back end.

19:40 But, you know, we get the, that really was a huge boost for me because I get to use their client JavaScript, which handles all the diffing.

19:48 And again, a big part of it too is just kind of they do have a really nice design.

19:51 So like you mentioned, Phoenix Live View has been around for a while.

19:54 It's a very popular project.

19:55 I think if you are in this ecosystem, so it's written in Elixir, which is a different programming

20:01 language that runs on the Erlang virtual machine.

20:04 And just to be clear, it's a totally great language.

20:08 It has a lot of really cool features.

20:09 It's nothing against Elixir.

20:11 It's just that for different reasons, I wanted this paradigm in the Python world because I'm

20:17 I'm working, you know, especially at work, I'm working on Python apps.

20:20 And that's the kind of world I live in.

20:22 And, you know, it's, it's, we can't change everything over to different languages.

20:26 Just, you know, I'll throw it out there for you.

20:28 You don't have to take the bullets.

20:30 But I think functional programming languages are super interesting.

20:34 They apply really well in certain to solve certain problems.

20:38 And I know some people, it's the hammer for all nails.

20:42 But for most people, functional programming is, it's just not what they're working in.

20:47 you know, things where you can change variables and have state turn out to be more productive

20:53 ways to write code, even if it maybe is not provably as correct or as thread safe or whatever,

20:59 right?

20:59 Like, so if most people are going to adopt it, most people are not using functional programming

21:05 languages and Erlang in particular, Python happens to be more popular than Erlang.

21:09 Yeah.

21:09 Yeah.

21:10 Well, there's different, I'll let you take those bullets, Michael.

21:13 But yeah, I mean, look, different languages are good for different use cases, right?

21:16 And but again, I think it's a really great idea that I thought, let me steal this.

21:20 And so, yeah, this is something that was written by, I think, Chris McCord is like the author of Live View.

21:24 And it's been around, yeah, for a long time.

21:26 It's gone through different iterations.

21:28 But yeah, it's incredibly popular in that ecosystem.

21:32 And yeah, they've done, I think, really great, great things with it.

21:35 Yeah.

21:35 And let's I just want to give a little shout out.

21:38 If you go to the Phoenix Live View GitHub, which, of course, I'll link in the show notes, there's a live demo on Fly that you can check out.

21:46 And there's also a two minute video.

21:49 Watch the two minute video.

21:50 It really shows like, okay, this is a quite an interesting and quite capable technology.

21:56 It might sound like, oh, you can't do very much with this because I don't know.

22:00 It seems like it's only built to make a few things easy.

22:03 I, after watching what he built there with this app with Phoenix Live View, I was impressed.

22:08 It's quite flexible.

22:09 No, for sure.

22:09 And there's a lot of, I think it took a lot of work to get there too, right?

22:12 Just to give, you know, them a little more, a lot of credit, like, because a lot of the

22:16 I mean, it's interesting because like once you take this approach to being having everything over WebSockets, well, then actually it's pretty great because it opens up a lot of things that could be hard, like things like, yeah, like presence, like knowing different users that are, you know, on the same documenter page as you or like server pushes.

22:29 You kind of get a lot of that stuff, not, you know, for free, but it's easy when that's kind of your base layer is everything over WebSockets.

22:35 But then some things like file uploads, like as part of this, they invented a way to kind of do file uploads over WebSockets.

22:43 Oh, that's interesting.

22:44 Yeah, because how do you do that, right?

22:48 And WebSecrets do support both like text and binary messages.

22:51 So it's not as crazy as you would think, but there is like a limit to, you know, you have to kind of, you know, chunk it and stuff like that.

22:55 But so it supports that.

22:58 And, you know, I mean, again, we can talk more about file, but there are other options for also going like direct to S3 or, you know, different things.

23:04 But, yeah, you know, a lot of work has gone into this and including around the optimization.

23:08 Like, what is that message format?

23:09 Like, how do you send minimal diffs for not just things like, you know, simple template changes?

23:14 but when you have lists or components or maybe you have huge lists of things,

23:20 how do you efficiently manage that on both the server side and the client side? And so I think

23:24 there's a lot of great ideas for dealing with this that were pioneered by Phoenix Live View that I

23:29 get to come along and kind of just steal. That's cool. Here's the downtime version.

23:36 Yeah, exactly. And I think that's kind of was like a lot of the focus early on was trying to

23:40 to stick to this just because, again, PyView, like you said, it is very early days and it is just

23:47 kind of like a personal side project. Although I am using it at my day job for a couple of production

23:51 apps now, which has been fantastic. But as a single developer with a Python web framework as a side

23:59 project, it was great to have a little bit of a roadmap on if I follow these patterns, I'm probably

24:03 going to end up in a good place. And I did. Of course, I did try and make things more Pythonic

24:08 where I could.

24:11 So PyView is very heavily typed.

24:13 So we're using obviously Python types for everything.

24:15 Whereas Elixir, I think they're adding types now.

24:19 It's been an ongoing thing to add some gradual typing like Python has done.

24:23 But Python is a little further along in terms of the typing story there.

24:27 And I think over time, maybe we'll diverge a little bit

24:31 in terms of making the APIs more Pythonic to the extent anything is not.

24:36 But yeah, for sure, having this kind of at least this core level protocol has been useful to follow.

24:42 Yeah, they've kind of worked out how the exchange works

24:46 and all those different things.

24:47 You're like, OK, let me do the--

24:48 Yeah, and I sort of have a roadmap to like, oh, these are the problems you're going to get into.

24:51 Because that's when I first started PyView.

24:55 So I did start it a couple years ago, just as a very--

24:58 but again, very sparse.

25:00 Like, can I get anything to show up on the page over Websockets?

25:03 And then kind of iterated.

25:05 And it's interesting to--

25:07 when I started the first version of the LiveView client

25:09 JavaScript I used, then figuring out what changed between that and the next version

25:12 and the next version and the next version.

25:13 You get to see the gradual progression of like, oh, these are some problems we're going to run into,

25:17 because they've sort of addressed that in this future version.

25:20 But I still have to deal with it, but I'll get there at some point.

25:23 Yeah, go look at the closed GitHub issues, and you're like, whoa, there's a lot of conversation

25:27 around this one.

25:28 Yeah.

25:29 Interesting.

25:30 So I think a nice thing to do for people would be to just do a quick walkthrough,

25:36 because you've got a nice little getting started thing.

25:40 You've just got to be careful that most people are listening, not seeing.

25:43 But let's talk through, let's maybe talk through what it means to create

25:46 just like a real simple program in PyView.

25:49 Sure.

25:50 Yeah, so I do, yeah, so the documentation is something, again,

25:54 it's a work in progress, but I did try to get to start getting some things together.

25:57 So yeah, I do have a cookie cutter project.

25:59 And I think, you know, the first one in documentation,

26:02 if you check out the cookie cutter project, It gives you like a very quick project setup.

26:08 Sorry, I'm just going to go.

26:09 Yeah, for people who don't know, like Cookie Cutter is a way to take

26:12 a pre-structured set of source files of all varieties, even images and other things,

26:18 and say, I'm going to ask you a few questions, I'm going to do a little text replace,

26:21 and then I'm going to generate that structure for you.

26:23 So a very nice way to kind of go like, all right, we got everything set up

26:27 for you to get started, right?

26:29 Right, exactly.

26:29 Because I really wanted to get, you know, And part of the thought with PyView

26:33 is I really do want it to be super easy to get started,

26:37 not just for other people, but also for myself.

26:39 Like, if I have a new idea of something, it's like I want to go from zero to one super quickly.

26:43 And that's kind of been part of the motivation.

26:45 And so this cookie cutter is a great way to--

26:46 so you check out the cookie cutter, and then you basically have a working example right away

26:50 with just the simple counter.

26:51 And so this example uses poetry for dependency management.

26:56 So if you do poetry install, and then--

26:59 It also includes Just, which is a command line runner.

27:02 So Just, it's kind of like--

27:03 I don't know if you've talked about this before, but if anyone's ever used Makefiles or things

27:07 like that for doing common project tasks, Just is a tool like that, but specifically written

27:14 for these types of things.

27:15 And so if you use Makefiles, you know there's a lot of tricks you have to do

27:18 to kind of get it to work in the way you want versus as a build tool.

27:22 And so Just kind of works the right way a lot easier, and it's something that kind of--

27:27 Yeah, exactly.

27:28 I'm using more and more.

27:29 So if you check out the-- if you run the cookie cutter,

27:32 run poetry install, and then run just, it'll tell you to open localhost to 8,000 in your browser.

27:39 And you'll have a counter example up and running already.

27:42 And the kind of interesting thing, if you want to play along with this more--

27:46 and I do have this in the docs in terms of what's going on here.

27:48 But it's a really good example to kind of open up in Firefox or Chrome, and then open the developer tools

27:57 and the network tab.

27:58 And when you load the page, what you'll see is--

28:02 and this is kind of the Live View model, right?

28:05 There's an initial page load, which is like the server--

28:08 so it goes to your view, and it runs your templating logic.

28:13 And it returns that as just straight HTML, like a normal web page.

28:16 So if you had turned off JavaScript, you'd still get the page back.

28:20 But if you have JavaScript on, which is obviously intention,

28:22 then what happens is included in that initial page load

28:24 is some JavaScript that comes back.

28:26 - Oh, obviously you have it open, Michael.

28:27 Yeah, so if you, if you, yeah, exactly.

28:29 So the HTML is right there.

28:31 So that's like the full HTML of the page.

28:32 So yeah, if you had turned off JavaScript, that part would still work.

28:35 But then if you click on the, do you see in there a WebSocket connection in your--

28:39 - Oh yeah, somewhere, socket, yep.

28:42 - So if you click on that, you can see the messages back and forth.

28:44 So when you click on the messages tab there, yeah.

28:47 And so you can see--

28:49 - Interesting.

28:49 - Right.

28:50 - Yeah, so there's a whole set of examples, or live interactive examples,

28:56 people can just go to pyv.rocks and click live examples and do this to see it right yeah yeah

29:02 okay this is super cool yeah that message you have right there it says diff zero one so like zero is

29:07 like the kind of slot in the template and so it says now that should be one so you click you know

29:11 plus again then the new message will be diff you know whatever and you can see this message says

29:14 event increment so this is what goes to your back end is you're getting a click event for increment

29:19 and you're sending back a response um and so yeah it's so does it like uh instrument your html with

29:26 of identifiers or something like that to then be able to do this?

29:29 Yeah, and so that was one of the things that I've been so unhappy with for a while

29:34 with PyView is because when I first started doing this, I was like, okay, I want a nice

29:39 HTML templating language, right? Or maybe even it'd be better if it was pluggable,

29:44 if you could use whatever templating language you want. But the problem is, most Python templating

29:49 languages, the input is your template and some data, and the output is a string.

29:55 And for this, what we're trying to produce is like a render tree.

30:00 And so really the mental model is a lot more like t-strings, if people are familiar with t-strings, where you have like a template, right?

30:08 Your HTML template, and it's separated into static parts, like strings, and dynamic parts, like things to be evaluated.

30:15 And that's kind of the live view model.

30:17 And the pie view model is like, basically, we take a template and we convert it into a list of statics and dynamics.

30:22 And each dynamic, like each evaluation spot itself has static parts and dynamic parts.

30:30 And so we have to take an HTML template and turn it into this render tree.

30:34 And so again, this is like a huge pain point because I couldn't find a templating language that would

30:41 let me kind of get that level of control.

30:42 And maybe there is one, and I'm not familiar with it.

30:44 Or maybe there is a way to get to these internals.

30:46 I'm not familiar with it.

30:47 But what I am doing was there is this library called IBIS,

30:52 which someone had wrote an open source as a tutorial on how to write your own templating language.

30:57 And so it's very similar to Jinja 2, but a lot simpler.

31:01 And so that was the initial templating language for PyView

31:04 because I could hack it just enough to get both HTML and also this more template-like view that I need.

31:15 This is one of the things that I'm very excited about with now that we have t-strings in 3.14

31:21 is that I think that model just maps so directly to this.

31:24 And I'm hopeful that we'll have a lot of different rendering

31:27 libraries or templating language for HTML.

31:29 Like I know there's already a good one, or it's a work in progress called T-DOM

31:34 that people are working on to make t-strings more HTML--

31:38 not friendly, not that they're not already, but there are certain things you want.

31:42 Like obviously, you want to be able to just automatically scaping of user input so it's not malicious.

31:47 Maybe even merging things in HTML attributes.

31:50 Like there's nicer things you can kind of do when you're thinking about the HTML use case, right?

31:55 But I like having like a template as like the core building block, because if you can get to a template, that's super easy to turn into like the structure we need for a live view.

32:03 And I imagine there'll be multiple ways to do that in the future, you know?

32:06 Yeah, very interesting.

32:08 It sounds a little bit like almost a concrete syntax tree of the DOM that you've got to like, okay, we've got to understand all the pieces and what parts get pushed down.

32:18 Like from here down is the chunk we got to send down because this part changed.

32:23 Exactly, exactly.

32:24 And yeah, like you said, it is a little bit like that.

32:26 I mean, because there's, you know, it's not even as simple as like this,

32:29 because there is like some special handling for things like components, you know,

32:35 are sort of managed slightly differently.

32:38 And then even kind of that, like if you had, this is like not a great example,

32:41 but if you had multiple counters on your page, maybe you'd want to optimize like,

32:44 well, they really just need one set of static content for all the counters.

32:48 even though we kind of want to manage them separately.

32:50 And so there's different optimizations like that that are done.

32:53 But yeah, it is.

32:54 Everything comes from this kind of render tree is how we can do those diffs.

32:58 Okay.

32:59 Let's talk through these examples a tad more.

33:01 And we don't necessarily need this going.

33:03 But, you know, back to the Alessio pointed out, the HTMX example.

33:07 If you go to the HTMX website, there's a bunch of cool live examples there as well.

33:11 And literally in the page, Carson has put it such that you see these exchanges

33:16 as you interact with it.

33:17 You know what I mean?

33:17 That's how significant that is.

33:20 So maybe let's pick out just a couple of the examples here

33:24 that we could talk through that you think are worth pointing out.

33:27 Some of the capabilities are inspiring, but not insane.

33:31 I don't know.

33:31 JOHN MCWHORTER: Sure.

33:32 I mean, a really quick one is this volume control, like the third one up at the top, which

33:36 it's not a super interesting example.

33:39 But just the thing about it is that it has keyboard control.

33:43 So you can see it's super easy to just do keyboard bindings.

33:47 And this is one of those things where like--

33:48 - Just arrow keys.

33:49 - Yeah, I mean, which seems like a small thing.

33:51 - I'm not using the mouse, right?

33:52 There it goes.

33:53 - Seems like a small thing, but it's one of those things when you start to dive into,

33:56 right, like, you know, even like, you know, sometimes you might wonder like, you know,

34:01 why are there all these different HTML component libraries

34:03 that do things like a button?

34:04 It's just like, well, you know, when you wanna think about things like accessibility

34:08 and different languages and blah, blah, blah, like there's actually a lot that goes into it.

34:11 And so something like keyboard bindings is something I honestly would never take the time

34:16 to add to all that before because it seems like such an undertaking,

34:19 even though you could say, oh, it's simple.

34:20 You just add event handlers to all your things and blah, blah, blah.

34:23 But yeah, it was just slightly out of adding to an example project.

34:27 But now it's because it's built into the framework.

34:29 It's super easy, and it gets treated the same as any other event.

34:33 So pressing a key up or key down, send it to the event,

34:35 just clicking the button.

34:37 And so it's one of those things.

34:39 It's a simple example, but it's--

34:41 JOSHUA SHARFSTEIN: Yeah, so let me describe it for listeners.

34:43 So you've got this progress bar looking thing.

34:46 That's the volume control, like, you know, your standard macOS looking thing.

34:49 And it's got a mute button, a max volume, an up and down button.

34:52 And these are like buttons that, you know, you might be used to, but also you can just,

34:57 you know, use the arrow keys and it's just as if you're clicking the button and it all

35:01 updates even with like probably one of those CSS transitions to make it feel a little animated

35:06 instead of jumping.

35:07 Yeah.

35:07 Looks really nice.

35:08 So what about the source?

35:12 I think there's a couple interesting things here.

35:14 First of all, the volume.html, this looks Tailwind.

35:18 Is that right?

35:19 Yeah, this is using Tailwind.

35:21 Yeah.

35:21 Okay.

35:21 Yeah.

35:23 It's interesting.

35:24 I feel like it's one of those things where my first pass of this example's website used

35:28 almost no HTML CSS and was like super ugly.

35:30 But I kind of wanted the focus to be on like what is the, like what is like the really,

35:35 what are you really writing versus like what is, you know.

35:38 But I kind of gave in and used Talens because it looks a lot nicer.

35:42 It looks more professional, something people would want to pick up, right?

35:45 Yeah, I think this gets lost sometimes in different projects because, you know, I look at a lot of people send me projects all the time.

35:52 And like, hey, do you think this is what we're talking about in various venues or whatever?

35:57 Having something that looks like, oh, I wish my app looked like that or it did like that is highly inspiring.

36:04 It's not, you know, if you had like, hey, look, we have all of our live demos and they're exactly like 1993 web view, like appearance, but see how easy the program is.

36:17 I know if you look at this, the source, it's full of, you know, like P8 for padding eight and, you know, such and such.

36:25 It's worth it.

36:25 Right.

36:26 It's so worth it.

36:27 And the HTML is just pure HTML, except for you have these sort of attribute-driven things, right?

36:35 Right, exactly.

36:36 Can we talk about how is the HTML different then?

36:39 That's exactly it, yeah.

36:40 So for this example, the difference is, right, for a button, we have this phx click attribute,

36:49 which is what tells, you know, wires up with Phoenix Live View that when someone clicks on this,

36:53 we should send this event call.

36:54 So the first one says phx click equals down.

36:57 And so when someone clicks on that button, we send an event to the server that just says,

37:00 like, you know, click down.

37:02 And there's also this PHS, PHX window key down and PHX key.

37:07 So, you know, basically we're sending like a key update, you know, for this arrow down

37:12 is like one of the keys.

37:14 And so these parts are not something that I, again, this is like just the straight Phoenix,

37:19 like if you're an Elixir app, it would work exactly the same way.

37:21 You could take this HTML and run it on Elixir app.

37:24 And if you had the Elixir backend, it would work exactly the same way.

37:28 So that side looks exactly the same.

37:30 Yeah, I mean, what's the value in renaming that to PYW or something?

37:34 Yeah, I know.

37:35 And actually, I think you could.

37:37 I think they do have it configurable with the client JavaScript

37:42 where you can do a different specifier if you wanted to.

37:44 But it's kind of nice this way.

37:46 I mean, I think the other thing is, too, in the age of LLMs,

37:49 and just even examples, at this point, there's a ton more Phoenix Live View code than there is

37:54 And so if you find a good LiveView example, it's like you can get it to work in PyView hopefully.

37:59 - Yeah, that's interesting.

37:59 So in a sense, the front end stuff is API compatible with both backends maybe.

38:06 Is that it?

38:07 - Yeah, sort of.

38:08 I mean, like, yeah, and like conceptually, I mean, I think that the thing is the Phoenix LiveView

38:15 has a different templating language.

38:18 So things like loops or conditionals look totally different, right?

38:23 So you might be able to pull up an example and go, I see how I'll do it here, but it's not identical.

38:27 Right, exactly.

38:28 Or if you see something in an example where it's just like,

38:29 I'm trying to do a form, but my PHX update isn't firing,

38:33 it's like it's probably the same solution in both places.

38:36 Got it.

38:37 Got it.

38:38 So then you've got the HTML side, which is pretty interesting.

38:43 Tell us about how this-- what do we write over here on--

38:47 Yeah, so--

38:48 The data exchange looks like-- sorry.

38:50 The data exchange looks like you're exchanging data classes,

38:52 like the DTO sort of API aspect?

38:55 Yeah, exactly.

38:56 So, well, you can, yeah, so each live view, like page,

39:01 is basically like you would type it to a specific, you know, I call it a context,

39:06 like which is like what, basically what's going into your template.

39:08 And so you can do, I mean, it doesn't have to be, I like using data classes.

39:12 It can be a data class, it can be a type dict, it could be a Pydantic class,

39:17 it could probably just be a regular dict.

39:19 I don't know that I've ever tried that, but I think that should work.

39:21 But it's just really just for the typing.

39:25 And it's what we'll get past here in template.

39:27 And then so maybe it's worth talking through.

39:29 Like there are these sort of different lifecycle components.

39:32 And so with your view, the first thing that gets called

39:37 is there's this mount command.

39:39 And that gets called any time--

39:41 I mean, when your view gets instantiated.

39:43 So when someone visits the page, we're going to create an instance of your class, your LiveView class.

39:48 And mount will get called with the socket, which is probably going to be more detailed than that,

39:53 but that's kind of like your interface to the communication.

39:56 It's not the web socket necessarily.

39:58 It's more like how you interoperate with the system.

40:03 And then also the session.

40:04 So if you want to copy stuff over from the HTTP session,

40:07 like user information or whatever, you can copy that over in the mount to your data.

40:12 Then after that-- and it actually gets called--

40:15 well, I'll talk about that later.

40:17 But then after that, there's an optional--

40:19 it's not shown in this example, but there's optional like handle params change, which gets called with path parameters or URL parameters.

40:27 And the reason that's separate is because your class might get just instantiated once

40:31 on when the page is viewed, but you might have like programmatic navigation that's not real

40:36 navigation. It's like JavaScript navigation where maybe for things like filter options or

40:42 pagination options, you want to put those in the URL so that it's kind of bookmarkable and shareable.

40:47 you don't want to do a full page reload and so anytime those get changed including on the initial

40:51 page load we'll call a handle prams method and you don't have to implement that if you don't care

40:55 about it um so that gets called in this case a volume is the volume it doesn't matter where

40:59 the volume exactly yeah but you might want to like be able to bookmark like this is a good volume or

41:04 whatever and i think the counting example does does have that just to kind of show how it would work

41:08 um i see so in that sense you get a bit of a deep linking into it exactly that's cool yeah okay yeah

41:14 Yeah, and again, it takes advantage of this kind of like JavaScript navigation that you can initiate from the front end or from the back end.

41:21 Like on the front end, you can initiate like a navigation transition that will like basically tell the back end, hey, change your prams to this.

41:28 And the browser takes care of like reading the prams and changing the, or the back end takes care of reading the prams and changing the state.

41:34 Or on the back end, you can also tell the front end like, oh, hey, because you did this, I want you to change the URL to be blah, blah, blah.

41:41 And here's what the new URL should be.

41:43 So you can do it both ways.

41:44 And then the render method gets called.

41:47 And it's not shown here because the base class, basically,

41:50 for the render method, it looks for a template file called whatever.

41:57 This is volume.py.

41:58 So it looks for volume.html.

42:00 And it uses that as your template.

42:01 It also will look to see if there's a volume.css.

42:04 And it will just inject that in as the CSS for this.

42:08 It exists.

42:09 But if you wanted to override render, you can.

42:11 And that's how the T-Street rendering works, is you basically do provide a render method

42:15 that returns a T string.

42:17 So after all that is done--

42:19 so that actually happens twice.

42:20 It happens once for the HTML render, and then it happens again for the LiveView render.

42:25 And those are handled separately, partially because that's how Phoenix LiveView does it,

42:29 but also because some things are different.

42:31 For the initial HTML render, some things are not available.

42:34 You can't do Pub/Sub stuff to subscribe to channels.

42:37 You can't do scheduling stuff.

42:40 It's a little bit more limited to what you can do.

42:43 But anyway, that's a separate step.

42:44 And then after render, if an event comes in, this handle event gets called.

42:48 And what you're showing here for the volume control is kind of like my V1 of the event method that basically just

42:54 takes an event.

42:55 So there's one method called handle event that takes the event and a payload, which

42:58 is like a dict of the options.

43:01 Then you have the socket.

43:01 And so you can see here, it's just a bunch of if else.

43:04 It's like if the event is key update, then just take the key as the event name.

43:08 If it's on or off, change the--

43:11 If it's off or they hit the left arrow, then set the volume to 0.

43:15 If it's on or they hit the right arrow, set the volume to 100.

43:19 And then there's some stuff that just bound the volume at the end.

43:22 And so that's all you do is you basically--

43:24 this handle event method gets called.

43:27 You're updating your state.

43:28 And then after this gets called, automatically, your render method gets called again.

43:33 And basically, you're just re-rendering with the new state.

43:36 And then again, on the back end, we're figuring out, Like, okay, last time you rendered this tree,

43:41 now you're rendering this tree.

43:43 What changed?

43:43 I'm just going to send what changed.

43:45 It looks very, I don't know, view or data binding like in here.

43:52 So when things start up, you say the context of this thing is an instance of the volume class.

43:59 And then all you write in your code is like socket.context.volume equals the various,

44:05 you know, plus equals 10, minus equals 10.

44:08 Exactly.

44:09 And somehow, iView says, okay, I've wrapped this thing in some kind of responsive or something that detects the changes, right, somehow?

44:19 Right. Well, yeah, actually, yeah, I mean, we're not even that smart right now.

44:21 I mean, we could be, and I think FinisLiveView is a little smarter about it, where they do wrap and kind of see if they, but like for this, basically, we just always render.

44:30 I see. So you re-render the page and just go, what is actually different about, oh, I see, when I re-rendered with new data, then the volume value changes.

44:38 Exactly.

44:39 But it is really nice because like you're saying, it's like you don't really--

44:42 like your application logic becomes really simple because it's really just, yeah, I update my state.

44:49 And then I know how to render my state object.

44:51 And I don't really care about whatever.

44:54 And even this handle event method, it's not really--

44:57 I mean, I don't know.

44:59 It feels like it'd be a little bit of a stretch to call it stateless because you're mutating state.

45:02 But at the same time, you don't really care where this state object came from.

45:06 It's like, given this event, how would I this state. Yeah, and it's got a very strong view.js feel like I just changed the properties of the

45:14 thing and something makes it happen that it goes back to everywhere this value is used. It changes.

45:20 Exactly. And that's really how it works. I mean, that's the kind of cool thing, you know, where

45:23 we're talking about HTMX, where, you know, you have to be really intentional about like, OK,

45:27 like how do I want to segment, you know, what I'm changing? And, you know, when I do this, I know I

45:31 want to change this part of the render, this part of the render. And with this, you don't really have

45:34 to think about it, right? Like you just change what you want to change. And the part of the template

45:37 that needs to change will naturally change because we're treating it as this diff operation.

45:43 Yeah, yeah, cool.

45:44 Let's do one more example, something that kind of shows

45:47 off what's possible.

45:48 OK, well, gosh, there's two things I'd want to show.

45:53 But we could do the maps thing, which is just a way how to integrate with JavaScript,

45:59 and then also maybe one of the newer things, or maybe the T Street version of the counter, just to--

46:05 yeah, so we'd look at the maps one.

46:07 And so this is very simple, but this is a thing that--

46:11 I think the thing with like frameworks with PyView and other frameworks is I think maybe people try to bucket

46:17 into like, oh, you hate JavaScript or whatever.

46:19 And like, no, I don't hate JavaScript.

46:21 JavaScript's great at doing JavaScript things.

46:23 And you do need to integrate with JavaScript a lot of the times.

46:27 And there's a lot of really great, rich, interactive JavaScript

46:29 things that wouldn't really make sense to do in the server.

46:32 So this is an example of a Maps thing using leaflet.js,

46:36 It's like a JavaScript library that uses OpenStreet map data.

46:39 We're doing a Google Maps kind of style maps view with tiles and stuff like that.

46:45 And so this example just kind of shows the events.

46:49 Basically, there's this hooks system, is what they call it on the Phoenix Live View side,

46:53 and call it the same thing.

46:55 But basically, it's a way to kind of--

46:57 we saw things like PHX key click blah, blah, blah, is kind of built-in event system.

47:04 So running JavaScript hooks is a way to kind of let you integrate custom JavaScript

47:10 and have access to that same event system.

47:13 So for this, there is a JavaScript component, which is kind of like a wrapper over--

47:17 not really a wrapper, but a wrapper over some JavaScript

47:19 stuff that handles this.

47:21 And so we have events going two ways.

47:23 And so when you click on one of the things in the sidebar,

47:28 it sends something to the back end saying, oh, update your state to say you have this national park

47:32 selected.

47:33 And then the back end also sends a--

47:36 I'm getting mixed up with this.

47:38 I think when you click on the marker, that's where the JavaScript sends the event to the back end.

47:41 MARK MIRCHANDANI: Yeah, yeah.

47:42 Literally, this is cool.

47:43 If I click-- so let me describe it for people.

47:46 So we've got on one side a map of the United States, and on the left a nice list of the different national parks,

47:53 the famous ones.

47:55 If I go entirely into this JavaScript thing and I click on something in the map, one

48:00 of the points of interest, which is one of these parks,

48:03 It communicates back to PyView and is selecting it in the list, right?

48:07 The Python bit.

48:08 But then again, if I click in the Python bit, like Glacier National Park or one near me, the Olympic National Park, right?

48:14 Then it will then drive the JavaScript.

48:17 So this is the bi-directional thing you're talking about.

48:19 This is very cool.

48:20 Right, exactly.

48:21 Yeah.

48:21 So the JavaScript part has access to a similar component system where it's just like, oh, if I get this event, I think I call it highlight park.

48:27 Then I know that, oh, I need to turn this marker on.

48:31 And going the other way, the JavaScript has its own handling, like, oh, when this happens,

48:35 then I should call this method on the LiveView.

48:38 And so your LiveView side, like your Python side, stays the same where it's still doing event handling

48:45 and also sending events if needed to the front end.

48:47 But you can get access to--

48:49 so maps, drag and drop stuff is a big one, even really rich editors.

48:54 I've done something with using CodeMirror, which is a really nice IDE kind of editing experience

49:02 in the browser.

49:03 And so you can still--

49:04 I think the thing with PyView, right, is it's not--

49:07 I don't know, for me anyway, it's not about technology-focused.

49:10 I only want to use Python.

49:11 It's like, I want to have great web experiences, whatever that takes, but in a simple way

49:16 that I can understand and debug and test.

49:19 So yeah.

49:20 JOHN MUELLER: Yeah, this is a very impressive--

49:22 that's an app.

49:23 Yeah.

49:24 I mean, I look at it, it's like, wow, that would be kind of a big

49:27 project to build and my feeling is it wasn't that big of a deal with pi. No it's very yeah that's

49:32 kind of part of the fun thing with like making these little examples is like super fun and also

49:35 like pretty easy yeah so similar one there's like that combat and board one just to quickly talk

49:39 it just is a similar thing with drag and drop but the same kind of concept. I want to throw out maybe

49:44 like just thinking back to that map one real quick before we move on it feels like this would actually

49:48 be quite relevant for data scientists as well right like I don't think you build it as data science

49:53 But there's a lot of like, oh, we need to build a dashboard that updates based on whatever.

49:59 And we need these different visualizations.

50:00 And with the JavaScript integration, I feel like you probably could do some pretty cool stuff.

50:04 Yeah, no, for sure.

50:05 Yeah, for sure.

50:06 And I've done, and I think there are a lot of really great JavaScript, like graphing libraries.

50:11 Like one that I've used before is something that I learned about just from figuring out that it's what like Google Notebook, like Google Collab, you know, their like Jupyter Notebooks thing uses called Altair.

50:20 And that's something which is cool because there's basically a Python backend for generating the graph data, but then the front end is this JavaScript thing.

50:27 And so I don't think I should put an example of that, but I've used it at work where we just have a very simple graph hook that wraps the Altair library and the backend generates the graph in Python code.

50:38 And it's just super easy to display and things like that.

50:41 And to your point, Michael, one of the really cool things

50:43 with PyView is because everything is over WebSockets, any server push stuff, like if data comes in or data changes,

50:51 it's really no work to get to tell the browser to update to the new state.

50:55 It's super, super easy to do, which is cool.

50:58 MICHAEL WOLFF: That's awesome.

50:59 MICHAEL WOLFF: Yeah, so the one other thing I wanted to touch on quickly is just

51:02 because I think the first example we looked at the volume

51:04 was using the older events.

51:05 So if you look at maybe the basic counter t-string version,

51:08 like the source for that, I mean, It's the same kind of counter example.

51:11 But the source is like, I think there's a count tstring5 probably to click on.

51:16 And then it's the third one in the list there.

51:18 But so this is just to talk a little bit about--

51:22 again, it's kind of a work in progress.

51:23 But the first version of the events was kind of like, oh, there's a handle event method

51:27 that all events go to.

51:28 But that kind of gets to be a little bit of a drag.

51:29 And so we added this @EventDecorator.

51:32 And so you can kind of--

51:34 instead of having handle event, oh, was the method increment?

51:36 Was it decrement?

51:37 You can just say @Event, decrement, @Event, increment and have those separate functions.

51:43 And then this is also showing the kind of T string templating

51:46 where you use two strings to generate it.

51:48 And the cool thing with this too is on line 58, you can see basically we're calling self.button,

51:55 which is a T string template, and then we're passing in self.decrement, which is the method.

51:59 And so you can kind of--

52:00 I mean, it's basically just doing that binding for you

52:03 automatically where it ends up--

52:05 - Okay, hold on, hold on, hold on.

52:05 So people, you have a T string, which is kind of Jinja-like,

52:13 and in here you have a format statement, and one of the values you're putting in here

52:18 is literally the function that has the decorator that is an event,

52:23 and then that gets called back through all the magic.

52:25 - Yeah, and it's like, it's like, I think it's cool that it looks like magic,

52:31 but it's, I mean, it's really not magic.

52:32 I mean, the thing, the simplest possible thing where basically it's just it's saving you from um like if you look at

52:39 that that button method um the button template it's saying like button phx click click equals

52:46 okay so you've created a wrapper function that then basically writes the component

52:51 yeah that that'll wire up all exactly yeah that's pretty cool yeah but this is something i'm i think

52:57 i'm really excited about because it's like um you know like one of the things that you really want

53:02 want to have, like after you've been making a complex app,

53:05 is a way to have components.

53:08 And that was kind of challenging in the templating system

53:10 that I originally started using, not just to have components

53:13 because you can have includes and stuff like that, but to fit into the Phoenix Live View component system.

53:17 But I think t-strings are exciting for me because it makes things like this really powerful.

53:22 And you think about just even things like having really smart forms and form binding.

53:27 And I have some of that, but it's a little clunky.

53:30 And I think being able to have like really nice, reasonable components that leverage t-strings,

53:35 make it so you have something that kind of looks very magically,

53:37 but it's, you know, it's basically just, you know, templating.

53:41 So, but I'm excited about it.

53:42 I think it'll make a lot of things easier and easier to kind of share, you know, components.

53:46 I love it.

53:47 I really like the programming here, the API.

53:50 We've got a little bit, not a lot, a little bit of time left here.

53:53 So let's just, let's touch on actually just a couple of things.

53:56 I think one of the issues that, you know, I talked about some of the magic, like some of these frameworks,

54:01 like hide away all the things.

54:03 Another one where there's these front end, back end, connected all Python, they feel like sometimes you're like,

54:09 OK, and the way that works is you run it on our cloud system.

54:13 You know what I mean?

54:13 Or you run it on our special bit of infrastructure.

54:17 And then thoughts immediately go to like, well, how durable?

54:21 How proven is that?

54:22 Like, could we use Kubernetes?

54:24 Could we do it there?

54:25 Like, gosh, I don't even know.

54:27 So let's talk about some of the internals.

54:28 And at its heart, this is Starlet, right, which is the same as FastAPI in a sense

54:34 in terms of how it runs, right?

54:35 JOHN MUELLER: Exactly.

54:36 Yeah, Starlette is doing all the heavy lifting.

54:43 And it handles the WebSockets and everything for you, right?

54:46 JOHN MUELLER: Yeah, the WebSockets, the HTTP, the routing, even middleware, also the authentication,

54:51 like using it for the authentication.

54:53 Like I had to do a little bit of work to kind of make that available at the, you know, the web socket level in terms of like, because it handles like all the routing.

55:06 But just the way live view works is there's really one web socket connection that's getting managed.

55:12 And then internally there's routing that's done by the framework.

55:15 I see.

55:16 Because you never set that up, right?

55:17 You don't manage different sockets in like different.

55:20 Exactly.

55:20 You're just like, I just want to handle event.

55:22 Exactly.

55:23 Yeah.

55:23 But yeah, but another cover is we're using their auth system and framework.

55:29 And so if you have used that or familiar with it, it's exactly the same.

55:34 It's just that we make it also available at the LiveView specific layer.

55:40 But yeah, so anywhere you can run Starlet.

55:43 And I've been mostly using it.

55:46 So that examples website that we're looking at, that is itself a PyView app that is using just Uvacorn,

55:53 deploy as a Docker container.

55:55 And that's primarily how I've been using it for apps that I've been writing or at work is like, yeah,

56:00 it's just a Docker app with Uvocorn.

56:04 But presumably, yeah, any HGI thing you could use.

56:11 So yeah, there's no magic there.

56:12 Yeah, anywhere you want to run it.

56:13 The one thing is-- this is something that's kind of more of a future thing, but part of--

56:18 that you don't have to use for a lot of apps, but some of the stuff like presence, like PubSub stuff

56:23 have built in, just because it's kind of something you want to have when you have this kind of

56:26 framework, but you can do stuff very easily. I have an example of this, but like, oh, this user

56:32 joined this page, this user left the page, and doing things like that. I don't have a way right

56:35 now for that to be multi-machine. It's really just single machine pub supplementation. And so

56:39 something I'm kind of working on for the future. But yeah, there's no special requirements. Anywhere

56:43 you're running a Starlette app or Fest API app or whatever should be totally fine. You do want to

56:49 have sticky sessions set up because it does require you

56:53 going to the same machine because we have this persistent state

56:56 for the user.

56:56 MARK MANDEL: Yeah, that is tricky with WebSockets.

56:59 I've been dealing with that for a project I'm working on.

57:01 And it's challenging because the natural inclination and a lot of the recommendation is, oh, how many workers

57:08 do you want your uveacorn or your granion to run?

57:12 MARK MANDEL: Yeah.

57:12 MARK MANDEL: And oh, if you need to scale up, you just put it behind a load balancer.

57:15 MARK MANDEL: Yeah, I agree with you.

57:18 It is challenging, but I think it's a solvable challenge.

57:21 And I think also it depends on kind of the app that you want.

57:24 Like for some use cases, I mean, you know, the sticky part you kind of need right now anyway.

57:29 But for some use cases, maybe you don't care about the PubSub or the presence,

57:32 or maybe you have a way to deal with that already.

57:35 Right.

57:35 If you don't care about PubSub or presence, then as long as it just sticks to.

57:38 As long as it just sticks.

57:39 And even the stickiness, I feel like there's potential solutions there, right?

57:42 Because like with the model, it really is like, you know, like we saw in examples,

57:48 like you get past this context to operate on, you make changes to it,

57:53 and you don't really care like where that came from or where it's running.

57:57 And so theoretically, I think it feels like there could be a situation where that is somehow distributed

58:01 or there's some kind of shared storage or, you know, it doesn't seem like impossible.

58:05 I don't know that it'd be worth the complexity for a lot of use cases,

58:08 but I feel like there's sort of a challenge.

58:10 And the PubSub stuff, I think is something that, you know,

58:12 I plan to kind of address.

58:13 So I think, again, it's like, if you're okay with running Redis,

58:16 that's a very solvable problem too having like multi-machine pub sub um right right right redis

58:21 or valky have like this web socket broker thing kind of which we manage uh basically i imagine

58:28 like your web socket connection talks to your server which then like puts you in the session

58:33 of of a redis or valky one but then that thing actually does the pub sub across yeah and that

58:38 could be that could be interesting for like i mean like one of the early things i was thinking is

58:41 like oh could i could deploy this with like abys lambda you know which like seems kind of impossible

58:46 And they do have, with their API gateway, they have a WebSocket broker.

58:52 They manage WebSocket connections.

58:54 And you just kind of get events like, oh, this WebSocket client 125 joined, whatever.

59:00 And then you kind of manage that.

59:01 And it kind of would be cool, just, I don't know, if a proof of concept or just if you really wanted to host on Lambda

59:06 or something like that.

59:07 But it's not.

59:08 I don't know that I'll get to that anytime soon.

59:10 Yeah.

59:11 Well, certainly an interesting project with the way it is.

59:15 Could certainly go farther.

59:17 A lot of the frameworks that are good at this scale out,

59:19 they don't have any presence or collaboration.

59:23 It's fine, right?

59:24 Yeah.

59:24 No, it's a good problem to have.

59:26 But yeah, it's something we'll figure out at some point.

59:30 But I think there's still a lot of co-ops you can write without it.

59:32 So it hasn't been a huge priority.

59:34 No, it's very, very neat.

59:35 All right.

59:35 So I got two quick questions for you here.

59:39 One, you mentioned LLMs at the beginning.

59:42 How do LLMs do with writing PyView?

59:45 and do you have tips for making it more knowledgeable?

59:49 Are there, do you have like some sort of specification file

59:52 you can give to, you know, Claude or something and say,

59:56 I know you might not be familiar with this, but here's what it is.

59:59 Now I'm going to ask you questions to work with it.

01:00:02 That's a really good push.

01:00:04 I feel like I should do something like that.

01:00:06 So I have used LMS to like write, you know, like application code, not, you know,

01:00:12 like application code, like using PyView framework like you're describing at work a lot.

01:00:16 And it's been mostly successful.

01:00:19 I think one of the things is it helps that the templating language--

01:00:23 we're not using 3.14 at work yet for these projects.

01:00:27 And so we're using the older style templates.

01:00:29 It helps that that language is very, very similar to Jinja 2.

01:00:32 And so that's been great.

01:00:35 It does get confused sometimes where, obviously, we don't have the same set of built-in filters.

01:00:39 And so I might try to use a filter that's only in Jinja 2

01:00:41 that we don't have or that includes syntax is slightly different.

01:00:45 So those that gets tripped up on.

01:00:47 I think I've had a lot of success with just really simple prompts like this is PyView.

01:00:53 It's Phoenix LiveView, but in Python.

01:00:55 And that's gotten a lot of mileage, just even something basic like that.

01:01:00 It sounds like you could create a Claude skill or an agent or just a set of really structured rules files

01:01:07 and maybe put it on the docs and say, here, grab it.

01:01:09 And throw this in.

01:01:10 I for sure should do that.

01:01:12 Yeah, I don't think that'd be helpful for me too.

01:01:13 I think that's something that I kind of, yeah, just even personally want to get better at

01:01:16 is like, yeah, I've been using these tools a lot for development and they've been great,

01:01:19 but I've been somewhat, you know, lazy in terms of like improving my workflow.

01:01:23 And I do see how it's like very successful when people kind of structure these things

01:01:27 a little better in terms of like having custom commands or yeah,

01:01:30 like agents that know about specific things.

01:01:32 It does seem like-

01:01:33 Yeah, but I do think that your cookie cutter helps.

01:01:35 Right.

01:01:35 Right.

01:01:36 Because it says, okay, here's the structure.

01:01:38 Here's a little working bit of it.

01:01:40 now keep building on that.

01:01:41 That goes a long ways.

01:01:42 So--

01:01:42 - No, for sure.

01:01:43 And I think even like having things like the just file

01:01:46 seemed to help in terms of like, it doesn't, you know, it knows like,

01:01:49 oh, to run tests, I run just tests.

01:01:51 To run type check, I run just type check.

01:01:52 Like it kind of knows a lot of this stuff.

01:01:55 Doesn't have to guess about it, but it kind of would be useful.

01:01:58 I do find it like, it's funny.

01:01:59 It seems like the LLM get confused a lot about like, oh, do I need to run poetry run versus just Python?

01:02:04 And it seems to always forget like how your project is set up, you know?

01:02:09 Yeah, I know.

01:02:10 You got to keep reminding it.

01:02:12 All right, so that was question one.

01:02:14 Question two, final question.

01:02:16 What's the roadmap?

01:02:17 You open to contributors.

01:02:19 Where are we?

01:02:20 Yeah, so like you mentioned, it's very early days.

01:02:24 And I've tried to not be conservative about breaking changes, but I think as we start getting closer to 1.0--

01:02:30 I think I'm at 0.8.0--

01:02:32 there probably will be some breaking changes, because as we've already seen in some of the examples,

01:02:36 I've gone through multiple iterations of how do I make this easier?

01:02:39 how do I make this easier?

01:02:40 And that's been a big focus for me is making it really developer-friendly and simple.

01:02:44 And so I think I'll try and make some stuff a little more cohesive.

01:02:46 So there may be some breaking changes.

01:02:49 But yeah, I mean, you know, I want it to be super easy to get up and running.

01:02:52 And I feel like there's work to do there.

01:02:53 I think, you know, the short-term roadmap is, again, I want to keep working on documentation,

01:02:57 updates, examples.

01:02:59 I saw a really great, you know, YouTube talk recently called like Verbs, Not Nouns

01:03:03 about Brian McDonald about like how to make your documentation more kind of like task-based.

01:03:07 Like what is the person trying to do versus explaining technology.

01:03:10 So I want to do that.

01:03:11 Like I said, I think the T-string templating is very exciting in terms of making that better,

01:03:17 figuring out the CSS story around that.

01:03:20 That's one thing that's annoying is writing CSS in t-strings

01:03:22 because you have to double escape all the curly braces.

01:03:26 Better form support.

01:03:27 I have some initial form support that kind of uses Pydantic.

01:03:33 But I kind of want to make that a little better.

01:03:35 And I've had situations where we have like very complex, like nested forms.

01:03:40 And I would love to get to a point where it's just like,

01:03:41 yeah, you just throw, here's my pandemic data model, make a form with error handling

01:03:46 and all this stuff and validation.

01:03:47 And I kind of want to get there.

01:03:48 And then I think again, like larger examples, like I think you called out the Phoenix Live View,

01:03:54 like PyBeats example, like they have this very big music player.

01:03:57 And I have some things like that where I have like an AI chat example

01:04:01 that are slightly larger, but kind of going to some more examples

01:04:03 to kind of inspire people, like what can actually be done.

01:04:06 Could you fully implement the live beats thing in PyView?

01:04:10 Yes, I can.

01:04:12 And I was thinking about doing it.

01:04:13 I think it's interesting, the history there, I mean, I don't know.

01:04:18 But my intuition is that part of it was that as they were building certain technologies,

01:04:22 they wanted to show them off and have a good test bed.

01:04:24 And so the way that it works is based on file uploads.

01:04:27 You upload MP3s that you want to play.

01:04:30 And I feel like that's because they wanted to show off the file upload stuff, which was

01:04:33 new at the time, I think.

01:04:34 And I could do that.

01:04:35 support. In fact, I have like even multi-part S3, like very advanced file upload support.

01:04:42 But I was thinking about doing it, but just doing streaming. I found a streaming service that is

01:04:47 for like royalty-free music if you're using it in a non-commercial way. And I think that might be

01:04:51 more exciting to show off like present stuff and even some JavaScript integration stuff and like

01:04:55 synchronizing stuff. And I think also I have a simple AI chat thing, but I think maybe

01:05:00 beefing up a little bit would be kind of cool too, because I know people are into AI stuff.

01:05:03 But you mentioned contributions, and I think, yeah, for sure, I think the thing that, to be honest, would be the most helpful is to have people try it, try writing a simple app or a complex app, whatever.

01:05:16 And I really want to hear what works well, what's rough, what's confusing, what could be better, any feedback.

01:05:24 Yeah, more than people contributing features is people just using it to make sure it works and giving feedback on how it should be, right?

01:05:30 Yeah, no, and contribution features are good, too.

01:05:32 I mean, I recently set up, like, also just a call, like, on GitHub, the repo.

01:05:36 There's also, like, a discussions thing.

01:05:38 It doesn't have a lot of things or anything.

01:05:39 I mean, there's two topics right now.

01:05:41 But, you know, because I do want to get more feedback and encourage feedback.

01:05:44 And, like, I think that's a great place to put features suggestions.

01:05:46 But, yeah, I mean, contributions are also welcome.

01:05:50 But, yeah, I just can't underscore enough how much, like, I want to have feedback.

01:05:55 Because, again, I want it to be, like, I mean, I want it to be a really great app that people feel is fun to use.

01:06:00 And they like using it.

01:06:01 And it's easy to get started.

01:06:02 And I know that it's not there yet, but any help to getting there would be great.

01:06:08 Yeah, very cool.

01:06:09 Larry, thanks for being on the show.

01:06:10 Very cool project.

01:06:11 I think people should certainly at least give it a look

01:06:14 to see maybe it'll help them go get their app up and running a nice little interactive app

01:06:19 way quicker than maybe they thought they could.

01:06:21 Yeah, thanks so much, Michael.

01:06:21 Yeah, I really appreciate the chance to come on and talk to you about this.

01:06:24 It's been a lot of fun.

01:06:25 I can't believe how much we talked about and how much more we could talk about.

01:06:29 So it was really fun.

01:06:31 We've got a browser full of tabs of things we didn't even get to.

01:06:34 So yeah, sorry.

01:06:37 Now that's how it goes.

01:06:37 All right.

01:06:38 Thanks for being here.

01:06:39 Catch you later.

01:06:39 Bye everyone.

01:06:40 Bye.

01:06:41 This has been another episode of Talk Python To Me.

01:06:44 Thank you to our sponsors.

01:06:45 Be sure to check out what they're offering.

01:06:46 It really helps support the show.

01:06:48 If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses on topics ranging from

01:06:55 complete beginners to async code, Flask, Django, HTMX, and even LLMs.

01:07:01 Best of all, there's no subscription in sight.

01:07:04 Browse the catalog at talkpython.fm.

01:07:06 And if you're not already subscribed to the show on your favorite podcast player,

01:07:10 what are you waiting for?

01:07:11 Just search for Python in your podcast player.

01:07:13 We should be right at the top.

01:07:14 If you enjoyed that geeky rap song, you can download the full track.

01:07:17 The link is actually in your podcast blur show notes.

01:07:20 This is your host, Michael Kennedy.

01:07:22 Thank you so much for listening.

01:07:23 I really appreciate it.

01:07:24 I'll see you next time.

01:07:35 I thought of me, and we ready to roll, upgrading the code, no fear of getting whole, we tapped

01:07:46 into that modern vibe, overcame each storm, talk Python and me, I-sync is the norm.

01:07:54 you

Talk Python's Mastodon Michael Kennedy's Mastodon