A novice question - how significant is the relative size here. Sure - 4 is smaller than 32, but is that really the biggest concern with a JS library (and modern internet speeds)?
In my opinion absolute relative size is actually less important than how many TCP roundtrips it takes. It is no accident the author of this library is trying to fit in under 4KB specifically.
Frankly it is an arbitrary number, mostly. I started with the goal of having no more than 7 functions, because that's the number of functions the first version had. It didn't take long for me to figure out that this wasn't enough for every-day use. My next goal was to be a number of magnitude smaller than jQuery, and thus 3.3kB. That was a lot better, but still not enough to be a viable alternative. So I settled with 4kB.
While 4kB may fit well in certain packet sizes, this does not help with HTTP headers that can easily have 100 bytes or more.
1) For poorer countries with spotty internet, or mobile only that is slow.
2) For mobile, where data use matters.
3) Ideally with a library this small, it's mostly doing exactly what you need it to and nothing else. So it should be faster for what you're using it for. It's not trying to be all things to all people, and the trade off for that should be giving up long-tail features in exchange for more speed.
Size itself is actually not that important. The time to load and process it still is to some degree, especially on mobile, and that increases almost linearly with size.
