Backend-Frontend Converter: Component-Based Conversion of .NET Computational Models to TypeScript

Petr Ivankov; Max Shestov

cs.CLOct 17, 2026

Backend-Frontend Converter: Component-Based Conversion of .NET Computational Models to TypeScript

Authors: Petr Ivankov, Max Shestov

Organizations: Independent researcher · Georgia Institute of Technology

Abstract

Computational models developed in .NET often need to run locally within web applications. We present Backend--Frontend Converter, an architecture for generating TypeScript implementations of component-based models. The converter maps components, connections, aliases, and formula trees to model-specific TypeScript code. Reusable runtime libraries provide numerical integration, data access, and state handling. We evaluate stored generated implementations through four orbital scenarios and a recorded trading-strategy comparison. Orbital calculations execute in a browser and are paired with C# results by crossing event and timestamp; trading outputs are aligned by date. Analytic scheduler tests and deliberately perturbed outputs assess the validation procedure. Each orbital scenario produces 91 paired events with identical timestamps. Position and velocity differences remain below $(10^{-6}\)~km$ and $(10^{-9}\)~km/s$ . All 20 analytic scheduler checks pass, and the comparator detects each of three prescribed state and time perturbations. The trading comparison contains 501 aligned daily records with matching indicator values, positions, and order events. The evaluated implementations preserve the compared outputs across the C#/TypeScript boundary. Component-specific generation and reusable execution libraries provide a practical route from supported .NET computational models to TypeScript applications.

Figures & tables

Model role	Source-side requirement	Target-side TypeScript requirement	Validation check
Component	Explicit runtime component	TypeScript component class or interface	Presence and behavior
Alias	Stable semantic name	Same alias in TypeScript	State initialization and output access
Measurement	Typed value access	Measurement map or interface	Value comparison
Processor	Known execution semantics	TypeScript processor implementation	Trajectory or sequence comparison
Domain plugin	Known domain behavior	TypeScript plugin implementation	Domain scenario tests
Data consumer	Output collection role	TypeScript consumer	Output alignment

Table 1: Migration contract for executable computational models. The contract defines which source-side model roles must have target-side TypeScript counterparts and how each role is checked during migration.

Fig. 1: Component-based mapping used by Backend–Frontend Converter. The computational model is represented through explicit runtime structures and realized either by the .NET/C# execution path or by the TypeScript runtime used in the orbital forecasting implementation

Source-side concept	Target-side/web concept	Role in migration
.NET/C# computational model	TypeScript model/runtime classes	Supplies the browser execution realization checked against reference outputs
OrbitalForecastCalculator	OrbitalForecast	Generated model components, formulas, configuration, and connections
C# Performer	OrbitalForecastCalculation	Developer-supplied execution wrappers
Motion-equation aliases such as x , y , z , u , v , w	TypeScript alias values with the same semantic roles	Transfers initial state and exposes calculated variables
Data consumer / chart object	TypeScript data consumer object	Collects calculated values during execution
Measurements	TypeScript measurement interfaces and maps	Preserve typed access to model variables

Table 2: Traceability between source-side and target-side architectural concepts

Fig. 2: Orbital forecasting workflow used in the case study. The same forecast setup is executed through the C# server reference path and the browser-side TypeScript realization; the resulting trajectory points are then used for visualization and reference-based comparison

Notation	Role
$x,y,z$	Cartesian position aliases in the shared coordinate frame
$u,v,w$	Cartesian velocity aliases in the same frame
$\mathbf{p}_{i}$	Position vector with components x , y , and z at trajectory point $i$
$\mathbf{v}_{i}$	Velocity vector with components u , v , and w at trajectory point $i$
$C\#$ , $TS$	Superscripts denoting the server-side C# and client-side TypeScript execution paths

Table 3: State-variable notation for the orbital forecasting case study

Run	$x$	$y$	$z$	$v_{x}$	$v_{y}$	$v_{z}$
1	-5448.34815324	-4463.93698421	0	-0.985394777432	1.21681893834	7.45047785592
2	-5458.34815324	-4463.93698421	0	-0.985394777432	1.21681893834	7.45047785592
3	-5458.34815324	-4453.93698421	0	-0.985394777432	1.21681893834	7.45047785592
4	-5458.34815324	-4453.93698421	0	-0.985394777432	1.21681893834	7.45057785592
Start (UTC): 2026-06-24T03:45:06.449; end (UTC): 2026-06-30T09:18:30.449.

Table 4: Initial conditions supplied to both implementations in the four orbital scenarios. Position is in km and velocity in km/s. Scenarios 2–4 change the initial position or vertical velocity.

