Joe Cheng | The Past and Future of Shiny | RStudio (2022)

Good afternoon everyone. I'm very excited to introduce our next keynote speaker, Joe Cheng, the CTO of RStudio. And since Joe is talking about Shiny, I thought I'd introduce him with a little story, a personal story, about Shiny.

And as many of you know, I wrote the book Mastering Shiny, and you might think, well, why did Hedley write that and not Joe? So Joe came to me, I don't know, like four or five years ago and said, hey, like, I want to write a book about Shiny, what should I do? And so I gave him my book writing advice, which is, writing a book's really easy. All you need to do is write for an hour a day for a year, and at the end of the year, you'll have that book.

Now, as far as I know, no one has successfully followed that advice. So it's provably terrible advice. And after my advice failed for Joe for some time, I kind of took pity on him and said, oh, hey, I love writing books, like, I'll write it for you. And to kind of cut to the end of the story, I wrote Mastering Shiny, and to say thank you, Joe built me a bike, which is the most amazing bicycle that I've, like, ever ridden in my life. And it seemed to me just like this perfect example of a win-win. Like, I got all of the pleasure of writing a book, and I didn't have to build a bicycle myself, and Joe got all the pleasure of building me a bike and didn't have to write a book. So, please welcome Joe Cheng.

The birth of Shiny

July 31, 2012 was the day that we first showed Shiny to the world. We were at JSM, not even a scheduled talk. Brian Lewis just lent us ten minutes at the end of his talk, and we showed Shiny. And if you consider that date, July 31, to be the birth of Shiny, then this is a particularly special talk for me to give to you today. Because that means that Shiny is ten years old.

Ten years. Hard to believe. So, to mark this anniversary, I thought I'd do things a little bit different this time than usual. I usually focus on what's coming, what's new, and I wanted to take this opportunity to talk a little bit about how Shiny started.

And the story of how Shiny started really begins with Danny Kaplan. Danny and his students were the very first beta testers of RStudio IDE. And Danny's feedback was so great, his fingerprints are all over the IDE even to this day. You can see all the parts that he influenced with his feedback. And in early 2011, Danny asked JJ for a way to build interactive apps in R that he could use to demonstrate statistical and calculus concepts. And JJ being JJ, in about a week, he built this. This is the manipulate feature in RStudio. Sort of the proto-Shiny, if you will.

And manipulate is great because it almost couldn't be simpler. You give it some kind of plot-generating function or plot-generating expression and include one or more unbound variables that you want the user to be able to control. Then for each of those, you describe how you want that to appear. So there are a couple of, there's slider and there's lookup, a couple of things like that. And this worked great and Danny ran with it and created quite a few really beautifully thought out and assembled tiny applets that illustrated these concepts. And he bundled them together as part of this project, Mosaic.

Now, it wasn't long, as tends to happen with software, it wasn't long before some questions started. Boy, it sure would be nice to have a customizable layout. Can I have those inputs show up in two columns, for example? Could I have more input types? Maybe multiple outputs at once instead of just one plot. Maybe different kinds of outputs like tables. And maybe instead of just showing things, we could also take some actions when the user clicked a button or something like that. And finally, why do people have to be using RStudio IDE to use these applets? It would be great to be able to take these little interactive things and move them out. All of those totally reasonable. Totally reasonable, great suggestions. And what he was describing was a full interactive UI framework.

Now, that was something that JJ and I clearly had the technical ability to create. But I felt really strongly this is not something that we should do. This felt like a trap to me. Because UI programming sucks. This is how I honestly felt in 2012. I had spent a lot of my career writing complex UIs. And the reason it sucks is because of this idiom called event handlers. This is the way all UI worked in those days.

The way event handlers work is so simple. I can explain it to you right now. The idea is this. When X happens, do Y. In this example, X being that some text box has changed. And in response, we want to do Y, which is update the text of this status label to some new value. Very, very simple. The problem is when you have multiple of these in your UI, they become hard to reason about. Similar to global variables. If you've ever been warmed off of programming with extensive use of global variables, it's the reasoning that becomes hard. And this is a huge problem because as your UI gets more complex and the logic gets more complex, it starts requiring extremely high levels of skill and discipline to do well.

