Being clear about the lack of msgpack support

[terhechte]

It took me some time to figure out that transit-js does not support the transit msgpack encoding. I finally found that info by doing the tour. It would be nice if the transit-js would immediately list on the frontpage / in the readme which transit encodings are supported without the necessity to go hunting for this information in other documents.

[puredanger]

Thanks, that seems quite reasonable. I'll let David decide exactly where that info should go in the readme.

[swannodette]

I've added a note about this to the first paragraph in the README.

[skrat]

Nice, this was first thing I was looking for when I came from @swannodette's article about transit-cljs. Is there any issue with implementing msgpack unmarshaller or is it just pile of work to be done?

[swannodette]

@skrat it is a bit of work but more importantly there's little use in pursuing the msgpack unmarshaller until there's evidence there's a performance advantage to doing so.

[skrat]

There is a big one when you transfer big typed numerical arrays for use with WebGL. We use msgpack for that as it provides much smaller downloads and much faster unmarshalling into JS ArrayBuffer. Same goes for complex structures that contain both numerical arrays and textures. This we can transfer complete 3d model in a single binary blob with much better download and parse times compared to JSON + separate requests for texture files. This is not your typical "tweet list" or "address book" use case but still ;)

[swannodette]

@skrat I definitely understand the use case. We will likely deliver MessagePack encoding support but it's not a high priority at the moment. I've added an issue for it here #6.