From a marketing perspective I'd argue it's good naming, since it sells the value of the library, rather than simply its feature/s. (i.e. its feature is 'handling webhooks' but its value is in allowing (the dev) to not have to deal with webhooks.
Steve Jobs once quipped about a similar thing he observed in the dairy industry's 'Got Milk?' marketing campaign, which focused on the absence of the product https://www.youtube.com/watch?v=XzPwMguPasM
With the library you’re able to use stripe without thinking about web hooks. The library is named based on what it enables a user to do, not how it works internally.
Comments
Haha "Stripe-no-webhooks library"
Library based on processing ... wait for it ... webhooks".
From a marketing perspective I'd argue it's good naming, since it sells the value of the library, rather than simply its feature/s. (i.e. its feature is 'handling webhooks' but its value is in allowing (the dev) to not have to deal with webhooks.
Steve Jobs once quipped about a similar thing he observed in the dairy industry's 'Got Milk?' marketing campaign, which focused on the absence of the product https://www.youtube.com/watch?v=XzPwMguPasM
Here a slightly longer version of that talk, that adds a lot more context. https://www.youtube.com/watch?v=doehWhv9SHU
It took a bit of hunting the internet, so I felt like sharing it.
With the library you’re able to use stripe without thinking about web hooks. The library is named based on what it enables a user to do, not how it works internally.
haha yes, it’s definitely a bit of a silly name. The idea is you the user does not have to deal with the webhooks!
Like serverless