It can be done. Clearly, we've had complex UIs for a long time, but it really is deceptively difficult and takes the most disciplined and talented engineers. And if you don't get it quite right, if you don't have that level of skill and discipline, you end up with bugs. And not just normal bugs like freezing and errors, but more pernicious ones. Like an app confidently giving you an answer that's incorrect. And that's bad enough in a normal piece of consumer software, but to inflict that onto the R community? To put the tools into their hands to confidently get the wrong answer? It was unconscionable. So, we didn't do it.

And the problem was, as much as I hated event handlers, I couldn't come up with not only a better alternative, but any alternative. I had been doing this kind of programming day in, day out for years. Constantly thinking there must be a better way than this. And I could not even conceive of a better way. Until around May of 2012. There's a lot of dates in this talk.

The Meteor inspiration

In May of 2012, I watched a screen cast for a brand new web framework called Meteor. And this was the craziest thing I'd ever seen. It blew me away. There were so many ideas in Meteor that they were demonstrating in their code that felt like alien technology to me. Or like a magic trick. One particular magic trick among many just stuck itself in my brain, and I couldn't dislodge it, and it was this. Like any other web framework, Meteor had a way for you to have templates. You would write some HTML markup, and in the middle, you would throw in some dynamic value, like a name. And this is where, in a traditional web framework, you would then attach an event handler to make sure that that template was re-rendered at the appropriate time. But the Meteor guy said this verbatim. I changed the data and the template updates. There's no event handlers. It just works. And he said it like that. And I was like, there's no event handlers. It just works. What? Like, how?

There's no event handlers. It just works.

How does that just work? And that was me. I mean, for like days and maybe a week or two after, I couldn't shake this thought. How did they do that? And the only thing I could think of is maybe they just re-execute everything. Every time something changes, they just re-execute all of their templates, but that didn't seem to be what they were talking about. Finally, I couldn't take it anymore. I just went and Googled how does Meteor work. Don't worry, you're not supposed to be able to see the code here, but there was a Stack Overflow answer that pointed to this file and said this is how it works. And I just include the screenshot so that you can see how short it is. 71 lines of code with pretty copious comments.

So I downloaded the Meteor repo onto my laptop and got on a plane ride home from a conference and I told myself, by the time I get off this plane, I'm going to understand how this works. And I did. It's actually pretty straightforward once you know the trick. It's simple, it's elegant, and it felt to me like maybe these guys are on to something. This is actually the better way to do this. Not just a trick, but a genuinely new way to do things. And I was very impressed, loved it, super satisfying to find out how it worked. And then I closed my laptop and, I don't know, watched a movie or something. No dots were connected that day. Shiny was not born that day.

The morning everything changed

In fact, it was almost a month later when it finally hit me. And the way it hit me was a little weird. I swear this is true. This has never happened to me before or since. That morning I woke up. I opened my eyes and the very first conscious thought in my head was an entire web framework. Yeah, that's not a joke. That literally is what happened.

And I will show you literally what it looked like. It started with a simple HTML interface. The most important thing was you weren't going to have to write any JavaScript as an app developer. All you had to do is write HTML tags and include IDs and classes that would indicate where inputs and outputs were and what they were called. And we would power that with reactive server logic using that trick from Meteor. All you would have to do is explain how an output is to be created based on these input values and Shiny would take care of knowing. And then a WebSocket connection to tie them both together. And this, what I'm showing, that was the first thought in my brain when I woke up that morning. It felt like a gift.

But the weirdest thing about that morning wasn't necessarily the completeness of this vision. It was the timing. This is terrifying. I've never told this story in public, but I thought it was a thing that I really wanted to share with you now.

That day, June 15, 2012, was supposed to be my last day at RStudio. That spring, I was feeling like my career had plateaued. I was a software engineer in my mid-30s. I loved the work that JJ and I were doing together, but it was just the two of us. And all around, I looked at my classmates and people that I had been peers with at past companies, and I saw them starting companies and riding rocket ships, you know, up the corporate ranks at the biggest tech companies and just doing the most amazing things that I would read about in the news. And I was deathly afraid of being left behind. And I felt like in order for me to feel like I was a success, I was going to need to start my own company.

