It's my great pleasure to talk about a topic that I'm enthusiastic about. I'm not a developer of the Shiny framework and I'm not a WebAssembly developer, but I recently discovered these tools, and I think they are amazing.

There are so many fun things that you can do with them. So this is why I decided to submit a talk to the conference to discuss it and hopefully give other people some ideas.

But let's set the stage. Let's start with a few pain points that typically arise in web development or in app development with Python.

Traditional web apps usually rely on some sort of server backend.

Flask, Django, and FastAPI are probably frameworks that you are familiar with.

These are also frameworks that I have played around with. I'm not an expert in any of those, so please don't ask any questions about them.

On the front-end layer, you could either create your own JavaScript front end if you are a web developer, or you can use Python frameworks like Streamlit or Dash.

The problem, at least for me, is that I'm an experienced R user and I've used the Shiny framework.

When I had to create Python web apps, I was surprised that I had to deal with all sorts of state management and take care of caching, and things can get complicated quite quickly—complicated and annoying.

Another thing to keep in mind is that usually these apps, particularly if they have multiple components, involve quite a bit of deployment complexity.

Now, the tools that I want to show you today, they tackle these issues.

Let's start with WebAssembly. Maybe some of you have heard about it before. Um, it gives an obscure definition of WebAssembly on the website.

It says it's a binary instruction format for a stack-based virtual machine.

So, I don't have a computer science background, so I have no idea what this means, but in practice, how I think about it, it means that WebAssembly can run compiled code in the browser.

So, this is pretty cool. So your Chrome, your Safari, your Edge can run C, C++, Rust, or Python code.

Also, people are working on this and it's near-native performance.

So we're not losing anything there. And the cool thing, if you think about web development, this unlocks a new area where we can actually build a web app that runs completely in the browser.

So you don't need a hosted backend server.

So this sounds like too good to be true and yes, it is. So there are some caveats and I will talk about them a bit later.

But if we can create apps without a dedicated backend server, we can basically deploy apps as static websites.

So I will show you an example where we do exactly this. I will give you an app that is statically deployed using GitHub Pages that you can try out.

So if you have used GitHub Pages or Netlify, this means you can just deploy a Python web app that uses data, has some interface, and people can play around with it.

You have basically no maintenance costs. You don't have to pay for a server or anything.

So that's pretty cool, I think. And I will talk about use cases and give you some ideas later.

In addition to WebAssembly, there are two more concepts that I want to introduce: Shiny and Shiny Live. So for those of you who have experience in R, you're probably familiar with the Shiny framework.

That's the go-to framework for building dashboards or apps in R.

Recently, the Posit company started translating the Shiny framework to Python. But the cool thing is it's in pure Python.

This is very useful when we talk about deploying things using WebAssembly.

The cool thing about Shiny, and I will give you a code example that illustrates this, is just why I think Shiny is cool.

First, you don't have to take care of state management. If you have written callback functions before, you don't have to do this.

Frankly, that's something I really struggled with in Python. So this is why I usually went back to R to create a simple dashboard.

You get an automatic reactive execution engine. As you will see in the example app, if we change the inputs, Shiny takes care of which elements should be re-rendered.

You've probably used Streamlit before, right?

And if you change an input in Streamlit, the whole site renders again because Streamlit is creating an HTML file and it's doing it all over again whenever you change an input.

And this feels like, I don't know, 1990s internet. But with Shiny provides an automatic execution engine, so it takes care of these issues for you.

[snorts] You also get full support for CSS and JavaScript customization.

As an independent consultant, I build dashboards for a couple of clients and you can spend a lot of time customizing dashboards using CSS and JavaScript.

The good thing is that at least the front-end and back end components are taken care of by Shiny, and you can layer your customization on top.

So this was Shiny, right? Shiny is about building web apps.

We'll give you an example in a minute. Shiny Live is just a framework that allows you to run Shiny apps entirely in the browser.

What it does is take your Shiny app and provide instructions on how you can run this using WebAssembly.

Maybe you've heard about Pyodide; that's the leading framework for WebAssembly in Python.

Essentially, it's a port of Cython to WebAssembly, so probably one could give a whole talk about Pyodide alone.

I think it's an amazing and exciting project.

The cool thing is that with Shiny Live, you don't have to worry about the nitty-gritty details here.

You can be assured that Shiny Live takes care of all the Pyodide organization for you.

Just to illustrate the concept: in a traditional Shiny app, if I create a Shiny app or any app in Python, usually You have a Python process that runs on a server, and you have a couple of clients that access the server, and the server executes the code.

The server takes care of maybe load balancing, caching, all these things.

And for data apps, of course, it also runs the code, right? So if you're doing some aggregations in response to changes in the UI, then the SH server is taking care of this.

Now with Shinylive, how we can think about it is that instead of, right, the server doing all these computations, you have little Python processes running on the client side that do all the work.

But we will come back to a similar image like this. It's not like we can get rid of the server for all the things that we want to do with web apps.

Um, of course, so things that might come to your mind. Oh, how, Kristoff, but how do you handle authentication?

How do you handle secrets and stuff like this? We'll get to this. Let's take a look at a code example. So for those of you who are familiar with the R Shiny framework, this will be very familiar, and for those of you who are new to this, I will walk through it.

