JavaScript module bundles are a syntax for bundling multiple modules into a single JavaScript file.
A quick example:
// filename: app.jsb
module "./count.js" {
#!/bin/sh | |
# TODO start versioning | |
usage () { awk -v CMD="$0" '{ gsub(/\$0/, CMD); print }' <<'END_USAGE' | |
Usage: $0 [OPTION]... [--] SETUP VARIATIONS | |
Measures the performance of code variations in multiple ECMAScript implementations. | |
Options: | |
--number COUNT, -n COUNT | |
The count of timed iterations of each variation (defaults to 1000). |
JavaScript module bundles are a syntax for bundling multiple modules into a single JavaScript file.
A quick example:
// filename: app.jsb
module "./count.js" {
Advantages:
This is some sort of answer to recent posts regarding Web Components, where more than a few misconceptions were delivered as fact.
Let's start by defining what we are talking about.
As you can read in the dedicated GitHub page, Web Components is a group of features, where each feature works already by itself, and it doesn't need other features of the group to be already usable, or useful.
If you're OK in having a node-esm
executable, please consider this solution.
#!/usr/bin/env sh
# the /usr/local/bin/node-esm executable
input_file=$1
shift
exec node --input-type=module - $@ <$input_file
Along with the many disruptive trends in code editors and text documents (Markdown) in general (Markup) comes the inevitable question, Is it time for a new take on the various design patterns and implementation strategies used to work with source text?
Code Editors
While there are many JavaScript code editor implementations out there, you can almost divide them down by eras, for instance, ones predating GitHub's overwhelming effect on the adoption of Markdown, ones during the height of JQuery… etc. But regardless of eras, the way those editors model markup, while very much full of a lot of originality and creativity, they often seem to pivot around variants of similar and familiar patterns. One clear observation that begs pointing out, since most (if not all) value features in any implementation are often coupled to the specific variations of the markup model, adopting new and distruptive ideas often times leads to completely new implementations (some still call those ve
const INCOME = 100_000; | |
// ----- 2022 ----- // | |
// https://www.canada.ca/en/revenue-agency/services/forms-publications/payroll/t4032-payroll-deductions-tables/t4032on-jan/t4032on-january-general-information.html | |
const CPP_BRACKETS = [ | |
[ 3_500, 0 ], // exemption | |
[ 61_400, 0.0570], // cap | |
[Infinity, 0 ], |
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
OUTPUT=hardlink | |
C_FILES=hardlink.c | |
all: | |
gcc ${C_FILES} -o ${OUTPUT} | |
clean: | |
rm ${OUTPUT} | |
install: |