cadorn, profile picture
Uploaded bycadorn
KEY, PPTX883 views

CommonJS via PINF JavaScript Loader - Introduction

The document outlines the vision and goals of the CommonJS project, focused on creating a JavaScript ecosystem that emphasizes code-sharing, interoperable libraries, and refactorable toolchains. Christoph Dorn, the author, stresses the importance of separating concerns in software design to facilitate easier changes and improve software evolution. It presents a proposed solution for JavaScript modules that includes various linking and loading strategies to enhance modularity and efficiency.

Embed presentation

Download as KEY, PPTX
CommonJS via BETA PINF JavaScript Loader github.com/pinf/loader-js (MIT Licensed) Introduction Boston JavaScript - October 14, 2011 by Christoph Dorn Copyright (c) 2011 Christoph Dorn <christoph@christophdorn.com> License: Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Various names and trademarks copyright respective parties.
About Christoph
About Christoph • 15+ years experience (web apps & business)
About Christoph • 15+ years experience (web apps & business) • Self taught developer
About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent
About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years
About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years)
About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions
About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions • CommonJS List (2 years)
About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions • CommonJS List (2 years) • Packages & dependency management
About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions • CommonJS List (2 years) • Packages & dependency management Focus: Toolchain Design & Efficient Workflows
What drives me?
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains.
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best!
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform!
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed)
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for:
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for: • Code-sharing, interoperable libraries and portable applications
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for: • Code-sharing, interoperable libraries and portable applications • Transferring the power of JavaScript to various parts of a system
What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for: • Code-sharing, interoperable libraries and portable applications • Transferring the power of JavaScript to various parts of a system • Seamless refactoring and re-composition of programs
What funds my work?
What funds my work?
CommonJS Ecosystem Goals
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs • Depend on code from URIs
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs • Depend on code from URIs • Distributed package registry and repository
CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs • Depend on code from URIs • Distributed package registry and repository • Consistent tooling interface
Separate Concerns
Separate Concerns To achieve our goals I believe we MUST:
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading)
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties)
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace)
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle.
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be:
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand • Restrict only where absolutely necessary
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand • Restrict only where absolutely necessary • Lightweight and easily implemented
Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand • Restrict only where absolutely necessary • Lightweight and easily implemented
A/The Solution
A/The Solution CommonJS/Modules/2.0 (draft)
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id)
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource())
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required)
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id)
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking • module.declare([“<dep_alias_id>”], factory); - Strict ASYNC
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking • module.declare([“<dep_alias_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_alias_id>”], factory); - Transport
A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking • module.declare([“<dep_alias_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_alias_id>”], factory); - Transport • /<packages>/<uri_no_protocol>/<revision>@/<lib>/<id> - Canonical ID
Logically separate concerns Plain Module Lazy ASYNC Strict ASYNC
Physical layers of indirection
PINF JS Loader Overview
PINF JS Loader Overview • Loads multiple module source formats:
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD)
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft)
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies • Runs an identical CommonJS package on many platforms for development and production:
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies • Runs an identical CommonJS package on many platforms for development and production: • Browser, NodeJS, V8CGI, GPSEE, RingoJS, Narwhal, Jetpack, Titanium, AdobeAir (platform and API support varies)
PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies • Runs an identical CommonJS package on many platforms for development and production: • Browser, NodeJS, V8CGI, GPSEE, RingoJS, Narwhal, Jetpack, Titanium, AdobeAir (platform and API support varies) • Can load CommonJS programs and export static bundle (inlined modules) based programs for running in Browser via BravoJS (multiple platforms and loaders coming soon)
Where does the loader typically sit?
Architecture & process of the loader
Architecture & process of the loader
Dependency trees afforded by the loader
Demo Time! github.com/cadorn/ace-extjs github.com/pinf/test-programs-js
Thank you! Slides and links will be made available at: github.com/pinf/loader-js/wiki

More Related Content

PDF
Docker introduction
byChen Cheng-Wei
 
PPTX
STC Summit 2015: API Documentation, an Example-Based Approach
byLois Patterson
 
PDF
Spring Tools 4 - Eclipse and Beyond
byVMware Tanzu
 
PPT
Dynamic Languages on the JVM
byelliando dias
 
PDF
SongYang-cv-frontend-15July
bySong YANG
 
PDF
OpenAPI Generator The Babel Fish of The API World - apidays Live Paris
byCliffano Subagio
 
PDF
Developing Great Apps with Apache Cordova
byShekhar Gulati
 
