JavaScript restrictions

A heavy set of restrictions are imposed on user code that can be executed by the interpreter. This allows to make the runtime as simple to implement and reason about as possible. The following restrictions are non-normative and being worked on pending the result of proof of concepts implemented in various host programming languages.

Mandatory

Whitespace and comments

Verdict: Recommended
Reason: easy to implement, required for LibreJS-level distribution of code in preferred form of modification by each web site
Standard: JS1

if-else

Verdict: Recommended
Implementation complexity: low
Incidence rate: very common
Reason: Turing-completeness
Standard: JS1

while

Verdict: Required
Incidence rate: very common
Reason: Turing-completeness
Standard: JS1

for-in

Verdict: Required
Incidence rate: rare
Reason: single original way for dynamic iteration on Object keys
Standard: JS1

function definition and return

Verdict: Required
Incidence rate: very common
Reason: basic modularization. A restriction of return at the very end of the body was considered, but then dismissed as easy to implement without this restriction while greatly improving clarity of user code.
Standard: JS1

read from standard input

Verdict: Recommended
Incidence rate: none in web code, high in command line and server CGI code
Reason: Turing-completeness
Solution: process.stdin.on
Workaround: some other API that can open and read from a file descriptor
Standard: Node.js

reading contents of a file

Verdict: Recommended
Incidence rate: none in web code, high in command line and server CGI code
Reason: native platform interface
Solution: require('fs').readFile()
Alternative: require('fs').readFileSync()
Workaround: some other API that can open and read from a file descriptor
Standard: Node.js

writing contents to a file

Verdict: Recommended
Incidence rate: none in web code, high in command line and server CGI code
Reason: native platform interface
Solution: require('fs').writeFile()
Workaround: some other API that can open and write to a file descriptor
Standard: Node.js

Verdict: required, partial
Restriction: recommend working around property accessors by not reading this field after having written to it and only write to it once between browser preemption points (starting execution of a script, XHR, document.write, timeout, form submit, a href)
Implementation complexity: low if String backed, intermediate if property accessors need to be introduced to the language just for this
Incidence rate: low, but non-negligible
Reason: useful for authentication of extant web hosting services
Workaround: none on web, adding and parsing headers via HTTP/TCP connections on native platforms
Standard: NS2

Call stack quota

Verdict: required
Reason: the visitor must have control over untrusted code
Implementation complexity: low

Heap allocation quota

Verdict: required
Reason: the visitor must have control over untrusted code
Implementation complexity: higher intermediate due to many corner cases
Solution: account for each allocation including overheads of alignment and padding, accessing a large index in an array, allocate many small objects, concatenating large strings, setting many fields on a single object, manipulations on mmap'ped files

CPU time quota

Verdict: required
Reason: the visitor must have control over untrusted code
Implementation complexity: intermediate
Solution: if the interactive user agent is single threaded without a means to abort the script from the interface, start a watchdog timer within the event loop and terminate the script if the single atomic dispatch takes more than the quota. If the user interface can remain responsive for aborting a running script, the total CPU time since the last user interaction with the script should be metered and the user warned if it had taken more than a threshold or if the average CPU utilization percentage caused by the script had exceeded a threshold after some time.

Quality of life improvement

Array object

Verdict: recommended, partial
Restriction: creation with the 0-argument constructor, only the `.length` getter can be used and square bracket indexing, missing: join, reverse, sort
Implementation complexity: low, intermediate with an efficient data structure
Workaround: substitute an Object, manually update a length property with each addition or iterate over it until reaching `undefined` instead of a given length
Standard: ES1

window.localStorage

Verdict: recommended, partial
Reason: caching, private keys, state not uploaded on each request as with cookies, safer than cookies
Restriction: getItem(), setItem() and key(). Without getters, length is not supported, removeItem() and clear() optional
Implementation complexity: low, individual files with storage quota accounting
Workaround: store private keys and state in URI hash anchor and ask user to update bookmark after every session
Standard: 2009-2010 (Firefox 3.5, Safari 4, IE8, Opera 10.5, Chrome 5)

Pause, resume and terminate script upon interactive command

Verdict: recommended
Implementation complexity: low if granularity provided by event loop conditioning is sufficient, intermediate if termination at reductions or via a separate process model would be warranted, very high if resumption without POSIX job control signals also required

Pure anonymous function expression

Verdict: Recommended
Reason: Potential for building a higher level library by the user
Standard: ES1 (`Function`), ES3 (`function(){}`)

Nested function definition

Verdict: Recommended
Reason: modularization, reducing global oversaturation and reduce visibility of unrelated functionality
Standard: ES3

short-circuiting operators &&, ||

Verdict: recommended
Incidence: high
Workaround: if, &
Standard: JS1

