Well for the sake of argument I wrote one anyway. Matcher takes a sorted array of strings at initialization and identifies the subset of compatible matches as you supply it with characters (or whole strings). Why a sorted array? So that the matching can be done in logarithmic time for each character using binary search. This makes for a worst case running time of n*log(n) (log(n) on average) It is written in the same manner as FastMin, with engine optimization on the mind. Because Matcher offers the array index of the matched string upon successful match, an array of strategies can be created to correspond with the match array. This eliminates the need to create a dictionary object.
It's an awful lot of code to avoid a one-line solution, so there should be a loss in performance, right? Using Matcher in FastMin actually led to a performance increase of 57%. I was astounded. As it turns out, a single unoptimizable line causes the entire enclosing function to be deoptimized. So, the simple act of accessing an object property by string triggered a deoptimization that hampered the entirety of HTMLFastMin.
And yes, the title of this post is a shameless pun.