Run	Events	Max. pos. diff.	Mean pos. diff.	Max. vel. diff.	Mean vel. diff.
1	91	$4.10\times 10^{-7}$	$1.60\times 10^{-7}$	$4.42\times 10^{-10}$	$1.72\times 10^{-10}$
2	91	$3.97\times 10^{-7}$	$9.00\times 10^{-8}$	$4.28\times 10^{-10}$	$9.70\times 10^{-11}$
3	91	$3.94\times 10^{-7}$	$1.52\times 10^{-7}$	$4.25\times 10^{-10}$	$1.64\times 10^{-10}$
4	91	$1.41\times 10^{-7}$	$4.05\times 10^{-8}$	$1.52\times 10^{-10}$	$4.38\times 10^{-11}$

Table 5: C#/browser TypeScript comparison for the four orbital scenarios. Paired event timestamps agree exactly. Position and velocity residuals are Euclidean norms in km and km/s

Fig. 3: Position and velocity residuals against crossing-event index for the four scenarios. Dashed lines show the 1 mm and 1

\mu

m/s tolerances; paired timestamps agree exactly

Fig. 4: Simplified component structure of the trading strategy case study. Historical trading data is processed by average and Donchian Channel filters; formula and recursive-position components compute Sell Buy.Formula_3, which is used by the order component to generate trading actions

Measure	C#	TypeScript	Difference
Input scenario
Symbol	AAPL	AAPL	–
Bar interval	1 day	1 day	–
Historical interval	2022-01-01 to 2024-01-01 (end exclusive)		–
Aligned daily records	501	501	0
Short / long moving-average windows	10 / 40	10 / 40	–

Table 6: Behavioral validation results for the trading strategy case. The C# and TypeScript realizations use the same daily AAPL input and are aligned by trading date

Code Translation

Code translation converts programs between languages, frameworks, and representations while aiming to preserve behavior and sometimes improve safety or performance.

See all 40 papers

WaveTLM: Reliable Time-Series Language Modeling through Task Compilation
Sep 16, 2026Jiahui Chen, Bingke Zhu, Hongyu Pan +1LLM Reliability Time-Series Foundation Models
Institute of Automation, Chinese Academy of Sciences Beijing, China
T2J-BENCH: Benchmarking Coding Agents on Execution-Grounded PyTorch-to-JAX Repository Migration
May 27, 2026Tao Feng, Jiefeng Chen, Linxin Song +9Code Generation Evaluation Code Generation Benchmarks
Google Cloud AI Research · University of Southern California · University of Notre Dame +1
Implementation of tangent linear and adjoint models for neural networks based on a compiler library tool
Mar 17, 2026Sa Xiao, Hao Jing, Honglu Sun +1Weather Forecasting Data Assimilation
State Key Laboratory of Severe Weather Meteorological Science and Technology (LaSW), Beijing, China · CMA Earth System Modeling and Prediction Centre (CEMC), Beijing, China

Sep 16, 2026J/K move · Enter open · S save

WaveTLM: Reliable Time-Series Language Modeling through Task Compilation

Jiahui Chen, Bingke Zhu, Hongyu Pan, Yingying Chen

Institute of Automation, Chinese Academy of Sciences Beijing, China

LLM Reliability Time-Series Foundation Models Time Series Language Modeling

Open paper AskPDF arXiv

Time-series language models provide a shared natural-language interface across temporal tasks, but plausible text does not guarantee reliable task outputs. Responses may appear reasonable while hallucinating the required object: numerical sequences can violate shape, scale, channel order, or temporal alignment, and textual decisions can fall outside the legal label space. We formulate reliable time-series language modeling, separating task-object reliability from predictive quality. We introduce ExecTS-QA, a contract-grounded benchmark spanning forecasting, imputation, classification, anomaly detection, and waveform analysis. We further propose WaveTLM, a unified compiler-executor model whose task compiler transforms user requests, visible arguments, and wave-grounded evidence into typed task states, while task-native executors construct numerical tensors, legal decisions, or structured records. On ExecTS-QA, a single WaveTLM checkpoint achieves 99.40% contract-valid coverage, compared with 37.83% for the strongest evaluated string-first baseline, while retaining balanced predictive performance across all five task families. Evaluations on SciTS, TSQA, IRTS-ToolBench, and ARFBench provide additional evidence of transfer. The code, construction scripts, and ExecTS-QA dataset will be publicly released upon publication. These results show that task compilation can convert plausible language generation into reliable time-series outputs.

Abstract

Code Translation

Explore similar work

WaveTLM: Reliable Time-Series Language Modeling through Task Compilation

T2J-BENCH: Benchmarking Coding Agents on Execution-Grounded PyTorch-to-JAX Repository Migration

Implementation of tangent linear and adjoint models for neural networks based on a compiler library tool