So I went to JJ. I mean, I've been with JJ for a long time, and I opened up to him about how I was feeling. And he said to me, I totally understand. And if that's what you want to do, I will support you. I'll help you however I can.

But this was in the run-up to UseR. We were trying to get RMarkdown off the ground. He had a keynote. So my commitment to him was I'm going to fully focus on RStudio until UseR is over. And as soon as UseR is over, I'm going to go on leave and think about my future. And if all went well, I'd never come back from that leave.

The last day of UseR, what did I say? June 15, 2012. It was that day. What was supposed to be my last day at RStudio.

And in the blink of an eye, when this appeared in my brain, it was like a light switch was flipped. And all those feelings I had, all the fear and insecurity, were just erased in an instant. And I was completely consumed by this curiosity of would this work? Can we build this? And just filled with this creative drive to see this happen.

And I tell this story because I want you to understand how profound a gift, really this was the first of many profound gifts that Shiny gave to me. I was about to make a pretty big life and career decision that I think would have been a mistake because I was making it out of fear and out of insecurity. And what Shiny gave me was something to run towards with curiosity, with creativity. And it's just been such a magical 10 years, I wouldn't trade it for anything.

And what Shiny gave me was something to run towards with curiosity, with creativity. And it's just been such a magical 10 years, I wouldn't trade it for anything.

Building the proof of concept

Now, I took this sketch, you know, jotted it down and ran down to find JJ. And I showed him, I was like, look at this. And he immediately got it. I mean, instantly he was like, this is it. This is what you work on from now on. Forget everything else. You're working on this. And he just requested one change. It took him some time to convince me. He said, why are we making people write HTML? And I was like, I'm saving them from JavaScript. They can learn HTML. But he was pretty insistent, and he was very right. And what we ended up was this. Writing R on both the client and the server. Of course, you can use HTML if you want to. But this is pretty much what we have today in Shiny.

So, with this idea in hand, we spent a frantic seven weeks making Shiny into a proof of concept that we could present at JSM. And seven weeks later, this is what we had. This is the demo that we displayed at JSM. And we had settled on a tagline that was easily create interactive web applications in R without needing to know HTML, JavaScript, and CSS.

So, now we knew that it was possible. But now what? Now, to me, my ambitions for this was, gee, I hope someone uses this and likes it. And JJ being JJ said, why shouldn't all our users be making apps? And why shouldn't Shiny be the way that they make them?

So, the three of us got to work. Winston Chang joined the company just a very short time after JSM, and we got to work working on Shiny. And in order for Shiny to be a success, for it to have an impact on the R community, there were three big questions that we had to answer, and the answers had to be yes across the board. The first question, can we even build this in R? We did the proof of concept, can we take it to production? Because the conventional wisdom was that R is a language for stats, not web frameworks. Secondly, are R users ready to write web apps? Because writing web apps is very different than data analysis. There are different muscles that you need to use. And Shiny in particular was going to ask people to learn concepts that nobody, almost nobody had seen before. Were R users ready to do that? And the third was, would the R community respond?

Are R users ready?

I want to tackle these questions one by one, a little bit out of order. The first one being, are R users ready to write web apps? And what we learned was this. R users are not afraid to learn. I mean, think of who you need to be to even be considering learning Shiny. Okay. You learn statistics. You know about visualization. You learn to code. You know Git. You probably know the grammar of graphics. Yeah, I think they can sit through a few tutorials and read some reference documentation. R users were not afraid and continue to not be afraid.

And R users were and are incredibly motivated by what Shiny offers them. We did not have to sell very hard for people to realize Shiny was not just one more tool in their toolbox, but it was a force multiplier for everything that they can already do in R. Because it meant those existing skills could be exposed to a broader audience than they could otherwise accomplish. And Shiny produced mic drop moments for R users. I'm going to go out a little bit on a limb here and tell me if this sounds familiar. I heard multiple stories of people going into a conference room with their Shiny app and leaving JAWS on the floor.

