deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

WebForms.py 2.1 brings server-driven UI commands to Python web apps

WebForms.py 2.1 ports the WebForms Core model to Python: the server builds UI commands that the WebFormsJS browser library executes, so pages update without per-interaction JavaScript.

WebForms.py 2.1 brings server-driven UI commands to Python web apps

WebForms.py 2.1 has been released, and it ports the WebForms Core programming model to Python web applications. According to the release announcement on dev.to from the Elanat Framework project, the package supplies the Python half of a two-piece architecture in which the server decides what the interface should do and a browser-side library carries it out.

A commander on the server, an executor in the browser

WebForms Core divides the work of updating a page between two roles. The WebForms class inside WebForms.py is what the project calls the Commander: a developer instantiates it, describes the changes wanted, and returns its response to the browser. WebFormsJS, a JavaScript library loaded in the page, plays the Executor. It reads that response, locates the relevant HTML elements, and applies each requested operation to them.

The announcement's pitch is that a Python backend can change what the user sees without anyone writing JavaScript for each interaction, and without Python reaching into the DOM itself. The server emits a description of the intended change; the client library turns that description into the actual update.

Targeting elements with InputPlace

A central piece of the API is InputPlace, which states where an operation applies. InputPlace.id('result') directs a command at the element whose ID is result, so developers address parts of the page without hand-writing selectors.

Every command combines three ingredients: the target from InputPlace, the operation as a method name, and the value. form.set_text(InputPlace.id('result'), 'Hello from Python!') asks WebFormsJS to swap that element's text; form.increase(InputPlace.id('counter'), 1) bumps the number shown in the counter element by one. Calling form.response() closes the batch and produces the payload the browser library consumes. The announcement also shows the increase method applying different amounts depending on game logic, such as 100, 5 or 1 points in its demo.

A Flask demo that updates a page in place

The release note walks through a number-guessing game built on Flask. The server reads three digits submitted by a player, validates them, generates three random digits of its own, and compares the positions. What matters for the story is the response path. Invalid input produces a single set_text command carrying a warning, followed by form.response(). A valid round queues several commands together — advancing a turn counter, writing the server's digits into one element, and setting both an outcome and a detail line in two others — before returning the response.

The example illustrates the model's core appeal: several regions of the already-loaded page change at once, while the server never ships a fresh HTML document nor assembles JavaScript strings to make it happen.

Why it matters

Server-driven UI keeps resurfacing as an answer to JavaScript-heavy front ends, and WebForms Core joins that lineage with its own command-response protocol, in the same neighbourhood as approaches like htmx or Phoenix LiveView. For Python teams — the announcement itself pairs the library with Flask — it offers a route to keeping interface logic beside the rest of the server code rather than duplicating it in a separate client codebase.

Caveats apply. This is a project's own release note rather than independent coverage, and it leaves open questions such as integrations beyond the Flask demo, browser support, and how the response format behaves at scale. Even so, version 2.1 gives Python developers who want page updates driven from the server something concrete to evaluate.

  • #python
  • #flask
  • #server-driven-ui
  • #webforms
  • #javascript

Related posts