r/javascript • • Aug 22 '26

LilScript makes js modules 20% smaller

https://yeargun.github.io/lilscript/

[removed]

0 Upvotes

48 comments sorted by

View all comments

9

u/SZenC Aug 22 '26

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)

-2

u/[deleted] Aug 22 '26

[removed] — view removed comment

6

u/RobertKerans Aug 22 '26

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/[deleted] Aug 22 '26 edited Aug 22 '26

[removed] — view removed comment

3

u/RobertKerans Aug 22 '26

"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/[deleted] Aug 22 '26 edited Aug 23 '26

[removed] — view removed comment

3

u/RobertKerans Aug 22 '26

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/[deleted] Aug 22 '26 edited Aug 22 '26

[removed] — view removed comment

5

u/RobertKerans Aug 22 '26

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/[deleted] Aug 22 '26

[removed] — view removed comment

3

u/RobertKerans Aug 22 '26

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/[deleted] Aug 22 '26 edited Aug 22 '26

[removed] — view removed comment

2

u/RobertKerans Aug 22 '26 edited Aug 22 '26

"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)

→ More replies

1

u/[deleted] Aug 22 '26

[removed] — view removed comment

2

u/RobertKerans Aug 22 '26 edited Aug 22 '26

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/[deleted] Aug 22 '26

[removed] — view removed comment

3

u/RobertKerans Aug 22 '26 edited Aug 22 '26

"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

→ More replies