LilScript makes JavaScript libraries smaller
Details
- External ID
- 49374554
- Source
- HN
- Company
- —
- Product
- —
- Website domain
- —
- Launched
- Aug. 20, 2026
- Cohort
- —
- Upvotes
- 14
- Upvotes percentile
- 0.6834677419354839
- Tags
- —
- Fetched at
- Sept. 10, 2026, 5:32 a.m.
- Updated at
- Sept. 10, 2026, 5:32 a.m.
Description
https://yeargun.github.io/lilscript/LilScript is a typed, compression-first language that compiles into js and sometimes into exec(will be more stable in future). The compiler mangles, reshapes the program into optimized js that happens to be 5-15% smaller (after gzip/br compression or raw) compared to the best performing JS toolchains like oxc/esbuild/terser/..## What has been proven to work with LilScript?- makes VSCode's core js modules 20% smaller on average- makes the world's most performant & small markdown rendering npm library, marked, 5-7% smaller and 10% faster- and many more demos.. works with pretty much any js/ts library## How it is compressing js finer than vite/oxc/terser/esbuild/..### 1. By changing the app.``` class Vector { float x; float y; init(float x, float y) { this.x = x; this.y = y; } float lengthSquared() { return this.x * this.x + this.y * this.y; } }int[] values = [1, 2, 3, 4]; auto doubled = values.map((int value) => value * 2); int sum = 0; for (int i = 0; i < doubled.length; i++) { sum += doubled[i]; } Vector vector = new Vector(3.0, 4.0); if (vector.lengthSquared() == 25.0) { print(`sum=${sum}`); } ```Above code compiles into this:``` var b=[1,2,3,4].map(a=>a2|0);var a=0,c=0;while(a<b.length){ c=c+b[a]|0; a=a+1|0; }console.log(`sum=${c}`)```This is not minification of the same program. The compiler changed the app.oxc / esbuild / terser / .. starts from JS and mostly keeps the shape of the app. Meanwhile LilScript the language is designed from scratch to give compiler any extra knowledge that could help the compiler's compilation. Just like Google Closure Compiler - Advanced Mode, and beyond.### 2. Tryhard property mangling.Visit the world's most used web applications, chatgpt.com, and read the source codes. You will see that, there are lots of framework related js properties that dont get minified, and are indeed human readable.Those names stay in the bundle because the toolchain cannot prove they are local. A property might be a public API, a DOM field, a framework hook, or something a plugin reads by string. So the minifier leaves it.LilScript:- *a-* does both eliminates the objects, weird code structures into more optimized variables/arrays - *b-* rename any variable into mostly occured, short versions, field cleverly to minimize entropy (based on the objective compression algorith. gzip/brotli) so that the end result is highly compressed.*(a)* is the same move as the `Vector` example, at library scale: objects and classes that only exist as a programming convenience get flattened into scalars, arrays, and tight loops.*(b)* is not "make every name 1 letter." gzip and brotli win when the same short tokens repeat. The compiler picks the names that show up the most, and scores the spelling against the compression algorithm you asked for (gzip, brotli, or raw). Different `cost_model` → different names → a different file that is smaller after* that codec.That is why the same program can be 5-15% smaller after gzip/br compression or raw: the JS is shaped and named for the compressor, not just for a human reading the AST.Feel free to PR, experiment (Please respect the modified MIT license)LLM models can oneshot implement your library with LilScript. For non optimized libraries, it could end up 20%+ size reduction and somewhat performance improvements (which usualy matters very little)Please share your opinions, would love to discuss about the future direction for the language and the compiler
Enrichment
- Theme
- niche developer utilities and toolchains
- Vertical
- Horizontal
- Function
- Dev tools
- Audience
- Developer
- AI stance
- Not AI
- Project type
- Commercial product
- Normalized one-liner
- make javascript libraries smaller
- Manually corrected
- False
Could you build this?
No Developing a custom typed programming language and optimizing compiler that achieves superior compression through novel AST mangling and reshaping requires deep expertise in compiler theory and program analysis.
What it would actually take: Built with compiler toolchains (lexing, parsing, AST generation, semantic analysis) targeting JavaScript as an intermediate/output language. The primary challenge is designing safe code-rewriting and minification passes (dead code elimination, property renaming, scope hoisting, dynamic exec-packing) that outperform existing production-grade optimizers like Terser and esbuild without introducing semantic runtime errors.
Discussion
2 comments analyzed.
Concerns raised: GitHub link not easily findable
Competitors
Other products that read as similar to this one — 95 launches clear the similarity bar, closest 8 shown.
Attention rank: #44 of 96 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 288 days after the earliest competitor.
- GrainJS · hn · 2025-12-26 · 5 upvotes · similarity 0.45
- TinyPDF · hn · 2025-12-18 · 253 upvotes · similarity 0.42
- Nectar, a Rust-like React that compiles to WebAssembly · hn · 2026-07-06 · 29 upvotes · similarity 0.40
- zep.js · ph · 2026-09-21 · 4 upvotes · similarity 0.39
- Titan · hn · 2025-12-11 · 49 upvotes · similarity 0.39
- LemmaScript, a verification toolchain for TypeScript via Dafny · hn · 2026-04-21 · 5 upvotes · similarity 0.39
- Tabulate-Export · ph · 2026-09-06 · 2 upvotes · similarity 0.38
- Typical is TypeScript with type-safety at runtime · hn · 2026-01-11 · 8 upvotes · similarity 0.38
Other launches for this product
- No other launches for this product.
Same idea, different domain
Nobody's really built a dev tools tool for Sales yet.