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. User-level extensibility of Transit read and write operations combined with Transit specification level support for maps with non-scalar keys means users can reliably 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 lookup, update, and iteration. For many operations transit-js maps and sets are more than an order of magnitude faster than the alternaives. In some cases transit-js maps and sets approach or surpass the performance of pending native implementations. In addition the lookup semantics of transit-js 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 almost doubles the payload.