Let's say you want to create a web app and you know Python really well. Your first thought might
be Flask or Django or even FastAPI. All good choices, but there's a lot to get a full web
app into production. The framework we'll talk about today, Reflex, allows you to write just
Python code and it turns it into a full web app running FastAPI, Next.js, React, and more,
plus it handles the deployment for you. It's a cool idea. Let's talk to Elvis Kahoro and
Nikhil Rao from Reflex.dev. This is Talk Python to Me, episode 483, recorded October 24th, 2024.
Are you ready for your host, please? You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython,
both accounts over at fosstodon.org, and keep up with the show and listen to over nine years of
episodes at talkpython.fm. If you want to be part of our live episodes, you can find the live streams
over on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified
about upcoming shows. This episode is sponsored by Posit Connect from the makers of Shiny. Publish,
share, and deploy all of your data projects that you're creating using Python. Streamlit, Dash,
Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs. Posit Connect supports all of
them. Try Posit Connect for free by going to talkpython.fm/Posit, P-O-S-I-T.
And this episode is brought to you by Bluehost. Do you need a website fast? Get Bluehost. Their AI
builds your WordPress site in minutes, and their built-in tools optimize your growth. Don't wait.
Visit talkpython.fm/bluehost to get started. Nikhil, Elvis, welcome to Talk Python.
Hey, it's great to be here.
Yeah, it's awesome to have you here. You're building some cool products, and Nikhil, you're back on the
show. We spoke to you back in Salt Lake City at Startup Row, and now your startup is more started,
and I'm really excited to hear about it, and that's what we're mostly going to focus on this episode,
talking about building Python web apps. You know, normally when you say something like that,
a person who is not a web developer would go, oh, you're building apps with Python, web apps with
Python. That's cool. A web developer would be like, okay, what is that? That's Python, CSS,
HTML, JavaScript, React, et cetera, SQL. There's a lot going on normally, but we can winnow it down
a little bit and have a little more focus. When we say Python web apps, it's a little more like that,
right?
Yeah, definitely. And I think a lot of people, when they hear Python web apps, they think of,
you know, Django, Flask. Like these are, they call themselves Python web frameworks,
and they're really great frameworks. But like you mentioned, there's a lot of things that go into
web development. There's front-end, back-end, hosting, et cetera. And when you think of frameworks
like Django, Flask, they do a great job of handling the back-end, the database, the kind of connection
layer. But like you mentioned, when you have to write the front-end, you end up having to kind of go back
to HTML, React, JavaScript, and the traditional tools. And generally in web development, you'll set
up your back-end as kind of one service, your front-end as one service, hook them up through some sort of
API and develop through that. And it works great, but one part, like you mentioned, is there's a lack of
unification. So when it comes to building an app, you have to piece together a front-end, a back-end,
then figure out how to host it. So a really big part of why we started Reflex was to kind of simplify
all these different layers of web development into one batteries-included framework. And one of like
the biggest challenges along with the batteries included is having everything built in, but also
keeping it flexible enough, right? Because people want to do all sorts of stuff with their web apps.
So that's really one of the main challenges that we faced going through all this was how
can we make a framework that, you know, people can just get started, but it doesn't box them
in. They can still make all the stuff they were going to make, you know, using their JavaScript
apps.
Right. That is the big challenge. And we're going to dive into that. You guys got some awesome
stuff. But before we do, maybe, you know, it's been two years or so since you've been on
the show. Give a quick introduction, just who you are.
Yeah, definitely. So yeah, I'm Nikhil. I'm co-founder here at Reflex. Last time we chatted was about
a year and a half ago. At that time, our company name was Pinecone with a Y. That was at Startup
Row. And our mission when we started, and even now, is to just simplify the whole process of
web development from front-end, back-end, hosting, all these parts, and make a framework that simplifies
all these parts so a newcomer can easily share their ideas without getting all caught up in
learning new tools, learning new languages, boilerplate, and all this.
So that's been our goal from the start. And maybe just some background on why we even came
to this idea. So prior to working on this, I was working at a self-driving car startup, and then I
was working at Apple. And at both these roles, I was working on AI teams with really talented engineers,
but we were all Python engineers. So we could do, you know, anything with database, backend,
all this stuff. But when it came to something as simple as make a UI for this app, make a dashboard
to showcase this data, you know, make a little form to submit it. You know, there's sometimes
these senior engineers would be like, okay, that's not my domain. I can't do that in Python. You know,
someone else go handle this.
I have a PhD in machine learning, but I can't build a website. So now what?
Exactly. And that's kind of where we are. And a big reason of that is if you think about,
you know, different languages and their use cases, Python is used in so many, it's one of the most
broad languages. If you think about all the areas it's used, backend databases, AI, ML, all these areas,
but there's really one place that it's not used traditionally. And that, and that's kind of
front end development. And for there, like JavaScript is king. And if you take the inverse of that and
think about JavaScript, it's one of the most popular languages in the world, right? Like it's,
it's one, two or three up there. And if you think about the use case for it, it's all web,
it's mostly all around web applications. So what we see, what we kind of notice is, you know,
people love Python. They want to do all their work in Python when it's accessible and people love web
development and they use JavaScript because they love web development, but there's not much usage
of JavaScript outside that domain. So really our big focus was, well, can we fill in this gap in the
Python ecosystem where people are doing everything in Python? And then suddenly this one domain of
websites, front ends, that, that can't be handled and they need to, you know, use a different tool,
use a different language, outsource that. And that was a big thing we wanted to solve. The same people
with the ideas, building the backend, building the AI, building the, whatever it is, should be the,
also the people presenting it, building the UI layer and kind of sharing their ideas.
Yeah, absolutely. I, many people I talked to would rather build everything in Python, but they,
they end up piecing it together as they have to. Elvis, good to see you.
Yeah, same.
Yeah. Quick introduction about you.
Yeah. So I guess we met at PyBay.
Yeah, we did.
Yeah. So that was very, very fun. And yeah, so I'm Elvis, he and his, I'm working at Reflex as a
developer advocate. And prior to this, I was working at Warp. So I was there like three years
doing like developer experience, developer relations.
Yeah. Shout out to Warp.dev, man. That is an awesome terminal. I really enjoy that. I use that
pretty much universally now. And yeah, I'm, thank you for that recommendation. It's still going strong.
Very good team. Really good product. Yeah.
Yeah. Awesome. So now you're working at Reflex, formerly Pinecone, same company, new name.
Yeah. Awesome. Yeah. Even doing more, you know, this Warp is more Rust, right? So now you're more
in the Python side of things. Yeah.
Yeah. But even there, I was like, everything that I was building was like internal tooling to like
optimize developer experience. And so everything was in Python. And so that's how I actually came
across Reflex. And then I was like, oh, this is a dream, like being able to like work in open source
and build Python apps and like serve the community. And so when I saw that job posting, I was like,
whoa, I would love to join. And they were in SF. So that was great. So I could just walk over to the
office and things. So yeah, that is kind of the magic of San Francisco, right? Like it's not you and
potentially a whole family move thousands of miles away. It's just you take a different bus or a
different BART train or something. Yeah. Very cool. All right. Well, Nigel, let's talk really quickly
just about startup lane. You know, like I was just looking back on this as I knew you were coming on the
show and I was like, well, you know, what happened to all those companies? And I don't have a great,
totally good sense. I know that some of these have pivoted. You know, we had Ponder, we have
Generally Intelligent, we had Wereobots, Neptyne, Nyxtla, Pretty Base, and Pinecone, which is now Reflex.
And this was, well, what is this startup row really quick while we're on this topic?
Yeah. So this was back when we first started. I think our company was maybe one or two months old. And
we were, we had just got into, we were part of the Y Combinator winner 23 batch.
So while going through that, we launched on, I think, Hacker News early January. And that's when
we first started, you know, publicizing our open source, getting users on it. And we got, we got
quite good traction when we started. And part of one of the events that was happening was PyCon,
which was, I believe in April of that year. And it was a great opportunity for us as a Python,
you know, a Python company, like to kind of meet our audience. And yeah, so part of that was the
startup row where there was a lot of, you know, I think seed or like very early stage startups
coming to present. So at that time, we were maybe only two months old. So very early, but it was still
a great, really great experience. You know, I think it was probably the first event, you know, that we've
done as a company. So that is a really good experience to meet different Python developers and to meet all
like the other developers that, you know, the companies you mentioned, like, even ones that
were not, that aren't listed here, there's a bunch of awesome Python people that came there. So
yeah, it's not just the companies that are in startup row. That's its own special thing. But the
whole expo floor hall is a pretty awesome place to just walk and mingle and learn what people are up to.
Yeah, definitely.
Yeah, yeah, that's cool. I know that Ponder, Ponder got acquired. So congrats to them.
Oh, nice.
I got acquired by Snowflake, which is, you know, that makes a lot of sense. Yeah.
Yeah, I know, generally intelligent, their founders are some of our friends,
they're an investor in our company, they rebranded now to imbue. So I think they're doing well as well.
Yeah, I think whoever put together that, that group, whoever selected the companies that go there,
did pretty good. Because, you know, startups don't have a typically a huge likelihood of succeeding.
But I think most of these are still around. So that's awesome.
Yep.
Yeah, cool. All right. Well, let's talk. We've introduced it a little bit. But reflex, let me just read,
I'll read the little, the H1, H2 for you. And then we'll go from there as that front end,
back end, pure Python, and then the open source framework to build and deploy web apps,
no JavaScript required. There's a lot to unpack there. So tell people what reflexes,
and then we'll dig into the use cases and some of the open source stuff and so on.
So I think we kind of talked about earlier, reflexes of Python framework to build web apps in Python. And it's an open source framework. So you don't have to sign up for a SaaS or do anything. You just do pip install reflex kind of like what's shown at the bottom. And you can start using it like any other Python library. And like I mentioned, the key distinction that we're trying to do is kind of unify the whole web stack. So all the parts that normally go into web development, building a front end, building a back end, connecting them, maybe including a database, and then deploying it.
Usually these involve using several different tools, technologies, even often multiple languages. And the overhead for that could be really high. So if you think about before, like a full fledged web app, usually you're not going to do that unless you have, you know, you have like a mission to do like you have something you're trying to make, you have it kind of specked out and you're going to kind of invest that effort into it. It's very hard, or most people aren't going to, you know, prototype a web app or kind of build out like that, because the overhead needed is way too high to kind of mess around.
So what generally happens, especially for Python developers is they'll use Python scripts, they'll use Jupyter notebooks. And in the Python community, also, there's other pretty good frameworks, things like Streamlit, Gradio, which are also in the Python environment.
And I think try to target a very similar problem that we're doing where, you know, people have their data, people know Python, and they want to showcase it. So these are kind of the existing tools that were there before we started. And I think they all have their place to get started with, but they're very limiting and what you can build with them, right? Like, it's good for the most basic prototype, you can have a script, you can have a Jupyter notebook.
But this is not something necessarily you'd want to share within your team to build out to a larger app. Like usually, once it becomes a bit more complex, you hand it off to another team, or if you're brave, you go learn JavaScript or something. But usually there's a point where it's like, all right, I've done my job, like someone else, like go make this production ready. And a big part of what we're trying to do different at Reflex is compared to other Python, and I'd even say other like non JavaScript frameworks,
is to keep everything in, you know, Python in one language, but without having any of these trade offs that usually come with a low code or no code platform. So usually low code and no code, they sac they exchange things like performance features, things like that for usability, customization, customization. So you can build a certain subset of apps. But you need to kind of, you know, keep your aspirations confined to what that framework is going to give you like you want some random component, you want a mapping component, you have to hope that framework has it.
You want to integrate with a certain database, you have to, you know, hope that they're going to give you that integration. So one of the very nice things about Python is for especially the back end integrations, right?
Actually, before before that, let me just back up one second. So compared to a lot of these low code, our goal was to have the same framework, you use, you can easily build a prototype your app, you know, in a few hours, build a quick prototype of your app.
And you can use that same framework to then grow your app all the way to a production grade app. So if you're like, look at our main website, reflex.dev, this entire website was built in reflex. So you can kind of see that badge at the bottom.
I think this is kind of distinguishing thing from others, like, usually to build a website like this, you would need to use JavaScript, but there's, this was entirely built in Python and reflex. And it just goes to show like the kind of, you know, along what we're chatting about, of, you can build, you know, a basic chat app, a little prototype app, as kind of is shown in the demo section right below on the landing page, where we have a bunch of, you know, different use cases.
So you can build that prototype, but you can also extend that all the way to a production app that's, you know, serving either internal users, or even in, in our case, for some startups that are serving external public users using reflex.
Yeah, a lot of times when I talk to people about these kinds of apps, often, it's, we've got an internal app, and there's 20 people using it. And it doesn't really matter if it takes a little while for the app to load up. And, you know, we're not worried about SEO or any of those things, right? But to make your, your product a landing page, and that's a pretty big deal.
Yeah. And I'm not saying that's the typical or intended use case.
Sure, of course.
There's other things if you just want a static landing page, but it was more to show the extent to which it could be used. But like you mentioned, a lot of our there's kind of like two domains of people that want to use us. The main audience is really developers, engineers that are not web devs are not JavaScript devs. So obviously, that includes, you know, hardcore Python people who are, you know, senior Python developers. But a lot there, it's also just like anyone who knows a bit of coding, because Python tends to be, you know, people have taken one CS class, it tends to be a Python class, they've learned a bit of Python.
So we actually see use cases outside of even software engineering. So people in finance, manufacturing, biology, where they, you know, before had an Excel spreadsheet, but they knew a little Python, and they're now able to develop, you know, these internal apps for their companies.
So that's kind of the developer profile we're looking at. And in terms of the companies and use cases, it's a lot of, you know, small teams that they want to do more with the team they have, like they like for on one hand, it's kind of startups, you have a one two person startup, and you need to get your, you know, app demoed, you're building some AI thing, and you want to get a demo, you don't want to go hire a contractor or front end developer to build that you want to iterate quickly, and kind of work through that, especially during that iteration phase, right?
Like when you want to iterate, you don't even know fully what you want to build. So it's really empowering to, or what we're trying to do is empower people by giving them a tool where they can iterate on their ideas, and not have to depend on someone else.
This portion of Talk Python to me is brought to you by Posit, the makers of Shiny, formerly RStudio, and especially Shiny for Python. Let me ask you a question. Are you building awesome things? Of course you are. You're a developer or data scientist. That's what we do. And you should check out Posit Connect.
Posit Connect is a way for you to publish, share and deploy all the data products that you're building using Python. People ask me the same question all the time. Michael, I have some cool data science project or notebook that I built. How do I share it with my users, stakeholders, teammates? Do I need to learn FastAPI or Flask or maybe Vue or React.js? Hold on now. Those are cool technologies, and I'm sure you'd benefit from them. But maybe stay focused on the data project.
Let Posit Connect handle that side of things. With Posit Connect, you can rapidly and securely deploy the things you build in Python. Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Ports, Dashboards, and APIs. Posit Connect supports all of them. And Posit Connect comes with all the bells and whistles to satisfy IT and other enterprise requirements. Make deployment the easiest step in your workflow with Posit Connect.
For a limited time, you can try Posit Connect for free for three months by going to talkpython.fm/posit. That's talkpython.fm/P-O-S-I-T. The link is in your podcast player show notes. Thank you to the team at Posit for supporting Talk Python.
Yeah, I think one of the problems with the low-code, no-code stuff for people in our orbit is they know code. They're good developers. They just might not be front-end developers or designers or whatever. So I think it's probably a little frustrating to work with really low-code, no-code type of stuff.
Because you're like, ah, if I could just program it, just a little bit of code would totally make this work. But it's in JavaScript or it's in something else. Like, Elvis, when you're talking to people about this, you know, like, how do you present this versus something like Retool or Gradio or something like that?
I was using Retool at the last company. And one of my frustrations was the fact that I didn't have control.
I think they do make pretty cool stuff, but it's different, right?
Yeah, it is different. I think Retool is very powerful. They have a lot of plug and play.
I think for someone who's, if you're coming from a developer background, I think you're so used to having full control that, like, giving some of that control away can be a difficult adjustment.
And I think one of the nice things about Reflex is that all of these UI components get transpiled into React, right?
And so one of the key value props is that you're bringing an entire ecosystem closer to back-end people.
And so, like, there's a couple of companies that will have someone doing front-end and making components just for their internal tools team.
And it's like, you can just wrap those in Reflex. And now all of your components still adhere to, like, your style guide or to your theme.
And so you're not really, like, limiting people in terms of, like, the components that they have available to them because it is React under the hood.
Oh, that's pretty interesting. Yeah.
Yeah. So it's, like, very elegant because it turns into FastAPI and React.
So it's like, you're not really limited when it comes to, like, producing apps that can get bigger or, like, scale or have, like, routes and things.
It's basically some developer tooling on top of React.
And then, so what you end up programming is probably mostly generates React.
And then it's also FastAPI on the back-end. That's really neat.
Well, basically, going back to, as we were developing this, the most important thing we kept in mind was, okay,
we want to make it really easy. You know, a newcomer should be able to build this.
But not have, pretty much have ways to do anything, right?
Like, never make people hit that graduation point where they're like, okay, I've hit the limits of Reflex.
Let's go use a serious framework like React.
So it's very intentional that people never hit that goal.
And, like, one way that we achieve that is you code everything in Python, but the end output that it compiles to is a production-grade web app.
So for the front-end, though you're coding it in Python, the front-end will compile out to a Next.js app.
The back-end will compile out to a FastAPI back-end that hookup together.
So it's pretty much the same architecture you would write as if you were writing it by hand.
So there's no, there's, like, we're not taking a shortcut as in, like, if you were to write it by hand, it would actually compile.
You would probably write a Next.js front-end, FastAPI back-end, and connect it.
And we're kind of giving a layer on top of that.
And by developing on top of React, it goes back to this.
We don't want to reinvent the wheel.
WebDev is a really mature ecosystem.
We're not going to be able to remake React and all the components out there.
So when we started, our big approach was let's wrap React.
And not only, like, do our components wrap React, but we make it very easy for developers to wrap their own components.
So kind of like what Elvis said, we have companies, like, Fortune 100 companies, that internally they have their own React, you know, component library that they must use for every app that they're building.
And they were able to wrap those in Reflex, and now they can use, you know, their private custom React components.
One person wrapped it once, and now any Python developer is able to access it and develop with it.
So our really big point is, like, you're not going to be locked in.
We have, you know, 60-plus components built in.
But anything that's possible in React and JavaScript, you can easily bring that to Reflex without waiting for us.
Okay, so there's a bit of an escape hatch to just go down straight to React.
The nice part is you don't have to write the React directly.
I mean, you can write it once.
But after that, we have a third-party component ecosystem.
So I can show you on our website later as well, but many people have published their own third-party components.
Oh, interesting.
For example, like, we don't have a map component built in.
So last week, someone published a Reflex map component.
So if you want to, like, hook up a map into your thing, it's now possible.
And there's a lot of these...
AG Grid.
Yeah, AG Grid, you know, audio recording, and all these, like, niche cases, right, where we're not going to be able to support it all.
But the nice part about having an open source and open source community is community can add to the project, shared with others, and everyone can benefit from it.
Another one of the challenges of low-code, no-code type stuff has to do with the deployment side of things.
I maybe buy a SaaS subscription at some low-code place.
But, you know, in practice, the performance is just not good enough to, if you put it on the internet, it'll just not take it or something like that, right?
If it's basically JavaScript over FastAPI, like, that's a very well-known and super scalable setup, right?
Part of that is, in the unification, it wasn't only front-end, back-end, it was also deployment, which a lot of people, they build their app, and deployment takes as long, if not longer, than the actual building, especially...
And the DevOps all along the way, yeah.
Yeah, especially if you've never done this, right?
Like, to go learn about, you know, how to domain names and what is, like...
SSL.
What is S3, SSL?
Like, all these things take a long time.
And that, so, and going back to the thing of balancing that thing of batteries included, yet, if you don't want to use our batteries, you know, you should be able to self-host it.
So, along those lines, what we've included in Reflex is a one-line deploy.
So, after you build your app, you can just type Reflex deploy.
We set up all the infrastructure, and you'll get a URL back that anyone can access your app through.
So, we have the ASL hosting service built in as well to Reflex.
And if you don't want to use that, like many companies, you know, say you want to deploy on your private cloud, or et cetera,
it's really important to us to stay with, like, open source and make it so, you know, if you want to use it in your own use case, that's always possible.
So, we have guides and make it easy to deploy on all these.
And like you said, because it's kind of a standard output, it's kind of easy to self-host it yourself as well.
Right, right.
What you know about running FastAPI probably translates pretty well.
Yep.
What's the database story?
There's got to be a database, right?
This goes back to, like, the whole batteries yet flexible.
So, we have a built-in ORM similar to Django.
It's nothing but a kind of light wrapper around SQLAlchemy, but kind of hooked up more to Reflex.
So, kind of taking care of some abstractions in terms of making the models work with Reflex state, et cetera.
So, the nice part is we have first-class support for any SQL database because of the SQLAlchemy, like, tight integration.
When you start Reflex, you have a built-in SQLite database that gets any app that wants it.
It's there for you.
You don't have to do any setup.
So, you can start developing with databases right away, like, without, you know, having to learn too much outside or doing any setup.
And then once you want to go to, you know, production, deployment, and you want to use, say, Postgres, MySQL, or whatever you want to use for your actual database, it's just a matter of, in our config, putting the database URL that you want.
So, we make it really easy to partner with whatever you're doing.
So, a lot of people use us with providers like Supabase, Neon, where they set up their database using one of these providers, and they can easily connect it to their app.
That's cool.
So, basically, anything SQLAlchemy supports, just set the connection string, and you're good to go.
Along that line, right?
Like, a lot of people ask us follow-up questions like, well, how do you handle MongoDB?
How do you handle NoSQL?
How do you handle, like, XYZ tool that I want to use in my app?
And this is another part where I think our big advantage over low-code, no-code frameworks, where, you know, if you want, say, a drag-and-drop builder to support your random database, because there's no code in it, you're kind of dependent on them, right?
Yeah, yeah, yeah.
For us, we kind of have this kind of nice privilege where we can say, hey, it's just Python.
Go use the Python library.
Anything you can do in Python, you can, like, integrate in Reflex.
So, we give a lot of first-class support, but a lot of what we're doing is we're on the shoulders of React and Python.
Oh, interesting.
So, if I wanted to use, say, Beanie and Pydantic and MongoDB, I'd just do that?
Just do pip install, whatever the library is, and use it like any Python.
So, for example, like, a huge use case people use us with is, you know, AI apps.
So, a lot of people use OpenAI, Anthropic, and all this.
And it's just a Python library away.
And oftentimes, they already have written that Python script first, right?
And they just want a UI on top of it.
So, it's, like, even easier to hook up at that point.
Anything you want to add to that before we move on?
This whole deployment, managing, DevOps-y side of things?
Yeah, it definitely reminds me of the code where, like, any, like, sufficiently advanced technology is, like, indistinguishable from magic.
Because, like, we recently sponsored CalHacks.
And, like, being able to, like, see people who are taking, like, CS1, CS2, like, the magic, like, in their eyes.
And, like, they can, like, run it.
And then, like, a website comes up.
Yeah.
It's just so compelling, you know?
And then, so, like, for me, I'm just, like, looking forward to the future where more people can use it.
And then we can just, like, make, like, the web ecosystem, like, more democratized, you know?
Like, just bringing power to people who, like, don't have a JavaScript experience, you know?
Yeah, it's a big part of the Python story as well, right?
One of the alternatives to this is notebooks, right?
Which I know is not even close to the same thing.
But a lot of people who are not web developers or just don't want to take a month to build a website, right?
They'll kind of create a notebook and use the notebook to visually communicate in interesting ways, right?
But when it comes down to, I want something that feels like a website for someone, it kind of falls short most of the time.
They use a notebook for that.
Yeah.
So the reason I brought it up is notebooks totally democratized visualization and interaction for data scientists in a way that was massive.
Yeah, I completely agree.
And I think most people would agree, like, a web interface is nicer than a notebook, but a notebook is so much easier to build, right?
So when considering that trade-off, people are like, all right, here's my Jupyter notebook.
And what we're trying to hope, or what we're trying to do is make it as easy to, okay, convert your notebook to a website that's more easily shareable, more easily kind of deployable, and all this other stuff.
This portion of Talk Python to Me is brought to you by Bluehost.
Got ideas, but no idea how to build a website?
Get Bluehost.
With their AI design tool, you can quickly generate a high-quality, fast-loading WordPress site instantly.
Once you've nailed the look, just hit enter, and your site goes live.
It's really that simple.
And it doesn't matter whether you're a hobbyist, entrepreneur, or just starting your side hustle.
Bluehost has you covered with built-in marketing and e-commerce tools to help you grow and scale your website for the long haul.
Since you're listening to my show, you probably know Python, but sometimes it's better to focus on what you're creating rather than a custom-built website and add another month until you launch your idea.
When you upgrade to Bluehost cloud, you get 100% of time and 24-7 support to ensure your site stays online through heavy traffic.
Bluehost really makes building your dream website easier than ever.
So what's stopping you?
You've already got the vision.
Make it real.
Visit talkpython.fm/bluehost right now and get started today.
And thank you to Bluehost for supporting the show.
Along those lines, I think we're going to chat about it maybe a bit later.
But our goal, like right now, a big part of it is making, okay, you can write your UI in Python, right?
So it's making that part of it more accessible.
But our goal is not necessarily, you know, to stop at Python.
Our goal is just to make it easy for someone with an idea to build a web app.
So along those lines, like as we started, a lot of the positive comments people have said is, okay, now I can, you know, one language, one framework.
But still, it's just because, you know, Python, that doesn't suddenly mean you're a designer, you're a web developer.
Like I can now make, you know, an Airbnb style website just because the HTML is now in Python.
So a big part of what we're trying to do is accelerate a lot of the entire process.
Because fundamentally, I think people have in their mind, like they know what they want to build.
They know what it looks like in their head.
In their mind, they can visualize it.
But it's kind of their technical implementation and their tool.
Like all of those are not good enough for what's in their mind to become reality.
So that's why they have to settle for notebooks, settle for, you know, an approximation of what's in their mind.
Because they're like, okay, this is with my time and effort and tools.
This is like what I'm trying to do.
And along those lines, so I think Python is definitely one good aspect of it because, you know, it's now in their language.
We're trying to bring it to where they are.
But there's a lot of stuff that I think the whole web dev ecosystem is going to change in the upcoming years.
And we want to be part of this kind of new age of frameworks that's incorporating things like AI along with code.
And kind of that integration between the two where a lot of stuff, you know, that's easier to do in AI.
It makes sense to do there.
But it's important that the output of that is something that the developer can understand, edit, and kind of work with.
So it's still their contribution that's getting, you know, built in the end.
I'm skeptical of many integrations of AI into, I'll say, most apps.
But I know you're leaning towards not playing a little bit.
It's pretty neat.
So, yeah, we'll get to that.
But, yeah, it's pretty empowering because, you know, if you just stare at a blank screen of HTML where it literally just says angle bracket HTML, angle bracket body, now what?
Like, that's daunting, you know?
That's kind of the point we're trying to go after because there is, you've probably seen, like, there's a lot of AI website generators that, you know,
they'll make kind of your landing page.
I think there's two real downsides to a lot of existing ones that we're trying to kind of attack differently.
One is they're mostly meant for static sites, right?
Like, they'll give you your thing, but it's very hard to add your actual stuff to it.
And part of that is they generate kind of the stuff, but it's not in a way that's usable by the end user.
So you could generate a nice dashboard interface.
But for a developer, they're like, well, how do I actually put my data in there?
How do I hook it up with my database?
How do I actually make this nice thing actually practical?
So I think that's kind of the approach we're trying to do is, like, once, if we have these AI features, it's not just an AI to build.
It's something that the developer can also, you know, understand the output with and work with it.
So it's like Python we see as great in this thing as, like, an intermediate language with which both AI can kind of write to and a developer can actually understand.
And compared to an AI outputting a bunch of React code, which would be really hard for then a Python developer to actually go make modifications with.
It's write only.
And you can't do much with it after it's created.
Exactly.
I want to talk through some of the little examples and what code looks like within the constraints of a mostly audio show to the extent that we can do that.
But I want to talk open source first.
Because one of the considerations you guys said, hey, let's circle back and talk about Reflex.
I'm like, wait, I don't know what Reflex is.
But then it's Pinecone, right?
I'm always a little bit hesitant to have just a company on the show because I'm afraid it's just, well, we're just going to talk about our product all day.
But, you know, I think there's one.
I feel like having an option to write Python code across the board is super interesting for Python people.
There's a few other things that I've covered previously that are somewhat like that.
Like Anvil is close, but it has a very different approach.
And Streamlit, very different approach, but kind of somewhat very slightly sort of similar output, but not the same for sure.
But also just the fact that you guys have this also as open source.
I think that that's a pretty compelling option.
And so one of the things I think this makes it pretty relevant for people.
And then I looked at the GitHub repository and it has 20,000 stars.
That's like a third of Flask or a third of Django.
That's pretty good, you guys.
When we started, we always wanted to open source it from the start.
I think that was like very, very important to us.
I think our idea was I'd rather have a large number of users and only X percent of them,
say on a paid product than a small number of users that are all paying.
Like our biggest thing is all about kind of the community.
And related to that, I don't think there's been many, especially in like, say, web frameworks.
I can't really think of many web frameworks that are not open source that I've really took off because a big part of things like web frameworks are the ecosystem around it, right?
Like it's not just the framework, but what are all the stuff people build on top of it?
Like the integrations, the components, the tutorials and all this stuff around it.
So a big part of what we wanted to do was open source it, make it really easy for people to get started and not have a huge like burden to even start.
And yeah, pretty much lower all the activation energy that someone would need to get their first app up and running.
Yeah. And actually the open source has really been good.
Like it's been awesome for our community.
So when we first started like a year and a half ago, like people, what is very surprising to me?
Like this is the first time I've done an open source project, like, like, you know, led an open source project.
And it's what was most surprising in a positive way was like how many people are eager to contribute to open source?
Like I did not expect when I started, but like so many people were like, hey, can I work on this?
Hey, can I add this feature?
And what's really nice is like we have our reflex core stuff that we're working on, but everyone has a different use case of what they're trying to build with it.
Right. So it's like this balance of like, okay, we have a plan of our roadmap.
We're going to add these features.
But then other people will say, well, I want an audio component for this and I want this.
And the nice part about being open source is you really encourage people to add their own stuff to it.
When they hit a bug, a lot of people are like, all right, it's open source.
I can just go fix the bug.
I don't have to rely on the maintainers.
So for the and like going back to kind of the velocity, because we started around a year and a half ago, and I think we're getting pretty good traction.
And a lot of that is because of our great kind of community that's been building a lot for us.
Yeah, it is an interesting aspect of choosing what platform you want to work with.
Right. Because it's closed source.
It might be great, but you're stuck with whatever you're going to get.
Right. Maybe fingers crossed something comes, but you know, no promises.
Right. But if it's relatively small, like a component or something.
Yeah. Then people can add their own.
And that's pretty cool.
Whenever I'm like evaluating like tools to bring into our tech stack, especially for go to market.
One of the first things I look at is like, it's like open source and then their docs.
And like whether they have an API.
Like those are like my first three like top tier criteria.
That way we're not like constrained in the future.
If the company decides to pivot or to change their roadmap and things.
Yeah. Pivot. It definitely could turn out bad if it's your platform.
Right.
So Apache 2 license.
Tell me what, what does that mean for people who want to go and build stuff with us?
Basically, we wanted to make it as permissive as possible.
So I think the gist of it is you can kind of use it for anything you want paid, commercial, open source, whatever it is.
The only restriction, as far as I understand, I'm not an expert, by the way.
So maybe anyone looking into it, consult a license themselves.
But I think it's just you have to like attribute trademarks if you're copying the code with it.
But we really wanted to make it super permissive, you know, like let anyone use it and then build products on top of it.
Like our hosting, like, you know, more premium components, like built in auth that will provide value for people that are using it in a, say, a business or more, you know, production use case.
So the core open source, it's really important.
Like anyone who wants to build anything, like we want to give them something to start building.
And so it's always interesting to me on what hand we have a business and employees to we're giving away our thing.
That turns out to be a pretty good business model these days, but it is a little bit.
How does that work?
And I think what you are offering is pretty helpful.
Basically, the real, in addition to the core product, right, the real reason which you can go and sign up at Reflex.dev is take away the trouble of hosting this, upgrading it, maintaining it, patching it.
Just push a button or a CLI command and your thing lives, right?
Exactly.
Yeah.
We want to simplify the process of hosting because once you build your app, you end up having to host it anyways.
And there's a lot of clouds out there, right?
And we have self-hosting guides, so anyone that wants to can do that themselves.
But a lot of these clouds, they're configured to host any type of app, right?
Which is really great for the cloud because they can host anything.
But for the user, it means it ends up being a lot of configuration, a lot of setup, and a lot of overhead when they just want to get their app and share it with someone.
So one part of what we're doing with our hosting service is, one, making the UX around it really nice.
So just a simple deploy command, your app is up and running.
The second is we're really able to optimize our hosting around Reflex apps.
Since it's the only type of app that we host, we can really optimize the performance, the cost, and all these other factors, as well as add a lot of stuff on top of it.
For example, in the future, like analytics and different stuff on your app where that's another add-on if you're using a third-party hosting.
So there's a lot of plugins on the open source side.
But there's also, once you've hosted your apps, a lot of things you end up having to add in terms of analytics, tracking, monitoring, etc.
So we have unification on the framework level, but also we're going to have it on the cloud level where every part of the framework and from the front and back into the hosting kind of knows about each other.
So you can probably get some big machines and have a multi-tenant database with good performance, stuff like that.
There's kind of two aspects to our hosting.
One is a public cloud, and you can think of that similar to Vercel for Python.
So that's more geared to, say, hobbyist startups, people that want to build their ideas shared with the public community.
And another big use case, which is where a lot of our app developers come from, is the internal app use case.
That's kind of another aspect where we're building tools to easily deploy to our internal cloud, monitor who's accessing your apps, etc.
Yeah, I saw that over on Reflex.dev.
If you go to pricing, it's basically free for hobbyists, coming soon for pro.
You don't have anything to announce yet, do you?
We're working on our pro hosting service.
So right now, we have a hobby, so anyone can kind of deploy a few apps for free.
But our pro is going to have features like custom domains, ability to configure your machines, multi-region, and make it actually like a crib.
Let's a crib, probably.
Yeah, yeah, SSL, all that.
So actually making it kind of able to serve more users.
I'm pretty fascinated by the idea that it's FastAPI in the back end.
Because I'm always concerned that these things just don't scale.
Like you're going to build it and it's awesome for 100 people.
But then if it ever becomes popular, then it's a bad idea.
You know, it just doesn't take it.
That's a big reason also why we built our website as this is kind of the leading edge, cutting edge Reflex app.
Like hopefully in terms of features and number of traffic, like it's tested our framework a lot in terms of like improvements to support it.
I'm sure that it has.
All right.
Let's talk for a moment, for a few moments maybe, about what the programming model looks like.
And just keep in mind, most people listening can't see what we're talking about.
But nonetheless, let's just give people a sense of what it's like to write code in this.
Okay.
So if you go to Reflex.dev and scroll down, like just have a page or something, there's a little tab thing across the top here that has how do you create a form?
How do you create a chat bot?
How do you create an image gen?
And, you know, this thing's pretty cool.
It says, what do you want to see?
And all this stuff is live, right?
So I could be in here and type, I want to see a bunny.
And within just a moment, boom, there's a bunny running on, what was it?
I don't remember where I saw it.
Running on Flux, right?
Yeah.
Here it is.
Flux schnell.
Fast.
The fast version.
It's very fast.
It's pretty fast compared to, I was playing with Mid Journey yesterday and, you know, that took a while.
Then a lot of 500 errors and it took a while longer.
Then eventually I got a picture out of it.
Yeah.
It was pretty cool.
You got charts and so on.
Let's maybe just talk about this little, send us a message, put your name, email.
And message.
What does it look like to code up one of these things?
In all these examples you show, the code on the right is the entire code needed.
So it all fits in one file.
Like there's no extra stuff you need beyond that.
So if you were to copy that and run it in an app, it would actually run.
Yeah.
And just to get people listening, there's probably 50 lines, 45 lines, something like that, a code.
And so one thing you'll notice is it's all in one language and in this case, even one file.
So it doesn't have to be in one file.
Like you can have multi-page, et cetera, Reflex apps.
But the kind of nice part is the front end and back end can live together in one repository.
And so normally, you know, people that have written front end, they're probably used to either writing React HTML tags or, you know, templating through Jinja, et cetera.
And what we kind of do different in Reflex is we define your front end as nothing but Python functions.
So it fits in exactly with all the Python syntax.
You don't have to kind of learn a new language there.
Everything is a Python function.
So for example, normally when you have a button, rather than writing an HTML button tag, we have built-in components like rx.button, which as you call it, will create a button.
And the kind of layout of the front end, if you've ever worked with React, it's very similar to React or even HTML in the sense that you have this nested tree structure that kind of maps directly to the HTML DOM.
And within there, you can define all your UI components.
So that kind of is how the front end works.
And once you define your UI, these Python functions compile down to React app in the end.
Now, the interesting thing is how to make this interactive, right?
Like how do you add state to this?
So in this example, you want to do a form or in the image generation, I really want to hook this up with my OpenAI or my mid-journey model to create something.
So normally in web development, you end up having to write a front end, a back end, and a networking layer between the two where you set up a FastAPI endpoint for every single action you want.
Then on the front end, you're going to call that API, get the result by, parse it back, and then update your UI.
So that's the normal flow of, say, even adding one new feature.
Like if you want to add a button that generates an image and shows it, it will involve touching like multiple files, going through all this stuff, and hooking it together.
So one thing that we've done in Reflex beyond bringing it to one language is abstracting away the front end, back end networking layer.
So in Reflex, you'll never have to write an API call.
You never have to write a post request, a get request, or any of that.
All of that is done under the hood.
So to set up your kind of state and interactive, you can do this all within what we call a state class.
So a state class is just a normal Python class.
And within it, you define all the fields in your state that can change over time, which we call vars, as well as any event handlers that can change the vars.
So an event handler is just a Python-like function or method.
And I think the image gen is a good example of it.
So for example, in the image gen, the image URL is a var because it's something that's going to change.
And an event handler would be the get image function, which is a function that when they hit submit on the input, we call it.
So in order to hook up the front end and back end, all you have to do is hook up the UI to the Python function.
So you can say button on click equals state dot get image.
And what this does under the hood is when you click that button, it creates an event.
It sends up through a WebSocket to the back end.
It will run your Python function on the back end.
So whether that's your OpenAI, your Replicate, whatever it is, all their state runs on the back end on a server.
And that's what allows us to keep the state in pure Python.
So it will update your state UI.
In this case, it's going to update the image URL and send that back.
And it works very similar to React in the sense that as your state updates, the front end updates reactively.
That's super cool.
Kind of just two-way data binding on the values there.
Exactly.
Yeah.
All right.
So you just said something interesting that there's the next JS React front end and the FastAPI back end.
But you didn't say it's calling HTTP APIs.
You said it's using WebSockets.
Yes.
What's the deal there?
Why WebSockets and not Pydantic over HTTP or something?
No, it's a really good question.
And I think this is like, and a lot of people ask us, you know, how is Reflex's performance?
Or what are the downsides of Reflex?
Like, what's the catch?
Because up to now, we've been saying, you know, we can perform, create anything you can do in JavaScript, anything you can do in React.
So a lot of people are kind of ask about the performance.
And we kind of made design Reflex to be really performant in everything we do.
And the reason we use WebSockets is because Reflex apps, especially like very stateful apps, often need to make a bunch of requests.
So rather than having to reestablish a new HTTP request every time, by keeping a WebSocket, we are really able to optimize the speed of the apps.
So when you create, when you kind of send the type your prompt, say you want a bunny and you press enter through the website.
We changed it to a fast bunny, by the way, because you said the website was fast.
Now we have a fast bunny.
So when you want that fast bunny, it will create a little event that says, hey, this guy wants to call get image and he typed fast bunny.
It'll take that little payload, send it through the WebSocket that's already been established, run the Python function on the backend, and then send only the state delta back.
So for example, if you have a really large app with hundreds of pages and hundreds of states, changing this is not going to say, hey, front end, this is their entire new state.
We only send the diffs and stuff back over the WebSocket.
So all of this was done like in the name of performance and making Reflex apps really snappy for whatever you're doing.
In a sense, the Python code that I write, even though there's this React bit, some of it still lives on the backend.
Yeah.
And then some of it gets kind of mirrored to React on the front end.
Is that right?
This is something, especially like as people are learning Reflex, like one of the things we try to emphasize most, which is though it's all in one file, it's all in Python.
There still is a distinction between the front end and backend because of this fact that the front end compiles to Next.js app while the backend is a FastAPI.
So in this case, it's pretty much all the UI code, right?
Like what's inside the index function.
That's your Next.js React app.
Your FastAPI is pretty much your state and your event handlers.
So within there, you can keep everything in pure Python.
use anything you want.
The one thing you can't do and we can't do is compile arbitrary Python to JavaScript.
So that's the reason all the event handlers run on the server.
So you can use any library, anything you want.
And on the front end, we only compile kind of a static website.
So there's no logic that ever happens on the front end, actually.
Just updating the bindings and triggering events.
The front end is just like a dumb UI.
It's like, give me the state.
I'm going to show the state.
That's definitely a nice bunny.
So one thing that I think is notable here, and I've seen this in other frameworks as well.
Like, for example, I had QPy on Talk Python recently, which is also sort of React stuff on the front end.
But this is a lot more, QPy is more running, I think, React type stuff almost in PyScript, I believe.
Oh, got it.
All on there, which is interesting, right?
But one of the things that I think you find with a lot of these is the shape of the code matches the DOM a lot of times.
Or at least the conceptual idea of the hierarchy of the UI, right?
So, for example, here you've got a VStag with a skeleton with a flex.
And then you start putting forms and in the forms and all of this, every word that I said there is another level of indentation.
And then you indent and you get a React input and a React button and you unindent Python style, right?
And I think it makes it pretty easy to think about, here's the code, here's the UI, because the shape of the code matches the concept.
It mirrors the UI in some ways, right?
And rather than just pure top to bottom imperative, we're just generating the UI, but it actually, like, the way it's structured, it's kind of like Flutter.
It looks like it matches it, you know?
There's kind of two approaches people in this space have taken to building.
Like, one is imperative, which is kind of what you said.
And I think, for example, Streamlit has taken this approach where to do a button, you would do, like, ST heading, ST button.
And it will implicitly, like, kind of magically put it into its thing.
And I think it could be good for simple stuff, but it's really hard to reason about as your thing gets larger, because you have to kind of contextualize, wait, has this been called already?
Like, what order is everything going through?
Is the button in this group or is it outside of the group?
Or, yeah, stuff like that, right?
It's nice in some sense, but I don't think it scales very well, especially, like, conceptually.
Like, it's hard to kind of reason about what all you've kind of built.
I guess going back to, like, why it's in this structure, it's, like, this is already kind of the natural structure, right, from HTML, from React.
And I think a lot of, as we were going through stuff related to API design, we try to improve the API where we can.
But a lot of the times we realize, you know, the people that did it originally had a good idea.
Like, and there's a reason it's kind of the standard.
I think it takes a little getting used to, to be honest, to see search nested stuff.
But I do like it.
I think it's good.
Part of it, I think in this example, we kind of nested it just to show, you know, it's all in one function.
But in a more practical setting, you would break this up into different components.
So similar to React, you probably wouldn't have a giant nested thing.
And you can think of each of those things as units that you work with.
Yeah.
Also, like, decorators help a lot with, like, making dynamic components on the fly in terms of different functionality.
Yeah.
All right.
Let's talk about just a couple more things while we're here.
I want to talk about the components.
And the components are these building block pieces.
Maybe pick just a couple you think highlight the idea of these things and we can talk about them.
A really big thing people use this for is kind of like tables and graphing.
So maybe if you go down to the table section, the AG grid one might be a good one.
So this is actually a good example of a third party component.
So you can see we have our built in components, but a lot of our enterprise users really wanted this AG grid feature, which is one of the most popular kind of table libraries.
So we make it really easy.
This is an example of a third party library.
Someone's wrapped that you can kind of bring in.
And this is an easy way to kind of showcase your data.
So a lot of data scientists, et cetera, use this library.
It can hook up with your data frames and kind of show this.
So this is another example showcasing kind of the flexibility of you want that random react library, even if it's not in Reflex, like the team or external contributor often wraps this easily.
And yeah, the kind of nice part about it is it's more high level.
It has a lot of these built in features like pagination, searching, sorting and all these.
So I think it's this balance, right?
Like we can give people the raw components like you can code everything in HTML.
You can build everything from the ground up yourself or you can use this kind of high level thing.
And the nice part about Reflex is you can kind of approach it at any level that you want.
So it's like I want this nice built in thing that has sorting pagination.
Here it is.
Or you're like, you know, I'm just going to build everything from the ground up.
I want my own table component.
We also give you the tools to do that.
So I think it just kind of shows the scale at which you can kind of pick your level of abstraction as you're using it.
Yeah.
Then you just pip install the name of the thing and then just use it like a native component, right?
Exactly.
And it will act as if like all other Reflex components.
So there's nothing like distinct between our components and something you would wrap yourself.
I was a reasonably sized company with a team of maybe many of them knowing React.
It might make sense for me to build out an internal library of widgets that we use on our app and plug in to Reflex something like that.
We have a whole guide on our website on wrapping React with different examples.
And we're trying to make it accessible for Python developers.
So because that's our user at the end, right?
So we wanted to make it accessible for even a non-JavaScript, non-React expert to be able to wrap these components.
So we've seen in different companies, like I kind of mentioned earlier, that have their internal component systems in React.
A Python developer was easily able to kind of wrap these because we make it super easy to wrap as just a Python class where you just define the props.
So maybe if you go to the wrapping React section on the left-hand side, it's kind of at the, maybe go back to the main docs section.
But yeah, we try to make it really easy to bring your own components as well.
So whether you already have one or you want to make your own.
So this is like a spline one.
And you can see all you have to do is list all the props.
It's a Python class.
You kind of have to just go find what library, what NPM library you're using, list all the props.
And for interactive ones, you may have to define that.
And then you can start using it right away.
As part of your component, you define just basically the NPM thing to install or whatever.
And then off it goes.
Yeah.
And Reflex will handle, it'll install the component.
It will wrap it for you and it will compile out for you.
All right.
I said three things.
One was components.
The other is this AI generator.
And then I want to just talk about the roadmap.
So let's get short on time.
So let's go and talk about this FlexGen thing.
This is build web apps at the speed of thought.
Create UIs with Reflex framework with simple prompting.
This is in beta.
Like we're kind of released it on our Discord and we're going to do more releases.
But this version of it is similar to if you've seen like v0.dev from Vercel.
This is kind of, I'd say like a version of V04 Reflex where you can, it's a web editor.
You can enter your prompt.
It's going to live stream your output.
At the end of it, it's going to give you the code that you can copy into your app and you
can start adding a backend to it.
So I guess an important note is this is more for like your starter app, right?
Like when you're first starting your project and you want to get like a good starting point.
We'll fix that.
So don't worry about it.
It made such a nice one for me before.
Let's see.
Yeah.
The idea of this one is to be kind of a web editor to get your app kind of started building
out from.
And this is kind of just a version of V0 for Python.
So this is level one of what we're building with FlexGen.
But a more interesting thing that we're developing now internally and are hoping to release in
the next month is a local version of this.
So this is, this has no context of your existing code base.
It has no context of what you're building, right?
So you could ask it to build a little component, but a big issue with V0 and other of these web
developers is how do I actually integrate this into an existing app?
Like it's good at building brand new stuff, but how do I like update an existing app?
So on this front, we're building a local AI toolbar, which has a lot of these agentic
features around Reflex, but on your local.
So for example, the features we have there are you can click a button and say, when I click
the button, do this or click a text and say, change, like, you know, put a form under this
text.
And the big idea there, I think this is a good, good first start, but I think in the long
run, I'd see the toolbar as being this way where the AI and the developer kind of integrate
together with Python as a common language.
So for crazy stuff that you don't want to deal with, like make a form that works in mobile
view, et cetera.
The AI can handle a lot of this, but once it outputs, it's outputs code that you can actually
go understand and read.
Like it's not this obfuscated JavaScript or React code.
It's code that you can go edit by hand if you want, and you can easily hook up your own
state and data to it, right?
Which is a big other thing.
I think other frameworks miss, which is here's a great dashboard.
Great.
But it's all fake data.
Like how do I actually make it hook up with my clicks, hook up with my different data?
So that's a big part of what we're trying to bring to the local environment.
This thing will generate a visual look and feel thing and you actually go show the code.
That's all fake data.
Yeah.
And then it's fake.
Yeah.
Of course.
And then you can show the code and then now you can kind of copy the code, start using
it in Reflex.
And then with the toolbar, you'll then be able to make incremental upgrades on top of this
rather than starting from scratch.
And that will have like full context.
And on top of that, we're aiming to build a lot of stuff on top beyond, you know, just
prompting and updating.
Like there's a lot of improvements that we want to build on top of that as well.
All right.
Well, this is pretty neat.
I like it.
It definitely gives you some ideas for here's some possible layouts and so on.
And it gives you at least a little bit of an idea of what you might want to do and take
it and run with it.
So that's helpful.
Yeah.
I think some ideas we have in the future for the local are, you know, buttons that can,
you know, keep your same content, show you different variations, like auto style it, etc.
Like a lot of stuff that people don't want to deal with, but they're like, just give me
some ideas and how it could look and turn people more into like, you know, prompters and
selectors rather than implementers.
All right.
Let's close it out with the roadmap.
Where are we going?
So recently we just released Reflex 0.6 last month.
And right now we're going after 0.7.
So a big part of 0.7 is cleaning up a lot of our core components that we have, especially
for the features people use the most.
So the ones we're starting off with are like you can see here, AG grid support, which is
a big thing people asked.
And beyond that, just like very good support with tables, databases, and graphing to help
a lot of these internal apps and data science use cases.
Beyond that, like one really important thing for web frameworks that we're trying to build
is auth.
So built in auth.
So if anyone's ever used Django, you know, they have a really great kind of way that you
can plug any auth system in.
And that's often the first thing someone wants in a practical web app, right?
They're like, I have, especially a data app.
They're like, I have this great app, but I don't want anyone to be able to access it.
And we already have integrations with third party auth providers.
But we want to bring in just like first party auth where you can just add a click of a button.
Your website is going to have auth at this point.
A lot of these, the other stuff here is related to a lot of performance improvements that we're
going to make.
So one key feature of Reflex is the development experience.
So one part of that is code, but the other part is things like hot reload and how fast is
it for me to actually make iterations on what I'm doing?
So a lot of these other tickets are internal changes we're going to do to make it easier for
pretty much improve the hot reload times.
So we wanted people to improve their iteration speed a lot.
A lot of time people like pretty much all their time should be spent looking at actions and coding
and not waiting for anything.
And then one final thing related to kind of how we want to simplify the approach of UI and state
is we're implementing a system called CSR, which is kind of right now,
I kind of mentioned there's this difference between compile time and runtime.
And there's certain things, your entire UI kind of needs to be known at compile time.
So you have to compile your code and that's what you get at runtime.
And what we're introducing is this idea of dynamic components, which are dynamics generated at runtime.
So this will enable a really cool use cases.
For example, you can have a chat bot that instead of just returning text all the time,
it could return components.
So it could return a graph, it could return a whole Reflex page.
And these could be components that you don't know upfront and are actually generated during runtime.
So it's going to help a lot in terms of flexibility and also in terms of, you know,
the ease of use in using Reflex, because since they're generated at runtime,
you can now use pure Python.
You don't have any limitations.
And there's a lot of advantages on the developer side as well.
Yeah, that's very cool.
So yeah, this is on the open source.
And we're also, like I mentioned, releasing some of our AI features.
And the biggest thing, though, is we're releasing our first version of our hosting service.
Our hosting service has been in beta for some time right now.
But along with all this, we're releasing our first kind of paid version of our hosting service.
And yeah, getting people on apps onboarded onto there is coming up.
So I'm really excited for that.
Framework looks really nice.
So sure to help a lot of people.
Awesome.
All right, guys.
One final parting thought from each of you.
Yeah, I can go.
I think one of the fun things that I've experienced with working here is that
even when I'm writing our docs,
it's like some people have never interfaced with props before.
And so Reflex, in a way, is like a bridge to the web ecosystem.
So it's been fun thinking about what are the mental models that I can take in Python
to help explain things that are in web?
And it's like, how can we bring those in and then create pathways
for people to start building apps?
Yeah, there's not a lot of event-driven stuff in Python,
but so much of the web is event-driven callbacks and stuff.
Yeah.
I'm just excited about thinking about new kind of user interfaces,
both in terms of like coding APIs and, you know, actual user interfaces
that people are going to be able to build upcoming.
I think the current web frameworks, you know, the Django's and Flask,
they've been around for a long time.
And I think they have a lot of great stuff,
but there's also a lot of new stuff that I think a next generation of web frameworks
could like add, you know, to accelerate a lot of work.
And I'm just excited about thinking of what are those features?
Like how can we accelerate while keeping the good stuff that's already been,
you know, discovered before?
And yeah, I think there's, especially now, like a lot more people are building,
a lot more people are becoming builders and sharing.
So I'm excited about like empowering all those people.
Yeah.
There's a lot of abstractions to like think through in terms of like,
like how can we create guarantees that can enable someone to be successful in the long term,
especially when it comes to building apps that can serve like hopefully millions of people
and millions of traffic, but then also like being flexible enough that they can still start.
That's a challenge.
And you know, there's a lot of places that are struggling with those challenges or trying to solve them.
Look at AWS.
Just go to the services tab of AWS, right?
That place serves tons of people, but boy, is it complicated to look at the hundred or whatever services
and decide what you need and how they go together, right?
We have system initiative now though.
So that's going to be huge value add.
Yeah.
I think in one way, I think we're, we're on an effort to just like simplify this whole thing
and yeah, just make it really easy for more people to build.
Yeah.
It's a good mission.
All right.
Nikhil, Elvis, thanks for being on the show.
Talk to you guys later.
Yeah.
Thanks so much.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/Posit, P-O-S-I-T.
And this episode is brought to you by Bluehost.
Do you need a website fast?
Get Bluehost.
Their AI builds your WordPress site in minutes and their built-in tools optimize your growth.
Don't wait.
Visit talkpython.fm/bluehost to get started.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.