5 ms·

We're talking about JavaScript in the browser though... what other message format is more readily and performantly processed in-browser using JavaScript than JS

by EB66 7y ago

We're talking about JavaScript in the browser though... what other message format is more readily and performantly processed in-browser using JavaScript than JSON?

manfredo 7y ago
Infrastructure for protobufs is pretty effective. It is parsed in browser, but several implementations show better performance than JSON decoding. A unified set of libraries (or rather, code generators) to encode and decode in various languages is a plus, too. Both my current and last company used protobufs to encode API request data, as well as for things like config loading.
est31 7y ago
Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines, you could make the case for usage of binary formats like protobuf. IMO this trend of piling on technology after technology to handle bloat instead of designing websites to be lean is wrong but it's certainly the direction we are walking into. Websites will become even more opaque and complex. Definitely not looking forward to it.
- AgentOrange1234 7y ago
  I don’t think this is a one-or-the-other situation. “Bloat” is a problem on, say, news sites with horrible ads and it’d be great if they kept it lean. Obviously they don’t need webassembly and binary formats. But... there are also incredibly powerful tools (google maps and docs, quake in the browser, streaming services, etc) that push the boundaries, which these kinds of tech will enhance, or make possible in the first place.
- ssalka 7y ago
  >Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines Any idea what the timeline for such changes could be? Personally I'd welcome the possibility of compiling complex web apps down to WASM, but I can't see the things you mention happening any time soon
  - nojvek 7y ago
    You don’t need webassembly. We already have typed arrays to represent binary data and do fast slices. That’s essentially what flatbuffers is. Slightly larger than protobuf but insanely fast to parse since it doesn’t need to scan the whole file. It’s both memory and CPU efficient. Netflix uses it in their app because TVs can be low powered devices. That’s why Netflix feels so much lighter than amazon, hbo or Hulu. They all freeze my Vizio TV but Netflix is smooth. https://github.com/google/flatbuffers https://github.com/google/flatbuffers
- austincheney 7y ago
  The browser DOM wouldn’t change simply because you are accessing it from a different language. I really get the impression that people who advocate web assembly as JavaScript replacement do so out of some ignorance of JavaScript and almost complete ignorance of the DOM.
- rolltiide 7y ago
  I'd like to see protobuf take off, but we're talking 2025, 2028?
  - nojvek 7y ago
    https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/ Is what you want in the browser.
- alimbada 7y ago
  > Websites will become even more opaque and complex. Definitely not looking forward to it. Why is that an issue? Do websites need to be open source? How many people, including software developers, will actually view the source for a 3rd party website and/or try to debug it? Beyond screen-scraping and learning purposes I don't see a use case for it. I'd be quite happy with my browser(s) downloading and executing binary blobs if it means better usage of my devices' resources and bandwidth.
dvt 7y ago
Protobuf.js, gRPC, etc, etc, etc. It's not like you can't send arbitrary binary data over HTTP or WS.
- tantalor 7y ago
  For typical cases JavaScript protos (jspb) should use JSON wire format. You would only use binary wire format depending on whether your message type is suited to it, e.g., lots of internal byte arrays.
  - mumblemumble 7y ago
    Lots of repetitive data with a relatively flat structure can be a good argument to get away from JSON, too. Let's set aside binary formats for a moment. I once sped up populating a large-ish table of data by an order of magnitude - and achieved a pretty decent reduction in data volume, too - just by switching the format to CSV.
    - tantalor 7y ago
      Is CSV so different than JSON? Before: ["my", "data", 1, 2, 3] After: my,data,1,2,3 I'm surprised it is 10x faster.
mumblemumble 7y ago
I'm not necessarily assuming JavaScript in the browser; we could just as easily be talking back-end services written in Node. That said, I'm going to also submit that, if you're shoving big enough messages at a fast enough clip that you feel motivated to be this worried about deserialization speed in the browser, you've also got bigger fish to fry. Either way you cut it, it's at least worth stopping to think about whether you're being penny wise and pound foolish.
anderspitman 7y ago
Flatbuffers?