eval

Verdict: recommended
Incidence: low
Implementation complexity: low
Workaround: interpreter
Standard: JS1

Strict equality === !==

Verdict: recommended, partial
Reason: suggested by style guides, avoids wide classes of errors, easy to understand by beginners
Restriction: can only homogeneously compare non-NaN integers or strings, along with `null` and `undefined` to any value to reduce bug potential
Incidence: high to always
Implementation complexity: low
Workaround: error prone and too verbose, invoke abstract equality and `typeof` or `instanceof` in every expression it occurs
Standard: ES3

document.write

Verdict: recommended
Incidence rate: intermediate
Implementation complexity: low
Reason: the simplest alternative for interactive document modification
Workaround: serialize state, generate a complete new document using the string return value of a `javascript:` link to navigate away to, deserialize state
Standard: NS2

reading the value of a form input element

Verdict: required, same for textarea
Incidence rate: high
Implementation complexity: low, read both the default value from the static HTML and text entered by the user
Reason: allow for interacting with typed user input without server involvement
Workaround: unsatisfactory due to lack of caching, allow to submit the form via GET and parse the values from the URI upon load, without forms, provide an on screen keyboard with individual links for each key
Standard: NS2

Consecutive terms of same operator in expressions

Verdict: recommended
Restriction: you can apply the same operator consecutively in an expression without using parenthesis
Use cases: string concatenation, numerical sums, factors, short circuiting bool logic
Incidence rate: high
Implementation complexity: trivial (only a few lines of code)
Drawback: it creates an irregular corner case of supported syntax that needs to be remembered
Workaround: parenthesis
Standard: JS1

Automatic ToBoolean conversion

Verdict: supported
Reason: expected by users
Drawbacks: restricting it could improve hardening, either remove it completely or only support integers 0 and 1
Incidence rate: high, higher for an interpreter substituting integers for the Boolean type
Implementation complexity: trivial
Workaround: invoke the `Boolean()` function
Standard: JS1

To research

Abstract equality == !=

Verdict: not mandatory, avoid in user code if possible
Reason: may lead to bugs, difficult to keep in mind all corner cases for beginners, may only be needed for compatibility with JavaScript 1.0
Incidence: low
Implementation complexity: low
Workaround: usually unwanted, but may simulate by first converting a value to canonical form according to the standard and compare with a sequence of strict equality checks
Standard: JS1

Floating point numbers

Verdict: Desirable, but unsupported
Restriction: only integers supported and the special value of `NaN`
Reason: too complex to implement and potentially increases memory use and more difficult to optimize. `NaN` is desirable to detect error conditions of standard functions.
Standard: JS1

Automatic ToString conversion

Verdict: partial
Restriction: only allowed for concatenation of a String and Number, Object or undefined using `+`
Reason: expected by users, but would be beneficial to forbid
Drawbacks: can often cause bugs if working on values of unforeseen types
Incidence rate: high
Implementation complexity: trivial, assuming `String()` is already available, high if had to make standard library conforming
Workaround: invoke the `String()` function
Standard: JS1

Unicode

Verdict: partially supported
Restrictions: String indexing may iterate on UTF8 instead of UCS-2. May assume that the HTML and JS source are all encoded as UTF8.
Use cases: must be able to process input in extant human languages in a way that should work in a way equivalent to extant web browsers.
Standard: JS1

Operator precedence in expressions

Verdict: partial
Restriction: only support unary and binary operators to avoid having to observe operator precedence rules. A few subexpressions may be supported without parenthesis that are very common: function invocation, array index, object member. The special case of consecutive terms of same operator is detailed separately.
Incidence rate: intermediate
Implementation complexity: intermediate
Workaround: parenthesis, temporary variables
Standard: JS1

Booleans

Verdict: not supported
Incidence rate: high
Implementation complexity: low
Workaround: can be substituted with `0===1` and `1===1`, but 0/1 can also be used instead of false/true similarly to C
Standard: JS1

Date

Verdict: partial
Restriction: You can only subtract two Date objects from each other to get the elapsed time in milliseconds, add a Date and a Number offset to result in a Date and divide or compute modulo of a Date by a Number (usually 1000) as taken in number of milliseconds since Unix epoch. This should allow for Number to be represented on 32 bits. Consider methods for returning the locale time offset.
Implementation complexity: high if unrestricted
Incidence rate: low
Workaround: library
Standard: JS1

RegExp

Verdict: partial, investigate
Restrictions: only String.prototype.match, no RegExp class, PCRE subset
Incidence rate: intermediate to high
Implementation complexity: intermediate if platform has compatible built-ins, very high otherwise
Runtime overhead: variable memory and CPU utilization, may be exploited with ReDoS unless additional sanitization is implemented
Workaround: while, if, String charCodeAt
Standard: ES3

