FAQ

What JavaScript environments does transit-js support?

transit-js supports any ECMAScript-262 Edition 3 or later implementation provided it supplies a JSON module with parse and stringify methods. This covers most web browsers released in the last 14 years. transit-js also works just fine in environments like Rhino and Nashorn on the JDK. If you encounter issues in a ESCMAScript-262 Edition 3 compliant implementation please open an issue.

Why return ES6 compliant Maps instead of plain JavaScript Objects?

Many popular programming languages can represent richer forms of data than JSON can encode. This forces client and server applications to develop ad-hoc practices in order to coordinate on even basic common scalar values like 64bit integers and dates. 64bit integers are common as ids and transit can naturally treat them as map keys. The story is quite similar for dates. Combined with specification level support for composite maps, returning ES6 maps means that users can reliable index values in the most natural way for the domain at hand.

Why not use an existing ES6 Map/Set shim?

Existing shims perform poorly for update, lookup, and iteration. For many operations transit maps and sets are more than an order of magnitude faster than the alternates. In many cases transit maps and sets approach the performance of pending native implementations. In addition the lookup semantics of transit maps and sets are based on values not reference which subsumes the proposed specifications and greatly generalizes their applicability.

Why Google Closure Compiler instead of Uglify for code compression?

Code written for the Google Closure Compiler benefits from far more aggressive compression than is currently possible with Uglify. transit-js is currently 8.9k gzipped, using Uglify to compress the final source doubles the payload.