This is kinda thin, it reads more like an ad than anything else :/<p>I mean <i>of course</i> you shouldn't make breaking changes to your API unless you must. <i>Of course</i> if its hard to use its not good enough. These are universal truths that apply to most anything that other people build upon or merely use.<p>I've spent the last two years making a JavaScript API and I feel like there's so much more real substance they could talk about here. Writing an API is a very interesting process, and its <i>hard</i>, harder than writing a general program or even a language.<p>You don't just have to consider users needs or a grammar. Instead you have to consider all the things your clients (other programmers) might want to do, <i>and</i> all of the things their users might want to do.<p>This means you have to be extremely forward thinking, considering all the ways programmers might err while building with your library. When making general programs you have to worry about shooting yourself in the foot. With an API, you have to put forth <i>U.N. Peacekeeping</i> levels of effort to make sure nobody is going to shoot anybody or themselves. (Hopefully with better than U.N. Peacekeeping levels of success!)<p>> If it’s hard to use, it’s not good enough (meaning you have to use it first)<p>This can't be stressed enough though. One of the lessons I learned here is that making a large number of sample applications (I'm at 44 little apps and counting for my lib) exposes a vast amount of untold hangups, issues, and <i>wishes.</i> It's incredible the things you demand from your API once you start using it compared to the things you thought you'd want. And they've exposed far more kinks than testing alone could have shown me.<p>Ah I've rambled a bit. Maybe I should write my own experiences later tonight.