4 ms·

I think that one underrated point about web apps performance is JSON serialization for non-JS languages. JavaScript is obviously fast with that, but non-JS lang

I think that one underrated point about web apps performance is JSON serialization for non-JS languages. JavaScript is obviously fast with that, but non-JS languages exposing API, like Rails in a separated FE/BE architecture, spend much time transforming data into JSON, and it doesn't seem stressed enough to me.

chrisseaton 4y ago
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.
- izietto 4y ago
  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.
  - onlyrealcuzzo 4y ago
    Most interpreted languages have a C library that handles JSON serialization and deserialization.
    - izietto 4y ago
      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.
      - chrisseaton 4y ago
        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?
        izietto 4y ago
        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.
        weatherlite 4y ago
        > 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?
        kaba0 4y ago
        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.
- gostsamo 4y ago
  Because json means javascript object notation a.k.a js does not need to de/serialized its own native format.
  - chrisseaton 4y ago
    > 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.
  - cestith 4y ago
    Are you taking JSON API submissions and just running them through eval()? If so, where's your API?
  - 0x457 4y ago
    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.

chrisseaton 4y ago

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.

izietto 4y ago
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.
- onlyrealcuzzo 4y ago
  Most interpreted languages have a C library that handles JSON serialization and deserialization.
  - izietto 4y ago
    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.
    - chrisseaton 4y ago
      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?
      - izietto 4y ago
        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.
      - weatherlite 4y ago
        > 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?
        kaba0 4y ago
        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.
gostsamo 4y ago
Because json means javascript object notation a.k.a js does not need to de/serialized its own native format.
- chrisseaton 4y ago
  > 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.
- cestith 4y ago
  Are you taking JSON API submissions and just running them through eval()? If so, where's your API?
- 0x457 4y ago
  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.