VISUALIZATION, ETC.

A Javascript question on performance vs. convenience

Here’s a Javascript-specific software engineering problem I’m
considering within Facet.
I’m trying to decide how (or even whether) to approach type-checking
in the API, and I’m looking for input.

Since Javascript is dynamically checked, if a user passes a bad value
into a function, the error might only manifest itself much further
down the code. Tracking this error down is a slow and opaque problem:
the error message will typically come from the innards of Facet, which
will confuse users that are not intimately familiar with the library
(at present, anyone but me).

The easy way to solve this problem is to add a strict layer of
type-checking into every function. This works, but carries a runtime
penalty, and good code pays the cost of debugging over and over
again. This is not a problem if the API call is not on the application
hot path, but some calls are unavoidable: anything that happens
per-frame on WebGL should be considered on the hotpath, since spare
cycles can be used for more features. The canonical example of this
type of thing is in
Shade.parameter.

I’m leaning towards creating two sets of methods, the
slow, type-checked method, and the fast,
you be careful with dat
non-type-checked version. But what’s the best way to expose this in
an API?
Is this even hopeful to do robustly and effectively?
I have created an issue on github. If you’ve run into this
type of issue in the past, want to voice an opinion or simply help
out, I’d love to hear from you.