Post

This blog post reminds me of a blog post from Elixir community called "Let it fail". If you skip the whole BEAM / Elixir stuff, in particular this part: > Write less code by "ignoring" unexpected errors Where it talks about expected vs unexpected errors. yiming.dev/blog/2022/07...

🙌 Damn right! Dependencies are not free, they're permanent maintenance. If you can do the thing in a couple of lines of code just do it.

Great post. Do packages always start out so, or do you think this is a natural evolution of open source? Is it easier to submit a PR to address your edge case than fix your code locally? There’s probably some psychology at play here that we’d do well to understand.

I agree! And thanks for the kind words. Your articles are good inspiration 🙏

crazy that JS doesn't have a clamp function

Conceptually rather than in the usual typing sense - know what inputs make sense, only design for those, validate for those, have patterns in the rest of your code that means things other than that can’t end up getting sent to that code…

following everyone who retweets this

Just yes 🙌

Yep ✌️

Great post. It helped to convince myself of these ideas, to work out theoretical reasons why they work. It's about reducing entropy of code including reducing dependency lengths (this happens to be the same metrics AIs target to generate good language and code). benoitessiambre.com/entropy.html

Great post! As a maintainer of a relatively complex library (Sentry SDKs), I feel like we have to handle a lot of edge cases and graceful degredation is super important. Last thing you want is your error monitoring library breaking your app. But this really resonates with me on an API design level.

I noticed this in an older version of date-fns (v1 or v2), 90% of the function I was reading was validating inputs, latest uses TS and doesnt validate as much Before TypeScript and IDEs that understand TypeScript (even in JS), that was kind of the JS way of doing types... runtime validation