4 ms·

It's 7kb minified and gzipped. Vue is almost 30kb. If you use a runtime version of Moon, it becomes 3kb. This makes it faster to load on mobile devices. Along

by kbr 9y ago

It's 7kb minified and gzipped. Vue is almost 30kb. If you use a runtime version of Moon, it becomes 3kb. This makes it faster to load on mobile devices. Along with that, it also has lots of official plugins similar to what Vue provides.

coldtea 9y ago
>This makes it faster to load on mobile devices. That's not very significant, since even your favicon will be of comparable or even bigger size, much less any static asset like an image.
- leeoniya 9y ago
  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.
continuations 9y ago
Does it support native mobile development? To me that's an important issue. Vue has Weex. React has React Native. Angular has NativeScript. I'd need something similar to switch to a new frontend framework.
- xigency 9y ago
  Why? Are you making a website or creating an app.
  - wolco 9y ago
    The answer to that question is always: yes.
valuearb 9y ago
If it has plugins, how many do you need to match key Vue features and how long do they take to load?
- kbr 9y ago
  Each plugin is about 2kb and takes a couple milliseconds to load. By plugins I meant things like moon-router and monx. Check out the "extras" section in the README: https://github.com/kbrsh/moon#extras https://github.com/kbrsh/moon#extras
nkkollaw 9y ago
Sure, don't get me wrong—I'm not saying it's useless or it isn't an achievement. You have to realize though that as developers we invest a lot of time on learning a technology. Companies invest a lot of money into stacks. It's not always easy to find developers and if your stack is "standard", it makes it easier to both grow your team and get up to speed with the code. For a developer, company, or team, 23KB of JavaScript aren't going to be a very good incentive to ignore the advantages that come with using a standard framework like Vue. Websites are easily 10MB in size nowadays, 23KB are a drop in the ocean. I can optimize the logo and get 23KB without have my team learn a whole new framework. What I'm trying to say is that I don't think "smaller Vue alternative" is a good selling point. If anything, because as your framework gains acceptance people will want more features, and it will inevitably grow, and there goes your competitive advantage. It should do something better, or differently in a big way or a way people care about. Just my two cents. I've never created anything that a huge number of people use, so I'm no institution in this area.
- SamBam 9y ago
  > You have to realize though that as developers we invest a lot of time on learning a technology But plenty of front-end developers have not developed in Vue. If I'm starting a new project and someone suggests doing it in Vue, and I have to learn it all anyway, I might consider this as an alternative.
korzun 9y ago
The size is not a factor at that scale. Mobile suffers from issues latency, not with the 10-50K size difference. You can't compare your framework to something else (in size) if your framework does not account for backward compatibility and is missing some of the features.

by kbr 9y ago

coldtea 9y ago

>This makes it faster to load on mobile devices. That's not very significant, since even your favicon will be of comparable or even bigger size, much less any static asset like an image.

leeoniya 9y ago
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.

continuations 9y ago

Does it support native mobile development? To me that's an important issue. Vue has Weex. React has React Native. Angular has NativeScript. I'd need something similar to switch to a new frontend framework.

xigency 9y ago
Why? Are you making a website or creating an app.
- wolco 9y ago
  The answer to that question is always: yes.

valuearb 9y ago

If it has plugins, how many do you need to match key Vue features and how long do they take to load?

kbr 9y ago
Each plugin is about 2kb and takes a couple milliseconds to load. By plugins I meant things like moon-router and monx. Check out the "extras" section in the README: https://github.com/kbrsh/moon#extras https://github.com/kbrsh/moon#extras

nkkollaw 9y ago

Sure, don't get me wrong—I'm not saying it's useless or it isn't an achievement. You have to realize though that as developers we invest a lot of time on learning a technology. Companies invest a lot of money into stacks. It's not always easy to find developers and if your stack is "standard", it makes it easier to both grow your team and get up to speed with the code. For a developer, company, or team, 23KB of JavaScript aren't going to be a very good incentive to ignore the advantages that come with using a standard framework like Vue. Websites are easily 10MB in size nowadays, 23KB are a drop in the ocean. I can optimize the logo and get 23KB without have my team learn a whole new framework. What I'm trying to say is that I don't think "smaller Vue alternative" is a good selling point. If anything, because as your framework gains acceptance people will want more features, and it will inevitably grow, and there goes your competitive advantage. It should do something better, or differently in a big way or a way people care about. Just my two cents. I've never created anything that a huge number of people use, so I'm no institution in this area.

SamBam 9y ago
> You have to realize though that as developers we invest a lot of time on learning a technology But plenty of front-end developers have not developed in Vue. If I'm starting a new project and someone suggests doing it in Vue, and I have to learn it all anyway, I might consider this as an alternative.

korzun 9y ago

The size is not a factor at that scale. Mobile suffers from issues latency, not with the 10-50K size difference. You can't compare your framework to something else (in size) if your framework does not account for backward compatibility and is missing some of the features.