SMotaal

Fragma (concept)

Okay, concept means messy and probably requires flags on nightly or the likes, agreed? Just don't expect this to be more than what it is!

Live Demos

throttle — renders n instances of a perpetually changing element

https://smotaal.github.io/experimental/fragma/alpha/throttle#n

• #100

SMotaal

Specifiers

I have been trying to find a good way to paraphrase intuitive concerns regarding scheme-less specifiers and I think that while import: is different from other ideas proposed for somewhat related purposes, it may be coming from similar but more tangible consideration.

Yesterday I did a little experiment with URL in node, Chrome, and Safari , and Firefox. My general thought is that new URL(x, y) is a resolution formula that follows closest to the web standards so my assumption is that it pairs well with the whatwg expectations on specifiers.

The bottom line is that constructing scheme-less specifiers that depend on scheme-less referrers is not possible, and the hack used just to get through the list of valid specifiers was to resolve the referrer against file://y:/ which is not a proposed solution by all means.

Given the importance of specifier resolution (ie x -> y = z) I am

SMotaal

source
https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal/blob/eb77f14d68b6502a82837fff9f1be184148be5ee/README.md

File Specifier Resolution in Node.js

Contributors: Geoffrey Booth (@GeoffreyBooth), John-David Dalton (@jdalton), Jan Krems (@jkrems), Guy Bedford (@guybedford), Saleh Abdel Motaal (@SMotaal), Bradley Meck (@bmeck)

Motivating Examples

SMotaal

ECMAScript Proposal: Non-Module Namespaces

This is a first draft for a proposal for adding a new dimension to the current ECMAScript module architecture that would make it possible to fulfill platform dependent behaviours for common and non-common requirements without breaking the established compliance criteria. This is not yet a formal proposal.

In the default case of resolving an external dependency (which translates into bindings across two or more linked ES modules) the existing standards are technically sufficient and can only improve by increased adoption and natural progression. However, when it is necessary to either import from or respond to a specific platform, the current standards can be improved upon, which is the topic of several proposals, and is the main focus of this proposal.

Potential Use Cases

// Module-specific

SMotaal

Forks

guybedford/node/tree/irp-implementation

Setup

# clone
git clone https://github.com/guybedford/node.git --branch irp-implementation --single-branch node-esm

SMotaal

URL.resolve(…) Polyfill

Concept

(url => (href, specifier) => {
  try {
    url.href = href;
    if (/^\.{1,2}\/|^\/(?=[^\/]|$)/.test(specifier)) {
 const [, path = '', search = '', hash = ''] = /([^?#]*)([^#]*)(.*)/.exec(specifier);

SMotaal

browser	regexp	method	time
Chrome	/)|/	exec	: 6.9599609375ms
Chrome	/)|/	[Symbol.search]	6.98681640625ms
Chrome	/)(?=|)/	exec	5.283203125ms
Chrome	/)(?=|)/	[Symbol.search]	4.552001953125ms
Chrome	/(?=)|)./	exec	4.844970703125ms
Chrome	/(?=)|)./	[Symbol.search]	5.030029296875ms
Chrome	/(?=)|)/	exec	4.688232421875ms
Chrome	/(?=)|)/	[Symbol.search]	4.72802734375ms

SMotaal

Moved here: SMotaal/experimental/modules/documents/Source%20Text%20Disambiguation.md

SMotaal

module.exports = 'cjs';

SMotaal

{"processors":{}}