WelsonJS: Windows desktop apps built on the built-in ECMAScript engine

What WelsonJS is for, and who it is not for

WelsonJS is a framework for building Windows applications on the ECMAScript engine that already ships with Windows. The README describes it as being for "extreme conditions where conventional solutions may fail", and the system requirements section states Windows XP SP3 or later, with Windows 11 24H2 listed as the current target. That range is the whole point. An app written this way does not bring a browser engine with it, so it can run on a machine where installing Node.js or an Electron bundle is not allowed, not possible, or not worth the disk space.

The audience follows from that. People integrating with legacy Windows systems, people automating Office or a browser from a script, and people who need a small self-contained tool on a managed desktop. The README lists legacy system integration as a use case and the topics include RPA, SCADA, automation and LOLBins, which tells you the maintainer expects the app to touch local system facilities rather than sit in a sandbox.

It is not for anyone shipping one codebase to Windows, macOS and Linux. The runtime is the Windows one, so the portability story ends at the Windows boundary. It is also a poor fit if your code needs modern JavaScript features that the host engine does not implement, because you cannot upgrade the engine independently of the operating system.

How the runtime works: mshta, WSH and the loader files

The mechanism is visible in the repository layout. There is no compiled runtime binary. Instead there are loader scripts, each one an entry point into a different Windows host: app.hta for the HTML Application host (mshta), app.js for the Windows Script Host, webloader.js, uriloader.js, officeloader.js, mcploader.js, bgloader.js and testloader.js. The package.json main field points at app.js, and the start script runs bootstrap.bat.

So the data flow is: Windows launches a host process, the host reads a loader, the loader pulls in the framework from lib/ and the application code, and the app runs inside that host with whatever objects the host exposes. That is why the same project can present itself as a desktop app, a background service, an Office add-in path and an MCP server. The host decides what the script can reach.

The package.json dependencies are telling. core-js, html5shiv, excanvas, modernizr and jQuery are all there to patch or paper over an old engine and its rendering layer. The project also accepts TypeScript, CoffeeScript and ReScript sources, and the top level contains helloworld.ts, helloworld.coffee, helloworld.ls and helloworld.re alongside helloworld.js, which implies a build step that compiles down to something the host engine can execute. The README does not spell out that compilation step in the text available, so treat the toolchain for those languages as something to confirm in the repository before you plan around it.

Installing WelsonJS and running it for the first time

The README gives a one-line PowerShell bootstrap and a launcher download. The bootstrap command is the shortest path and it is quoted verbatim in the README:

irm https://catswords.blob.core.windows.net/welsonjs/bootstrap.ps1 | iex

That fetches bootstrap.ps1 and executes it. The same README also offers a downloadable launcher archive at catswords.blob.core.windows.net/welsonjs/welsonjs_launcher_latest.zip, which is the option to use when the machine cannot reach the network or when you would rather inspect the script before running it.

If you clone the repository instead, the package scripts are the entry points. The start script is bootstrap.bat, and the service scripts are separate:

npm run start
npm run installService
npm run startService

startService maps to sc start WelsonJS.Service, and stopService maps to sc stop WelsonJS.Service. installService runs installService.bat, and uninstallService runs uninstallService.bat. That set of scripts is what turns a script collection into something that survives a reboot, which is the difference between a demo and a deployed tool on a managed desktop.

For a first real use, the repository ships examples/ with runnable scripts such as examples/census.js, examples/certchecker.js, examples/fix_excel_format.js, examples/ipctest.js, examples/rotate_file.js and examples/virustotal.js. The README does not document the command that executes a specific example, so read the loader files (testloader.js is the obvious candidate by name) and the example header before assuming a runner. There is also settings.example.ini at the top level, which is the file to copy and edit for configuration; the README does not list its keys.

The engine you get is the engine Windows gives you