And something about Shiny feels within reach to R users, even though there are a lot of concepts that you need to learn. Somehow it feels like we wrote this for you. We wrote this expecting you to come along and learn it. And that felt different than TypeScript and React and these other web technologies where it felt like this was really for somebody else and you would have to become somebody else to learn this set of skills.

And these things might almost seem obvious by now, but it wasn't back then. And in 2012 to 2015, there was like a Cambrian explosion of reactive frameworks in all different languages, and most of them are forgotten. Because most of them didn't find a user base that was motivated by what they had to offer or they couldn't make it past the learning curve. So I just want to be clear, I don't take this for granted. It's amazing. It's amazing that things worked out this way.

So the question we had going into this is, are users ready to write web apps? And the conclusion that I've come to is that R has the best audience for Shiny. It's perfect.

The R community responds

The next question, would the R community respond? And instead of telling you, let me just show you. This is just a list off the top of my head the other day of some of the many amazing packages that people have released that are built on top of Shiny and enhance the capabilities of Shiny in some way. And I know that a lot of you in this audience are using these packages, and the authors of some of these packages are here in the audience as well. Maintaining an open source package that people actually use is not an easy feat, and a lot of people put a lot of time into the packages, not only on this list, but on all the ones that I don't have room to list here. And again, I don't take that lightly. That is a huge vote of confidence in the work that we're doing and the foundation that we've built.

So I'm so grateful to all these people, and there's a GitHub user called nanxstats that has a document called awesome Shiny extensions at GitHub. And this is a list of just a whole bunch of packages written in R that extend or enhance Shiny in some way. Again, it's humbling to see how much time and energy people have invested in trying to make Shiny better.

And as Hadley said, writing books ain't easy. I'm sorry, this is unscripted, but I believe the first advice you gave me about book writing was I asked, how does it work with getting a publisher or whatever? And he said, step one, write a book. Step two, get it published. There's no step three. Yeah. Not great advice. So I'm astounded that there are, I mean, not just three, but there are several more complete books that people have written about Shiny. And again, knowing how hard it is to put together a book, I'm in awe that there are people who are doing this for Shiny.

I don't think we can really talk about the Shiny community without mentioning Eric Nance. Eric Nance might be the biggest cheerleader for Shiny inside or outside of our studio. And among the many contributions that Eric has made is he currently has the Shiny developer series going. It is, what, 30-plus episodes and counting of really interesting and deep conversations with very interesting and deep people around the Shiny community. So I definitely encourage you to check that out.

And there are so many other ways people contribute that are not necessarily in those categories. Every GitHub issue or PR, it takes time and energy to put together reprexes, to put together patches, and I appreciate every single one. Every year we hold a Shiny contest, and I'm blown away by the amount of care people put into crafting these submissions. It clearly means a lot to people. Blog posts, conference talks, workshops, there's so much content that people put together about Shiny, and it is not easy.

There are entire tutorials that were created by people in the community. Zev Ross here in the front row created a tutorial talking about how to use Shiny from scratch with a bent-towards-GG plot, and that got a lot of people into Shiny in the beginning. Appsalon, are the Appsalon guys here? The Appsalon folks? Yep. They did a Shiny conference.

So I'm sorry. You know, it's been ten years. Please, can you just give me this? I'm so grateful to all these people and all the different kinds of contributions they've made, and because I have the attention of this whole room, and I know a lot of the people in the community are in this room, can we just take a second and all say thank you to all these people?

So the question was, will the R community respond? I can't even put into words how the community has responded.

R as the best language for Shiny

And finally, can we even build it in R? In 2012, you might have heard things like, R is a DSL, a domain-specific language. The alternative to R isn't Python or C Sharp. It's SAS. Or use R for, you know, a web server. These are real quotes from a real talk that was given by John D. Cook at GoTo2012. And this is not to pick on John D. Cook. These were totally reasonable statements at the time. And what we found was not just that it was going to be possible to do this in R, but it was bizarrely good as a host language for Shiny. Bizarrely good.

