Reflex Roadmap

[picklelo]

This page is a living document outlining the major projects we're working on for Reflex 0.9 and beyond, as well as for our AI and Enterprise features.

Feel free to comment to leave feedback or upvote any issues you'd like to see prioritized, and we welcome outside contributions for any issues.

Key Focus Areas

Stability: As we approach our 1.0 release, we're focused on making our core API stable and limiting breaking changes so Reflex can be a solid foundation for long-term projects.

Simplicity: We want to improve the out of the box experience so users can focus on their ideas rather than implementation. This includes building a 3rd party component ecosystem, as well as simplifying the APIs for many of our core components.

Speed: Reflex apps should be fast, both for the end user and for the developer. We have projects to make sure apps stay fast as they grow in size, and to improve the compile / hot-reload times so devs can iterate quickly when building.

Event System & State Management

The largest architectural initiative for v1.0 — a fundamental redesign of Reflex's runtime, touching event processing, state synchronization, and the developer-facing API.

Tracking issue: #6236

Key goals:

• EventContext as the foundational execution primitive (owns state lock, manages backend event queue, tracks mutability scope)
• Redesigned EventHandler with a global registry, awaitable semantics, and partial-arg call convention
• Replicache-based state synchronization (optimistic UI, offline support, conflict resolution)
• rx.Field as a first-class descriptor enabling composable states without rx.State inheritance
• Event handlers as HTTP endpoints with auto-generated OpenAPI spec for agent/MCP integration
• Full-stack OpenTelemetry instrumentation

Compiler & Build Performance

Replace multi-pass compilation with a single tree walk using a plugin-based architecture, and improve the developer iteration cycle.

Tracking issue: #6235

Key goals:

• Single-pass compiler with CompilerPlugin protocol and context objects
• Selective page recompilation and caching for faster hot reloads
• Single-port dev mode with internally-managed hot reload
• Source maps for better debugging support

Component Library & UI