The central constraint is that you do not control the JavaScript engine. On a modern Windows 11 machine the host is current; on the Windows XP SP3 end of the supported range it is not. The dependency list reads like an admission of this: core-js for missing built-ins, html5shiv and excanvas for an HTML layer that predates modern standards, modernizr to detect what is actually present at runtime. Those libraries exist because the same source has to survive on hosts of very different vintages.

That has practical consequences. Feature detection is not optional, it is the normal style of the code. A language feature that works on your development machine can be absent on the deployment target, and the failure appears at runtime on the customer's PC rather than at build time. The README's claim of ECMAScript compatibility is a statement about the engine the host provides, not a promise that the framework normalises everything.

The second limitation is the attack surface question. The topics list includes mshta, mshtml and LOLBins, and mshta is a well-known living-off-the-land binary. Running an application through it is exactly what makes the approach work on locked-down machines, and exactly why security teams may flag it. The README asserts the project is "security-oriented" and mentions controlled execution, but the text available does not describe a sandbox, a signing requirement or a permission model. If your environment has application control rules, verify how the loader is treated before you build a deployment plan around it.

WelsonJS compared with Electron and Node.js

Electron bundles Chromium and Node.js into the application. You get one engine version across every machine, a modern standard library, and identical behaviour on Windows, macOS and Linux. You pay for it in download size, memory and update cadence, and you cannot install it where large unsigned binaries are blocked. WelsonJS inverts every one of those trade-offs: nothing is bundled, the footprint is small, and the behaviour depends on the host.

Node.js is the closer comparison for scripted automation, and the difference is the dependency itself. A Node.js tool needs a Node runtime installed or shipped, and on a locked-down Windows desktop that is often the blocker. WelsonJS runs on what is already there. The price is that you are programming against an older engine and against COM-style host objects rather than npm's ecosystem, even though the project does pull a set of browser-era npm packages into its own tree.

The honest framing: choose Electron when consistency and modern tooling matter more than footprint. Choose Node.js when the target machines can take a runtime and you want the package ecosystem. Choose WelsonJS when the machine is the constraint and Windows is the only target.

Licence and the cost of keeping up

package.json declares the licence as "(GPL-3.0 or MS-RL)", and the README adds a note: the default is GPL 3.0, but if GPL 3.0 is not compatible with Microsoft products, the MS-RL licence applies. There are two licence files in the repository root, LICENSE and LICENSE_MSRL. That dual arrangement is unusual and worth reading carefully with your own counsel, because which one governs your distribution depends on facts about your product that this article cannot evaluate. The GPL path carries source disclosure obligations for distributed software; the MS-RL path is a Microsoft-drafted licence with its own conditions. Do not treat the choice as a formality.

The upgrade cost is a function of the supported range. The release history shows 0.2.7.57 in December 2025, then 0.2.7.60 and 0.2.7.61 in August 2026, so the project has been shipping recently. The last push was on 2026-09-09. That is a live repository, but the version numbers also tell you the project is still on 0.2.x, and the package.json version field (0.2.7.50) trails the newest release tag, which suggests the version string is not always bumped in lockstep with releases. Pin a tag rather than tracking master, and read the release notes before moving, because a framework that targets Windows XP through Windows 11 has a wide surface to regress on.

Editorial conclusion

Adopt WelsonJS when the target is Windows, the machine cannot take a bundled browser runtime, and the app has to keep working on old or restricted hosts; the README states Windows XP SP3 or later, and the package ships loaders for mshta, WSH, Office, URI and MCP entry points. Do not adopt it for cross-platform desktop products or for anything that needs a modern V8 class engine, since the runtime is whatever the host Windows provides. Before committing, verify the licence path you fall under (GPL-3.0 or MS-RL), confirm the exact Windows build you must support, and run bootstrap.bat from a clean checkout to see whether the launcher and the service scripts behave on that machine.

Frequently asked questions

Official sources

1. gnh1201/welsonjs on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases