- Hello, YouTube. Hello, Fabio. - Hi, Michael. How's it going?
- I'm very excited to talk about PyScript and WebAssembly and the work that you've been
doing. I think it's a big deal, and it's going to be really important for us, so let's kick
off this podcast. Fabio, welcome to Talk Python to Me.
- Thank you. I'm really happy to be here. Thank you for having me.
- You're welcome and I'm excited to have you here
because I am quite excited about the PyScript announcement
that you have put so much work into.
I'm very excited about the possibility of finding Python
in other places than where it has really great strongholds.
For as much as Python is, the incredible growth of Python
that Stack Overflow blogged about in 2017
and all the growth in different metrics,
but by some metrics, first most popular language
or second, depending.
But for all of that, there's still very notable places
where Python is not.
And what you're working on has the possibility
to unlock one or more of those places
for a whole different set of contingency
that people have data scientists, web developers,
UI developers, maybe just for desktop even.
So exciting.
- Yeah, yeah.
I think it captured a lot of the things behind the project
and really happy to talk about all of those
'cause yeah, that's the reason we started it.
So next time.
- Yeah, and it's super exciting.
There's been some attempts at this
and we're gonna get into,
I wanna sort of start our conversation about the history
of what has come before and so on.
Before we do though, let's just hear a bit about you.
How'd you get into programming in Python?
So, programming, I think I always been, I was being curious about a lot of things and
probably doing too many things still today.
But early on, I got into programming through friends who had computers and Commodore or
things like that.
We would hop on.
I had, in my bed at some point, bought a--
I don't even know the version.
It was similar to Commodore, but it was in Brazil, a Gradient
MSX or something.
It was a local, a national branded computer.
But it allowed you to jump in and do basic stuff
and programming.
So I remember trying to play with my friends
and try to code games.
Of course, we never got anything done.
But I always been passionate about computers and gaming
and stuff like that.
So into college, I had to do a computer science degree,
training to become a game developer.
Also never happened because I got--
- I think it's really interesting that so many people
want to get into game development,
and then they kind of see
the sort of grinding mode of that industry, right?
It's like both fascinating and has this great pull,
then you're like, but it's really hard on humans as well, right?
Yes, it's a very hard industry and very competitive.
My brother is an indie game developer
and a lot of sleepless nights and working hard,
trying to get his thing out there.
And so, yeah, I think--
and through life, I also--
just life happened.
I met my now wife and started to be a little more serious
about gaming is great, but also need to make plans
for the future.
So I ended up graduating and started
to work for a company that did automation,
like machines automation in big industries,
mainly on pharmaceuticals.
And I worked there for a while, and I was in the team that
would develop high-level applications for analytics.
And we would usually do for big pharmaceutical production
lines, so providing all the charts and everything
they need to say this production batch is
valid for whatever FDA or whatever entity is approving them.
A lot of paperwork, a lot of things.
Eventually, at some point,
my unit became a big part of the company.
My, at the time,
the CEO of the company asked, "Hey,
do you want to start a startup,
spin off of our company,
just focus on software?"
I did that.
- That sounds like a pretty fun challenge.
- Yes.
- Do a startup without quite the risk
of actually being a startup.
- Yeah, yeah.
- You're gonna get paid, you know what I mean?
- Yes, you're gonna get paid.
It also, I think the startup reality in Italy,
I was still in Italy at the time,
it's very different from here.
It's really hard to have investors or to have,
to collect money and basically you need to,
it boils down to you investing on your own company
and then trying to get profit within a number of years.
- Okay, it's gotta be way more bootstrap, self-funded,
you know, sort of thing, huh?
Okay.
- Yeah, so eventually--
- Do you think that's changed or is that still the same?
- I think it's changing.
Yeah, in the last 10 years, I think a lot changed
just from like the industry in general became way stronger in Europe as well.
There's a different mindset.
Um, and I think culturally South, South Europe has this culture of, of.
The, a different way to see money, in investments compared
to, to the U S for instance, or, yeah.
Um, but eventually like this experience, led me to the Python community.
early on. I actually got into Python not by myself. I heard about the language, I was curious, but
someone within the company said, "Oh, the son of this customer is really big in the Python
community. He could help us see if it's a good fit for our use case." And it was around early
maybe 2000s, maybe 2001.
- So early days of Python, really.
- Yeah, yes.
And early days of scientific Python as well.
The whole, still the whole separation
between NumPy and NumPy, and numeric, all of that.
So I started, I loved the language,
started to use it in our tools.
It was a funny time where it was definitely unknown as a language and to get into big
companies, it was a little tricky on the QA point of view.
But it was interesting.
Eventually I started to get more engaged with community, started to go to meetups in Italy
and everything.
And I think it was around 2004 or 2005,
I started to go to my first conferences in Europe,
loved the community, started to,
how can I get involved?
And so at that point, later, late 2000s,
I started the, with a bunch of friends
in the Italian community,
we started the Python Italia Association,
which is basically a non-profit trying to push the language.
And the main focus was organizing the PyCon Italy conference.
We started in 2007.
Also that great, great community, a lot of work, but also paid back.
You know, I remember the first year we were like, let's do this thing.
We were very passionate and we end up in negative.
and all the members of the society.
Yes, so just to say that big props to everyone
in the community doing a lot of the community work
because it's a lot of work and it often is not paid
or can even be out of--
- You might have to pay to do the work.
- Yes, yes. - Or the opposite
of getting paid.
- Yeah, long story short,
I started to be also more engaged
the European community. And we organized the EuroPython in 2011. So for three years in a row,
and that got me into the EuroPython Society. Eventually became chairman of that, which
basically means EuroPython Society is this European non-profit that pretty much in line with
with the PSF, tried in different ways,
but tries to engage with the community,
organize conferences, raise some money to invest back
in the community through grants and things like this.
And then I did that for a number of years.
So eventually, well, back in the day,
when I was starting to learn Python,
I also started to use a lot of the scientific libraries
and one of them was Chaco,
which was a graphic plotting library for Python
that Peter Wang developed with Brian Vindman,
I think he was in the show.
- Peter Wang being the CEO of Anaconda.
- Yes, today, CEO of Anaconda.
And we met for the first time in person
at EuroPython in Florence.
And he was like, okay, we know each other
from the internet for a while, like, let's get more involved.
And then at that year,
I was still trying to make my company be successful.
It wasn't the right time,
but the following year met with Travis Olyphant,
the other founder of Anaconda in Berlin.
And we just figured out, you know,
like we're doing a lot of things that are similar.
We're passionate about the same thing.
So I eventually joined Anaconda in 2014.
- Yeah.
- And then eventually that following year,
I moved to the US and joined the company full time.
- Fantastic.
Well, it's quite the journey from just-
- Yes.
- This is interesting language.
Let me just start participating in some of the meetups.
Meetups become conferences,
conference become continent wide conferences.
And I think it's a pretty good takeaway
for people who want to get more involved in the community.
And like every one of those steps
probably didn't feel massive
other than maybe moving to the US and joining in the condo.
But, you know, they all probably seem like really iterative
and sort of incremental, but at the same time,
it's, it builds up this really cool place where you're
- Yeah, actually. - Maybe building
amazing Python things in the browser at, in the condo.
- Right, yeah.
My experience has very much been what, you know,
a lot of people say, you come from the language,
to stay for the community.
That is really my experience.
Yeah, and then, yeah,
Anaconda allowed me to work on a lot of interesting things
like is Python on the browser is the ultimate project.
But when I joined, I started with being a core developer
for Bokeh, which had some of that Bokeh
is a visualization library for Python on the browser.
So, you know--
- And with your project you have now,
you can still put Bokeh in the browser.
- Exactly.
(laughing)
- There's a science.
- You can stay in the browser.
- Yes, exactly.
Even more in the browser than before, I guess.
All right, let's dive in.
Now, before we dive in real quick,
since you talked about gaming,
wanna be in game development and your brother and so on,
have you watched the documentary,
"Power On, The Story of Xbox"?
- I haven't.
- This is a documentary that came out.
It's a four hour show.
You can watch it on YouTube.
And it's like the history of Xbox.
- And if you're just into like tech history documentaries,
this thing is pretty interesting.
But let's not talk about games.
Let's talk about the birth and death of JavaScript.
Have you seen this presentation?
- Yes.
- Oh my, it's so good, isn't it?
- Yes, one of my favorites, plenty of talks, you know.
- So, the reason I bring this up
is there's a lot of interesting building blocks
that I suspect many people in the Python community
are fully unaware of, right?
There's been all these developments
over in the JavaScript world.
And Gary Bernhardt did this talk at PyCon 2014,
the birth and death of JavaScript.
And no, I'm not mispronouncing it.
That's how it's done in the talk.
And it tells this hilarious story of the future
of like weird human evolution and programming
and JavaScript and how we don't do JavaScript,
but everything's JavaScript.
But what is the underlying theme
is like a actual interesting technical history
of how people started doing crazy stuff
with JavaScript pre-WebAssembly.
So there were compilers like in Scriptum
that will compile C code to JavaScript
and then the JavaScript Jits have become so fast.
So one of the examples was like Chrome running Firefox
running something else, like maybe like an embedded Windows.
I can't remember what it was,
but just there were like layers and layers of JavaScript
doing wild stuff that we wouldn't imagine otherwise, right?
>> Yeah. I think that's part of also one of the reasons with Peter,
we said, "Okay, this is the right time to try this out,"
because the browsers became so powerful.
They are basically, if you see from a different perspective,
they are mini virtual machines.
They have their own file system,
they have their own isolation, networking,
a lot of the things you can really see that as a VM.
>> Like the JVM,
like the.NET CLR and to some degree like Python, right?
>> Right.
>> The CPython on a regular machine.
>> Yeah. You can run full operating systems
on top of browser.
Honestly, the explosion of interesting things in
the last few years have been crazy
and doesn't seem to decelerate at all.
So the level of maturity is kind of encouraging.
- It is.
And the performance, while not native performance,
is not that far off.
At least some of the examples that Gary gave,
it was like 50%.
You could run Doom at 50% speed
when you compile it to the browser
or something insane like that.
- Right.
Yeah, it's good enough.
I mean- - It's more than good enough.
Yeah, I mean, because the alternative so often is,
well, we're gonna send a request over to the server
and that might be native and fast,
but it's also network latency
and it's also a shared compute resource
with a thousand other people.
And here you are sitting on your MacBook Pro Max
with 16 cores, you know, and you're just waiting.
- Yeah, yeah.
That's actually one aspect that a lot of people
don't consider.
There is, you know, there's the performance
in terms of how fast it goes.
But there are a few aspects that you also
need to consider overall in the overall experience.
How long for the developer side of point of view,
how long before they can actually
get in front of something usable or speeding up
their environments and things like this.
Then there's loading time versus execution time,
also very different.
but from the eyes of the user, it kind of sums up.
So there are so many small niches or small verticals
that we can work on in the whole JavaScript
or browser ecosystem that I think we can make
a lot of improvements in the next few years.
- Yeah, you think of grid computing
and distributed computing,
part of the power of the cloud is that I could just go say, I need more.
We have four servers, but a bunch of people showed up.
So give me 20 servers and scale my Kubernetes cluster across that for now.
And four to 20 is amazing, but four to a hundred million is really different.
If, if we can push a lot of that compute to everybody's personal computers,
Even our iPhones are unimaginably fast little devices.
Like the whole M1 crazy transition
is basically an iPhone chip with more voltage
and better cooling.
There's not much more to it than that.
So finding ways to execute more of our code
on the clients is pretty interesting.
- Yeah, totally agree.
We already see that even on the server side,
you know, projects like Bask, we're very popular,
pushing the computing on nodes
and you know, the distributed architecture
is very powerful and is needed.
You know, we can have the possibility to make the same thing
on the client side on the browser as well.
- Yeah. - Yeah.
- Dask for those out there who don't know
is a pandas-like, NumPy-like API that you can just say,
but run it distributed across these machines
on the cluster automatically.
You know, Matthew Rocklin started Coiled,
and you know, former Anaconda alumni,
a lot of tie-ins there.
- Yeah. - Yeah, cool.
And so this is, it's not the same thing in any way,
but it is a way that really takes Python
and gives it way more compute resources, potentially.
So are there any particular,
I sort of set the stage with this compile to C and stuff,
but is there any other sort of building blocks
in the history of how we got to what you all built
in the JavaScript stack that you wanna call out?
- Yes, definitely.
I think one major thing that,
you know, I wanna give props as much as we can
to the Pyodide project,
which is a runtime for Python on the browser.
And they've been extremely,
like one of the reasons we could work on PyScript
was because it has a level of maturity
and performance right now that is really stable, right?
And they actually also been,
They're a great community, very supportive.
So a big shout out to them,
Hood and Roman specifically, the two main core developers.
And the whole work underneath that project as well,
you know, like the progress of the Emscripten
and Wasm and WebAssembly,
there's a huge community behind that.
So actually that's one of the principles
that we tried to, at the core of FireScript,
is we don't want to reinvent anything that we don't need.
We want to be really additive to the ecosystem,
glue things together, provide nice and easy APIs
and high-level APIs so that we can lower the barrier,
basically give more accessibility to the tools,
to the users, rather than reinventing something
that's not needed.
- Yeah, so PyIodide.
This project is a cool project.
I interviewed Michael from the project
about this way back, a couple of years ago,
but yeah, it uses this Emscripten
and WebAssembly story to basically compile
a port of CPython to run in WebAssembly in the browser,
which is fantastic, right?
I mean, that's, in some degree,
that's the building block that you all really needed, right?
- Yes, yeah, definitely.
Yeah, I must mention also, yeah,
Michael Dropbaum and Christian Himes,
who has been also pushing a lot
of the Python on Wasm ecosystem.
- Yes.
- Yeah, there's a lot of good energy
in the Python community
to actually try to push that together, right?
- Yeah, and also Brett Cannon has been a big proponent
of making that happen.
I don't know how directly involved with the day-to-day,
like let's make it compile,
but I know he's been really pushing on that effort as well.
And so let's get to your announcement.
I mean, I didn't go to PyCon this year,
mostly just not ready to be in a room
with people from around the world for that long.
And I thought to give the world a chance to try it out,
then I'll see how it goes and do it next year.
But I missed everyone there.
But I got a lot of messages.
One was friends saying, why aren't you here?
Why can't we have a beer together?
Sorry, I really missed that.
And then the other is, have you heard of PyScript?
Oh my goodness, this was the announcement.
Like this, if there's any big piece of news
that came out from presentations and talks and announcements,
like this is the one.
So PyScript, people can guess, but what is it?
Tell us about this.
- So PyScript is a framework that allows users
to basically use HTML tags to define,
to run Python code and define different components.
Those can be related to executing code,
but also providing, defining your environments,
what packages you want to install, et cetera,
as well as some UI components that make things easier
make things easier for users that are not familiar with HTML and CSS and all the styling
of things. It's based on a Python runtime, which is Pyodide, that allows Python execution
on the browser and it has interoperability capabilities
with JavaScript as well.
So you can use both Python libraries
as well as JavaScript libraries in your code.
- Yeah, this is really great.
And if people go to pyscript.net and scroll down
and what is Pyscript, it really calls all these out.
Like if you're trying to present this to your boss
to your team, you're like, this is something cool
we should check out, like, they should definitely
go to that list right there, yeah?
- Yes, yeah.
And that is, you know, the most immediate list of things.
You know, there's a lot that we're working on
and trying to provide as a tooling,
but it's very, very new and very, you know,
green, if I must say.
So, yeah.
- So maybe don't totally release a product on it just yet?
Yes, definitely very bad idea to release a product on this,
you know, expect APIs, code and features to change.
Actually, it's one of the things that we intentionally talked about before Python was,
you know, should we have a versioning in place or something like this,
so that, you know, you would expect any project to go that goes out there to have versions and everything.
We intentionally said no, let's wait because it is,
or let's put a version like do not use in production.0.0.0.1.
>> Yes. Mostly because with this,
we wanted to have something that is working,
that is useful,
that it can be used by and hacked on by users day one.
but also give the vision that we have in mind
and for people to see the possibilities.
And that was the main focus for the project until PyCon.
Now, a lot of the following things
are just the things that we want to achieve
in order to enable a community.
And this is an open source project.
It's not an, it started at Anaconda,
but it's an open source project.
We want to have a strong community,
have contributors beyond the Anaconda team,
and do it together, right?
- Yeah, that was one of my questions
I wanted to ask you about is,
it sounds like you all have a very strong vision
of what this should be and where you want it to go.
- Yes.
- But from what you just said,
I was wondering, does that mean it's more source open
than open source?
And like, we're driving this way and we'll take PRs
as long as it's on our roadmap,
or how open are you to people just jumping in
and giving ideas and trying to build it up?
- Yeah, great question.
We are very open.
So it's worth also saying that right now
we are at the stage where I don't think we've made it
that easy for people to onboard and understand the vision,
understand the project and actually be able to contribute.
We're missing a lot of documentation.
So one of the biggest pushes that we've been having
after PyCon is to actually build up the documentation
around those things so that, you know,
anyone contributing have a easier time on boarding,
understand the visions and can give feedback
based on those things.
So as soon as we are also growing the team behind it,
so there's a lot of small things that we are preparing
for being a community that is on itself
or itself organized and everything.
So overall, I think that this is really a community project.
- Sure.
Speaking of community,
let me just pull up the GitHub page.
- So you're just shy of 10,000 stars.
- Yeah, crazy.
- I don't know how old it is,
but how long has this repo been public?
Not that long.
- No, we actually made it public
10 minutes in during Peter's talk.
So it--
- Okay, so you're like half a flask almost
or half of closing in on FastAPI levels
of numbers of stars.
There's a lot of interest in this.
- Yes, which is really exciting,
but also it's somehow overwhelming, right?
Like, I'll be very honest.
- Yeah, probably there's a lot of expectations as well.
Right?
- Yes, yes.
And so we are aware of all of that.
I think the main thing really for us is to,
you know, we wanna make sure that our users have patience
because we're trying to get to a stable state
or at least--
- It's less than two weeks old, come on.
- Exactly, yes.
I could talk about this for hours,
but at the same time, we wanna make sure that it's usable
and we wanna collect users' feedback to make it better.
Actually, one thing that is very important
is that it got a lot of interest
and a lot of excitement from the Python community
and some of the web community as well.
But I really wanna make sure
that everyone understands the picture,
the full picture is what Peter said,
like programming for the 99%.
So beyond developers,
how can we have a tool
that students can learn very fast,
get to learning coding very fast,
or even non-developers.
I would love my mom to write her recipe book with MyScript,
because it's that easy.
And thinking about the possibility
of shipping that in your phone or your mobile,
users in developing countries that do not have access
to computers and things like this, but they have a phone.
What we also hope is that the social impact
of a tool like this could be very big.
One can dream.
- Yeah, one can dream for sure.
So something maybe you could take inspiration from
is the Swift Playgrounds.
Right, it seems like you can model that pretty well.
And I feel like Swift was largely borrowing from Python
in a lot of its ways.
So it's time to borrow a little back from Swift.
For people who don't know, Swift Playgrounds
is like a little bit like a REPL,
a little bit like Jupyter,
but then on the right you get kind of more iOS outputs,
like little widgets and graphs and animations and whatever.
But it seems like that could be a similar way
that's sort of like Jupyter,
but also a little more web playful.
- Right, yes.
And I would say we have no shame
into like borrowing from others, right?
I think that actually is how you can grow well,
like take what's successful from this community
or this language, et cetera,
and try to use that to make a better tool.
- Yeah, I mean, because it's so early,
because it's so fresh, like one of the drawbacks,
call it a drawback, one of the temporary limitations
is people can't just jump in and build the next version
of Gmail or whatever with it right now.
But a benefit is so many people wanna contribute
to open source, and they're like, I love Django,
I'm gonna contribute to that,
I love Jupyter. I want to contribute to that. And then it's such a complex, highly leveraged,
very polished system that like, well, contributing to that means you have like an insane level
of understanding to make this little change that won't break everything else. Whereas
this is pretty fresh, right? So if somebody wants to come along and build something like
a Swift playground equivalent, the doors open for and I'm not sure how much you want to
But like the door is open for people to be,
to grab ideas that are lower hanging fruit at the moment.
- Yeah, yes.
And the idea is also to allow users to extend
the tool itself and without having to change the tool,
like with extensions and things like this.
Like in my mind, I see that as a sort of Minecraft
for programmers, right?
Like you can build your own blocks
and then share with others and then they can share.
- Right, check out my mod pack for this thing or whatever.
- Yes, yeah, yeah.
And yeah, the idea is to make it well,
powerful, but also fun and hackable.
- Yeah, very cool.
All right, now let's talk about,
I know we talked to some of these things here,
but let me just dive in a little bit on the bullet points
to kind of do a wrap up summary
before we move into the coding.
So Python in the browser,
this means it runs 100% in the browser
through primarily WebAssembly,
which is leveraging the Pyodide project, yeah?
- Right, that's right. - Okay.
And the WebAssembly stuff runs,
I think, even better than the JavaScript,
(laughs)
the C code compiled to JavaScript,
'cause this is still more of a binary form and whatnot.
That's pretty excellent.
One of the things that really inspires me here,
you spoke about this will allow us to do things
on our phones and on lower end computers
and do other things like that
where like now we have this possibility
just if you have a browser, you can kind of do it.
I totally agree and that's great.
But what really gets me excited about where this could go
is progressive web apps or something even like ElectronJS
even like electron JS, right, where I build like a true desktop application like VS Code
or slack or whatever, but instead of having to write everything in JavaScript, you know,
write it in Python, right? And just got to include the two meg or three meg wasm file
with your what is already a massive Chrome distribution. So no one would know anyway.
Right? Anyway, so yeah, there's like this way to sort of, this is what I was hinting
at the beginning as well like oh my gosh,
we can have things in our dock that are like modern looking
that are based on Python.
Easily.
Very exciting.
Yes.
And the whole story about the native apps and mobile
and whatnot.
Russell Keith McGee, maintainer of B-Ware,
is he just joined Anaconda a few months ago.
>> He did. I didn't know that. Excellent.
>> Yes. He's been looking at the project,
collaborating, contributing with some stuff.
He actually made an example.
One of the examples is written in Toga,
which is the Beware Toolkit for UI design and stuff like this.
It's built in Toga,
but it has a PyScript backend so that it
can render to PyScript directly.
Pretty much like it can build for iOS or Android or Mac.
But another interesting story is the opposite.
Can we have a PyScript app that then Toga can transform
into an electron-like app that you can just run on your mobile?
>> Do it. Please do it.
So many people will be happy.
- Yeah, if you're listening, that's for you.
- Yes, oh my goodness.
Look, I think there are plenty of negatives
about electron apps, like why does my password manager
need 400 megs of RAM to run?
But we have such a limited set of options
for desktop and mobile apps in Python
that for now, that would be massively welcome
to do something like this.
And then there's always possibilities of,
well, do you actually have to ship Chrome
in some massive runtime,
or could there be a smaller host?
There's layers of improvement.
All right, next one, Python ecosystem.
When you think about the history,
this is not the first or the second time
that someone has done Python in the browser.
If you're familiar with, are you familiar with Anvil?
- Yes.
- So I had Meredith Ahn from Anvil
to talk about both Anvil one time
and then I think it was Sculpt, which is what they use.
And Anvil has both a backend and frontend
that's all Python and really interesting project.
And they were using a JavaScript variant called Sculpt.
And there's, I think,
Brython is another one that you could choose.
But one of the challenges of that is it's Python-like,
right?
It's not really the Python runtime.
Do you maybe want to talk about how that differs
from the Python ecosystem, Python runtime that you all have?
- Right.
That's exactly the difference, right?
Like, and probably the PyDive folks
would have a lot more to say,
but the big difference is what you said.
Like, it's Python-like, and it will mimic--
- For example, numerically,
like JavaScript doesn't have integers,
so your Python has to somehow fake integers
if you're gonna do things like that, right?
- Right, yes.
So it's mimicking what you would expect with Python,
but with the JavaScript.
And it's not really a full-blown Python interpreter
that you can also install your packages.
The whole Python ecosystem is not supported.
And I think that's the big difference
that was the differentiator for Pyodide.
And now that, you know, CPython actually compiles
to Wasm through Emscripten, it's very exciting.
- It's running the same VM or the same runtime
that we get with CPython on our desktops, more or less.
Like a cut down limited version,
but it's not like a weird transpiled to JavaScript
and then run it thing.
- Yes, correct.
With a few caveats, right?
That's one of the things that I think is worth mentioning.
It's the same CPython code and it's the same thing you get in your local installation.
A few things are different just because the browser as a VM,
they work differently.
File system is different on the browser.
>> Threading probably.
>> Threading, multiprocessing, pipes, and things like this.
There are solutions for some of these
that will require work and probably upstream
with some of the parts of the standard libraries
or the third party packages,
but they are just different.
So we need to account for that.
- Sure.
All right.
So you can use, it says many popular Python packages
and stuff in the scientific data stack.
- Question from the audience from Christopher Tyler says,
my very limited understanding since you're using Pyodide
is that there's a limitation on the libraries you can use,
meaning can you import your own custom libraries?
Generally it's yes, right?
But not universally, isn't it?
- Right, that's a great question.
So you can, let's talk first about the standard libraries
and the third party libraries that you have,
PyPI, et cetera.
So PyAOdyte ships with the sender library
plus a set of packages that they ported.
Most of these, they use C extensions and things like that.
So they need to be compiled.
And so the PyOdyte team took that work and took care of it.
They're included in the distribution.
There is a way for you to also build packages
that depend on C extensions.
they have a nice guide in their website that you can follow
and they will help with that.
In general, you should expect pure Python packages to work
if you pip install them, right?
The caveat there is, do they have other dependencies
that depend on C extensions
and that will cascade in what work?
Or do they rely on some of the things
that I mentioned before, like multi-processing and sockets
and stuff?
So in that case, the package may install,
but it will raise an error because multi-processing is not
supported or other--
>>What about simple stuff like async and await?
>>Great question.
That is--
>>It's not-- from a like--
what it expects of the operating system is pretty low,
but it's also pretty advanced.
- Right, that is more of,
I think it's less of the packaging problem
and more of a philosophical problem
in terms of how you compare Python to JavaScript,
for instance, right?
JavaScript, even if it's synchronous as a language,
it has built the idioms over time
to always try to be asynchronous.
because for obvious reasons,
you don't want to block your browser
or if you're doing something in your page
and you block your Chrome on your phone.
- And that way it seems like it should be a fantastic match
for async and await.
- Yes.
- The way to know, oh yeah.
- Yes, it is a fantastic match
and almost everything that you do that would be blocking
in JavaScript, you would async await.
In Python, we are used to do everything blocking.
And then when we want to do explicitly,
we just, we use async I/O or something different.
So I think on that side of things,
it's more of a how you develop your Python code
rather than the...
- You might have to have a mental model
that matches closer to like what JavaScript
traditionally has.
- Yes, yeah.
But you know, we can use async await
anywhere in your code in PyDive, in PyScript.
- Oh, sweet.
Okay, I should have started on this list here
40 minutes ago.
But next question from Roller is,
how would I pip install something in the PyScript?
Which is, you know, a follow-up from what Chris asked
in this like Python ecosystem integration.
Clearly, pip install a thing is like,
gotta be at least 30% why Python is so popular.
- Right.
Yeah, not commenting on the packaging for Python
or JavaScript.
And we all know that most people don't have problems with them.
They all have idiosyncrasies, let's say.
They all got their weirdnesses.
Right.
So Pyodyne itself allows you to use
MicroPip, which is-- we will pip install your dependencies.
So like an NPM-like thing, where it creates--
Instead of a node module, it creates something else.
- Yeah, instead of a node, it's like NPM,
or it's more like pip really for Python.
And we'll go, and if it's a package provided
by Pyodite itself, we will load that package for you.
If it's a package that is not available there,
it will check on IPI.
And you can also specify the location of the package itself.
So if you have your own repository,
but you have your URL to that points to a wheel file
or a zip file, it will install from there.
- Yeah, and that wheel can be remote,
just like you might have a CDN pointed thing
for JavaScript, like here's my wheel, okay.
If it's pure Python, right?
If it's C, then all bets are off.
- If it's C, you should have done your duty
and ported it to WebAssembly.
But the PyScript provides a layer on top of that,
where you can specify a tag called PyEnv
and it accepts YAML format
and you can specify your dependencies there
and both for packages and also has an extra key called paths
where you can actually provide the link to your modules.
- Effectively like the working directory of your Python.
So when you type import file name or directory slash file
it kind of mirrors that to the browser, right?
- Yes, exactly that.
If you know how Python works,
it's basically adding those files to your sys path.
So it finds them.
- Yeah, cool, cool.
All right, another one that's really important here
is Python with JavaScript.
So it's not like you're locked
into this PyScript little box, right?
What I think, this is another thing
that makes me very optimistic for the future
is you can communicate back to other JavaScript,
to JavaScript events, button clicks to the DOM.
So if, here's another dream that I have,
is something like a Vue.js wrapper type of thing
that I could do in Python,
and then do sort of model binding or attribute binding
to the DOM and have that sort of stuff happening.
And this is really important to make it a first class citizen
that can work with all the stuff on the page,
not like a canvas it was given or something.
- Yeah, yeah.
So before I go into this,
I wanna plus one on what you said
around reactive sort of programming and components
where they can be attributes
that auto notify others elements.
So that is definitely something
that we would love to explore more
and there's a lot of interest.
And on the Python with JavaScript side of things,
after the keynote at PyCon, I saw a lot of videos coming up
with like, oh, is JavaScript that now that Python
can run on the browser and things like this?
I think that narrative kind of looks at one side
versus the other, where what we really wanna encourage
is actually the two together, right?
There is a ton of really great libraries in JavaScript.
And there is a level of maturity in JavaScript
on things on the browser or UI creation,
or drawing on canvas or on the page
that we were nowhere close to the 1% in Python.
And all of a sudden you can use those tools in Python
and vice versa.
all of a sudden JavaScript users could use NumPy or SciPy
and other things to power their applications, right?
So I think- - That's interesting.
I really thought about the benefit others,
like outside of Python people may be receiving, but yeah.
- Yeah. - Now Python becomes
a thing so they could leverage, yeah.
- Exactly, I think if we start looking at this that way,
then you can see how PyScript is a glue
for building richer applications,
depending like independently,
if you're a JavaScript developer or Python developer,
And we are starting with Python, it makes a lot of sense.
But if there is a Rust implementation on Lasm or R,
I'm sure that the Python scientific community
will love to use R tools in the page with Python stuff
and maybe JavaScript as well, right?
- Yeah.
- I think it's building together kind of movement
that we wanna push forward.
- Yeah, if I can look out and imagine a future,
I don't know that there's a chance
how much it would exist,
but a really great future of like,
well, we have WebAssembly.
What if we really made WebAssembly
more of a first-class citizen
from a browser maker perspective?
One things I think would be fantastic is
if instead of getting to the DOM through JavaScript
and through the events through JavaScript,
is if all of the browser makers said,
"Here's a WebAssembly native thing that you can use
"to bind to the DOM and to the events
"and basically control it."
You could have Rust in the browser,
Python in the browser, C# in the browser,
and they could all have this common API defined
and maybe even an adapter type thing,
like, well, in C# it's classes,
and in Python it's lambdas, I don't know, whatever, right?
Like some variation that's more native to your world.
But if there was some kind of interaction
that we could build on, that would be even better,
but we don't have that.
So this integration with JavaScript
and all of its modern features is fantastic.
You still would want that,
but it would be nice if there was a way,
just put Python aside.
Like if I'm doing WebAssembly stuff
that I could stay in WebAssembly,
stay native to interact more with the browser.
- Yeah, and honestly, the interaction
between the WebAssembly part of it and JavaScript,
it's very fast.
But I want to highlight one thing that you said.
A lot of the future and how can this improve
is on the browser folks.
- It's on the vendors.
Yeah, it's on their shoulders to do it.
- Yes, 'cause like the huge bottleneck
that we have right now is that you still,
like when you load your things,
you still need to compile them
and run them in WebAssembly.
So there's a, the loading time right now is very high
and we're working on optimizing things.
And there's a lot of work, great work from the CPython folks
and the Pylite folks to reduce the size of things
that you're shipping by default.
But ultimately, if you have a large scientific application
you still want to install NumPy and Bokeh
and other stuff like this, and you will have a loading time.
- There is a loading time.
And, you know, I think that might mean
it doesn't make sense for the homepage of Reddit
or like your marketing page that needs to load super fast
to have to be implemented in this.
But if you're writing something like Google Maps, Gmail,
or like I go to those sites and then they spend and spend
and spend for three seconds already, you know,
like the first time you hit that, it does that.
The second time it would just be cached, right?
All the stuff is off the WebAssembly stuff
It's just off disk and it,
if your expectation is this page might take two seconds
to load sometimes, you're good, I think, honestly.
- Yeah, yeah.
All that to say like, this is the current state, right?
I think there's a huge margin for improvement in the future
and a lot of really great people are looking at it.
- Yeah, okay.
I agree and I think the momentum is just building.
So let's look at some code and some examples
so we can make this concrete for people over audio,
which is tricky, but let's do it anyway.
So you've got the GitHub page,
which has a bunch of examples.
And so what I wanna do is kind of just pull up
some of the examples here and let me remind myself
what they are called.
Let's do this one first, actually.
I wanna look at anti-gravity.
So we all know the XKCD.
And if you go to the REPL in Python,
you type import anti-gravity, amazing stuff happens.
And so here we have that equivalent in PyScript,
but there's a couple of things
that are really interesting about this.
So let's pull this up.
It says based on this thing, and you give it a second,
and it says, the XKCD is, how are you flying?
There's someone up there flying, like Python.
I just imported anti-gravity, right?
It's great.
But this is a variation.
Do maybe describe what just happened on the screen here.
People can go to the demo and watch it, of course.
They just check out the repo.
This is a great, great example done by Philip Rudiger.
His core contributor to PyScript,
but also contributor to panel, HoloViews.
OK, he's done a lot of great stuff.
And what's happening here is we're loading the SVG first.
And then there's another Python function
that basically takes that the stickman and makes it float.
But basically-
- It literally animates and flies up into the sky.
Like it really takes off, not just it's up there, right?
- Yes, yes.
And for anyone wanting to check them out,
the examples are also available on PyScript.net/examples
and you can run them directly there.
- Interesting.
- Yeah, cool.
Okay, yeah, we'll link to that as well.
So I said this is interesting.
It's interesting for several reasons.
One, if I go and look at my task manager in Vivaldi,
this is doing like 30% CPU, constantly refreshing.
I don't know what the frame rate is,
but it seems certainly passable in terms of
there's cool animations going on,
on this rendering this canvas.
It looks good, right?
It doesn't seem like, oh, this just isn't gonna work.
It's like the person doesn't like glitch.
(laughs)
- Right, right. - You know what I mean?
- Yeah. - The other one is
it highlights many of the things
that I think are pretty interesting here.
Let me pull up the code for the example.
And this maybe will give us a chance
to talk through the programming model.
So first of all, the first thing that's interesting
is it has this pie E and V section.
and you have, people maybe have seen examples
and if you go to the home screen,
you can actually, the pyscript.net,
it says there's new tag done through web components
called py-script instead of just script
and you can just write Python code directly in the browser.
But you only wanna do that for so long
until you wanna read it across a couple pages or whatever.
So what's really cool here is the implementation of this
is actually a custom Python file on the server, right?
- Yeah, exactly.
We are, we been working on that for some time,
the design of this, 'cause as you said,
there's a tension between allowing people
to just drop things in the page
and then have your Python code there.
And it just works to also, you know,
suggesting better patterns to do this.
You definitely don't, from a quality point of view,
it's really hard to test anything that you just drop on the page.
A readability point of view.
>> A refactor it or anything.
>> Right. But at the same time,
we really want this to be something that people can play with and hack
with and then don't have too much to think about,
oh, I need a file, I need to name it Python
and all of that.
- If there was a NPM install step
and then there was a compile step and then a pack step,
like you would shave off like 75% of the people
who are just wanting to check it out.
- Right, so we allow this pattern,
but you could also say like the same code could be
the same thing in PyEnv and then in PyScript,
you could also have PyScript source equals
in a Python file.
So you can run that from files as well.
- Right, yeah, so just like with the regular script tagging,
say source, and it can do a thing on startup,
you know, like jQuery did its $document.ready hook
right at the top all the time.
Like you could do the equivalent of something like that.
Okay, this is cool, but this is only part of it.
Let me open up the other file, the antigravity.py.
And this is the one, this is the one
that made me really happy because when I look at this,
it's, you know, how is that animation happening, right?
what you do is you set a timer to do a callback,
you know, where you are in JavaScript,
and it goes click, click, click, click, click.
Let's see how often are you doing this?
Do you remember what the target frame rate was here?
I'm looking.
- I don't remember.
- Yeah, anyway, there's some sort of time
where you say run it this frequently.
And basically what you do is you go over here
and you say, this is Python,
you say document get element by ID.
All right, first of all, awesome.
With a ternary expression.
And then you go and add through the DOM parser,
you add the SVG in there.
That's amazing.
You do a replace child with some HTML stuff.
And then you go and you hook this set interval.
So set interval is the way to say,
set a callback on a timer in JavaScript.
and then you just call the Python function self.move.
Right, so there's a really cool interaction
between JavaScript that's happening at a high frequency
that shows do some stuff in Python,
go over to JavaScript, you know, go through the DOM
and then call back into Python
when things that are interesting happen.
Here is an interval, but it could be a button click
or a dropdown select or whatever, right?
- Right, right.
And we are also, we're doing some work right now
at providing a higher level interface
that would be more Pythonic to those JavaScript,
the usual things that you would always do in JavaScript,
like selecting an element by ID or class
or things like this.
- A CSS selector sort of model or something, yeah.
- Yeah, exactly.
So I think the goal is to provide the simplest
and more expressive or Pythonic interface that we could
to hide some of that complexity,
because at the end, a lot of Python users or new users
will have to end up learning about JavaScript itself.
- You're like, I didn't wanna learn JavaScript
and here I am learning JavaScript.
I think what you're learning though is not,
you're not learning JavaScript.
What you're learning is the DOM API,
the APIs that JavaScript often consumes.
- Right, correct. - You have to learn
that the DOM has a get element by tag name
rather than I have to say, I can't say var anymore,
var char, they have to say let or else it'll complain.
You know what I mean?
Like you're not learning the language nuances
but you are learning the APIs
that JavaScript people are very common.
- Yeah, and it's a great point.
Like another thing, for instance,
the set interval could be replaced with full Python
and just say like from async I/O import sleep,
you know, time sleep, and then while--
- Let's do a loop.
- There's do a loop and async await there.
- Oh, no kidding, okay.
Like a while true.
- Exactly.
- Await sleep, then move.
Okay, yeah, this is really, really neat.
I think this example is so simple, it's playful,
and it's not just, we put a graph on the page.
Not to say that that's not important,
but it's different than what we've seen before often.
- Yeah, honestly, really props to you, Philip.
Like, and I don't know what, 50 lines of code
or 40 lines of code.
- Yeah, 45 for the entire implementation
of a flying anti-gravity.
- Right, pretty neat, yeah.
- And in Python, those are not 45 lines of JavaScript.
- Right.
- Cool, okay, audience question.
Marcel says, "Would it accept loading data
"from a file for processing?"
like, you know, we're pulling the modules,
but like, what's the data story?
- That's a really, really great question.
I think the data story is yet to be told.
We're dedicating a lot of effort to that.
Right now you can load data using fetch basically,
and you can fetch data and then read just like normal files.
PyDite provides a PyFetch wrapper
around the JavaScript fetch,
but there is a lot that can be done
and we are working on it to have better support
and just, you know,
how does the story for larger files look like?
And--
- Can I do a Panda read CSV and give it a URL
or something like that?
- That's a great question.
I'm not sure. - I don't know.
- Yeah, I don't know.
- I have no idea, I'm really just wondering, yeah.
- Yeah, but yeah, that's one of the stories
that I think needs more development.
Right now you can pull files
and read them with that method,
but there's more work to be done there.
- Yeah, okay, cool.
Let's look at another demo here.
Let's see, give me, I'm running out of time, so good.
Okay, this one's interesting too.
This panel, I think it's panel stream is the one.
Number here.
- And this is one of those
that is gonna take some time to load
because under the hood, it's installing panel
and installing bouquet, I think,
and other visualization libraries that are heavier.
- Right, right, right.
So, oops, I'm gonna get too wide,
but maybe I'll zoom it out.
There we go.
Well, let's try it a second time, right?
So, what do you guess?
Seven or eight seconds maybe it took that first time,
but if I hit it again,
it says it downloaded 3.6 megs.
And it's probably-
- You should have cached most of the things
that you compiled.
But also if you set your browser to not cache,
it will not change anything.
- Yeah, well, I think the challenge is that I'm using
just Python-M HTTP servers.
I'm not really using a proper server for this.
So that's not helping.
I'm gonna let that one load up while we're,
I'm pulling up another one here that I wanna talk about.
- Yeah, is there one that you think we should highlight
in particular?
I mean, we've got the matplotlib one,
which is pretty interesting over here that shows this.
- Right.
The D3 one is pretty interesting as well
in the sense that for now-
- The D3 one you said?
- Yeah. - Right.
- Okay.
- D3 has been a library that Python folks
have always wanting to be using.
- That one was super fast.
That one was two or three seconds.
- Right.
- Less than two seconds, yeah.
- Yeah, and that should have basically
the same loading time as JavaScript
because we're not really importing much
or installing new libraries.
- And once I hit your example server,
then it's cached it, right?
- Yeah, yeah, the second time you do, yes.
So another one, the WebGL,
Right, right, right down.
There you go.
Yeah, this also should load pretty fast
and shows wrapping WebGL directly.
- So this, if people obviously listening don't know,
this one shows an example of dodecahedrons or something,
a bunch sort of rotating and spinning around.
It's a little bit like a 3D asteroid game
with no spaceships.
(laughing)
Something like that, I guess, maybe is a way to think of it.
And if I go to, oh, and it also,
as I move my mouse, it reacts to it.
I hadn't moved my mouse.
So that's pretty cool.
I opened up my little task manager thing.
Let's show me that.
I don't know if it shares, but it says,
basically, it shows you how hard it's working,
and it's 20% CPU for this 3D rendering interaction thing.
If you probably try to do this in pure Python
and like Pygame, it might be more, you know?
- Yeah, I'm not sure about like the performance
and you know, like resources,
but it should be pretty much,
once you're using JavaScript things,
they should be pretty much the same as JavaScript,
pure JavaScript.
Much like Python often just sort of orchestrates C code
once you've loaded something into the C layer
and you're kind of just instructing it
through simple commands,
it's probably not very different here.
- Exactly, yes.
- All right. - Yeah.
- Cool, all right, so I strongly encourage people
to go check out the demo code.
It's just under the example folders in the GitHub repo,
which we'll link to.
Fabio, we're running low on time here.
There's so much more I wanna talk to you about.
- You drive.
- Yeah, yeah, let me just see a couple of example
or a couple of areas I wanna talk about here.
I just wanna quickly touch on security.
I think the security story is pretty simple,
but I do have one question.
So to some degree, people might go,
"Oh my gosh, it's compiled C in Java script in the browser.
What madness are people gonna unleash on the world?
This is like ActiveX
or some dreaded calm thing all over again."
And really WebAssembly also has the same sandbox security
as JavaScript, right?
- Right, yes.
So yeah, actually a lot of the issues
that we've been getting around security
boils down to that people like not being used
to seeing the browser as a VM.
So, oh, if I type OS, like list there and stuff like this,
and I have access to the file system.
Well, you're having access to an ephemera's file system
in the browser and not your local file system.
That is a very important aspect.
- One thing that would make me super happy
is if we had some beautiful Python API
to the local data side of things.
So inside the browser in JavaScript,
you get access to, what's it called?
local DB and there's like a, there's different levels.
There's like a file sort of file per site,
file storage thing that's tied to your user.
And then there's like an embedded SQL light like thing.
I mean, if you had something like SQL model
or some other proper ORM that would let you connect
to query that, I suspect that it could probably
be built pretty easily with a interoperability layer
to figure out just how to translate that
to JavaScript, but do you is it?
What do you think you know more now?
Now that there are lots of possibilities and scenarios of,
you know, using what the browser provides you like local storage
or small instances of databases and stuff like that.
The there so that is almost shipped and default with all the
browsers.
There are interesting projects.
well, at least one that I've seen, like Google Project,
where from Google, from the Chrome team,
that is experimenting with scenarios
where you can actually allow apps to access your file
system or other resources, native resources.
It goes through a process of approval.
But you can mount directories and use them
from your browser as a local mount.
And those are also very interesting scenarios
that could open up a lot of different ways
of interacting with PyScript.
Maybe it would mean you can actually
develop your PyScript app directly from your local machine
and then serve it on the browser real time,
or your app could write files or do your models
or computation on the browser and then write results
to your local files.
There's a lot that can be explored.
- Yeah, very exciting.
Okay, my security question though,
outside of the, it's all the sandbox,
let's not stress about it.
We already have had WebAssembly for a long time.
Is this pyenv section here where you can say,
go find this file, right?
And I'm thinking of, you know, my website,
which has a static files, static files folder section
where I might put this,
'cause that needs to be served up
as effectively a static file to the front end.
But I've also got my app.py, my various views,
and settings.json.
And if I put too many dot dot slashes there,
am I going to be able to get to other stuff, or is it OK?
What do you mean?
Suppose this folder, this file lives in static/antigravity.html.
But the rest of my app is one directory up from--
- Oh yeah. - From that,
like, could I say my path to my module is
dot dot slash app dot pi and then maybe read like some-
- Right. - Source code
with like a token that I've, you know,
put in there that I shouldn't have put in there,
but then now it's public.
- Yeah, relative paths should work just fine.
There's also, I think with PyScript,
the distinction between development time
and deployment time or bundling time
is a little more highlighted.
As a developer, I'd love to have those relative paths
and explore and have full access to a lot of libraries.
But when I deploy, I bundle my application,
one of the things that we are very interested in developing
more is we should bundle that as one thing.
And the path should be absolute so there is no issues
with what you're saying.
We could bundle the interpreter and your dependencies
so that we can optimize size,
remove dependencies that you're not using.
So, you know, the loading time is smaller,
basically three shake,
like a lot of JavaScript libraries do.
So yeah, there are definitely patterns to explore
and that's an area to.
- Yeah, okay.
I mean, yeah, you definitely don't wanna go dot dot slash
app because somebody could then inject that.
But it's interesting.
I'll be cool to see what you all do there.
But definitely, that's the only thing that's come to mind.
I wonder what's going to happen there.
Let's see.
[INTERPOSING VOICES]
App, it's basically on you to define what you're actually
serving as a static file server, right?
- I see, so if it's not accessible as a static file already
this will just 404?
- Yeah.
- Okay, then Flask Pyramid friends have it covered.
Yeah. - Yeah, exactly.
- Okay, now I see where it's,
so it's just, you're like, it's not our responsibility,
but you shouldn't be allowing, you know,
slash static slash dot dot slash app.py
being served anyway, right?
- Right. - Okay, cool.
The other thing is, one of the things
that Steve Dower talked about recently
is that they started enable the real, the full CPython
to being built within scripting WebAssembly targets.
Is this of interest to you all?
Does this-- - Very much.
- Is this super speed PyIoDyed's version in some way?
is what Pyodide's version actually is?
- So the Pyodide team and the CPython on Wasm team
are collaborating on making the two,
making Pyodide basically use that
as a baseline Python interpreter.
That actually would be very helpful
to the Pyodide team as well.
They would have way less things to maintain.
they can just delegate to the improvements
and optimizations that the CPython core team
they're doing and can focus on the additional features
of Pyodide.
So that actually is, we had a--
- Right, they're building in the WebAssembly version
'cause it didn't exist.
That's probably not what they wanted to do, right?
- Exactly, yes, yes.
- Yeah, okay.
Their real innovation, I think,
in addition to just getting the WebAssembly thing
working is like, how do you bring these important C mixed C
libraries in like NumPy and such to the browser that otherwise
wouldn't just drop in as you know, Python stuff running on
top of the interpreter. Right, that that seems to be the most
important thing that they're, they brought to the table.
Right,
exactly. Not discounting that, like there was not a WebAssembly
and they made that also happen, right?
Like that's also super important, but I guess
what makes them more distinct of all the other attempts
is that they're really focused on making sure
the data science libraries work in this situation.
- Yes, I think that is one of the main things
that made PyDive successful because it, you know,
a lot of times you would support just the language itself
And then when you want to support more complex use cases,
like C dependencies, you are too far
in the process of your implementation.
And then you're like, oh, now we have to rewrite half
of the code to refactor, to account for, you know,
a lot of the complexities.
- We got to backfill it so we have support
for all these things.
How are we going to write our own NumPy now or something?
- Right, yeah.
And C extensions are always the place
where most projects have a hard time, right?
Like historically, the different implementations of Python
and .NET or PyPI or others.
CX Nations has always been like the trouble kid.
- It definitely is.
It's also tricky for the GIL.
It's also tricky for thinking about reference counting
versus other collection cleanup type.
Yeah, it's an important boundary to be aware of,
but it's also really been a lot.
All right, final thing.
Let's just wrap this up with what's next,
where you're going.
- So I think I hinted at a lot of those,
I think the main thing for us in the immediate future
is really to work with the community
and build up more of that side of things.
And then also work on documentation
to put out also the vision and what's next.
There are a bunch of things that are really interesting
that we will be looking at, right?
Like a reactive layer or components
to interact with each other and notify each other.
The story around data and what,
how does working with data look like in PyScript?
a lot of development around the possibilities
of using PyScript in a peer-to-peer
or web three sort of scenario, right?
What can we make to support applications
talking to each other directly,
or using a mode where you work offline and online
and you can make the experience better.
- Right, like a little bit of a progressive web app
- Exactly. - Tiny thing, yeah.
I'd be super excited to see that come along.
- Yeah, honestly, one of the difficulties with this project
is that it breaks so many patterns that we are used to,
both like, oh, I'm running my thing on my machine
or on a server, or I'm doing a web.
It means, okay, it means that I always have a server
and a client side, and they have the network in between.
Now we're shifting the paradigms and a lot of things are new,
so we can explore.
The other thing that we're looking at,
well, better support for the optimization, loading times,
all of those things.
How can you hold state of your application?
So basically, as it's running, et cetera,
or if you just have a notebook-like workflow,
how can you save the state of your PyScript app
and share with others?
And they can start from the same point you were.
- Yeah, those are all great things to be working towards.
Is this tying in any way to JupyterLite?
I mean, it's got similar goals.
I'm not sure if it has any similar foundations or anything.
Maybe I'm very familiar with the Jupyter folks.
I work together with many of the core developers
and historically, JupyterLite is a great project
that basically implements the Jupyter notebooks
using Pyodide as a runtime or a shell.
- Yeah, so it's not that far out
of being maybe in a similar space, but yeah.
- Right, it's similar in that sense
that it ties right into the Jupyter experience.
So it has it's locked into the notebook flow
and authoring notebooks and stuff like that,
where PyScript is more, has a larger scope
and it's really to author applications
and a little different.
- Okay, very interesting.
All right, well, congratulations.
This seems like a pretty promising project
and I know there's a lot of interest in it.
Let me close it out with a comment from the audience.
Andre Mueller said, "I tried Jinja.
"The Jinja wheel just straight up with PyScript
"and it works straight away, like no changes."
So that's kind of meta actually.
Jinja within PyScript within HTML.
Love it.
- Yeah.
- Awesome.
All right, well, let me ask you the final two questions
before we get out of here.
If you're gonna write some Python code,
what editor are you doing using these days?
- It's usually a mix between VS Code or PyCharm.
- All right, cool.
Yeah, both good.
And notable PyPI package or some other kind of,
maybe it doesn't come quite off PyPI,
maybe it comes off a CDN these days.
Hi, script, obviously.
What do you want to give a shout out to?
- Well, I gave a lot of shout outs to Piodyde.
Once again, it's a great project.
I think I use notebooks
and the whole Jupyter ecosystem a lot as well.
The whole scientific stack
and a lot of the things that are around,
you know, the many interesting projects like,
you know, NumPy, Pandas, Dask, Bokeh, Numba.
A lot of that ecosystem is really
in my day-to-day kind of workflow.
- Yeah, fantastic.
- Yeah.
- Cool, cool.
All right, well, once again, congratulations
on all the interest and excitement.
It's really taken off the last couple of weeks.
So thanks for coming on the show and talking about it.
Thank you so much for the opportunity.
I had a great time chatting about it.
- And final call action, people want to get started.
What do they do?
- Great, great question.
Go to PyScript.net, check the website.
We have links to the repo and to the--
- Very interesting install steps here.
And it says, ah, no, you don't install it.
- Yes, we hope people would click
and actually see the Easter egg, which was good.
And yeah, we really want to be an inclusive community.
So if you have questions or you want to report bugs,
or just ask where you can help, just
reach out either on Twitter or reach out
on the repo, open bugs there.
In the next few weeks, you should
expect more documentation on community engagement,
having a discussions group
where people can actually ask questions more easily.
We're evaluating starting bi-weekly
or something like that community call
where we just are there for the community
to ask questions live on a Zoom or something like this.
So be patient.
We're getting there to support our community
and allow people to actually contribute back.
- Cool, well, very exciting.
Thanks for doing it.
Thanks for being here.
Thank you.
- Thank you.
- You bet, bye.