r/javascript 10d ago

LilScript makes js modules 20% smaller

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-40% 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
  • https://yeargun.github.io/solidlil/
  • https://yeargun.github.io/monacolil/
  • https://yeargun.github.io/markedlil/ (Some numbers on the websites aren't fair comparisons, especially for SolidLil. Highly optimized JS libraries see fewer benefits(Still, the app code/logic, gets pretty great optimizations). LilScript is designed to be at least as efficient as the best-performing JS/TS toolchains.)

How it is compressing js finer than vite/oxc/terser/esbuild/..

1. By changing the app.


  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 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 shipped js 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.

How well do LLMs write LilScript?

Since 1.5 years ago, you haven’t been writing the code yourself anyway. So why worry about what language the agent writes in? I myself have pretty much rewritten 6–7 of the most popular npm libraries from scratch in LilScript in just 1.5 days-while actually designing the language itself.

Feel free to PR, experiment (Please respect the modified MIT license)

Please share your opinions, would love to discuss about the future direction for the language and the compiler

0 Upvotes

48 comments sorted by

View all comments

10

u/SZenC 10d ago

The licensing conditions alone are enough reason to never use this package/language. You don't get to tell me what other libraries I can and cannot use, that's plainly ridiculous. (And I won't get into how your license is self-contradictory, how using niche languages with LLMs will yield inferior results, or the many other flaws with this idea)

0

u/Normal_Act8586 7d ago edited 7d ago

Hmm, the license has been updated, by the way. The React-related parts have also been removed.

I’d genuinely love to hear what you think the flaws of the LilScript idea are.

I do want to emphasize one thing, though: in 2026, LLMs are pretty much capable of writing LilScript without any major issues. It’s almost JavaScript anyway. Sure, inferior results can happen, and people obviously need to test their software before rewriting it in LilScript.

Also, look at Bun being rewritten in Rust. I don’t think “you broke everything, therefore this is definitely the wrong direction” is a very defensible argument on its own. Rewriting software in a different language can absolutely be the right decision when there are compelling technical reasons for doing so.

LilScript is proven to optimize several npm libraries with 50M+ weekly downloads. With almost one shot rewritten with LilScript, 100% test coverage, 5-45% size reduction vs currently best performing js ts toolchains (Viteoxc/terser/esbuld/..)

2

u/SZenC 7d ago

Let me just pick out one part here

LilScript is proven to optimize several npm libraries with 50M+ weekly downloads. With almost one shot rewritten with LilScript, 100% test coverage, 5-45% size reduction [...]

It is hardly surprising that you can express a library in another language given appropriate bindings. Any Turing complete language can be transpired into any other TC language with the same bindings. The LLM has just invented yet another such language for you.

Now, if you'd just built a new transpiler that achieved better compression of identical source code, I might have been interested. But instead you built a custom DSL, did not explore how expressive/restrictive it is compared to plain JavaScript, and then built a transpiler and proclaimed victory. I'm happy you managed to build something you like, but it has no value to the wider world. You set up a soccer field in the middle of nowhere, didn't tell your opponents, and now act surprised we call your 45-to-0 match a bit underwhelming

0

u/Normal_Act8586 7d ago edited 7d ago

Now, if you'd just built a new transpiler that achieved better compression of identical source code, I might have been interested.

But man, it already does not change the algorithms. You tell llms to rewrite the js/ts code with LilScript (without changing algorithms or anything).

And it gets compiled into smaller js compared to original js/ts, mangling on/off, raw/gzip/brotli.

It has different compilation modes for raw/gzip/brotli
Different focuses on compilation, "size-first", "balanced", "performance" (for web apps size first is almost always the right option)

And while considering whether LilScript is an unnecessary thing or not, its not fair only to consider rewriting things with LilScript. Also consider, writing with LilScript from scratch. LLMs write normal code. use objects, arrays, ...

They get compiled into both smaller, and often times a little faster primitives.

I can never understand the perspective and defensiveness over this ?. I am telling you. I never told llm not to "rewrite the code so it becomes smaller".

Rather, I told them to rewrite with LilScript, dont change algorithms, 100% test coverage.

You see, in Go, C, Rust. Structs are arrays in memory.
Why web shouldnt have this for instance ? In lilscript, objects are either converted into let/const/var or arrays. Which happens to be sometimes faster, almost always raw/gzip/brotli smaller.

And just like this, much more syntax and tricks LilScript has and will have even more in future. To give compilers more room for optimization.

You percieve it like a
'woow a language, a compiler. AST... '

I am telling you
'use LilScript, your js becomes smaller IN PRACTICE, right now, almost always.'

I am not telling that oxc/vite/esbuild were failing to do their jobs. They were just not as tryhard as LilScript is in terms of making bundles tiny.

Disagree? You can not disagree.

Plus it is cross compilable, not works always obviously.
With correct language design, extra syntaxes, it could become a pretty solid cross compilable language.

Designed from scratch. And I need help for this for sure

1

u/SZenC 7d ago

That's a lot of words, non of which address the issue I raised. If you cannoteaningfully respond to criticism, I don't see why I and others should keep engaging with your project

0

u/Normal_Act8586 7d ago edited 7d ago

? I never claimed I compress the same AST. I am not building a drop-in Oxc/Terser for identical JavaScript.

What I measured is: same public API, same tests, rewrite in LilScript, compile to JS, compare to the official library through Vite/Oxc/Terser. The rewrite is part of the method. The language is stricter than JS on purpose (struct vs Record vs extern, no any, objects can dissolve). That extra information is why the compiler can emit a different, usually smaller program. It is closer to Closure Advanced than to “Terser but tryharder.”

You are keep telling:

"You changed the code, thats why this is fake"

I am telling you:

"You give prompt to llms, they write ts/js and lilscript version of the same thing. Then js/ts get build with the currently best performing js toolchain/bundler. LilScript also get compiled. LilScript is smaller and is often times a little faster."

Since entire world use LLMs to write code, tada. its less js. Which is a valuable thing for web ecosystem and indeed is a 'proclaimed victory' by your words

0

u/Normal_Act8586 6d ago

I answered you multiple times.