And I feel like that's sort of an extraordinary claim, so I will provide some evidence. It's going to get a little bit geeky, so just be ready for the shift in tone. A lot of languages have positional and named arguments, programming languages. A positional arg, like you see here, is like X, right? There's no name. You just put it with the right number of commas, and it gets matched up. And then you have named arguments where you specify exactly what parameter you're passing. Height equals 20 in this case. And tons of languages, tons of languages have both positional and named arguments. But what almost none of them have, none that are in current use that I could find, R allows the named arguments to be passed first. Super random, weird quirk. Nobody does this. This is not considered a best practice. Python doesn't do it. Ruby doesn't do it. C Sharp doesn't do it. None of these languages that have both named and positional args let you put them in this order.

And this matters for Shiny. It matters for Shiny because a lot of what the UI layer of Shiny does is express HTML. And think about how you express HTML if you're familiar with HTML. An HTML tag really lets you express three things. The tag itself. In this case, on the outside, we have a UL tag for an unordered list. Secondly, the attributes for that tag describing, well, attributes about the tag. In this case, it's saying that this unordered list is for the purpose of navigation. And third and last, you have children. What are the things that are contained inside of this tag? But this order is the right order. This is the way we think about it, right? What am I making? A UL. What are the attributes of that UL? It's a nav. And then what's inside the UL? Children.

So if this is the structure we're aiming at, how closely can we match that in R? Pretty close, as it turns out. It almost looks like we've just taken away some angle brackets and added some parentheses. And some commas. Sorry about the commas. It's the same order. UL first. Attributes second. Children third. And it's only because we're allowed to put the named arguments that we're using for attributes first.

So just to take a language at random... Let's talk about Python. Python has named arguments, but they have to go last. So we end up with tag first. Attributes at the bottom. And then all the children. And that is a problem, because it adds all this space that you have to look past in order to find out what kind of a UL you're creating. This example is just 12 lines, but you can imagine if this is a production dashboard, it might be screenfuls that you have to traverse.

So I don't want to put up the weakest straw man possible, so let's steel man it a little bit. So here is one option that you could use in Python to improve the situation. You could get rid of named arguments altogether and express everything with positional arguments. And you could do that. You could put a dictionary at the top. Similar to like a named list, I guess. And this would work. It adds some curly braces. It adds some quotation marks. So it's not perfect, but it certainly works. I'm not going to argue it doesn't work. I would call this maybe 85% as good as what you can do in R.

The other way you go in Python is to go all named arguments. So you don't pass children as unnamed arguments. Instead, you make a named argument called children and give it a list. Again, the details here aren't important. The point is it's worse, I guess. That's the point. And this one, to me, is worse than the previous one because it actually pushes the code off the page. We've added a line, a vertical line, and a level of indentation for each level of children at this point.

And also, switching from UI to reactivity, nonstandard evaluation ended up being weirdly, bizarrely good for reactive programming, not something that we had anticipated. This is what my sort of... if I could wave that magic wand and have a language to express reactivity in, it might look something like this. I want a language keyword for the word reactive. That's an important concept. I want to attach a code block to that keyword. And then reading something out of a reactive expression, like read data, say, I want a star operator, sort of like dereferencing a pointer in C. So this is kind of what, you know, if I got my wish, this is what a perfect language for reactivity would look like. And let's see what we have in R. It's pretty close.

In Python, we have to go a different way. Python does not have nonstandard evaluation, so you can't pass a bare block of code to a function and expect it to be anything but a value by the time the function gets at it. Instead, in Python, you have to write a function, a named function, and then you have to apply reactivity to it. Now, again, I don't want to leave you with a straw man, so here's the steel man. Python has a few tricks of its own up its sleeve, and this is called a decorator. And you know what? This is not bad. I'll say this is maybe like 90% as good as R. I still don't love that it's a function. It feels like you made a function, and then you made it reactive, and I really prefer how it looks in R, where it sort of feels like you constructed a reactive. But I'm not going to argue that this doesn't work and doesn't have appeal to people who come from this tradition.

Okay, so can we even build it in R? R is the best language for Shiny. I will die on this hill. R is the best language for Shiny.

R is the best language for Shiny. I will die on this hill.

So those three big questions were answered. Can we even build it in R? R is the best language for Shiny. Are R users ready to write web apps? R has the best audience for Shiny. And will the R community respond? To almost an absurd degree you have responded. So yes, Shiny has been a success.