So I tried to make a very, very simple app. So first we talk about the code we will revisit this later, this example, because we will extend it, but we will also look at the live app.

I use NumPy because I want to plot some numbers, a vector of numbers, and I use the Shiny library.

In particular, there are only three functions that I need: the app, render, and UI. And this is how you Typically, I approach a Shiny app in a very natural way, coming from art.

But first, you think about how to define the UI.

What are the components? What is the layout that I want to use? A simple layout could be a page with a sidebar, right?

So we use the UI to define the page sidebar, and then you would, for instance, introduce a sidebar with a slider. As you can see, the Shiny framework provides some UI components such as page layouts and, for instance, sliders, but you also get text boxes, checkboxes, radio buttons, and things like that.

They even have a chat interface if you want to build an LLM into your Shiny app. In the slider, I would just define what the slider is called, the name of the object, and the minimum, maximum, and starting value.

What you would also do in the UI is define output components. Here, I want to create a histogram using this input slider that picks the number of bins as a UI input.

So you could define the output as a plot, which is a histogram, but this could also be an output table, output text, output HTML, or something like that.

So different outputs that you tell Shiny what the type is, and it takes care of the rendering.

I will also include this title: 'Hello PyData Berlin.' Once you have taken care of the UI, you would define the server logic.

You could do this in the same script as I do here, right?

That’s the same app.py file, but you can, of course, split it up across multiple scripts.

as you would usually do. And if it's a bigger project, maybe you would even isolate different server components, different UI components, right?

And then assemble them in one main script. But what happens here? You define this server function.

You use the decorators that are provided with Shiny. Essentially, you can think about decorators as they wrap the functions that come afterwards in the output or render plot function.

At least intuitively, that's what's happening.

And what you basically do here is, right, you have the output on top; we have defined our histogram output. So in the server, we have to define what this histogram looks like, how it is created, and render plot also indicates that you're actually rendering something.

So Matplotlib or Seaborn or something like that is used, and I would define a histogram as a function here.

So I'm using NumPy to define a random seed, and then just in line 19 you see I'm creating a vector of random numbers using NumPy and then just plot the histogram.

Also, very importantly here, as bins we have input n, so this is exactly the n that we defined above in the slider, and if you want to start this app, you would just run this.

So app, the app function uses the app UI and the server as input.

So this is a Shiny app, right? So what you define in the Python code is what should happen?

What does Shiny Live do? Shiny Live exports this app to something that can be executed using WebAssembly.

So if you run a Shiny Live export app to a docs folder in the terminal, what you will get are a couple of files.

So in the docs folder, you will get an app JSON. So that's basically the logic of the app, the whole app serialized to a JSON.

We will look at this again later. An index.html. This is just a simple web page that displays the application.

So there's not much happening here. I'm going to skip the edit folder because you can also get an editor view of an application.

But crucially, there's a Shiny Live service worker and there are also Pyodide files. So what the Shiny Live service worker does is take care of what do I need from Pyodide and what do I execute in the browser, and Pyodide basically delivers all the libraries that you want to use.

Okay, a few more things before we look at the live app, so you can already grab your phone.

The script that I've shown you before, the app.py, if you run Shiny Live, it is encoded in this app JSON.

So this is a bit abbreviated here. I cut this off because, I mean, it's just right. It puts all the Python script into one line.

It's very long. But as you can see, what happens at the top is it imports matplotlib as plt, import numpy.

So this is exactly just the Python code, right? So the first thing you might realize Here, oh my god, everything I put in my Python script is in this app's JSON, right?

And if you deploy this as a public website, then this will be public.

Keep that in mind. But deploying Shiny apps, uh, Shiny Live apps as static websites is super, super simple. So if you have deployed something with GitHub Pages before, um, it's just the same.

You just point GitHub Pages to a docs folder. Not going to go into details here.

I'm just going to refer to a guide, um, a walkthrough by Ramy Krispin, who has done some work on this.

But again, it's very simple. GitHub Pages has become very, very easy to navigate these days.

Now I invite you to test the deployed Shiny app for those of you. So what you will find is that it should work on your phone.

If it doesn't work on your phone, please approach me afterwards because I really want to find out why it's not working.

So if you start the app, maybe... So what happens now is that your browser has to download the app files.

It's taking some time, probably because we're all connected to the same Wi-Fi. [laughter] And what your browser does is it starts up a Python session, runs the app, and should host it in your, uh, so you should see a similar simulation icon like this, right?

It's a super simple Shiny app. So there is a slider here.

If you change it, the histogram changes because you vary the number of bins. So that's not too bad. I think it's very easy to create something like that.

Building Reactive Data Apps with Shinylive and WebAssembly

PyData is an educational program of NumFOCUS, a 501(c)3 non-profit organization in the United States. PyData provides a forum for the international community of users and developers of data analysis tools to share ideas and learn from each other. The global PyData network promotes discussion of best practices, new approaches, and emerging technologies for data management, processing, analytics, and visualization. PyData communities approach data science using many languages, including (but not limited to) Python, Julia, and R.

We aim to be an accessible, community-driven conference, with novice to advanced level presentations. PyData tutorials and talks bring attendees the latest project features along with cutting-edge use cases.

Building Reactive Data Apps with Shinylive and WebAssembly

Scripts