I don't think you are whack.  It's more of the conundrum that is the last
Web APIs movement.   What is an API?  REST?  SOAP?  What makes the movement
successful?  Everyone has their opinions.

I classify JavaScript API under, "Embeddable".

If you build a button, badget, widget or sophisticated JS app.  It's client
side and thus can be embedded anywhere.  It's build for syndication and
embeddability.

Google Maps was built for hackability.  I remember Lars talking about this
in the early days, in one of his keynotes.  The JS isn't the API.  The API
drives the JS.

Companies like Band Page <http://www.bandpage.com/>, do the JS embed driven
by API, but don't release the API.  It's there.  They acknowledge that
savvy devs will hack it, and they won't prevent it.  Much like google maps
team admitted to.

I think naming matters.  I think your right.  JS API is not right, but I
don't think my approach is either.

I find advocating for an API is first.  Whether you make that public or not
is up to you.  Then a healthy embeddable strategy is important, either way.

I think JS is inherently client side or SDK...but then again NodeJS has
bucked that trend.

But great conversation and thoughts.  I think you have opened up something,
few discuss.

And needs more discussion.

Kin Lane
kinl...@gmail.com
apievangelist.com / apivoice.com

** Attending API Strategy & Practice
<http://www.apistrategyconference.com/> conference?
**