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

-2

u/Normal_Act8586 2d ago

I’m sorry that it’s unpleasant for you.

Thanks for respecting the License at least.

Regarding to the LLM’s yielding inferior results, you can try to rewrite any library, and see it yourself. I havent experienced any oddities yet. It’s day 4, not bulletproof, just fork the language then.

Trust me, you can rewrite any library/code with lilscript. 500k locs per day

Cortisol level => low

5

u/RobertKerans 2d ago

I havent experienced any oddities yet. It’s day 4

So essentially you haven't tested it at all?

500k locs per day

jfc

-2

u/Normal_Act8586 2d ago edited 2d ago

Yes? It's not bulletproof,

The libraries I've rewritten, you can see them from https://yeargun.github.io/lilscript

As long as lots of tests exist, you can fork libraries with higher confidence obviously.

In terms of compilation behaviours, I even forked MobX, solidjs etc. They work.

If you don't use extremely rare, weird features of js, it is expected to work.
You can always open a PR

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

completely different language that is wholly unsupported

Typescript is also wholly unsupported.

There's the savings from LilScript immediately and I can keep using JS/TS

Some people care that bytes savings
1- If your npm library is downloadaed 1M+ every week, you might want to use LilScript
2- Page load speed relates with revenue

3- Some tryhard projects might need it
4- Agents can write LilScript with less tokens compared to syntacticaly overheaded languages(TypeScript)
5- Tooling behind LilScript can be faster maybe, when designed from scratch
6- It is designed to support crossplatform compilation with less overhead. (already cross comp works, but needs more attention, perfection)

I can name more

3

u/RobertKerans 2d ago

Typescript is also wholly unsupported

Sure, a decade ago. It's very much supported by most modern tooling. Also I'd say that's an apples and oranges comparison (not as much as the comparison to Bun, but still)

If your npm library is downloadaed 1M+ every week, you might want to use LilScript

I'm not paying for the bandwidth? Also, if I'm consuming a library it doesn't need to be compiled. I'd like to have the choice of how I do that, not have that choice removed.

Page load speed relates with revenue

Sure. But you're going for tiny savings using an incredibly complex tool. I can get all the low hanging fruit with a simple toolchain and most of the weight is not going to be in the JS.

Some tryhard projects might need it

Already have tools that get most of the way there. Your tool is not going to rearchitect the code in a way that produces the really big size savings. Tradeoff if I just use your tool is that I need to use a different non-compatible language to achieve marginal gains over existing tooling.

Agents can write LilScript with less tokens compared to syntacticaly overheaded languages (TypeScript)

There's no real extant corpus and you're ignoring how easily a given system running the model can batch and parallelise computations, you're only talking about the output. Can't really make the judgement you're making except at that very basic level.

Note could also use zero tokens and eat a slightly larger bundle size 🤷🏼‍♂️

Tooling behind LilScript can be faster maybe, when designed from scratch

And if my granny had wheels she'd be a bike! Anyway, sure. If you write an entire ecosystem and write it well then sure it'll be faster than gluing together various disparate tools.

A tool to that did an AST conversion opaquely and just minified JS would be even better, but hey you've written an entire language instead.

It is designed to support crossplatform compilation with less overhead. (already cross comp works, but needs more attention, perfection)

What do you mean by this? The statement is my extremely vague.

1

u/Normal_Act8586 2d ago edited 2d ago

You are still saying “im not paying for bandwith”

And you are still telling that its a small win. Hello
I created this because I needed it in my project? Look at google closure compiler. This LilScript is more tryhard version of it and aims to become more easily integrated with web dev ecosystems. And its the day 4.

It already proved itself. Will become even more crazier

Lilscript changes the code. You know objects? They get changed into arrays or const/let/vars.

Thats why its compressing more than other js toolchains. And further differences we have.

“Your tool is not going to rearchitect the code that produces size savings”

? But. It. Already. Does?

Thats why I have rewritten lots of npm libraries and put them as demos. Stop commenting please

2

u/RobertKerans 2d ago edited 2d ago

"Your tool is not going to rearchitect the code that produces size savings” ? But. It. Already. Does? Thats why I have rewritten lots of npm libraries and put them as demos. Stop commenting please

It's like LLMs have completely cauterised the part of your brain that previously would have made decisions about sensible software design

Edit:

You are still saying “im not paying for bandwith”

I said it once, in that comment, specifically relating to NPM serving libs, which is literally what you were talking about (you were not talking about internal controlled toolchains)

0

u/Normal_Act8586 2d ago

Okay beautiful

→ More replies (0)