Introducing Shiny for Python

So I hope that I've convinced you, or at least I've convinced you that I am convinced that R is the best language for Shiny. But you know what they say about Python. Python is the second best language for anything. And that is not an insult. That is a compliment. That quote was popularized by Dan Callahan at PyCon 2018. During a keynote, he said, Python is the second best language for anything, and that is an amazing aspiration. Because it means that whatever domain you're operating in, whatever weird new technique in computing you're interested in, there's a pretty good chance that you can stitch something together in Python. And it might not be the very best version or the very best expression of that idea, but it will be available to you without going somewhere else. And there is undoubtedly power in that.

So introducing Shiny for Python.

Here is an app running in Shiny for Python. This is sort of our July 31st, 2012 moment for Shiny for R. That's about where we are today with Shiny for Python. I don't expect you to be able to read this code, but if you could, and you know Shiny for R and you know a little bit of Python, this is going to look pretty familiar. There are a lot of concepts that carry through between the two, even though we are dealing with two separate languages. And the server side is filled with the same kind of reactive concepts that you're used to from Shiny for R.

And before we go further, I have to warn you, this is an alpha, and it's especially alpha because we did all this work in secret. And we're not used to doing that. None of us really like it. We're really happy to not have to do it after today. So we are not ready to call something out of alpha until the community has had a chance to bang on it and we still reserve the right to change the API. So I'm going to give you that warning.

Our design philosophy for Shiny for Python was that it's very similar conceptually to Shiny for R. And that wasn't necessarily a first principle that we started with. We were open to changing our ideas as we moved from R to Python and vice versa. But I think what we found was a lot of the trade-offs that we had made in R were pretty universal, and they felt pretty good in Python. But it's not a slavishly literal port from R. We don't want Shiny for Python to feel like it was written by R users. We want it to feel idiomatically like Python.

So to give an example of what I mean when I say, you know, Python is the second-best language for anything, I tapped our resident astrophysicist, Dr. Julia Silgit. Not a joke. And I asked her, you know, I hear Python maybe is big in astronomy. Is there something we could do with a Shiny app for that? And she had this idea for an air mass calculator. And long story short, this lets you provide a list of astronomical objects you're interested in observing on a certain day and from a certain location on Earth. And this calculator will tell you what times of night are optimal for viewing that object, including how much air lies along your line of sight between you and the object you're viewing. Because depending on its angle from the horizon, you're going through a different amount of atmosphere. So that's what this air mass calculator is showing you. Super easy to do because of AstroPy. And super easy to turn into this app because of Shiny.

So Shiny for Python, again, alpha. It is available now. If you go to shiny.rstudio.com slash py, you will find lots of documentation. There are examples. There's articles. There's API docs.

And I want to talk a little bit about editor support. We expect that most people are probably going to be writing these things in VS Code, and we've written an extension for authoring Shiny for Python in VS Code. If you use something else like PyCharm or JupyterLab, that should work too. We're a pretty standard Python web framework in that respect. RStudio IDE is going to get basic support for Shiny for Python apps in the next release. That'll be mostly in the form of a run app button. And if you are using RStudio Workbench to have RStudio on the server, then the VS Code and JupyterLab versions that are run on RStudio Workbench work great if you have the current release of RStudio Workbench.

Now, because Shiny for Python is Shiny, we have to talk about deployment options. And I'm so pleased to tell you this is working today on ShinyApps.io. You can deploy Shiny for Python apps today. RStudio Connect already supports Shiny for Python in its current version, the one that came out earlier this month. It's just not documented at our request. And RSConnect Python is the CLI tool you use to deploy to those servers. And as of today, assuming everything went well... Okay, I'm getting the nod. Yes, this is available now in RSConnect Python.

And, of course, as JJ said this morning, we never want to lock up your work in proprietary solutions, so we do always have an open source option available. Shiny server open source. It'll be fully released when I get back to my hotel room. There was one more button I forgot.

Listen, guys, it's a long talk, and I was very nervous. Okay, instructions for all this is, they're all available on the Shiny for Python site under the Deploy tab.

