Why is JS faster than Ruby at JSON serialisation/deserialisation? The algorithm and data structures seem exactly the same in the two languages to me. In fact Ruby should be faster as it has simpler arrays without things like holes.

I guess that, since JSON is Javascript Object Notation, it should be faster for Javascript to serialize/deserialize it, but it might be just a psychological bug of mine. Anyway, my main point wants to be the fact that JSON serialization/deserialization seems an area of improvement on API web apps. As a Rails developer it requires a lot of effort to deal with that part of the application performance. Just providing a list of 50 db records with 10 attributes each, with some transformations (let's say that e.g. 4 attributes are virtual and some keys are renamed), add an important overhead to the response.

Most interpreted languages have a C library that handles JSON serialization and deserialization.

Yes, but are they as fastest as possible?

Take Ruby. One of the most common improvements you do as Rails developer to a Rails web app is adding `oj` gem, which replaces the default JSON ser/deser with a more performant one. But it doesn't come by default with Rails. Can you guess how many Rails web apps performing JSON ser/deser don't use it? I'd be curious about that.

Moreover, it's really hard to find a presenter library oriented to performance. There are wonderful DSLs, but none of them seems optimized to speed, IMHO.

JS VMs are generally better engineered than Ruby VMs due to more investment, including better JSON handling code yeah. But that’s nothing to do with JSON being (almost) a subset of JavaScript. Unless you can think of a concrete reason why?

> JS VMs are generally better engineered than Ruby VMs due to more investment

Is that still true? Shopify is investing a whole lot (u don't need me to tell u of course). Yes I know Google/Firefox etc had teams working on JS but did they invest that much more than Shopify?

Yes, both in terms of money and dev-hours, I wouldn’t be surprised if Google put 2 orders of magnitude more resources into V8.

Nonetheless, Shopify’s investment into truffleruby may well be worth it, as it builds on top of the many many work-hours that went into the JVM.

Nono, I agree with you, I think I was wrong above, as I wrote above it was probably just a psychological bug. But I still think there's much room of improvement with the tools we already have.

Because json means javascript object notation a.k.a js does not need to de/serialized its own native format.

> js does not need to de/serialized its own native format

This doesn’t make any sense. JSON is a string. Converting a Ruby array or hash to or from a string is exactly the same work as converting a JS array or object to or from a string.

Individual implementations may be better in JS, but there’s no inherent reason for that.

JSON is a text format that looks like a JavaScript Object when it (the object) is in text form. It has nothing to do with its memory layout. It's just a name.

The actual object in memory has to be serialized/deserialized to/from JSON.

ECMA-404 (the standard for JSON) allows values that cannot be possible represented in JavaScript - integers and float bigger than 53 bits; At the same time, it forbids totally legal JavaScript's NaN and Infinity.

JavaScript is faster and JSON because any modern JS VM is a lot faster than Ruby VM. If JSON didn't require serialization/serialization, it would be inherently unsafe at any speed.

: There are ways to handle exchange without serialization and serialization safely, but you're suggesting is that memory that holds json text is just cast to json object.

Are you taking JSON API submissions and just running them through eval()? If so, where's your API?