• Replace Radix with a Reflex-native component library built on basic HTML elements (Reflex-native component library built on base HTML elements #6247)
• Improved rx.memo with full support for props/children/arbitrary arguments (New @rx._x.memo decorator (experimental) #6186)

Interoperability & Standardization

Align Reflex with Python ecosystem standards so the framework composes naturally with existing tools and workflows.

Tracking issue: #6246

• ASGI interoperability — make Reflex mountable as an ASGI sub-app (ASGI Interoperability — mountable Reflex sub-app #6239, Embedding Reflex in other apps #46)
• Config via pyproject.toml with app profiles (Config via pyproject.toml with app profiles #6240)

Dependency Reduction & Decoupling

Reduce framework dependency footprint and modularize into separate packages maintained in a monorepo.

Tracking issue: #6237

• Reduce External Dependencies #4921
• Remove unsupported hacks to use Pydantic v1 (Remove unsupported hacks to use Pydantic v1 #6241)
• Remove SqlModel as hard dependency
• Remove JSON5 dependency (remove JSON5 dependency #5820)
• Split reflex repo into monorepo: reflex-core, reflex-html, reflex-radix, reflex-lucide, reflex-orm (Monorepo split: separate pip distributions #6242)

Database & ORM

Make the database layer less opinionated — remove custom ORM abstractions that get in the way while keeping an easy-to-use experience built on standard SQLAlchemy/SQLModel and Alembic.

Tracking issue: #6238

• Extract database functionality into reflex-orm package (Extract reflex-orm package #6243)
• Remove rx.Model — let users bring their own model base (Remove rx.Model #6244)
• Simplify rx.session + reflex db to thin wrappers over standard tooling (Simplify rx.session and reflex db CLI #6245)

Internationalization & Localization

• I18N/L10N framework support (Internationalization (I18N) and localization (L10N) (Feature Request)  #2339)

AI & MCP Integration

Making the open source framework AI-agent friendly.

• Move docs into framework repo for AI tool accessibility
• Event handler HTTP endpoints with OpenAPI spec (see Event System & State Management: Tracking Issue #6236)
• Framework-level MCP server — agent-friendly tool discovery for Reflex apps (Framework-level MCP server: agent-friendly tool discovery for Reflex apps #6248)

Error Handling & Developer Experience

• Unify generic frontend/backend exception handler API (Unify generic frontend/backend exception handler API #5168)
• Better error path for unprocessable delta (Need a better error path when backend sends unprocessable delta #6019)

PWA & Mobile

• PWA first-class support (PWA - First class support for Progressive Web App development #3931)
• Push notifications in PWAs (Push notifications support in PWAs #5078)
• Desktop app support

Incomplete Plans from Previous Roadmap (0.8.0)

These items were on the previous 0.8.0 roadmap and have not yet been completed. They are being tracked separately or carried forward into the plans above.

Reflex Cloud

• Cloud: Support for Team and Enterprise tiers #4915
• Cloud: Improved Integration with Reflex.Build #4916
• Cloud: Improvements to CLI #4917
• Cloud: Improved Package visibility #4918
• Cloud: Improve Billing Usage Display #4919
• Cloud: One-Click Auth / User Management #4920
• Cloud: Improved Log Searching #4924
• Cloud: Custom Alerts #4925
• Cloud: Custom Roles #4926
• Cloud: Otel + Prometheus support #4927

Reflex Enterprise

• One Click Auth [Pro plan]
• Database Model Interface [Pro plan]
• 3rd Party Integrations with AI Builder [Enterprise Plan]

Please leave comments on what you think about this tentative plan.

[abulvenz]

Firstly, I ❤️ like the plans and think the three main goals are a good focusing point for 0.5.0.
One minor drop of bitterness (at least for my current code):
Remove the middleware 🙀 ? I would need new ideas for authorization then. I do not want to rely entirely on the routing and if-statements. What are the ideas how authorization (I don't mean solely authentication here) might be added to an app?
Other things that middleware is good for: Checking when the last action of a user had been carried out. Conditionally having fine-grained influence on states. Debugging event orders by mere printing.
Maybe there are plans to have a similar mechanism that replaces this nice (not tremendously over-documented ;) feature?

[benedikt-bartscher]

Awesome, love to see how reflex evolves! 🚀
Is Pydantic v2 fixed on this roadmap? If so, I would offer my help regarding SQLAlchemy support and adjust my affected PRs to pydantic v2.

[picklelo]

@abulvenz Thanks for the feedback - I will modify that project, we don't want to break any existing functionality.

We want to move certain internal events like the initial state hydration away from using middleware, but we will still have easy ways to support other use cases.

[picklelo]

@benedikt-bartscher Yes we either want to upgrade to Pydantic v2.0 for the performance and compatibility benefits

In the long-term we can potentially remove the Pydantic dependency altogether and use Python dataclasses, since we don't use many of its features anymore internally. Though that would require moving away from FastAPI and SQLModel, so not planned anytime soon.

[cllatser]

Hi everyone, as I have said before. I have been programming for a short time, I did a Python Bootcamp and for the final project I used Reflex when it was called Pynecone. I could have used Django or Flask, but I chose Reflex because I think it will have a future.

What would I like from Reflex 1.0?

Let's see if I can explain. I would like Reflex to be from a base agnostic of any external framework, using as it can be done now 100% html and css. So as not to depend on third party libraries, such as Astro (Javascript).

From there, when starting the project the user will be asked whether or not to use a framework or not, for example Radix-Ui, Taildwind.

Then the ability to share components with (3rd Party Component Ecosystem) seems to me great.

Good job to all the team, long life to Reflex.

Best regards.

[dentroai]

Perhaps these thoughts help you in finding the right direction for your product.

Started to use reflex because:

• wanted same coding language as most ML frameworks -> python
• wanted a low code tool that's flexible. Using little code to achieve common use cases with the possibility to customize easily
• wanted frontend and backend in one, allowing for a single code base that can handle auth and user management
• used streamlit before, but can't build any serious project with it because customizing look of components is a pain, page randomly refreshes deleting existing state, weird logic where the code is rendered top to bottom making common use cases difficult to implement (or at least much different)
• need to be able to self-host it for GDPR critical use cases

Like it even more since I started:

• wrappers of 3rd party libraries like motion
• askInkeep on discord
• team on discord is very responsive
• hosted version for non GDPR criticial use cases
• lots of inbuilt components that actually do work out of the box such as file upload or scrollable area

[include]

Really like to see the "Simplicity" point here. box system is really a pita :) - thank you for Reflex!

[Sprocketer]

@benedikt-bartscher Yes we either want to upgrade to Pydantic v2.0 for the performance and compatibility benefits

In the long-term we can potentially remove the Pydantic dependency altogether and use Python dataclasses, since we don't use many of its features anymore internally. Though that would require moving away from FastAPI and SQLModel, so not planned anytime soon.

@picklelo In terms of improving performance - I'm not sure how much Javascript next.js (which seems to be under the hood) uses, but have you seen Astro? Seems to be super fast because it renders static JS components as HTML. Might be a reach, but maybe there's some way to include something similar at build-time?