There is one more deployment option for Shiny for Python. You can deploy it to a static web server. Wait, what? And I'm sorry, I'm gonna have to leave you with that teaser, because Winston Chang is gonna talk about this tomorrow at 11.30 a.m., running Shiny without a server.

I gotta say, this is, I mean, this is a magic trick of our own. When Winston suggested this technique, I actually told him not to do it. I said, you are wasting your time, and he proved me wrong within 48 hours. So it should be a talk to remember. I do have to give a little caveat. Instructions apply, not all apps will be eligible, serious side effects may occur, must be 18 years or older. You don't need to be 18 years or older, but I'm not joking about the other ones. There are caveats. This is not gonna be a universal model for how we deploy Shiny for Python, but the fact that this is even possible is incredible, and I think for definitely some of you in this room, it's gonna be a powerful way to deploy Shiny for Python apps.

The future of Shiny: R and Python

Now, I want to make it clear that the future of Shiny is not Python. The future of Shiny is R and Python. And I don't want you to think that we only have goodies for the Python community today.

Again, a lot of this work was done in secret, so we have to consider it alpha, but, man, the things... You might have known that Shiny for Python was coming. I don't think you know that this next one is coming. A visual editor for Shiny UI. Now, some of you that have known me for a long time might be a little bit surprised. I mean, this has been suggested many times, and I have shot it down sometimes in sort of a principled tone. So Nick Strayer's gonna talk about why we think that this is the right time for us to do something like this and how we avoided the pitfalls that I was so worried about when it came to visual editors.

Greg Swinehart is a developer who's worked with and for our studio for, gosh, like ten years now. And recently, Greg joined the Shiny team to help us help you make better-designed, better-looking apps. So it's early stages, but Greg is gonna talk about both some of his own design principles that come to mind as he looks at Shiny apps and how they can be better, and also some of the components that we're creating that will help make it easier for you to fall into a pit of success when it comes to your designs.

And finally, Barrett Schlurke is gonna be talking about Shiny Test 2. This is not secret. This is up on CRAN. And Shiny Test 2 is a fundamental part of the Shiny stack for anybody who cares about robustness and keeping their apps bug-free. It's really difficult work, and it takes a lot of patience, and it's not particularly glamorous. And I think Barrett Schlurke, I can't think of a better person to tackle these kinds of hard problems.

I'm sorry, I can't resist this. Can anyone deadlift more than 503 pounds in this room? And Barrett Schlurke is also the strongest person at RStudioConf. He's also a new dad, but there's lots of new dads. That's 503 pounds. That's ridiculous.

This is Team Shiny. I knew this was gonna be the hardest part of my talk. It's my favorite slide, and it was the hardest thing to come up with anything to say. I'm so grateful to this team. I'm so grateful for the work that we've done together over the last year.

All right. Thank you very much. If you want to learn more about Shiny for Python, you can go to this link or use the QR code, and don't forget these talks tomorrow by Shiny team members. Thank you so much for ten great years of Shiny.

Q&A

Thanks, Joe. Thanks, everyone. While we wait for questions on the Slido, I had one more comment for Joe, because during this talk, I remembered, I think it was in 2012, like, Joe, it must have been, like, at USAR or JSEM, like, Joe was telling me about this idea he had to do, like, a web application framework in R, and I was, like, in my head, like, yeah, Joe, that's just what R needs, a web development framework. So, another case where I was very, very wrong.

So, first question for you, Joe, how did you come up with the name Shiny? So, the name Shiny comes from a show called Firefly. A few months before Shiny, you know, became a thing, I was laying sick in bed, and I watched the whole series Firefly for the first time, and they used the word shiny to mean good. They'll say, yeah, I'm feeling shiny. Yeah, this job is going really shiny. And I just thought, like, oh, that's, I like how they just sort of slipped that in all casual, and I thought that'd be a cool name for a project someday.

The day that I was creating the GitHub repo for the first commit of what was to become Shiny, on GitHub, there's a little name suggester, right? It says, like, having trouble thinking of a name? It's blah, blah, blah. And it's three segments. I don't remember the first segment, but it was like, it was something like Ninja, Octocat, Shiny. And I was like, all right, that's a sign from God. It's shiny. That's what it's going to be.

