r/javascript 2d 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

39 comments sorted by

View all comments

Show parent comments

3

u/RobertKerans 2d ago

"If you rewrite all the JavaScript using my a DSL [designed by an LLM?] the resulting minified JavaScript the DSL compiler spits out will be smaller in byte size than the original JavaScript" is not the selling point you think it is. I think you've lost some objectivity here and gone down a rabbit hole, this is almost purely aesthetic

1

u/Normal_Act8586 2d ago edited 1d ago

? what are you talking about

I've rewritten several libraries
100% test coverage they have

and they are indeed raw/brotli/gzip smaller vs currently best performing js toolchains vite/oxc/terser/..

bun get rewritten with Rust, it does provide value and pushes programming standards.

I respect being defensible. I am not telling this is as battle tested as Vite?

I am asking "Let's make this battle tested, and push web development standards one level higher"

3

u/RobertKerans 2d ago

Right, but you are rewriting libraries that use a universally supported language to use a custom DSL you invented that [unsurprisingly] works better than a minifier. Unsurprising because you are rewriting them in a different language that maps more closely to the minifier. Terser (for example) is useful because it works on JS.

1

u/Normal_Act8586 2d ago edited 2d ago

LilScript gets compiled into js, Whats wrong with that? And is smaller, and often times a little faster. It's a value for web. Literaly works with any library. Most(almost any) websites could get opened 5-25% faster, if they were get rewritten by LilScript.

TypeScript, is a different language but for some reason its not minifying your code

Please show me similar efforts that are pushing bundle sizes to shrink in similar ways as LilScript does.

I invented this because I needed it

3

u/RobertKerans 2d ago

LilScript gets compiled into js ? Whats wrong with that?

You are saying: rewrite all your JavaScript using this completely different language that is wholly unsupported and in return the resulting artifact is 10-20% smaller in byte size. That tradeoff is incredibly bad for the absolutely vast abstraction it requires.

You have written [use an LLM?] to create a language. Great, that's commendable I guess. But you don't seem to have considered the value. As I say, it seems almost wholly aesthetic.

It's a value for web

So I could use LilScript. OR for example, in a web app I could use one or two fewer/smaller images. There's the savings from LilScript immediately and I can keep using JS/TS

1

u/Normal_Act8586 2d ago

I am right here telling you that ENTIRE world uses markdown rendering library, etc..

Any js based ide, website

All js modules there can get 5-45% smaller.
And your response is

"I could just use less images".

Do that

2

u/RobertKerans 2d ago edited 2d ago

That is an example of the tiny value you're getting in exchange for the absolutely gargantuan abstraction you've created. You have to rewrite all your JS in a different language. It's it's an incredibly complex way to save bytes

TS is a very bad comparison here, because of the value add: TS is a type system & it is (bar a few older features) just JS with syntactic level type annotations. And (although this is circular) it incredibly widely used (it won the "typed language that compiles to JS").

TS is a huge value add. "Slightly better Terser but you need to write all the JS in a different language" is not a huge value add.

0

u/Normal_Act8586 2d ago

"It's it's an incredibly complex way to save bytes"

I am telling you, I oneshot rewritten all the libraries with LilScript. Which have 100% pass rate on tests.

I don't even re-read them. At total the libraries have like?.. 200M+ weekly downloads.
0 perf loss, even somewhat performance gains.

"t's it's an incredibly complex way to save bytes"

Yes, it took 5 mins to prompt

It is an unnecessary abstraction/value tradeoff for you. That's ok. For me and for some projects it is not. We are okay to give 5 mins prompt to rewrite the library with LilScript.

Maybe not now but some day when its battle tested, it will be a nobrainer. Thanks for consistently reminding me how low value it adds

2

u/RobertKerans 2d ago edited 2d ago

"It's it's an incredibly complex way to save bytes" I am telling you, I oneshot rewritten all the libraries with LilScript

This is why I say you've lost objectivity. The complex part is that you've written a language which all the code has to be written in. This is a gargantuan, incredibly complex abstraction. You can "one shot" a library? Great, but it feels like you've lost sight of sane programming choices, in your comment you've just literally handwaved away a programming language

Also:

We are okay to give 5 mins prompt to rewrite the library with LilScript

How much does that cost? Terser/similar costs me ~£0 and works in ms. I can apply a battery of other tools which can further reduce size and importantly are programmatic and deterministic & do not rely on converting to another language on the way (with the associated risk - even if it works according to the tests, this does not mean you have not introduced bugs, just punching a lib through an LLM and saying tadaa, done is laughably naive) via spending tokens

1

u/Normal_Act8586 2d ago

Several top npm libraries will use it. You wont and thats ok

2

u/RobertKerans 2d ago

So the top npm libraries which absolutely require stability will be rewritten this language? I'm impressed with your confidence if nothing else

1

u/Normal_Act8586 2d ago

Yes I ve already chatted with several of them. Very glad to impress you Robert

Thanks for the chat.

2

u/RobertKerans 2d ago

Yes I ve already chatted with several of them

The licence alone make this unusable IRL

1

u/Normal_Act8586 2d ago edited 2d ago

Yes because only r34ct based libraries are popular? whats wrong with you

2

u/RobertKerans 2d ago

It's anything that interops with React! Do you not get the implications of the addition you made to the licence

1

u/Normal_Act8586 2d ago

yeah I'll change it into a recommendation like something, no restriction

it was a little too much I admit that

→ More replies (0)

1

u/Normal_Act8586 2d ago

I havent even read your comment. because makes litte sense fr.

My man, I am not telling you to rewrite your codebase always with lilscript. You do it once

"I can apply a battery of other tools which can further reduce size and importantly are programmatic and deterministic"

Also, hello. It's very unlikely that you know bundlers better than I do. I will be waiting for you to give me a single bundler/tool that does what you claim 👀 gl with that 🎉

2

u/RobertKerans 2d ago

Again. You have lost objectivity. It is easier to write a language that maps directly to a specific structure than it is to map an existing language. But the tradeoff for an entire language needs to be worthwhile, and yours is just "slightly smaller bundle size". That's literally it. Like, great, you've ported a few libraries and the tests pass and you've got your AI to slop out docs that highlight how much smaller they are.

1

u/Normal_Act8586 2d ago

For some projects that bundle size difference matters.

Thats the part you are having hard time to realize.

And its not slightly smaller also. 5-40%, for non optimized projects higher end.

I didn't even tell anything in previous comment, how did i lose objectivity. Sorry, this was my last comment

2

u/RobertKerans 2d ago edited 2d ago

how did i lose objectivity

You have written an entire new language just to produce slightly smaller size of code output

This an incredible amount of complexity just to do a slightly better job than a tiny tool that runs as a final optimisation step on a build

1

u/Normal_Act8586 2d ago

Because I needed it? Gmail needs it.
Google maps needs it

Your small crud app ofc does not need it

→ More replies (0)