Yes, you emulate them with 32-bit numbers. It is a huge performance bottleneck if you do it naively, which most compile-to-JS languages that support 64-bit integers do. Emscripten even has a flag to let you choose between correct-but-slow 64-bit integers and fast-but-incorrect (drops to 53 bits).

It is possible to get fast longs in JS, though, if you push your optimizer far enough. This is what we have done in Scala.js. I wrote a paper about this, but it is still under submission so I cannot disclose it just yet. However, I can point to the implementation:

* The user-land implementation of `Long`s in Scala.js: https://github.com/scala-js/scala-js/blob/master/library/src...

* The PR that made the performance breakthrough in the optimizer, by stack-allocating all instances of `RuntimeLong`: https://github.com/scala-js/scala-js/pull/2488

I just had to look this up, the limitation is that JS has a max int of 2^53?

Do you know what the reasons were for JS not implementing full 2^64?

Also I noticed theres a JS C-types that has 64 bit ints, would that not help here?

All numbers in Javascript are IEEE 754 64-bit double precision floating point numbers. The significand precision is 53 bits (see here https://en.wikipedia.org/wiki/Double-precision_floating-poin...).

Thanks for the clarifications.

Re ctypes, I assume you are talking about https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes. On that page you can read:

> js-ctypes is only available from chrome code; that is, ctypes is not available to websites, only application and extension code.

Basically `js-ctypes` won't work in an actual browser. So you cannot use it. There are other Node.js-specific native packages that give a representation for 64-bit integers, but not arithmetic operations. Besides, even if they had arithmetic operations, they would be heap-allocated, and since the JIT cannot understand them, it would not be able to optimize them as well as what we built for Scala.js.