I know I've asked you this question myself. What do you think of people calling Shiny, R Shiny? Yeah, I think maybe Dean Attali popularized this and just felt like, hey, it's more clear, and he really was successful in popularizing it. And I think for people internal to RStudio, they'd frequently ask, hey, is it R Shiny or is it Shiny? And I said, it's Shiny. It's not R Shiny. It's just Shiny. And so I think, like, all of us sort of developed a little bit of an aversion to R Shiny. But now that there's Shiny for Python, it's going to be hard not to call it R Shiny. So I've made my peace with it.

So what about, obviously, other similar frameworks like Dash and Streamlet? Why Shiny for Python? Yeah, totally. It's a valid question, and it's a really interesting question we didn't have to face with Shiny for R. I think that there, as these frameworks were coming out, we looked at them, each one of them, and we were curious, not even from a competitive point of view, but just out of curiosity, what were their approaches? What tradeoffs had they chosen? And it turned out that despite the proliferation of these kinds of web frameworks and Python, all of the tradeoffs that they chose were actually quite different than what we were doing with Shiny. And I think the kinds of apps that I see people build, people in this room, a lot of them would actually be difficult to build given the tradeoffs inherent in those other... You know, this is not, like, a Python conference. It's not PositCon. It's, you know, it's RStudioCon, so I don't want to belabor it, but I do want to say that there are real differences, and I think that there is room for... We think that there's room for something new in the Python world.

Someone related, what about PyScript? Oh, the new thing that Peter Wang presented. Yes, so PyScript is a really interesting piece of technology that sort of goes the other way. It lets you take an HTML page, you know, that might have JavaScript, might have whatever in it, and it lets you embed Python snippets of code into your JavaScript apps, basically. I think they want to replace JavaScript as the language of directly manipulating web apps. So that replaces one part of the stack. It replaces the language JavaScript with the language Python. So I think that's an interesting endeavor and certainly very impressive technically and quite different than I think what we're trying to do, which is to go from Python and sort of relieve you from having to have to think about the entire stack. So the orchestration of how data moves back and forth between the server and the client, there are just a lot of things that are part of our stack that PyScript is just out of scope.

Now, you mentioned that we might be able to run Python, Shiny for Python, but out of server. What about Shiny for R? We sure hope. We sure hope so. The thing is that right now, the technology that this... Is it okay if I say the word? This approach that we're taking for running in the browser is called Wasm. And Python is the second best language for Wasm, yeah. Those guys, every time. Yeah, they're the second best language for Wasm. Yeah, Rust is probably number one. So the question really is about, is R going to have Wasm? Yes, so that is something that we're going to be working on. George Stagg, who's recently joined our studio, is giving a lightning talk about this. So we are actively working to bring Wasm for R so you can take any R application and compile it to JavaScript, basically.

I feel like we just did a really bad version of, like, Winston's and George's talk. Sorry, you should check them out. It's going to be pretty exciting. Okay, I've got a high-stress question for you, but I'm going to follow it up with a low-stress question. So when will the book that covers all of these exciting new features be out, though? Whenever Hadley needs a new bike.

Would it be possible to use both R and Python within a single app? Could you use both R and Python in a single app? I mean, I suppose you could do something with Reticulate. We know you can, because people do use Reticulate with Shiny for R, and I'm sure the reverse works as well. But yeah, definitely not something that we have thought a lot about in building Shiny for Python.

How about other packages in the kind of Shiny ecosystem, like Shiny Test 2 and HTML tools? Are you going to bring those to Python as well? Yeah. We sure hope so. Again, this is the 2012 moment of Shiny for Python. Anything's possible. Are those three big questions going to be answered the same way in the Python community? Nobody knows. So I think it would probably be premature for me to stand here and say that all these things are going to appear. But it is certainly our intention, if we're successful in the fullness of time, for Shiny for Python to be a mature and complete stack in the same way that Shiny for R is.

So sort of following up on that, is the plan to have the features develop at the same pace for both R and Python in the future? Oh, would the features be developed at the same pace? Certainly for features where Python is catching up to R, naturally it's going to go much