WebForms.php 2.1 ported from C# by DeepSeek, audited by Qwen before release

WebForms.php 2.1 has been released as the PHP back-end implementation of WebForms Core 2.1, and the way it was built is the unusual part. According to a post on dev.to by the Elanat Framework project, published 5 September 2026, the PHP code was converted from the C# reference implementation using DeepSeek, manually reviewed, then independently evaluated by a second model, Qwen, with corrections and testing before release.

What WebForms.php actually is

WebForms Core is a server-driven web technology built on what the project calls a Commander–Executor model: the server emits commands describing UI operations and execution flow, and WebFormsJS, running in the browser, interprets and executes them. The server-side WebForms class never manipulates the DOM directly — it generates the command structure. Because the class mostly produces command strings, its core logic does not need to be redesigned for each language, which is why implementations exist for several languages and why the C# version serves as the primary reference. That reference covers a wide surface: DOM manipulation, event management, Fetch operations, conditions, loops, state management, storage, browser history, WebSockets, SSE, templates, selectors and Action Controls.

A pipeline, not a straight translation

The dev.to post is explicit that the work was not a single C#-to-PHP pass. The chain ran: DeepSeek conversion, manual review, Qwen evaluation, corrections, testing, release. DeepSeek received the C# implementation and related helper classes under deliberately strict instructions: analyze the structure first and explain the conversion approach, preserve the C# behavior, but follow PHP conventions rather than producing code that merely mirrors C# structure. Method names were to become camelCase, so SetWidth turned into setWidth; parameters were to follow PHP style ($inputPlace rather than $InputPlace); and where C# relied on a language feature PHP lacks, the conversion had to use an appropriate PHP equivalent instead of imitating the syntax.

Handling overloading in PHP

Method overloading is called out as a representative problem, since PHP does not support signature-based overloading the way C# does. The approach leaned on PHP's own features: union types such as string|int, with the method deciding internally which behavior applies, and nullable parameters with defaults such as ?int $second = null for optional arguments. A converted setWidth, for instance, appends 'px' when it receives an integer width. The stated goal was matching the observable behavior of the overloaded C# methods while keeping a compact public API, not reproducing their signatures.

Why a human review still ran

The first review after conversion was manual, on the grounds that PHP which parses cleanly is not automatically PHP that behaves the same. The post lists the usual suspects: type conversion, null handling, method overloading, string conversion, arrays, optional parameters, naming conventions and object handling. The stakes are higher here than in a typical library, because the command strings act as the contract between the server-side WebForms class and browser-side WebFormsJS — a small difference in generated output becomes a functional difference.

What Qwen's evaluation caught

Qwen was asked to evaluate rather than rewrite, looking for incompatibilities between the PHP result and the original C# behavior. The post flags two findings as the most important.

The first involved implode(). The C# code joined mixed-type arguments with string.Join, and C# converts values to their string representation when joining. The initial PHP port called implode() directly on the mixed array, which is not equivalent for arbitrary values — PHP's handling of non-string arguments differs, particularly in newer versions. The fix makes the conversion explicit: map every element through strval before imploding.

The second involved null versus empty string in the internal add() method. C#'s StringBuilder.Append() with a null contributes nothing — effectively an empty string — rather than the literal text 'null'. The PHP version initially handled null differently, so methods such as deleteState(?string $path = null) could emit commands that diverged from the C# output. The fix normalizes explicitly, passing $path ?? ''. The post notes that both versions were valid PHP and frames the defect as a matter of cross-language semantics rather than syntax, at which point the syndicated text cuts off mid-sentence.

Why it matters

This release is a small but concrete case study in multi-model development workflows: one model performs the port, a human reviews it, and a competing model audits the result for behavioral drift. The Qwen findings in particular show that swapping each API call for its nearest-looking counterpart does not guarantee identical semantics, and that code which runs cleanly can still break a wire protocol. For WebForms Core, the language-agnostic command design is what made an AI-assisted port viable at all, and the same pattern — generator model, human gate, evaluator model — is likely to recur elsewhere. One caveat: this account comes from the project's own announcement on dev.to, with no independent coverage yet, so the pipeline and its findings are as the project describes them.