by EB66 7y ago

We're talking about JavaScript in the browser though... what other message format is more readily and performantly processed in-browser using JavaScript than JSON?

manfredo 7y ago

Infrastructure for protobufs is pretty effective. It is parsed in browser, but several implementations show better performance than JSON decoding. A unified set of libraries (or rather, code generators) to encode and decode in various languages is a plus, too. Both my current and last company used protobufs to encode API request data, as well as for things like config loading.

est31 7y ago

Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines, you could make the case for usage of binary formats like protobuf. IMO this trend of piling on technology after technology to handle bloat instead of designing websites to be lean is wrong but it's certainly the direction we are walking into. Websites will become even more opaque and complex. Definitely not looking forward to it.

AgentOrange1234 7y ago
I don’t think this is a one-or-the-other situation. “Bloat” is a problem on, say, news sites with horrible ads and it’d be great if they kept it lean. Obviously they don’t need webassembly and binary formats. But... there are also incredibly powerful tools (google maps and docs, quake in the browser, streaming services, etc) that push the boundaries, which these kinds of tech will enhance, or make possible in the first place.
ssalka 7y ago
>Once WebAssembly gains APIs to change the DOM quickly and the big JS frameworks switch to WebAssembly for their internal engines Any idea what the timeline for such changes could be? Personally I'd welcome the possibility of compiling complex web apps down to WASM, but I can't see the things you mention happening any time soon
- nojvek 7y ago
  You don’t need webassembly. We already have typed arrays to represent binary data and do fast slices. That’s essentially what flatbuffers is. Slightly larger than protobuf but insanely fast to parse since it doesn’t need to scan the whole file. It’s both memory and CPU efficient. Netflix uses it in their app because TVs can be low powered devices. That’s why Netflix feels so much lighter than amazon, hbo or Hulu. They all freeze my Vizio TV but Netflix is smooth. https://github.com/google/flatbuffers https://github.com/google/flatbuffers
austincheney 7y ago
The browser DOM wouldn’t change simply because you are accessing it from a different language. I really get the impression that people who advocate web assembly as JavaScript replacement do so out of some ignorance of JavaScript and almost complete ignorance of the DOM.
rolltiide 7y ago
I'd like to see protobuf take off, but we're talking 2025, 2028?
- nojvek 7y ago
  https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/ Is what you want in the browser.
alimbada 7y ago
> Websites will become even more opaque and complex. Definitely not looking forward to it. Why is that an issue? Do websites need to be open source? How many people, including software developers, will actually view the source for a 3rd party website and/or try to debug it? Beyond screen-scraping and learning purposes I don't see a use case for it. I'd be quite happy with my browser(s) downloading and executing binary blobs if it means better usage of my devices' resources and bandwidth.

dvt 7y ago

Protobuf.js, gRPC, etc, etc, etc. It's not like you can't send arbitrary binary data over HTTP or WS.

tantalor 7y ago
For typical cases JavaScript protos (jspb) should use JSON wire format. You would only use binary wire format depending on whether your message type is suited to it, e.g., lots of internal byte arrays.
- mumblemumble 7y ago
  Lots of repetitive data with a relatively flat structure can be a good argument to get away from JSON, too. Let's set aside binary formats for a moment. I once sped up populating a large-ish table of data by an order of magnitude - and achieved a pretty decent reduction in data volume, too - just by switching the format to CSV.
  - tantalor 7y ago
    Is CSV so different than JSON? Before: ["my", "data", 1, 2, 3] After: my,data,1,2,3 I'm surprised it is 10x faster.

mumblemumble 7y ago

I'm not necessarily assuming JavaScript in the browser; we could just as easily be talking back-end services written in Node. That said, I'm going to also submit that, if you're shoving big enough messages at a fast enough clip that you feel motivated to be this worried about deserialization speed in the browser, you've also got bigger fish to fry. Either way you cut it, it's at least worth stopping to think about whether you're being penny wise and pound foolish.

anderspitman 7y ago

Flatbuffers?