jsApiReporter was initially added as part of the pre-1.0 Ruby based browser
runner. It looks like it was designed to resolve a race condition betweeen
jasmine-core's startup in the browser and the Ruby runner's startup. Modern
runners handle that either by buffering messages in a custom reporter (e.g.
jasmine-browser-runner's BatchReporter) or by calling env.execute() after a
communication channel has been set up (e.g. the old Jasmine ruby gem). In
any other context, a custom reporter is easier to use than jsApiReporter
because it doesn't require polling.
Adding jsApiReporter to the env imposes small but measurable penalties in
time and space, both of which are proportional to the size of the test
suite.
Other than jasmine-py and Testdouble's jasmine-rails gem, neither of which
ever supported jasmine-core 4 or later, I can find scant evidence of
interest and no evidence of usage after about 2012.
Injected DOM wrappers were a nice idea in theory but everyone just passes
wrappers around document.createElement/document.createTextNode. That
includes HtmlReporter's unit tests and karma-jasmine-html-reporter, the
only known 5.x-compatible library that constructs an HtmlReporter.
This change broke spec filtering in Karma by changing the format of the
`spec` query parameter. Although karma-jasmine-html-reporter uses
jasmine-core's HtmlSpecFilter, karm-jasmine provides its own spec filter
that interprets the query parameters itself.
This feature may be reintroduced in 6.0 as a breaking change.
This reverts commit 8309416cb2.
