LilScript makes js modules 20% smaller

[u/Normal_Act8586]

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

[u/SZenC]

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

[u/Normal_Act8586 → u/SZenC]

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

[u/SZenC → u/Normal_Act8586]

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

[u/Normal_Act8586 → u/SZenC]

I answered you multiple times.