Why for .js?
If you think about sciencey requirements for a moment, situations pop up where you might want to send a large block of data to the client. With CRUD-style it doesn’t really matter so much what you use. With sciencey stuff it does matter (at least I think it does).
protobuffs balances compactness, serialize and deserialize speeds well.
http://benhakala.blogspot.com/2010/05/converting-google-protocol-buffers-to.html (alludes to google maps possibly using protobufs)
Additional references provided by community (see below for more context):
Google makes heavy use of Protocol Buffers in JS (GMail, etc.) through their Closure Library, generating JS code with a (unfortunately non-open-sourced) modified
protoc (it would probably have to be ported to a
protoc extension before being open-sourced).
Apache Wave (whose client webapp is built with GWT) also uses Protocol Buffers for its communications with the server, generating Java code by reflecting on the Java classes produced by
protoc (this is the PST, aka protobuf-stringtemplate, subproject).
Previously, Wave was using protostuff (and I don’t know why they switched to their own solution, I suspect PST is derived from what the original Google Wave was using, and protostuff was only an intermediate step during the move to open-source).
As a side note, I started exploring using Protocol Buffers on the browser side a while ago: http://blog.ltgt.net/exploring-using-protobuf-in-the-browser/ & http://blog.ltgt.net/using-protobuf-client-side-with-gwt with some almost-working code at http://code.google.com/p/protobuf-gwt/ that you might want to resurrect.
Finally, there’s work underway to make GWT RequestFactory proxies compatible with the server-side Java classes generated by
protoc (and you could use a
protoc extension or a similar approach to Wave’s PST to generate your RequestFactory proxies). It should already be possible, provided you use builders all the way on the server-side (which is not quite how the Protocol Buffers Java API was designed).
I’m a fan of protobuf – and I’d happily see stronger browser-side tooling for it, but json is so ubiquitous that you’d need a compelling reason to challenge the status-quo. Also; think “jsonp”.