potential optimization of 'L'
Closed this issue · 7 comments
afaik, call Object.prototype.toString on object Location (which equals to window.location) in Edge will return "[object Location]", and Function("return ({}).toString.call(location)") only cost 5066 char in non-IE browser, and currently 'L' cost 6181 char in non-IE browser when web worker supported. since Location is web-worker-safe, definition of 'L' can be optimized with Location. But, Firefox and Safari not tested, so idk how practical it is.
Object.prototype.toString.call(location) is "[object Location]" in the main thread of browsers other than IE, and "[object WorkerLocation]" in web workers. I added two new definitions that work with both variants.
why did you add definitions based on String.prototype.at? Definitions of "L" based on Object.prototype.toString.call(location) is supposed to work in Safari before 10 where atob() only available outside web workers, and String.prototype.at is still unsupported by current browsers.
Combinations of features that are not available in known environments are still interesting for a few reasons. Some features may be polyfilled in old browsers (e.g. by core-js). Some combinations may still be available in browsers that are not officially supported. In the end, the API allows using arbitrary features at the same time, as long as they don't mutually exclude each other. For these cases, definitions are not limited to known environments.
Implemented in JScrewIt 2.28.
Sorry for bothering you again. afaik, location.constructor is Location() (a standard constructor Function) In Edge(Chromium), and location.constructor.name only cost 2180 chars in non-IE browser. But, Firefox and Safari's case still unknown, and idk whether constructor function based method would make Object.prototype.toString.call() based method useless.
I checked the value of location.constructor + '' in all browsers and this is what I got:
| Browser | location.constructor + '' |
|---|---|
| Internet Explorer (main thread) | [object Location] |
| Internet Explorer ≥ 10 (web workers) | [object WorkerLocation] |
| Safari < 10 (main thread) | [object LocationConstructor] |
| Safari < 10 (web workers) | [object WorkerLocationConstructor] |
| other browsers | function Location() + ... |
I haven't checked the encoding lengths yet, but all of these should be useful for new specific definitions.
On the other hand, I don't see how those could make any of the existing definitions useless. Specifically, I'm thinking that the "L" in location.constructor + '' could be located at index 8, 9 or 14 depending on the environment (and counting backwards gives even more possibilities...). Although it would be possible to use environment-sensitive paddings to align the "L" at the same position, the result would be probably too expensive compared to the current definition Function("return toString.call(location)")()[SLICE_OR_SUBSTR]("-10")[1], which works in all browsers except IE.
Implemented in version 2.31.0.