3 ms·

it's significant because code has to be additionally parsed and JIT-compiled. which is not true of images which simply blit pixels to screen as they decompress;

it's significant because code has to be additionally parsed and JIT-compiled. which is not true of images which simply blit pixels to screen as they decompress; it's not simply about size on the wire. https://twitter.com/HenriHelvetica/status/877924754195324928 https://twitter.com/HenriHelvetica/status/877924754195324928

albedoa 9y ago
Even in parse time, a 23kb difference would be barely if at all noticeable on the worst performant devices. That chart is for 1MB of JavaScript, and I assume the x-axis is in milliseconds.
- leeoniya 9y ago
  true. i guess the point of the comment was that you can't compare loading an image to loading & executing a script by filesize.
coldtea 9y ago
>it's significant because code has to be additionally parsed and JIT-compiled. Which again be insignificant compared to the time it takes to download those assets from a cellular connection. Not to mention that today's (and 2015's) mobile CPUs aren't that slow, they are comparable to mid-level laptops from 2010 or even later. If you're catering to the developed world, visitors wise, you'll be ok with 30K.
localvoid 9y ago
But many libraries that has a primary focus on library size are usually sacrificing runtime performance to reduce size. Yes, they've reduced parse time, but significantly increased bootstrap time. I understand that they are doing it because of marketing reasons, because many people think that smaller means faster.
- kbr 9y ago
  Didn't see this earlier. Moon is actually pretty fast during runtime, and I haven't used many hacks to get it to be so small. Check out the source.
  - localvoid 9y ago
    I haven't talked about Moon, don't know too much about it. Just wanted to say that small size doesn't always mean that it will have low TTI. And Moon is small because it doesn't have features that are necessary to build complex apps. For example, keyed updates :)
    - kbr 9y ago
      Haha, like I said earlier, keyed updates will definitely be implemented in v1.

albedoa 9y ago

Even in parse time, a 23kb difference would be barely if at all noticeable on the worst performant devices. That chart is for 1MB of JavaScript, and I assume the x-axis is in milliseconds.

leeoniya 9y ago
true. i guess the point of the comment was that you can't compare loading an image to loading & executing a script by filesize.

coldtea 9y ago

>it's significant because code has to be additionally parsed and JIT-compiled. Which again be insignificant compared to the time it takes to download those assets from a cellular connection. Not to mention that today's (and 2015's) mobile CPUs aren't that slow, they are comparable to mid-level laptops from 2010 or even later. If you're catering to the developed world, visitors wise, you'll be ok with 30K.

localvoid 9y ago

But many libraries that has a primary focus on library size are usually sacrificing runtime performance to reduce size. Yes, they've reduced parse time, but significantly increased bootstrap time. I understand that they are doing it because of marketing reasons, because many people think that smaller means faster.

kbr 9y ago
Didn't see this earlier. Moon is actually pretty fast during runtime, and I haven't used many hacks to get it to be so small. Check out the source.
- localvoid 9y ago
  I haven't talked about Moon, don't know too much about it. Just wanted to say that small size doesn't always mean that it will have low TTI. And Moon is small because it doesn't have features that are necessary to build complex apps. For example, keyed updates :)
  - kbr 9y ago
    Haha, like I said earlier, keyed updates will definitely be implemented in v1.