littledan

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" {

thecraftman

I18next is an internationalization-framework, based on pure JavaScript which offers a complete solution to localize your product from web to mobile and desktop.

• Source: https://www.i18next.com/

Advantages:

• Plugins to detect the user language
• Load translations
• Optionally cache the translations
• Flexibility to use other packages eg: moment.js for date formatting
• Scalability — Option to separate translations into multiple files and to load them on demand

WebReflection

Why I use web components

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.

The Web Components Umbrella

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.

WebReflection

Update

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

SMotaal

Markie

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?

Distruption

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

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

jcanfield

OUTPUT=hardlink
C_FILES=hardlink.c

all:
	gcc ${C_FILES} -o ${OUTPUT}

clean:
	rm ${OUTPUT}

install: