[Music] foreign to build shiny apps in Python you can now tap into the vast ecosystem of packages and integrate them into your shiny apps it's always nice to introduce an open source package and stand on top of giants shiny semantic in Chinese for python is the implementation of the r shiny package shiny semantic in Python and we have one of the authors of the package to talk more about it Pavel demin is a shiny developer at Epsilon he's a self-taught developer with background in social science and statistics Powell enjoys multilingual environment with various modern Technologies delivering Solutions in our Python and react so let's dive into the talk thank you for the introduction weather hi my name is Pavel and today I'll be sharing with you my experience of porting shiny semantic from our shiny over to shiny for python this is the agenda for my talk first we will cover the necessary glass glossary uh we will cover the results of this experiment and then I will start talking about the experience of the device finally we will jump to conclusions and we will have a discussion section so before we proceed uh I want us to be on the same page and I want to have this small refresher on key libraries that I mentioned in my presentation so obviously you all know what shiny is but here are some libraries that some of you might not be so familiar with first and foremost this is semantic UI front-end framework which is the key thing in this whole process uh in particular in Chinese semantic so this is basically a library written in HTML JavaScript and CSS that creates those components that you see in the browser when you run your shiny application next shiny semantic is the r shiny package that adapts semantic UI it brings it into the our shiny world and it exports our functions so that the user can generate HTML code by writing our functions instead of HTML and also it provides us with shiny bindings this is what what is responsible for the communication between the shiny server and shiny client this is how you can render and update the components in shiny semantic finally buy shiny or shiny for python is a re-implementation of shiny in Python and I want to stress the most here that the server part of shiny has been Rewritten in Python however the client side remains unchanged and it means for us that the for building shiny bindings has got to be has got to be the same which means that we probably can reuse those from shiny semantic now that we're on the same page let's let's begin although this experiment was mostly about ideas Impressions and knowledge it also has some tangible results so uh if you're interested you can check them out first of all although the package the buy shiny semantic is in its earliest stage possible it's already available on Pi Pi you can install it with Peep and play around the source code of the package is all it's hosted on GitHub and we even created two demo applications which were supposed to help us during the development process you see them on the on the gifs on the slide so one is just a demo of of shiny semantic components and another one is a copy of a shiny app featured on posit Gallery in shiny which is a t-test simulation now I can sense that uh there has been too many instances of word semantics so maybe we can figure it out with a simple graph uh so first there was shiny and shiny are shiny by default uses bootstrap bootstrap 3 and bootstrap is cool uh until everybody uses bootstrap and what's cooler than bootstrap is the ability for your application to stand out from the crowd and this is why Epsilon team has decided to bring semantic UI into our shiny by building the shiny semantic package sometime later a semantic UI was not very well maintained and the the dependency on it was replaced with fomantic UI which is a community Fork of semantic which is actively maintained however the name has the name of Chinese semantica State the same for the compatibility reasons and for some other reasons fast forward to these days shiny for python is released and we started experimenting with it almost immediately and eventually we had an idea of taking one of epson's Open Source packages in our shiny and try to Port it into shiny for Python and see how it goes we chose shiny semantic for various reasons first of all it's arguably a signature package of epson it has most stars on GitHub it's recognized by the community uh and it would spark some interest second and even more important the semantic UI as a front-end library is pretty much self-contained so unlike uh fluent UI which stands behind another epson's package Chinese fluent a fluent UI although it looks beautiful it's very nice it really it relies on react to work and for for our experiment it would it would mean one extra dependency one extra thing to care about and we didn't want that we wanted to isolate the experiment this is why shiny semantics seemed to be a perfect candidate for this for this task and so okay shiny semantic it is let's start the development um and as as you've noticed on the graph this by shiny semantic maybe I'll show it one more time it has three incoming arrows from shiny semantic from fermented UI and from by shiny and I call these arrows sources of inspiration uh so what is a source of inspiration a good way to think about it isn't a form of a question I want my package to make most sense from the perspective of which technology and this question can be generalized to what target audience do I expect for my package uh namely what was the entry point of the developer who will be using this package into the shiny world was it an r-shining developer who is transitioning to Pi shiny was it a front is it a front-end developer who is familiar with semantic UI other front-end libraries and they want to start doing shiny or is it a python developer who learned about by shiny and now wants to to build interactive apps using this Library these are all more important questions and uh they they really affect in how we want to structure the the application to build the API itself and these three sources of inspiration ultimately resulted in three stages of development which were not predefined but rather changed each other one after another and retrospectively I named them after the corresponding packages which acted like sources of inspiration uh but this is all good these are all valid points but let's get back to Earth uh when we just started developing the package we didn't even think about how is it going to go to the open source to the public what is the target audience uh we didn't know how it would go at all so instead of overthinking it uh we decided to let it flow naturally and let's just start building and see how it goes that was the approach and we first approached the development with this uh Reckless thought let's translate existing R code into python like a proof of concept can we do that and actually a great idea why not if it's possible that's that's a great news right um it might seem Reckless at First Sight however if you take a shiny abs are built you will immediately notice a lot of similarities look at the screenshots uh one is an example in our a snippet in R second is in Python and they are very similar and this happens because of the great effort of the developer team behind by shiny and as a package developer I'm especially a huge fan of HTML tools which has been brought over to python uh what you see is is basically HTML tools this is this is a package both in R and python which provides you with functions that you write that generate HTML code that I mentioned before uh take this and combine it with the fact that shiny bindings can be reused and this thought or it doesn't seem insane right it makes perfect sense moreover I want to edit here that as an R shiny developer who uses Rhino extensively the transition to python seemed to be very natural because in a rhino application in R you won't see a calls to library or Source function instead you import each box module explicitly most often naming each function in the module explicitly that you need and this way you really granularly can control expert and import flows of the code and because of this writing python code a python application seemed not intimidating but familiar and helpful and this just felt amazing but now UI code is great but it's not all right and well python is not our uh you have to write functions you have to Define some logic structure modules those functions need to do something and the more you do that uh or you start well writing python code instead of translating R code you want to use genuine python features it starts from small things so at least list comprehension which replaces some parts of your code then you take some other parts and you want to change them you want to refactor something maybe in some places you want to bring part of your own personality to the project instead of copy pasting it um uh yeah and eventually you catch yourself on the thought that you're no longer translating the r code the r package instead instead you are re-implemented it re-implementing it in another language uh and next logical thought that you have is why would you want to re-implement a package that implements semantic UI instead maybe I should just Implement a semantic UI directly but in Python and this is how this first stage started smoothly transitioning into the second stage but before we go to the second stage I want to highlight that each stage has its own unique uh perks that we had and takeaways and The crucial takeaway of this first stage of the shiny semantic page stage is shiny bindings obviously some of them we were able to literally copy paste While others we had to slightly modify but it was not substantial it was a very nice reuse of the existing code base we also had huge inspiration in general ideas how to uh how things might work etc so with these takeaways we're smoothly going to the next stage the semantic UI stage so uh again it was not a predefined transition it was all goals organically sort of naturally and the reasons for the transition to this sort of stage are not only the ones that I mentioned in the previous slides but also the fact that as the project grows well it's still a small project it's not like a giant application or something but anyway as the project grows I I create more and more files and eventually I start thinking about how how should I structure these files uh and here is where combined with the previous thought that we should Implement semantic UI directly instead of looking too much at Chinese semantic our implementation combined with this you take a look at the semantic UI and it seems like it's very nicely structured and very logically so you have distinct sections you have elements collections views and modules and now it's a good point a good time to remember that unlike an r package which requires a flat structure where you would put all your R strips into our folder python allows for nesting and we can have those nice sub modules each responsible for a corresponding section in the semantic UI and this approach uh when when we want to mimic the structure and naming conventions of the original underlying Library it has a huge bonus in my opinion it's uh the we kind of Leverage the original documentation of the library so when when a developer when apply shiny developer is interested in how uh module the drop down function Works they immediately understand that they can navigate to the corresponding section on the semantic UI page and see examples tutorial use cases everything and that's a good thing however again the more you write code the more components you create the less sense it might the less sense it just all makes and first thing is if you have shiny specific functions and very importantly page wrappers like page semantic which is arguably one of the most important functions in the package it loads semantic UI into the browser and makes all other components work it doesn't fit into the structure so you create an exception you create a special folder for functions like that maybe you have other functions of helper functions some calculation functions validation functions you also create folders for them uh another problem is uh semantic well what does semantic even mean in the semantic UI the idea is that it uses CSS classes semantic CSS classes human readable you can see the example on the slide so if I wanted to have a large orange button which has a label but doesn't have a feeling color this is how I would Define it I would call a button component with a class large UI basic orange label button and this is great this is very flexible but when you need to package it into a function it becomes kind of difficult to constrain this flexibility so you might want to start creating different functions for that this is again a situation where your structure starts to be different from the original Library structure and initially we I had in mind this very clear structure identical to semantic UI but ended up with kind of a Frankenstein structure which was a com which has never represented shiny semantic on one hand but already doesn't represent semantic UI on the other hand uh but I love is Frankenstein and it works for me uh it does uh its job quite nicely good enough uh so it is but at this point it's clear that we cannot follow semantic UI in in the footsteps so we acknowledge that we're now going different we take away we still take away the project structure naming conventions for the components and we start thinking about something different and the next stage is called by shiny so remember how I mentioned the target audience of this package well at this point it seems that it actually doesn't matter because no matter the background the developer will first have to familiarize with by shiny and then use by shiny semantic if at all and it means that to provide the lowest friction possible and use shiny semantic we really want to align our API with with the with the framework library that we are working in right um at this point you might ask why didn't we just start with by shiny as the first source of inspiration well this is a good question a valid question but uh we actually specifically decided not to do this not to mimic by shiny at the first at the beginning because by Chinese Alpha it's very risky to rely on an unstable package I thought uh but in in the end we ended up still uh trying to follow the pie shiny because it's the approach that makes most sense and truth be told by shiny has been a source of inspiration throughout the whole project uh because you just need to know you need to to learn the source code of the phones are supposed to work how namespace is handled Etc and is handled differently by shiny by the way uh but then the the problem is that the bootstrap that is used by shiny and the semantic that is used by a shiny semantic they are fundamentally different and some things are achieved in very different ways and it's really difficult to make the API 100 interchangeable and look-alike what's more is uh components naming conventions are different and we have just taken the semantic UI naming conventions now we are we we are thinking about transitioning uh they're quite shiny on the screenshot you can see that uh this component in semantic UI it's called drop down in Chinese semantic it's called input moreover drop down doesn't have a label because it doesn't care about the label way was supposed to be a sibling HTML to so what do we do next uh how should we do this transition and it's clear that we need to do this transition uh actually the experimentation the project has stopped here but we still had some time to think about it seems like the optimal way would have to would be to have this internal functions that represent the semantic UI logic and structure like this drop down and have external functions that look familiar to the user and we have same function signatures preferably if possible is pi shiny so that we can achieve those that low friction transition and usage and Adoption of the library uh but this is an open topic and this is open source project so you're welcome to express your opinions and participate in the development do the contribution okay I think I'm over the clock a little bit so it's time to sum up during the experiment we learned a lot of things uh and just translate in our package into python or at least you shouldn't but you can reuse Chinese bindings CSS styling and general ideas which is already a huge jump start right considering from Building Solutions from scratch and then by shiny has a very descriptive uh has very descriptive functions name function names and most of them are very similar to the are ones both in terms of names and functionality so so it shouldn't be difficult to to transition really and although it's an alpha I believe that for a UI component Library it provides almost everything we need because to build UI components all you need is HTML tools and shiny bindings right and we have them and finally python is just a great language for software engineering it has great tooling great support great everything and specifically it's great for package development because it package and IPI and although the package is in Alpha it's already accessible it can be checked out it can be installed can be we can gather feedback already if we wanted and we wanted uh okay a small plus Krypton so this talk was about my experience of building a package but if you're interested more in building applications for quite shiny there's a blog post on Epson website feel free to check it out the link is on the image thank you let's discuss thanks for sharing your experience with porting and our package to python I hope this experience will help future people to put some popular art packages to python community we have a couple of questions for you um I like the analogy that building shiny apps using Rhino does not seem much different from building shiny for python can you mention some key differences that you saw uh uh sorry could you repeat the question please yeah so uh you mentioned that building a shiny app using Rhino is not as different as building shiny app for python right so right um can you list any differences that you felt between both uh oh the differences are on the first glance fundamental it's a different language right and when I mentioned that Rhino facilitates the process it's actually about python not being so different anymore because you're used to use modules and exclusive Imports uh however what's different quite a lot of things and I specifically mentioned this disclaimer in the past crypto experience of building a package for by shiny is very different from experience of building an application for pi shiny because you require completely different things uh from the experience that I that I had of building an application by shiny seems great however it really lacks the ecosystem that our shiny has so a shiny app is not only about building HTML components and structure right it's not it's not the landing really a data-driven application that requires some widgets to visualize the data Maps charts Etc and it's not that great as our shiny yet and we hope to see it change okay so uh maybe I'll break this down into two parts so velocity is a key advantage of shiny uh is it true that shiny for python has this and the second question is how is the development experience and development speed for prototyping packages for shiny and shiny for Python and packages for uh are shiny okay uh great question actually why shiny is fundamentally not that different from our shiny so if you're already familiar with how Pi shiny Works which function it has uh it should be pretty much the same right however again it it all comes down to Echo System all the time in our shiny you have a ton of packages and you don't need to implement something because you already know that I can just call this function from this package and I have this here you might not find that sometimes uh another part about packages I think it's comparable it's uh it's not difficult to build a simple r package and it's also not difficult to build a simple python package uh what's more there is a ton of tutorials on the internet for python how to build a package how to test the package how to publish a package how to publish a package to test mirror of Pipi to see it working Etc and that all really helps awesome uh so maybe we'll confirm this with Winston later today but what is your preference uh do we call it shiny for python or Pi shiny my personal preference is quite shiny uh I don't know I use them interchangeably okay uh thank you Pavel for the great talk and sharing your experiences thank you
2023-05-20