Xmas.JS is a lightweight, high-performance JavaScript/TypeScript runtime
Rust
264
1,317 commits
updated Mar 30, 2026
above logo does not represent any religious affiliation , it is simply a stylized representation of "Xmas" as in "ECMAScript".
A Modern System Scripting Runtime for the JavaScript Era
Features • Installation • Quick Start • Benchmarks • Documentation • Contributing
Xmas.JS is a lightweight, high-performance JavaScript/TypeScript runtime designed to replace traditional system scripting languages like Lua, Perl, and Python for system administration, automation, and glue code tasks.
Unlike Node.js, Deno, or Bun which target web applications and server-side development, Xmas.JS is purpose-built for:
Note: The word "Xmas" is pronounced like "ECMAS" (ECMAScript), not a religious reference. "JavaScript" in this context refers to ECMAScript/TypeScript, not Oracle's JavaScript™ trademark.
QuickJS does not use any sort of JIT compilation, making it ideal for fast startup and low memory usage, but less suited for long-running web servers.
Modern JavaScript runtimes like Node.js, Deno, and Bun are excellent for web servers and applications, but they're overkill for scripting:
| Runtime | Cold Start | Memory (Idle) | Best Use Case |
|---|---|---|---|
| Node.js | ~100-200ms | ~30-50MB | Web servers, long-running apps |
| Deno | ~150-300ms | ~40-60MB | Secure web apps, TypeScript projects |
| Bun | ~50-100ms | ~25-35MB | Fast web development |
| Xmas.JS | ~5-15ms | ~3-8MB | System scripts, CLI tools, serverless |
Traditional System Scripts Modern System Scripts with Xmas.JS
┌─────────────────────────┐ ┌─────────────────────────┐
│ Python + libraries │ │ Xmas.JS + TypeScript │
│ Slow startup │ → │ Instant startup │
│ Heavy dependencies │ │ Zero dependencies │
│ Version hell │ │ Single binary │
│ Limited async │ │ Native async/await │
└─────────────────────────┘ └─────────────────────────┘
Performance Targets:
Xmas.JS uses a pluggable virtual system layer called vsys to abstract all system-level operations. This enables:
┌─────────────────────────────────────────────────────────────────┐
│ modules (JS Binding Layer) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────────────┐ │
│ │ fs/mod │ │http/mod │ │module/ │ │Other JS Modules │ │
│ │(ModuleDef│ │(ModuleDef│ │loader │ │(Only registration, │ │
│ │ only) │ │ only) │ │resolver │ │ calls vsys) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └─────────┬──────────┘ │
└───────┼────────────┼────────────┼─────────────────┼─────────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────┐
│ vsys (Virtual System Layer) │
│ ┌─────────────────────────────────────────────────────────────┐│
│ │ pub struct VsysVTable { ││
│ │ // Filesystem ││
│ │ pub fs_read, fs_write, fs_stat, fs_readdir, ... ││
│ │ // Network ││
│ │ pub http_request, dns_lookup, ... ││
│ │ // Module Loading (key for serverless!) ││
│ │ pub module_resolve, module_load, module_exists, ... ││
│ │ // Permissions ││
│ │ pub check_fs_permission, check_net_permission, ... ││
│ │ } ││
│ └─────────────────────────────────────────────────────────────┘│
│ ┌───────────────┴───────────────┐ │
│ ▼ ▼ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Default Impl │ │ User Custom Impl │ │
│ │ (std::fs, tokio, │ OR │ (VFS, sandboxed, │ │
│ │ hyper, etc.) │ │ in-memory, etc.) │ │
│ └─────────────────────┘ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
| Scenario | Problem Without vsys | With vsys |
|---|---|---|
| Serverless/Edge | Runtime has full system access, security risk | Sandboxed execution, only expose what you allow |
| Multi-tenant SaaS | Tenant A can access Tenant B's files | Each tenant gets isolated virtual filesystem |
| Database Scripting | Scripts need real filesystem, deployment complexity | Virtual FS backed by database, zero external deps |
| Bundled Deploy | Need node_modules on disk, slow cold start | Load modules from single bundle or remote URL |
| Testing | Need real network/files, slow and flaky tests | Mock everything, fast and deterministic |
| Embedded/IoT | Heavy system dependencies | Minimal footprint, platform-agnostic |
| Game Scripting | Lua-style sandboxing is complex | Built-in isolation, expose only game APIs |
// User's untrusted code can only:
// - Read from /app/data (virtual, mapped to S3)
// - Make HTTP requests to allowlisted domains
// - Load modules from pre-bundled package (no filesystem access)
// - No filesystem writes, no arbitrary network access
let runtime = XmasRuntime::new()
.with_vsys(VsysVTable::new()
.fs_read_only(s3_virtual_fs("/app/data"))
.module_loader(bundled_modules("app.bundle"))
.net_allowlist(&["api.example.com", "cdn.example.com"])
.deny_all_else()
);
# Coming soon - pre-built binaries for major platforms
# Windows
curl -fsSL https://xmas.js.org/install.ps1 | powershell
# macOS / Linux
curl -fsSL https://xmas.js.org/install.sh | sh
# Run a TypeScript/JavaScript file directly
xmas script.ts
xmas app.js
# Run with verbose output
xmas -v script.ts
# Run in a specific directory
xmas --cwd ./my-project script.ts
# Start the REPL (default when no arguments)
xmas
# Or explicitly
xmas repl
The REPL supports TypeScript, TSX, and JSX syntax with syntax highlighting:
🎄 >> const x: number = 42
🎄 >> console.log(`Hello, ${x}!`)
Hello, 42!
🎄 >> const element = <div>Hello World</div>
Xmas.JS includes a built-in package manager (no need for npm/pnpm/yarn):
# Install dependencies from package.json
xmas install
xmas i # shorthand
# Add a package
xmas add lodash
xmas add -D vitest # add as devDependency
xmas add --pin zod # pin to exact version
# Remove a package
xmas remove lodash
xmas rm lodash # shorthand
# Run a script from package.json
xmas run dev
xmas run build --watch src/
# Update lockfile
xmas update
# Upgrade packages to latest versions
xmas upgrade
xmas upgrade --pin # pin upgraded versions
# Clean node_modules and cache
xmas clean
# Execute a command
xmas exec tsc --version
# Find why a package is installed
xmas why lodash
xmas why lodash 4.17.21
# Create new project from starter kit
xmas create vite
# Download and execute a package (like npx)
xmas x create-react-app my-app
Bundle TypeScript/JavaScript files using Rolldown:
# Basic bundle
xmas bun src/index.ts
# Bundle with options
xmas bun src/index.ts -o build -n app.js
# Bundle with minification and source maps
xmas bun src/index.ts -m -s
# Bundle multiple entry points
xmas bun src/index.ts src/worker.ts
# Bundle with custom format
xmas bun src/index.ts -f cjs # CommonJS
xmas bun src/index.ts -f esm # ES Modules (default)
xmas bun src/index.ts -f iife # Immediately Invoked Function Expression
# Exclude packages from bundle
xmas bun src/index.ts -e react -e react-dom
xmas [OPTIONS] [SCRIPT]... [COMMAND]
Commands:
install (i) Install packages defined in package.json
add (a) Add package to package.json
remove (rm) Remove package from package.json
run Run a script defined in package.json
update Prepare and save a newly planned lockfile
upgrade Update packages to the latest available version
clean Clean node_modules and cache
exec Execute a command (not a script)
why Find all uses of a given package
create Create new project from a starter kit
x Download and execute a package (like npx)
bun (bundle) Bundle TypeScript/JavaScript files
repl Start the interactive REPL
Options:
-v, --verbose Print verbose logs
--cwd <PATH> Run in a custom working directory
-h, --help Print help
-V, --version Print version
Python 3.11: █████████████████████ 45ms
Node.js 20: ███████████████ 120ms
Deno 1.38: ██████████████████ 180ms
Bun 1.0: █████████ 75ms
Xmas.JS: ██ 12ms ⚡
Python 3.11: ████████████████ 15MB
Node.js 20: ████████████████████████████ 45MB
Deno 1.38: ██████████████████████████████ 55MB
Bun 1.0: ████████████████████ 28MB
Xmas.JS: ███ 5MB 🪶
Benchmarks performed on Windows 11, AMD Ryzen 9 5900X, 64GB RAM
See TODO.md for detailed progress.
2025 Q4
2026 Q1
We welcome contributions! Xmas.JS is in active development and needs help with:
See CONTRIBUTING.md for guidelines.
TypeScript/TSX/JSX is transpiled to JavaScript before execution. Xmas.JS uses OXC (a high-performance Rust-based toolchain) to transform TypeScript to JavaScript on-the-fly. This means:
.ts, .tsx, or .jsx files directlytsc --transpileOnly)# Run TypeScript directly - transpilation happens automatically
xmas script.ts
# REPL also supports TypeScript/TSX
🎄 >> const x: number = 42
🎄 >> const element = <div>Hello</div>
For type checking, use your IDE's TypeScript integration or run tsc --noEmit separately.
| Aspect | Xmas.JS | Node.js/Deno/Bun |
|---|---|---|
| Primary Use Case | System scripting, CLI tools, serverless | Web servers, full-stack apps |
| JS Engine | QuickJS (interpreter) | V8/JSC (JIT compiler) |
| Startup Time | ~5-15ms | ~50-200ms |
| Memory Footprint | ~3-8MB | ~25-60MB |
| Long-running Performance | Slower (no JIT) | Faster (JIT optimized) |
| Binary Size | ~5MB | ~50-100MB |
Choose Xmas.JS when: You need fast startup, low memory, or are replacing Python/Bash scripts.
Choose Node.js/Deno/Bun when: You're building web servers or compute-intensive applications.
Yes, with some caveats:
# Use the built-in package manager
xmas install lodash
xmas install zod
We're continuously improving Node.js API compatibility. Check TODO.md for current status.
Not yet. Xmas.JS is in active development (pre-1.0). We recommend:
We're targeting a stable 1.0 release in Q1 2026.
QuickJS was chosen deliberately for our use case:
| Feature | QuickJS | V8 |
|---|---|---|
| Startup time | ~5ms | ~100ms |
| Memory overhead | ~3MB | ~30MB |
| Binary size | ~1MB | ~30MB |
| JIT compilation | ❌ No | ✅ Yes |
| Long-running perf | Slower | Faster |
| Embedding ease | Very easy | Complex |
For short-lived scripts (CLI tools, serverless, automation), the fast startup and low memory of QuickJS outweighs V8's JIT benefits. V8's JIT only helps after the code has run long enough to be optimized.
Planned for Q1 2026. QuickJS has experimental WASM support, and we're working on integrating it with proper WinterTC-compatible APIs.
Yes! Xmas.JS is designed to be embeddable:
use xmas_js_modules::prelude::*;
// Create a runtime
let runtime = AsyncRuntime::new()?;
let context = AsyncContext::full(&runtime).await?;
// Run JavaScript
context.with(|ctx| {
ctx.eval("console.log('Hello from embedded JS!')")?;
Ok(())
}).await?;
See our embedding guide for detailed instructions.
Xmas.JS uses Tokio for async I/O, providing:
async/await support in JavaScriptPromise API compatible with web standards// Async operations work just like in Node.js/Deno
const response = await fetch('https://api.example.com/data');
const data = await response.json();
// Parallel operations
const [file1, file2] = await Promise.all([
fs.promises.readFile('a.txt'),
fs.promises.readFile('b.txt')
]);
WinterTC (Web-interoperable Runtimes Community Group) defines standard APIs for non-browser JavaScript runtimes. Xmas.JS aims to be WinterTC-compatible, meaning:
fetch(), Request, Response APIscrypto.subtle)URL, URLSearchParams, TextEncoder, TextDecoderconsole, setTimeout, setIntervalThis ensures code portability between Xmas.JS, Deno, Cloudflare Workers, and other WinterTC-compatible runtimes.
Xmas.JS is dual-licensed under Apache-2.0 OR GPL-3.0.
This dual-license ensures open collaboration while preventing service provider lock-in.
Xmas.JS stands on the shoulders of giants:
Inspired by:
If you find Xmas.JS useful, please consider giving it a star! ✨
Made with ❤️ by the 🍋 LemonHX & 🎄Xmas.JS team
5,090 followers · starred Dec 2025
8,408 followers · starred Dec 2025
4,774 followers · starred Jul 2026
248 followers · starred Dec 2025
Xmas.JS is a lightweight, high-performance JavaScript/TypeScript runtime
Rust
264
1,317 commits
updated Mar 30, 2026
above logo does not represent any religious affiliation , it is simply a stylized representation of "Xmas" as in "ECMAScript".
A Modern System Scripting Runtime for the JavaScript Era
Features • Installation • Quick Start • Benchmarks • Documentation • Contributing
Xmas.JS is a lightweight, high-performance JavaScript/TypeScript runtime designed to replace traditional system scripting languages like Lua, Perl, and Python for system administration, automation, and glue code tasks.
Unlike Node.js, Deno, or Bun which target web applications and server-side development, Xmas.JS is purpose-built for:
Note: The word "Xmas" is pronounced like "ECMAS" (ECMAScript), not a religious reference. "JavaScript" in this context refers to ECMAScript/TypeScript, not Oracle's JavaScript™ trademark.
QuickJS does not use any sort of JIT compilation, making it ideal for fast startup and low memory usage, but less suited for long-running web servers.
Modern JavaScript runtimes like Node.js, Deno, and Bun are excellent for web servers and applications, but they're overkill for scripting:
| Runtime | Cold Start | Memory (Idle) | Best Use Case |
|---|---|---|---|
| Node.js | ~100-200ms | ~30-50MB | Web servers, long-running apps |
| Deno | ~150-300ms | ~40-60MB | Secure web apps, TypeScript projects |
| Bun | ~50-100ms | ~25-35MB | Fast web development |
| Xmas.JS | ~5-15ms | ~3-8MB | System scripts, CLI tools, serverless |
Traditional System Scripts Modern System Scripts with Xmas.JS
┌─────────────────────────┐ ┌─────────────────────────┐
│ Python + libraries │ │ Xmas.JS + TypeScript │
│ Slow startup │ → │ Instant startup │
│ Heavy dependencies │ │ Zero dependencies │
│ Version hell │ │ Single binary │
│ Limited async │ │ Native async/await │
└─────────────────────────┘ └─────────────────────────┘
Performance Targets:
Xmas.JS uses a pluggable virtual system layer called vsys to abstract all system-level operations. This enables:
┌─────────────────────────────────────────────────────────────────┐
│ modules (JS Binding Layer) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────────────┐ │
│ │ fs/mod │ │http/mod │ │module/ │ │Other JS Modules │ │
│ │(ModuleDef│ │(ModuleDef│ │loader │ │(Only registration, │ │
│ │ only) │ │ only) │ │resolver │ │ calls vsys) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └─────────┬──────────┘ │
└───────┼────────────┼────────────┼─────────────────┼─────────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────┐
│ vsys (Virtual System Layer) │
│ ┌─────────────────────────────────────────────────────────────┐│
│ │ pub struct VsysVTable { ││
│ │ // Filesystem ││
│ │ pub fs_read, fs_write, fs_stat, fs_readdir, ... ││
│ │ // Network ││
│ │ pub http_request, dns_lookup, ... ││
│ │ // Module Loading (key for serverless!) ││
│ │ pub module_resolve, module_load, module_exists, ... ││
│ │ // Permissions ││
│ │ pub check_fs_permission, check_net_permission, ... ││
│ │ } ││
│ └─────────────────────────────────────────────────────────────┘│
│ ┌───────────────┴───────────────┐ │
│ ▼ ▼ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Default Impl │ │ User Custom Impl │ │
│ │ (std::fs, tokio, │ OR │ (VFS, sandboxed, │ │
│ │ hyper, etc.) │ │ in-memory, etc.) │ │
│ └─────────────────────┘ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
| Scenario | Problem Without vsys | With vsys |
|---|---|---|
| Serverless/Edge | Runtime has full system access, security risk | Sandboxed execution, only expose what you allow |
| Multi-tenant SaaS | Tenant A can access Tenant B's files | Each tenant gets isolated virtual filesystem |
| Database Scripting | Scripts need real filesystem, deployment complexity | Virtual FS backed by database, zero external deps |
| Bundled Deploy | Need node_modules on disk, slow cold start | Load modules from single bundle or remote URL |
| Testing | Need real network/files, slow and flaky tests | Mock everything, fast and deterministic |
| Embedded/IoT | Heavy system dependencies | Minimal footprint, platform-agnostic |
| Game Scripting | Lua-style sandboxing is complex | Built-in isolation, expose only game APIs |
// User's untrusted code can only:
// - Read from /app/data (virtual, mapped to S3)
// - Make HTTP requests to allowlisted domains
// - Load modules from pre-bundled package (no filesystem access)
// - No filesystem writes, no arbitrary network access
let runtime = XmasRuntime::new()
.with_vsys(VsysVTable::new()
.fs_read_only(s3_virtual_fs("/app/data"))
.module_loader(bundled_modules("app.bundle"))
.net_allowlist(&["api.example.com", "cdn.example.com"])
.deny_all_else()
);
# Coming soon - pre-built binaries for major platforms
# Windows
curl -fsSL https://xmas.js.org/install.ps1 | powershell
# macOS / Linux
curl -fsSL https://xmas.js.org/install.sh | sh
# Run a TypeScript/JavaScript file directly
xmas script.ts
xmas app.js
# Run with verbose output
xmas -v script.ts
# Run in a specific directory
xmas --cwd ./my-project script.ts
# Start the REPL (default when no arguments)
xmas
# Or explicitly
xmas repl
The REPL supports TypeScript, TSX, and JSX syntax with syntax highlighting:
🎄 >> const x: number = 42
🎄 >> console.log(`Hello, ${x}!`)
Hello, 42!
🎄 >> const element = <div>Hello World</div>
Xmas.JS includes a built-in package manager (no need for npm/pnpm/yarn):
# Install dependencies from package.json
xmas install
xmas i # shorthand
# Add a package
xmas add lodash
xmas add -D vitest # add as devDependency
xmas add --pin zod # pin to exact version
# Remove a package
xmas remove lodash
xmas rm lodash # shorthand
# Run a script from package.json
xmas run dev
xmas run build --watch src/
# Update lockfile
xmas update
# Upgrade packages to latest versions
xmas upgrade
xmas upgrade --pin # pin upgraded versions
# Clean node_modules and cache
xmas clean
# Execute a command
xmas exec tsc --version
# Find why a package is installed
xmas why lodash
xmas why lodash 4.17.21
# Create new project from starter kit
xmas create vite
# Download and execute a package (like npx)
xmas x create-react-app my-app
Bundle TypeScript/JavaScript files using Rolldown:
# Basic bundle
xmas bun src/index.ts
# Bundle with options
xmas bun src/index.ts -o build -n app.js
# Bundle with minification and source maps
xmas bun src/index.ts -m -s
# Bundle multiple entry points
xmas bun src/index.ts src/worker.ts
# Bundle with custom format
xmas bun src/index.ts -f cjs # CommonJS
xmas bun src/index.ts -f esm # ES Modules (default)
xmas bun src/index.ts -f iife # Immediately Invoked Function Expression
# Exclude packages from bundle
xmas bun src/index.ts -e react -e react-dom
xmas [OPTIONS] [SCRIPT]... [COMMAND]
Commands:
install (i) Install packages defined in package.json
add (a) Add package to package.json
remove (rm) Remove package from package.json
run Run a script defined in package.json
update Prepare and save a newly planned lockfile
upgrade Update packages to the latest available version
clean Clean node_modules and cache
exec Execute a command (not a script)
why Find all uses of a given package
create Create new project from a starter kit
x Download and execute a package (like npx)
bun (bundle) Bundle TypeScript/JavaScript files
repl Start the interactive REPL
Options:
-v, --verbose Print verbose logs
--cwd <PATH> Run in a custom working directory
-h, --help Print help
-V, --version Print version
Python 3.11: █████████████████████ 45ms
Node.js 20: ███████████████ 120ms
Deno 1.38: ██████████████████ 180ms
Bun 1.0: █████████ 75ms
Xmas.JS: ██ 12ms ⚡
Python 3.11: ████████████████ 15MB
Node.js 20: ████████████████████████████ 45MB
Deno 1.38: ██████████████████████████████ 55MB
Bun 1.0: ████████████████████ 28MB
Xmas.JS: ███ 5MB 🪶
Benchmarks performed on Windows 11, AMD Ryzen 9 5900X, 64GB RAM
See TODO.md for detailed progress.
2025 Q4
2026 Q1
We welcome contributions! Xmas.JS is in active development and needs help with:
See CONTRIBUTING.md for guidelines.
TypeScript/TSX/JSX is transpiled to JavaScript before execution. Xmas.JS uses OXC (a high-performance Rust-based toolchain) to transform TypeScript to JavaScript on-the-fly. This means:
.ts, .tsx, or .jsx files directlytsc --transpileOnly)# Run TypeScript directly - transpilation happens automatically
xmas script.ts
# REPL also supports TypeScript/TSX
🎄 >> const x: number = 42
🎄 >> const element = <div>Hello</div>
For type checking, use your IDE's TypeScript integration or run tsc --noEmit separately.
| Aspect | Xmas.JS | Node.js/Deno/Bun |
|---|---|---|
| Primary Use Case | System scripting, CLI tools, serverless | Web servers, full-stack apps |
| JS Engine | QuickJS (interpreter) | V8/JSC (JIT compiler) |
| Startup Time | ~5-15ms | ~50-200ms |
| Memory Footprint | ~3-8MB | ~25-60MB |
| Long-running Performance | Slower (no JIT) | Faster (JIT optimized) |
| Binary Size | ~5MB | ~50-100MB |
Choose Xmas.JS when: You need fast startup, low memory, or are replacing Python/Bash scripts.
Choose Node.js/Deno/Bun when: You're building web servers or compute-intensive applications.
Yes, with some caveats:
# Use the built-in package manager
xmas install lodash
xmas install zod
We're continuously improving Node.js API compatibility. Check TODO.md for current status.
Not yet. Xmas.JS is in active development (pre-1.0). We recommend:
We're targeting a stable 1.0 release in Q1 2026.
QuickJS was chosen deliberately for our use case:
| Feature | QuickJS | V8 |
|---|---|---|
| Startup time | ~5ms | ~100ms |
| Memory overhead | ~3MB | ~30MB |
| Binary size | ~1MB | ~30MB |
| JIT compilation | ❌ No | ✅ Yes |
| Long-running perf | Slower | Faster |
| Embedding ease | Very easy | Complex |
For short-lived scripts (CLI tools, serverless, automation), the fast startup and low memory of QuickJS outweighs V8's JIT benefits. V8's JIT only helps after the code has run long enough to be optimized.
Planned for Q1 2026. QuickJS has experimental WASM support, and we're working on integrating it with proper WinterTC-compatible APIs.
Yes! Xmas.JS is designed to be embeddable:
use xmas_js_modules::prelude::*;
// Create a runtime
let runtime = AsyncRuntime::new()?;
let context = AsyncContext::full(&runtime).await?;
// Run JavaScript
context.with(|ctx| {
ctx.eval("console.log('Hello from embedded JS!')")?;
Ok(())
}).await?;
See our embedding guide for detailed instructions.
Xmas.JS uses Tokio for async I/O, providing:
async/await support in JavaScriptPromise API compatible with web standards// Async operations work just like in Node.js/Deno
const response = await fetch('https://api.example.com/data');
const data = await response.json();
// Parallel operations
const [file1, file2] = await Promise.all([
fs.promises.readFile('a.txt'),
fs.promises.readFile('b.txt')
]);
WinterTC (Web-interoperable Runtimes Community Group) defines standard APIs for non-browser JavaScript runtimes. Xmas.JS aims to be WinterTC-compatible, meaning:
fetch(), Request, Response APIscrypto.subtle)URL, URLSearchParams, TextEncoder, TextDecoderconsole, setTimeout, setIntervalThis ensures code portability between Xmas.JS, Deno, Cloudflare Workers, and other WinterTC-compatible runtimes.
Xmas.JS is dual-licensed under Apache-2.0 OR GPL-3.0.
This dual-license ensures open collaboration while preventing service provider lock-in.
Xmas.JS stands on the shoulders of giants:
Inspired by:
If you find Xmas.JS useful, please consider giving it a star! ✨
Made with ❤️ by the 🍋 LemonHX & 🎄Xmas.JS team
5,090 followers · starred Dec 2025
8,408 followers · starred Dec 2025
4,774 followers · starred Jul 2026
248 followers · starred Dec 2025