https://en.wikipedia.org/wiki/ReDoS

Partial

semicolon

Verdict: partial
Implementation complexity: high if done per standard
Reason: automatic semicolon insertion as called for by the standard is very complicated to both implement and remember.
Restriction: terminate or begin every statement with a `;`. You can leave out `;` either before the end of a block (end of program or before `}`) or after the start of a block (start of program or after `{`)
Standard: JS1

write to standard output

Verdict: Partial
Restriction: only a single string argument is allowed for console.log() without any formatting
Incidence rate: low in web code, high in command line and server CGI code
Reason: Turing-completeness
Solution: console.log
Workaround: some other API that can open and write to a file descriptor
Standard: Node.js, IE8, Firefox 4, Chrome 4, Opera 11, Safari 3.1

block scope braces

Verdict: supported
Restrictions: only allowed (optional) for body of if-else and while
Implementation complexity: easy if restricted
Workaround: function, multiple if
Standard: JS1

Immediately invoked anonymous function expression

Verdict: Recommended
Reason: desirable qualities of encapsulation useful for modules and userscript (userjs) within a web browser.
Restrictions: not all syntax may be supported and in not every position within an expression. This should work: `(function(){})();`
Workaround: `Function`
Standard: ES1 (`Function`), ES3 (`function(){}`)

Environment capturing by a function definition

Verdict: Desirable, but only partially supported
Use cases: state encapsulation for object oriented programming, Currying for functional programming
Restrictions: to avoid reference cycles, a runtime may make a shallow copy of the environment from above the function definition, not including itself.
Workaround: Use a C-like function definition order within the file. Recursion needs to be worked around by passing in a self-reference for the function. `Function` and `eval` could also be used as an alternative.
Standard: ES3

Variable initializer

Verdict: Desirable, partially supported
Incidence rate: frequently
Implementation complexity: easy
Restriction: single variable and single initializer supported per `var` keyword as usually recommended by style guides to maintain one statement per line.
Standard: JS1

Exceptions try-catch, throw

Verdict: desirable, limited support
Restriction: no classes, catch may be implemented as a restricted kind of environment
Reason: Useful for detecting error conditions of standard functions.
Standard: ES3, NS5

Field accessor chaining

Verdict: desirable, limited support
Incidence rate: very common
Implementation complexity: easy
Restriction: chaining starting from a variable should be supported, but may not support interspersing function calls or parenthesized expressions
Standard: JS1

window.location.href

Verdict: partial
Use cases: process arguments in the URI query or hash anchor, possibly read `GET` form submissions
Restriction: can only get the full URL as a string, no property setter
Workaround: library
Standard: NS2

window.location.replace

Verdict: recommended
Use cases: change internal state in the URI query or hash anchor, possibly create `GET` form submissions
Workaround: library
Standard: NS3

window.location.assign

Verdict: recommended
Use cases: navigate to a different page without a setter for href
Workaround: library
Standard: NS2

window.setTimeout

Verdict: partial
Restriction: function argument, up to a single timeout active at a time
Implementation complexity: higher intermediate, needs an event loop with termination and signal handling
Use cases: retry with backoff, autosave, neighborly crawling, animation, debouncing, initialization after onload (instead of noscript)
Workaround: eval instead of string argument, none for setTimeout itself (except for immediately invoking the function if the timeout is 0), implement a dispatcher that tracks upcoming events in ascending order to simulate multiple timers
Standard: NS2, JS1

form post

Verdict: partial
Implementation complexity: high, encoding types, file attachments, hooks for both HTML and JavaScript
Restriction: limited input types, limited attributes (action, method, enctype)
Standard: NS2

XMLHttpRequest

Verdict: partial
Implementation complexity: high, header handling, timeout, reference cycle
Restriction: can only return a string responseText without progress, CORS may not be complete
Use cases: interfacing with API, third party integration, incremental update of local state, bookmarklet that would parse the current document
Workaround: JSONP, form submit, Fetch
Standard: Internet Explorer 5, Gecko 1.0, Safari 1.2, Opera 8

Automatic ToNumber conversion

Verdict: partial
Restriction: only allowed to get milliseconds from a Date for certain operators detailed in the Date section
Reason: potential for bugs outweighs ergonomic benefits in most common code
Drawbacks: can often cause bugs if working on values of unforeseen types
Incidence rate: low
Implementation complexity: low, assuming `parseInt()` is already available, high if had to make standard library conforming
Workaround: `typeof`, `parseInt()`
Standard: JS1

Instantiate class with new keyword

Verdict: partial
Restriction: only for a few predetermined classes (Array*, Object*, Date, XMLHttpRequest), see constructor arguments detailed separately.
Incidence rate: low for custom classes, intermediate for built-in
Implementation complexity: high if assuming full OOP, prototype and this support
Drawbacks: prototype based inheritance is disfavored
Workaround: can cleanly simulate OOP by capturing state within a Function that returns an Object of methods
Standard: JS1

Unsupported

Automatic ToPrimitive conversion

Verdict: unsupported
Reason: implementation cost and introduced irregularity outweighs ergonomic benefits in most common code
Drawbacks: can often cause bugs if working on values of unforeseen types
Incidence rate: low
Implementation complexity: high
Workaround: convert to appropriate type manually
Standard: JS1

Constructor arguments

Verdict: unsupported
Implementation complexity: intermediate
Incidence rate: low
Use cases: Array initializer (instead of ES3 Array literal), ES3 RegExp
Reason: not crucial in practice
Workaround: separately instantiate the class and then initialize it (Array), use function application based alternatives that work without the new keyword (Function, String), substitute RegExp with String match, search or replace
Standard: JS1

window.setInterval

Verdict: unsupported
Implementation complexity: low
Workaround: simulate using setTimeout and Date
Standard: NS4

writing to the value of a form input element

Verdict: not supported
Incidence rate: low
Implementation complexity: higher intermediate, depending on widget toolkit, may need to keep the whole HTML source or a representation in memory and reflow
Workaround: generate a new document with the intended value set as default, possibly represent value within body outside form
Standard: NS2

variable declaration hoisting

Verdict: not supported
Reason: considered bad practice, confusing for beginners
Implementation complexity: low to intermediate depending on graph representation, may carry a runtime penalty when streaming
Incidence rate: very low, usually not on purpose
Use cases: none
Workaround: declare a variable before referencing it
Standard: JS1

do-while

Verdict: not supported
Reason: redundant, but would be beneficial at times
Implementation complexity: easy
Incidence rate: low
Workaround: while, if, return
Standard: ES3

for

Verdict: not supported
Reason: redundant, but would be beneficial at times
Implementation complexity: easy
Incidence rate: intermediate
Workaround: while
Standard: JS1

break, continue

Verdict: not supported
Implementation complexity: intermediate
Incidence rate: low
Reason: goto also disfavored by style guides
Workaround: return, if, altered loop condition, function expression
Standard: JS1

varargs

Verdict: not supported
Implementation complexity: intermediate (function arguments object, call, apply)
Incidence rate: rare
Use cases: a few standard library functions in ES3 whose functionality could be restricted to only support the minimal amount of non-trivial arguments (1 for Array.prototype.concat, push, unshift, String.fromCharCode, String.prototype.concat, 2 for Array.prototype.splice, Math.min, max and the Function() constructor)
Workaround: Array
Standard: JS1

block scope environment const, let

Verdict: not supported
Implementation complexity: complicated
Incidence rate: would be often useful
Reason: would increase memory pressure, would be less error prone for newcomers than the function scope `var`
Workaround: function, immediately invoked anonymous function expression
Standard: ES6

switch-case-default

Verdict: not supported
Implementation complexity: intermediate
Incidence rate: rare
Workaround: if-else
Standard: ES3

Literal object notation

Verdict: not supported, desirable at times
Implementation complexity: straightforward
Incidence rate: intermediate
Workaround: easy, create an intermediate object and add the value via an accessor
Standard: ES3

Literal array notation

Verdict: not supported, desirable at times
Implementation complexity: straightforward
Incidence rate: intermediate
Workaround: easy, create an intermediate array and add the value via an index
Standard: ES3

Reference cycles

Verdict: Unsupported.
Restriction: Avoid storing a reference within object `p` pointing to object `q` if there exists a directed path leading from `q` to `p`. Captured function environment scopes are also counted as a reference.
Reason: Such a cycle would mandate a more complicated and less deterministic garbage collection scheme for collecting cycles specifically.
Workaround: store the key of a given object within a common map instead of a direct reference. Inspect carefully which environment a given function definition captures and alter the ordering or use additional encapsulation to hide stray paths.
Standard: JS1

Tail call optimization

Verdict: unsupported
Reason: still not supported by most major browsers as of 2023
Implementation complexity: very high
Incidence rate: low (none for common imperative code)
Workaround: while
Standard: optional since ES6

Prototype

Verdict: avoid in user code
Restriction: runtime implementation may use it internally but may not expose it to user code
Reason: uniform implementation is difficult, slow and uses more memory. Also considered bad practice for most use cases.
Workaround: emulate regular inheritance by function expressions or chain only pure functions where applicable
Standard: JS1

Standards

Navigation

Back to gemiweb0