Is there a way to do protocol buffers in JavaScript?
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).
tradeoffs:
protobuffs balances compactness, serialize and deserialize speeds well.
text based protocols (xml / json) have a larger message size... but with javascript I wonder which is more effective.
reference:
code.google.com/p/protobuf-plugin-closure
Google Protocol Buffers or something similar for .net/javascript
https://github.com/sirikata/protojs
Google Protocol Buffers - JavaScript
http://www.vitaliykulikov.com/2011/02/gwt-friendly-protocol-buffers.html
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):
https://github.com/dcodeIO/ProtoBuf.js
http://blog.ltgt.net/exploring-using-protobuf-in-the-browser/
http://blog.ltgt.net/using-protobuf-client-side-with-gwt
http://code.google.com/p/protobuf-gwt/
The official protobuf project support only Java, C++, and Python. Not Javascript.
In particular, it was designed to be smaller and faster than XML. Protocol Buffers are widely used at Google for storing and interchanging all kinds of structured information. The method serves as a basis for a custom remote procedure call (RPC) system that is used for nearly all inter-machine communication at Google.
JSON is usually easier to debug (the serialized format is human-readable) and easier to work with (no need to define message types, compile them, install additional libraries, etc.). Protobuf, on the other hand, usually compresses data better and has built-in protocol documentation via the schema.
Protocol buffers are a combination of the definition language (created in . proto files), the code that the proto compiler generates to interface with data, language-specific runtime libraries, and the serialization format for data that is written to a file (or sent across a network connection).
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).
Historically javascript made working with binary a pain, which probably in part explains a relative lack of tooling - but with javascript typed arrays it could well be a lot easier now. I kinda agree that if you have to get the same volume of data (via some format), using less bandwidth is a plus - but before embarking on anything you'd need to check that bandwidth / processing was an actual bottleneck (and if bandwidth: have you tried gzip/deflate first).
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".
I have been looking for protobuf for javascript. There is a project here: https://github.com/dcodeIO/ProtoBuf.js
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With