Writer Framework: a visual UI editor with a Python backend

The gap Writer Framework fills between a notebook and a web app

A pandas script that produces a table is finished work that nobody else can use. Turning it into something a colleague can click through normally means a frontend, a build step and a deployment story, and that work has nothing to do with the analysis. Writer Framework takes the position that the interface should be assembled visually and the logic should stay in Python.

The README frames this as separation of concerns: "Build user interfaces using a visual editor; write the backend code in Python." That split is the whole product. The person who knows the data writes handlers; the layout is a document the editor produces. The stated audience is people building AI applications and data apps, which matches the topics attached to the repository: data-visualization, ui-components, models, websockets.

It is not a general web framework. There is no routing layer you design, no template language to learn. If your problem is a marketing site or a multi-tenant SaaS product, this is the wrong shape entirely.

How the editor, the Python handlers and the websocket runtime fit together

The repository is a Python package under src/writer with a TypeScript UI workspace in src/ui, wired together by package.json workspaces. The Python side depends on FastAPI and uvicorn for serving, websockets for the live channel, pandas, pyarrow, numpy and plotly for data and charts, and pydantic for state models. That dependency list tells you what the runtime is: a FastAPI process that also holds a websocket connection to the browser.

The build script in package.json runs npm run ui:build, then npm run apps:build, then npm run ui:codegen. The apps:build step copies ./apps/hello and ./apps/default into src/writer/app_templates/, which is why the CLI can scaffold a working app without downloading anything. The codegen step generates the frontend bindings from the component definitions.

So the data flow is: the editor writes a UI definition, the FastAPI process serves it, the browser holds a websocket, and user actions arrive in Python as events you handle. State lives on the server, not in the browser. That is what makes the Python side testable with pytest, and it is also why every interaction costs a round trip.

Installing Writer Framework and running the hello app

The README gives a single install command and a set of CLI subcommands. The package name on PyPI is writer, not writer-framework, which is the first thing to get right.

pip install writer

The README states support for Linux, Mac and Windows, with Python versions 3.9.2 through 3.12. Note the lower bound: 3.9.2, not 3.9.0. The pyproject.toml classifiers also list 3.13, so the classifiers and the README disagree on the upper end. Treat 3.12 as the documented ceiling.

Once installed, the CLI scaffolds and runs an app:

writer hello
writer create my_app
writer edit my_app
writer run my_app

writer hello creates a demo app, writer create makes an empty one, writer edit opens the visual editor in your browser, and writer run starts the app. The editor is where you drag components onto a canvas; the generated files land in the app directory you named. Run writer hello first and read the files it produces before you write any handler of your own, because the handler signature and the state model are easier to copy than to guess.

Where Writer Framework stops being the right tool

The visual editor is a constraint, not a convenience. Components are the ones the framework ships and the ones you generate through the UI workspace. If your design needs a layout the component set does not express, you are either writing a custom component in the TypeScript workspace or you are fighting the tool. The README does not document an escape hatch for arbitrary HTML, and the repository layout suggests custom components are a build-time concern, not a runtime one.

State on the server has a cost. Every click that changes something travels over the websocket and back. For a dashboard that refreshes on a button press that is fine. For a text input that filters a table on each keystroke, the round trip is visible, and the framework gives you no documented client-side state to soften it.

The release history is worth reading carefully. The most recent release listed is v0.8.2 from 2024-12-02, while pyproject.toml declares version 1.27.0 and the last push to the dev branch was on 2026-07-24. Releases and the version in the manifest have diverged, so the GitHub release page is not a reliable signal of what pip install writer will give you. Check the installed version rather than the release tag.

Writer Framework against Streamlit, and what the difference costs

Streamlit is the obvious comparison, and the difference is not cosmetic. Streamlit apps are Python scripts that rerun top to bottom on every interaction; the layout is whatever the script emits. Writer Framework separates the two: the layout is a document built in a visual editor, and the Python code is a set of event handlers over a state object.

That means a Writer Framework app has a stable UI definition that survives a code change, and a Streamlit app does not. It also means a Writer Framework app has two artifacts to keep in sync, and a Streamlit app has one. For a throwaway internal tool, one artifact wins. For something a team maintains for a year, the separation starts to pay for itself.

The second difference is the Writer platform. The Python dependency list includes writer-sdk, and the README describes Writer as a full-stack generative AI platform with LLMs, graph-based RAG tools and AI guardrails. The framework is usable without those, but the dependency is there, and the homepage points at dev.writer.com rather than a standalone docs site. If you want a framework with no vendor attached, Streamlit is the cleaner choice.

Licence, maintenance and the cost of upgrading

Writer Framework is Apache-2.0, and the LICENSE.txt file is at the repository root. Apache-2.0 permits commercial use, modification and redistribution, and it includes an explicit patent grant, which matters if you are shipping this inside a product. It does not require you to open your application code. This is a description of the licence text, not legal advice; if you are redistributing the framework itself, read the file.

On maintenance: the last push to the dev branch was on 2026-07-24, and the repository is not archived. The most recent release listed is v0.8.2 from 2024-12-02. Those two dates are roughly nineteen months apart, and the manifest version is 1.27.0. Whatever the reason, the release page is stale relative to the code.

Upgrade cost is where the version gap bites. The dependency ranges are pinned tightly: fastapi >= 0.89.1, < 1, pandas >= 2.2.0, < 3, pydantic >= 2.6.0, < 3, numpy <= 2.0.2 on Python below 3.10. A project that already pins pandas 1.x or pydantic 1.x cannot install this without an upgrade of its own. Check those three pins before you start, not after.

Editorial conclusion

Adopt Writer Framework if you want a browser UI over Python logic without writing frontend code, and if your app fits the component set the visual editor exposes. Do not adopt it if you need full control over the DOM, or if you cannot accept that the editor, the runtime and the Writer platform SDK move on the same release train. Before committing, check that Python 3.9.2 through 3.12 covers your environment, and run writer hello to see the generated app layout on disk before you design anything of your own.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. writer/writer-framework on GitHub