I wasn’t affected because TanStack doesn’t feel like the juice is worth the squeeze.
TanStack is so fragile and verbose just to ensure type safety allegedly.
Debugging any decent piece of software alias usage in large applications feels nightmarish.
It is still JavaScript even when it is called TypeScript. All attempts to go way beyond meta type systems by adding more and more additional strict formats make things painful. JS ain’t Java.
TanStack is a cool idea and I value their enthusiasm. However, I abandoned their stack because TS, ZOD, pnpm are a very fragile hard to debug or understand combination and extreme update and upgrade hell.
Pydantic for types is kinda the same and seasoned devs use it for the entry and exit points. The rest is simply Python and here NumPy and the likes.
TanStack is no way saver than npm. No one understands TanStack. Sorry to break it to you. It is security theater and developer hell.
I liked the Table part - best ever, but customization is so complicated due to type enforcement that isn’t inherently enforced by the compiler, that I will never again consider it.
> No one understands TanStack. Sorry to break it to you.
Damn, all these years of using TanStack libs successfully, and I had to learn it here that I don't understand them.
> TanStack is no way saver than npm. No one understands TanStack.
Pandas is also in no way safer than pip. Because pandas is a library and pip is a package manager and that comparison makes no sense lmao. It sounds like you maybe don't really get or use typescript and don't even really use like basic mypy style types in python (or don't get the difference between what a zod/pydantic validator does vs what a mypy/typescript type system does - zod is also only on the boundary). Which is OK but but there's a difference between not getting why a stack is useful or not having experience with it versus confidently and comically declaring that nobody else understands types either while seeming not understanding what any of the parts here do