I thought the author had lost his mind, declaring dozens of new functions to simply wrap inbuilt functions and religiously not using classes.
Then I realized it probably cuts the bundle size by 2/3rds to remove every "this.longBuiltinFnName()" and replace it with a minified function call.
Quite possible. This was a journey! https://tripleodeon.com/2022/01/software-without-compromise/
When I first started thinking about this project, classes still meant a bunch of transpilation overhead (which dates the origin story!). I persuaded myself that plain old objects with TypeScript interfaces would strike a better balance between performance, size, and developer experience.
So I ended up with a pattern like:
const longMethod1 = () => {...};
const longMethod2 = () => {...};
return {longMethod1, longMethod2};
class Foo { foo() {} #bar() {} }
Becomes:
class f { foo() {} b() {} }
Combined with any type of compression the negligible difference is eliminated. Though it is true that static functions might be more optimisable in some cases, I'd say that on balance, the effect on maintainability is too significant for the returns. I'll take DI and testability over maybe a few kb difference
I don't think there's dozens, but there's a fair few. Most of the stuff in the common directory seems to be standard patterns they use, so it's doing more than just wrapping a function.
https://github.com/tinyplex/tinybase/blob/main/src/common/ar...
which could be to some extent and example of what the OP is talking about.