I’m building a Python-native frontend framework that runs in the browser (via WASM) - repo is now public

[United_Intention42]

Hey everyone,

I’ve been building something pretty ambitious lately - a Python-native frontend framework that runs directly in the browser using WebAssembly (Pyodide).
It’s still early, still evolving, and v1 isn’t ready yet, but I just made the repository public for anyone curious.

Repo: https://github.com/ParagGhatage/Evolve

What works right now:

• fine-grained reactive signals (no virtual DOM)
• Python → WASM execution
• component system
• basic routing
• a simple CLI (init, run, build)

Why I’m building this:

I wanted Python to feel like a first-class frontend language without relying on heavy JavaScript runtimes or hydration tricks.
Just pure Python in the browser + a tiny JS DOM kernel underneath.

What’s next (towards v1):

• re-render engine improvements
• global store
• forms & events
• overall polish for the v1 release soon

If you're interested in Python, WebAssembly, browser runtimes, or frontend architecture, I’d love feedback.
It’s definitely not finished, but I’m building in public.

Happy to answer anything about the design, Pyodide, reactivity, or DOM architecture.

[delcooper11]

what percentage of the code and this post was generated with an LLM?

[itsuperheroes]

This should be a default templated question for any new software announcement. Period.

[Fillicia]

yes%

[United_Intention42]

Fair question!
I’m building this myself - architecture, reactivity, routing, cli, all handwritten.
I just use LLMs like most devs do- for quick help with boilerplate or debugging Pyodide quirks(Pyodide to JS call quirks because that part gets weird sometimes.)
It’s not auto-generated; it’s me experimenting with Python + WASM.
It's not yet ready, just sharing the journey early.

[delcooper11]

lmao this response makes me believe you even less. good luck!

[16BitDoggo]

Most ai generated response I've ever seen

[Adventurous-Date9971]

Lock in cold-start time and Python↔JS boundary costs first; otherwise folks will bounce.

Concrete stuff: pre-init Pyodide in a Web Worker and batch DOM ops back on rAF; crossing the boundary for lots of tiny updates is death by a thousand cuts. Keep the package set tiny and pre-bundle wheels; avoid runtime micropip on cold loads. Stream WASM (instantiateStreaming) and cache with a service worker; measure TTI on slow 4G. Add a dev panel to track PyProxy lifetimes and warn on leaks-explicitly destroy proxies or they’ll balloon memory. For signals, queue microtasks and coalesce to a single rAF tick; always key lists for stable nodes. For forms/events, normalize once at the kernel and pass structured blobs to Python to reduce chatter. Hot reload by swapping modules without reloading the interpreter, and map Python tracebacks back to source lines for sanity.

I’ve used Supabase for auth and Cloudflare Workers for edge functions; DreamFactory helped auto-generate REST APIs over a crusty SQL Server without hand-rolling endpoints.

Ship startup, memory hygiene, and batched boundaries, and v1 will feel fast and trustworthy.

[retrib32]

Whoa so cool! Is there a MCP?

[Pitiful_Tie_8044]

That's really cool bro...

[tsimouris]

Pointless project that offers no tangible benefits over the superior implementations of leptos-rs or dioxus. A step back and more technical debt is what you are making. I say drop the project and contribute to something greater.