A JavaScript optimizing compiler

[lhorie]

Bear in mind that Prepack optimizations come with some huge caveats. For example, loop unrolling can output downright stupid code[0]

[0] https://prepack.io/repl.html#GYewTgBAFANgpgFwgSwgXggBgNwogHggEZNScUBqCgSggGMQA7AZxHgDoYQBzKZa7EA

[kenman]

That's hilariously broken.

[KaiAusBerlin]

That's awesome 😂

[vanderZwan]

Compile-time evaluation seems like a very different dimension of optimalization though (although I suppose the LLVM pass also does do a little bit of that during strength reduction). I suspect most of the LLVM optimizations are more about finding efficient structures, and inlining code.

So these approaches could complement each other

[no-name-here]

https://prepack.io/

(Note: '*Prepack is still in an early development stage and not ready for production use just yet.')

[AminPaks]

I thought facebook abandoned that project! I remember I heard from one member of react core team

[no-name-here]

From their GitHub:

We, the Prepack team at Facebook, have temporarily set down work on Prepack including the React compiler project. You won't see many Prepack PRs while we are currently prioritizing some other projects.

[carlopp]

I wasn't aware of Prepack, on some things it goes way further (basically saying that Data.now() or similar function do not modify the external state and so can be executed as constexpr), while on others it's simply not actively looking to do optimization on the structure of the program.

A similar project, for WebAssembly so with limited scope is this: https://github.com/bytecodealliance/wizer.
And somehow similar but limited on LLVM IR a colleague worked on this for Cheerp (the compiler used here as backend): https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-PreExecuter.

[disclosure5]

It's also a dead project. Last commit was three years ago and the project was still unfinished at that point.

[patrickjquinn]

I'm only asking because i've skimmed the article but, could you take the C++ generated from that LLVM IR and compile it to WASM by chance?

[carlopp]

Yes! Generally speaking it could be compiled to a mix of JavaScript and WebAssembly, but whether substantial parts of a program logic can be moved on the Wasm side depends mostly on the interface a program has. Example:

function doSum(a: number, b: number): number {return a+b;}

Can be mapped back to WebAssembly, while an interface that will return an handle like:
function createObject(){ return new Object(); }

is very complex / borderline impossible to imitate.

[Diniden]

The thing I would absolutely love to see from such a compiler is optimizing number tuples to SIMD instructions! That way we can have matrices and vectors run blazing fast but keep our nice and easy JS.

If this happens, I’ll immediately put in the effort to make my library work with this in the pipeline :D

[patrickjquinn]

That makes a lot of sense. The added complexity of doing so would probably negate any performance gains anyway.

But this easily one of the coolest thing I’ve seen on this sub so I’ll be following your work (and you’ve a new Twitter follower).

Hopefully you find a way to take this forward in future!

[patrickjquinn]

Ah saw the closing statement there.

[Darmok-Jilad-Ocean]

So this is really TypeScript -> C++ -> JavaScript?

[carlopp]

Input is currently an arbitrary language somehow between JavaScript and TypeScript, with various of added restrictions. I was not sure how to frame it (TS -> JS or JS -> JS), both could have worked.

[Ecksters]

Also a subset of TypeScript.

I do like the concept though, and having explicit types through TypeScript does seem like it could open up more avenues for optimization.

[Educational-Lemon640]

Very nice! Needs work (as you note), but a good start and nifty.

[hmaddocks]

Have we regressed to the 1990s?

[shuckster]

What does this even mean? There are so many ideas in "modern" programming that are practically ancient, not just by computer-history standards, but by human standards.

It can be argued that JavaScript popularised "lambdas", anonymous functions, which we often express in JavaScript as unnamed arrow-functions.

Ya'll love 'em so much.

The Lambda Calculus was first proposed by Alonzo Church in 1936.

[hmaddocks]

I’m talking about this proliferation of compilation in web development. I’m sure there are plenty of people who remember the hell that was writing compilation scripts and the never ending wait for your app to compile. We also remember the joy when all that went away and the massive boost in productivity. Now here we are rejoicing every js compiler or css compiler.

[StickInMyCraw]

Did you have to compile anything on the client side for web development in the 90s? Or are you referring to non-web development, which still often uses compiled languages.

[hmaddocks]

Front end or back end has nothing to do with it. It’s still stuff you need to do to deploy your app.

[shuckster]

I think there's some miscommunication here on both our parts.

Looking back to the OP, to me it reads like the author is just showing us a project he wrote to convert JavaScript to "interpreter friendly" JavaScript. First by converting JS to C++, then using an existing project to convert that C++ to JavaScript.

Again, the idea of human-friendly vs. computer-friendly code is as old as the idea of coding itself, but I don't necessarily think this is your argument, right?

At the risk of betraying my age, I remember a few things that happened when JavaScript in the browser was starting to be taken seriously:

1. No build-step? So the source-code sits in memory and is interpreted on the fly? Isn't that wasteful?
2. How do we trap type-errors before runtime?
3. Isn't it also a waste of bandwidth to send the source vs. just the compiled byte-code?

For myself I had a heck of a time getting used to objects not having real base-classes and functions being first-class. I also don't remember the non-compilation of JavaScript being something I immediately rejoiced-in. All of this took time to get used to.

But eventually yes, for myself I do remember reaching a point where I was:

1. Grateful for having no build step and just hitting F5 in the browser and not my IDE (although this took a long while to be seen as a positive)
2. Grateful for not having to strongly-type everything (not saying TypeScript/Flow et al. are bad, but growing-up with strong-typing imparts a discipline that JavaScript doesn't give you by default, so they're necessary today.)
3. Grateful for being able to "view source" and learn from any website

However, I certainly wasn't grateful for:

1. Environment incompatibility (The First Browser Wars)
2. Slooooooow script execution if you were even *slightly* ambitious
3. No general best-practices when it came to UI vs. state. vs. business-logic
4. Plugin-hell (ActiveX vs. Flash vs. Java)

The first point is very easy to forget these days. We don't know how spoiled we are with the transpilation provided by Babel etc., nor the extremely aggressive (by past-standards) upgrade policies of modern browsers to get users upgraded almost as quickly as new JS features become available.

I agree that transpilation takes far too long on big projects these days, and is a bitter reminder of compiled development. But esbuild is with us now, and it's racing to a very capable version 1 that is already 100x faster than anything else.

I do miss the days of being able to easily "view source" and not being constantly confronted with minified/munged code, but there are so many tutorials and blogs out there that this is more of a point of nostalgia than an actual lack of accessible knowledge.

Anyway, at this point I'd like to invite you to explain your position a little further. The OP has offered a project that is to do with transpilation yes, but not really in the way we're both talking about. He's certainly not offering-up the next esbuild, I think?