Skip to content

Instantly share code, notes, and snippets.

View littledan's full-sized avatar

Daniel Ehrenberg littledan

View GitHub Profile
@littledan
littledan / ontimezonechange-explainer.md
Last active July 9, 2020 18:21
ontimezonechange explainer

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.

@littledan
littledan / README.md
Created August 6, 2020 02:40
`private.name`: References to private fields and methods

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;
@littledan
littledan / add-private-field.js
Created January 26, 2021 18:15
Example adding a private field to an existing object
class Super {
constructor(obj) {
return obj;
}
}
class Adder extends Super {
#field;
constructor(obj) { super(obj); }
static set(obj, val) { obj.#field = val; }

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

@littledan
littledan / js-module-bundles.md
Last active March 3, 2021 04:17
JavaScript Module Bundles

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" {
@littledan
littledan / anonymous-inline-modules.md
Last active June 29, 2022 01:07
Anonymous inline modules

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;
};
@littledan
littledan / decorators.md
Last active August 2, 2023 16:45
Decorators: yet another proposal (very early draft, will change)

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.