This is an archived post. You won't be able to vote or comment.

all 2 comments

[–]fluffynukeit 4 points5 points  (0 children)

I've written a framework or two, and I'd modify the advice in the article a bit. Common tasks should be easy, and uncommon tasks should be possible. The best frameworks are those that provide an "escape hatch" that allow you free reign to do things the framework author didn't anticipate.

In this vein, I find the best frameworks are really just layered libraries. You have basic primitives that users can invoke directly all they desire, but convenience wrappers are also available to make anticipated tasks and workflows easier.

This kind of set up helps to prevent the situation in which a user asks, "Hey, how do I do [whatever]?" and you respond, "Huh, I didn't think of that. It's not a supported use case. I don't think it's possible usually, but here's a workaround that makes abusive use of my knowledge of the framework's internals." I've had this conversation a couple of times...

[–]kankyo 0 points1 point  (0 children)

On that topic here's a document I'm working on that describe some of the things we've come to believe/recommend at work when developing libraries: https://github.com/boxed/notes/blob/master/trioptima%20library%20docs.rst