PDF
DevOps：建造開發維運的跨界之橋 (@ C.C. Agile #37)
byChen Cheng-Wei
 
Docker introduction
byChen Cheng-Wei
 
STC Summit 2015: API Documentation, an Example-Based Approach
byLois Patterson
 
Spring Tools 4 - Eclipse and Beyond
byVMware Tanzu
 
Dynamic Languages on the JVM
byelliando dias
 
SongYang-cv-frontend-15July
bySong YANG
 
OpenAPI Generator The Babel Fish of The API World - apidays Live Paris
byCliffano Subagio
 
Developing Great Apps with Apache Cordova
byShekhar Gulati
 
DevOps：建造開發維運的跨界之橋 (@ C.C. Agile #37)
byChen Cheng-Wei
 

What's hot

PDF
Working effectively with OpenShift
byShekhar Gulati
 
PPTX
Introduction to web development
byAnh Nguyen
 
PPTX
Publishing API documentation -- Presentation
byTom Johnson
 
PDF
CI/CD: Lessons from LinkedIn and Mockito
byC4Media
 
PPTX
Nexus Pro Customer Survey Findings
bySonatype
 
PDF
Migrating to Angular 4 for Spring Developers
byVMware Tanzu
 
PPTX
Engineering at bbc kl hpsd
byGavin Barton
 
PPTX
Survival Strategies for API Documentation: Presentation to Southwestern Ontar...
byTom Johnson
 
PPTX
API Documentation Workshop tcworld India 2015
byTom Johnson
 
PDF
The next generation of google APIs (Ade Oshineye)
byOntico
 
PPTX
API Workshop: Deep dive into code samples
byTom Johnson
 
PDF
API Description Languages: Which Is The Right One For Me?
byProgrammableWeb
 
PDF
Continuous Integration with Maven for Android apps
byHugo Josefson
 
PDF
The Ring programming language version 1.8 book - Part 6 of 202
byMahmoud Samir Fayed
 
PPTX
Salesforce: CI,CD & CT
byAgile Testing Alliance
 
PPTX
API workshop: Introduction to APIs (TC Camp)
byTom Johnson
 
PPTX
不只自動化而且更敏捷的Android開發工具 gradle
bysam chiu
 
PDF
Future of Grails
byDaniel Woods
 
PPTX
Publishing API documentation -- Workshop
byTom Johnson
 
PPTX
Writer APIs in Java faster with Swagger Inflector
byTony Tam
 
Working effectively with OpenShift
byShekhar Gulati
 
Introduction to web development
byAnh Nguyen
 
Publishing API documentation -- Presentation
byTom Johnson
 
CI/CD: Lessons from LinkedIn and Mockito
byC4Media
 
Nexus Pro Customer Survey Findings
bySonatype
 
Migrating to Angular 4 for Spring Developers
byVMware Tanzu
 
Engineering at bbc kl hpsd
byGavin Barton
 
Survival Strategies for API Documentation: Presentation to Southwestern Ontar...
byTom Johnson
 
API Documentation Workshop tcworld India 2015
byTom Johnson
 
The next generation of google APIs (Ade Oshineye)
byOntico
 
API Workshop: Deep dive into code samples
byTom Johnson
 
API Description Languages: Which Is The Right One For Me?
byProgrammableWeb
 
Continuous Integration with Maven for Android apps
byHugo Josefson
 
The Ring programming language version 1.8 book - Part 6 of 202
byMahmoud Samir Fayed
 
Salesforce: CI,CD & CT
byAgile Testing Alliance
 
API workshop: Introduction to APIs (TC Camp)
byTom Johnson
 
不只自動化而且更敏捷的Android開發工具 gradle
bysam chiu
 
Future of Grails
byDaniel Woods
 
Publishing API documentation -- Workshop
byTom Johnson
 
Writer APIs in Java faster with Swagger Inflector
byTony Tam
 

Viewers also liked

PPTX
Javascript modules
byRon Apelbaum
 
PDF
Web a Quebec - JS Debugging
byRami Sayar
 
KEY
Brunch With Coffee
bySébastien Gruhier
 
PDF
Javascript Dependency Management
bySean Duncan
 
PPT
JavaScript Modules in Practice
byMaghdebura
 
PDF
Workshop 2: JavaScript Design Patterns
byVisual Engineering
 
PDF
Javascript Module Patterns
byNicholas Jansma
 
Javascript modules
byRon Apelbaum
 
Web a Quebec - JS Debugging
byRami Sayar
 
Brunch With Coffee
bySébastien Gruhier
 
Javascript Dependency Management
bySean Duncan
 
JavaScript Modules in Practice
byMaghdebura
 
Workshop 2: JavaScript Design Patterns
byVisual Engineering
 
Javascript Module Patterns
byNicholas Jansma
 

Similar to CommonJS via PINF JavaScript Loader - Introduction

PPTX
Webdevcon Keynote hh-2012-09-18
byPierre Joye
 
KEY
CommonJS Everywhere (Wakanday 2011)
bycadorn
 
KEY
20120306 dublin js
byRichard Rodger
 
PDF
Building a full-stack app with Golang and Google Cloud Platform in one week
byDr. Felix Raab
 
PDF
JavaScript for Enterprise Applications
byPiyush Katariya
 
PDF
20 Most Helpful Node.JS Open Source Projects.pdf
byiDataScientists
 
PDF
Building businesspost.ie using Node.js
byRichard Rodger
 
PPT
TypeScript - Javascript done right
byWekoslav Stefanovski
 
PDF
GTUG JS will save us all
byMário Valente
 
PDF
Client Server Web Apps with JavaScript and Java Rich Scalable and RESTful 1st...
byzubinrlondoit
 
PDF
Node.js #digpen presentation
byGOSS Interactive
 
PDF
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
byFITC
 
PDF
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
byFITC
 
PDF
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...
byAmbassador Labs
 
PDF
Modern Architectures with Spring and JavaScript
bymartinlippert
 
PDF
Breaking out of the endless callback look - #jsday Italy keynote
byChristian Heilmann
 
PDF
Jsday
byChristian Heilmann
 
PDF
Essential Node.js for Web Developers from Developer Week 2013
byCA API Management
 
PDF
Choosing Javascript Libraries to Adopt for Development
byEdward Apostol
 
PDF
IBM InterConnect: Java vs JavaScript for Enterprise WebApps
byChris Bailey
 
Webdevcon Keynote hh-2012-09-18
byPierre Joye
 
CommonJS Everywhere (Wakanday 2011)
bycadorn
 
20120306 dublin js
byRichard Rodger
 
Building a full-stack app with Golang and Google Cloud Platform in one week
byDr. Felix Raab
 
JavaScript for Enterprise Applications
byPiyush Katariya
 
20 Most Helpful Node.JS Open Source Projects.pdf
byiDataScientists
 
Building businesspost.ie using Node.js
byRichard Rodger
 
TypeScript - Javascript done right
byWekoslav Stefanovski
 
GTUG JS will save us all
byMário Valente
 
Client Server Web Apps with JavaScript and Java Rich Scalable and RESTful 1st...
byzubinrlondoit
 
Node.js #digpen presentation
byGOSS Interactive
 
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
byFITC
 
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
byFITC
 
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...
byAmbassador Labs
 
Modern Architectures with Spring and JavaScript
bymartinlippert
 
Breaking out of the endless callback look - #jsday Italy keynote
byChristian Heilmann
 
Jsday
byChristian Heilmann
 
Essential Node.js for Web Developers from Developer Week 2013
byCA API Management
 
Choosing Javascript Libraries to Adopt for Development
byEdward Apostol
 
IBM InterConnect: Java vs JavaScript for Enterprise WebApps
byChris Bailey
 

Recently uploaded

PDF
Is It Possible to Have Wi-Fi Without an Internet Provider
bySidra Jefferi
 
PPTX
UiPath Autonomous Agents | Building and Orchestrating Agents End-to-End
byUiPathCommunity
 
PDF
10 Things AI-First Apps Do Differently by iProgrammer Solutions
byiProgrammer Solutions Private Limited
 
PDF
Cybersecurity: Safeguarding Digital Assets
byYasir Naveed Riaz
 
PDF
Data Virtualization in Action: Scaling APIs and Apps with FME
bySafe Software
 
PPTX
Unit-4-ARTIFICIAL NEURAL NETWORKS.pptx ANN ppt Artificial neural network
byssuserd4481a
 
PDF
Lab 1.5 - Sharing Secrets with GPG ~ 2nd Sight Lab Cloud Security Class
by2nd Sight Lab
 
PDF
Making Sense of Raster: From Bit Depth to Better Workflows
bySafe Software
 
PDF
Dev Dives: AI that builds with you - UiPath Autopilot for effortless RPA & AP...
byUiPathCommunity
 
PDF
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
PDF
DevFest El Jadida 2025 - Product Thinking
byElmehdi AMLOU
 
PDF
Decoding the DNA: The Digital Networks Act, the Open Internet, and IP interco...
byCSUC - Consorci de Serveis Universitaris de Catalunya
 
PDF
Security Forum Sessions from Houston 2025 Event
byMark Simos
 
PDF
December Patch Tuesday
byIvanti
 
DOCX
iRobot Post‑Mortem and Alternative Paths - Discussion Document for Boards and...
byDave Litwiller
 
PPTX
Building Cyber Resilience for 2026: Best Practices for a Secure, AI-Driven Bu...
byYasir Naveed Riaz
 
PPTX
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
PDF
Energy Storage Landscape Clean Energy Ministerial
bySurajitBanerjee38
 
PDF
Eredità digitale sugli smartphone: cosa resta di noi nei dispositivi mobili
bySpeck&Tech
 
PPTX
DYNAMICALLY.pptx good for the teachers or students to do seminars and for tea...
bympoorvika031
 
Is It Possible to Have Wi-Fi Without an Internet Provider
bySidra Jefferi
 
UiPath Autonomous Agents | Building and Orchestrating Agents End-to-End
byUiPathCommunity
 
10 Things AI-First Apps Do Differently by iProgrammer Solutions
byiProgrammer Solutions Private Limited
 
Cybersecurity: Safeguarding Digital Assets
byYasir Naveed Riaz
 
Data Virtualization in Action: Scaling APIs and Apps with FME
bySafe Software
 
Unit-4-ARTIFICIAL NEURAL NETWORKS.pptx ANN ppt Artificial neural network
byssuserd4481a
 
Lab 1.5 - Sharing Secrets with GPG ~ 2nd Sight Lab Cloud Security Class
by2nd Sight Lab
 
Making Sense of Raster: From Bit Depth to Better Workflows
bySafe Software
 
Dev Dives: AI that builds with you - UiPath Autopilot for effortless RPA & AP...
byUiPathCommunity
 
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
DevFest El Jadida 2025 - Product Thinking
byElmehdi AMLOU
 
Decoding the DNA: The Digital Networks Act, the Open Internet, and IP interco...
byCSUC - Consorci de Serveis Universitaris de Catalunya
 
Security Forum Sessions from Houston 2025 Event
byMark Simos
 
December Patch Tuesday
byIvanti
 
iRobot Post‑Mortem and Alternative Paths - Discussion Document for Boards and...
byDave Litwiller
 
Building Cyber Resilience for 2026: Best Practices for a Secure, AI-Driven Bu...
byYasir Naveed Riaz
 
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
Energy Storage Landscape Clean Energy Ministerial
bySurajitBanerjee38
 
Eredità digitale sugli smartphone: cosa resta di noi nei dispositivi mobili
bySpeck&Tech
 
DYNAMICALLY.pptx good for the teachers or students to do seminars and for tea...
bympoorvika031
 

CommonJS via PINF JavaScript Loader - Introduction

  • 1.
    CommonJS via BETA PINF JavaScript Loader github.com/pinf/loader-js (MIT Licensed) Introduction Boston JavaScript - October 14, 2011 by Christoph Dorn Copyright (c) 2011 Christoph Dorn <christoph@christophdorn.com> License: Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Various names and trademarks copyright respective parties.
  • 2.
  • 3.
    About Christoph • 15+years experience (web apps & business)
  • 4.
    About Christoph • 15+years experience (web apps & business) • Self taught developer
  • 5.
    About Christoph • 15+years experience (web apps & business) • Self taught developer • Independent
  • 6.
    About Christoph • 15+years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years
  • 7.
    About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years)
  • 8.
    About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions
  • 9.
    About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions • CommonJS List (2 years)
  • 10.
    About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions • CommonJS List (2 years) • Packages & dependency management
  • 11.
    About Christoph • 15+ years experience (web apps & business) • Self taught developer • Independent • Playing with and integrating toolchains for years • Firebug Working Group (3 years) • Extensions • CommonJS List (2 years) • Packages & dependency management Focus: Toolchain Design & Efficient Workflows
  • 12.
  • 13.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains.
  • 14.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best!
  • 15.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform!
  • 16.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed)
  • 17.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it
  • 18.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for:
  • 19.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for: • Code-sharing, interoperable libraries and portable applications
  • 20.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for: • Code-sharing, interoperable libraries and portable applications • Transferring the power of JavaScript to various parts of a system
  • 21.
    What drives me? I believe a major factor constraining software evolution is the lack of refactorability as a core design goal of toolchains. If we can easily change our software in every way we can focus on figuring out what actually works the best! Building a JavaScript based Toolchain Platform! github.com/pinf (MIT Licensed) JavaScript: Very expressive and easy to refactor; everyone will know it CommonJS: Developers seeking to build a JavaScript Ecosystem which allows for: • Code-sharing, interoperable libraries and portable applications • Transferring the power of JavaScript to various parts of a system • Seamless refactoring and re-composition of programs
  • 22.
  • 23.
  • 24.
  • 25.
    CommonJS Ecosystem Goals •Consistent low-level APIs across platforms
  • 26.
    CommonJS Ecosystem Goals •Consistent low-level APIs across platforms • Interoperable libraries
  • 27.
    CommonJS Ecosystem Goals •Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes
  • 28.
    CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications
  • 29.
    CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition
  • 30.
    CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces
  • 31.
    CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs
  • 32.
    CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs • Depend on code from URIs
  • 33.
    CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs • Depend on code from URIs • Distributed package registry and repository
  • 34.
    CommonJS Ecosystem Goals • Consistent low-level APIs across platforms • Interoperable libraries • Securable module sandboxes • Portable applications • Arbitrary & re-configurable program composition • Non-conflicting namespaces • Publish code to URIs • Depend on code from URIs • Distributed package registry and repository • Consistent tooling interface
  • 35.
  • 36.
    Separate Concerns To achieveour goals I believe we MUST:
  • 37.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns
  • 38.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading)
  • 39.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties)
  • 40.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace)
  • 41.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection
  • 42.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle.
  • 43.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be:
  • 44.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand
  • 45.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand • Restrict only where absolutely necessary
  • 46.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand • Restrict only where absolutely necessary • Lightweight and easily implemented
  • 47.
    Separate Concerns To achieveour goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading) • Physically (between runtimes and parties) • Link everything by URIs (globally unique namespace) • Layer control to introduce possibilities of indirection We are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle. It must be: • Easy to learn and understand • Restrict only where absolutely necessary • Lightweight and easily implemented
  • 48.
  • 49.
  • 50.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory
  • 51.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id)
  • 52.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking
  • 53.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource())
  • 54.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC
  • 55.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport
  • 56.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required)
  • 57.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators
  • 58.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor
  • 59.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id)
  • 60.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking
  • 61.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking • module.declare([“<dep_alias_id>”], factory); - Strict ASYNC
  • 62.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking • module.declare([“<dep_alias_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_alias_id>”], factory); - Transport
  • 63.
    A/The Solution CommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking • module.declare(factory); - Lazy ASYNC (‘require scraping’ ~ toSource()) • module.declare([“<dep_rel_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_rel_id>”], factory); - Transport CommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor • require(“<alias>/<id>”); - Static linking (alias_id) • module.load($alias_id, function callback() {}); - Dynamic linking • module.declare([“<dep_alias_id>”], factory); - Strict ASYNC • require.memoize(“<can_id>”, [“<dep_alias_id>”], factory); - Transport • /<packages>/<uri_no_protocol>/<revision>@/<lib>/<id> - Canonical ID
  • 64.
    Logically separate concerns Plain Module Lazy ASYNC Strict ASYNC
  • 65.
    Physical layers ofindirection
  • 66.
  • 67.
    PINF JS LoaderOverview • Loads multiple module source formats:
  • 68.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD)
  • 69.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1
  • 70.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft)
  • 71.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files
  • 72.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies
  • 73.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies • Runs an identical CommonJS package on many platforms for development and production:
  • 74.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies • Runs an identical CommonJS package on many platforms for development and production: • Browser, NodeJS, V8CGI, GPSEE, RingoJS, Narwhal, Jetpack, Titanium, AdobeAir (platform and API support varies)
  • 75.
    PINF JS LoaderOverview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft) • Plain JavaScript files • Dynamically downloads and resolves dependencies via CommonJS Package Mappings & Dependencies • Runs an identical CommonJS package on many platforms for development and production: • Browser, NodeJS, V8CGI, GPSEE, RingoJS, Narwhal, Jetpack, Titanium, AdobeAir (platform and API support varies) • Can load CommonJS programs and export static bundle (inlined modules) based programs for running in Browser via BravoJS (multiple platforms and loaders coming soon)
  • 76.
    Where does theloader typically sit?
  • 77.
  • 78.
  • 79.
  • 80.
    Demo Time! github.com/cadorn/ace-extjs github.com/pinf/test-programs-js
  • 81.
    Thank you! Slides andlinks will be made available at: github.com/pinf/loader-js/wiki

Editor's Notes