Daniel Ehrenberg littledan

See current development here.

This document proposes a new resource batch file format, together with a concept of preloading resource batches on the Web. This proposal is derived from Web Bundles by Jeffrey Yasskin and dynamic bundle serving by Yoav Weiss, with significant input from Pete Snyder, who raised concerns about Web Bundles.

Resource Batch Preloading

When loading subresources on the Web, developers currently have an unfortunate choice between serving resources individually, or using bundlers, both of which have disadvantages which hurt loading performance. This document proposes a new mechanism, "resource batch preloading", which allows subresources to be loaded

CURRENT DEVELOPMENT OF THIS PROPOSAL.

Old draft below in case anyone is curious

JavaScript module bundles are a syntax for bundling multiple modules into a single JavaScript file.

A quick example:

// filename: app.jsb
module "./count.js" {

Note: this document is subsumed by the module blocks proposal

Anonymous inline modules

Anonymous inline modules are syntax for the contents of a module, which can then be imported.

let inlineModule = module {
  export let y = 1;
};

Private fields and methods can only be accessed from lexically inside the class where they are defined. In many cases, it is important for code more generally to be able to access a private field or method. It's possible to close over access to private fields and methods to grant some other code the capability to access them, but the code to do this is awkward and redundant.

The private.name syntax creates a reified reference to accessing a private field or method without the need for repetitive arrow functions. As an example of usage:

class C {
  #x;
  static x = private.name #x;
}
c = new C;

Decorators: yet another proposal

Introduction

Decorators are a proposal for extending JavaScript classes which is widely adopted among developers in transpiler environments, with broad interest in standardization. TC39 has been iterating on decorators proposals for over five years. This document describes a new proposal for decorators based on elements from all past proposals.

Decorators @decorator are functions called on class elements or other JavaScript syntax forms during definition, potentially wrapping or replacing them with a new value returned by the decorator.

A decorated class field is treated as wrapping a getter/setter pair for accessing that storage. Decorated storage is useful for observation/tracking, which has been a pain point for the original legacy/experimental decorators combined with [[Define]] semantics for class fields. These semantics are based on Michel Weststrate's "trapping decorators" proposal.

The current timezone is visible to JavaScript in a few ways, such as:

Intl.DateTimeFormat().resolvedOptions().timeZone
new Date().toString()

The current timezone can change, for example in mobile when the user physically moves to a new location and on desktop when the user changes their system timezone settings. These changes do not require a page reload, but rather are observable within a single page running JavaScript, relatively consistently across browsers, although there are no web-platform-tests for this behavior.

Web apps with timezone-specific UI, such as calendar apps, email applications, or event schedules, may want to respond to timezone changes to update dates and times accordingly. Currently, web apps have no way to accomplish this without repeatedly polling for the current timezone. This proposal introduces a new timezonechange event that instead notifies the application.

	class Super {
	constructor(obj) {
	return obj;
	}
	}

	class Adder extends Super {
	#field;
	constructor(obj) { super(obj); }
	static set(obj, val) { obj.#field = val; }

	npm install -g test262-harness
	npm install -g babel-cli
	npm install -g jsvu
	jsvu
	git clone https://github.com/tc39/test262.git
	test262-harness --test262Dir test262 --babelPresets stage-3 --hostType d8 --hostPath ~/.jsvu/v8 test262/test/intl402/*

	A summary of the issues for WebAssembly that Dan has been thinking about:

	- CSP -- https://github.com/WebAssembly/content-security-policy/pull/13
	- When the checks happen
	- What the checks are
	- Resource limits -- https://github.com/WebAssembly/spec/issues/607
	- Should we align resource limits?
	- How should the limit on local variables be interpreted?
	- What are the magic numbers? (These have already had to rise due to lack of implementation)
	- Memory objects limit -- do we have consensus that there should be no limit? https://github.com/WebAssembly/design/issues/1167

	class Vec {
	#x;
	#y;
	#z;

	constructor(x, y, z) {
	this.#x = x;
	this.#y = y;
	this.#z = z;
	}