SlideShare a Scribd company logo

CommonJS via PINF JavaScript Loader - Introduction

cadorn
cadorn

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.

TechnologyBusiness
1 of 81
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
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

What's hot (20)

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

Viewers also liked (7)

PPTX
Javascript modules
Ron Apelbaum
 
PDF
Web a Quebec - JS Debugging
Rami Sayar
 
KEY
Brunch With Coffee
Sébastien Gruhier
 
PDF
Javascript Dependency Management
Sean Duncan
 
PPT
JavaScript Modules in Practice
Maghdebura
 
PDF
Workshop 2: JavaScript Design Patterns
Visual Engineering
 
PDF
Javascript Module Patterns
Nicholas Jansma
 
Javascript modules
Ron Apelbaum
 
Web a Quebec - JS Debugging
Rami Sayar
 
Brunch With Coffee
Sébastien Gruhier
 
Javascript Dependency Management
Sean Duncan
 
JavaScript Modules in Practice
Maghdebura
 
Workshop 2: JavaScript Design Patterns
Visual Engineering
 
Javascript Module Patterns
Nicholas Jansma
 
Ad

Similar to CommonJS via PINF JavaScript Loader - Introduction (20)

PPTX
Buildmanagment tools mavenandgradle.pptx
praveena210336
 
PPTX
DevOps Friendly Doc Publishing for APIs & Microservices
Sonatype
 
PDF
Top DevOps Tools You Should Know In 2023.pdf
SatawareTechnologies6
 
PDF
Comprehensive Guide to Hire DevOps Engineer.pdf
EcosmobTechnologies1
 
PPTX
How To Become A DevOps Engineer | Who Is A DevOps Engineer? | DevOps Engineer...
Simplilearn
 
PPTX
Full Stack Web Developer (MERN STACK Developer.pptx
RamudgarYadav
 
PPTX
Ng spain
Christoffer Noring
 
PDF
Introduction to License Compliance and My research (D. German)
dmgerman
 
PDF
DevOps_1698587929.pdf cours ciCd automatique
khezzanehouria8
 
PPTX
Top frontend web development tools
Benji Harrison
 
PDF
Popular Programming and Scripting Languages for DevOps Engineers
Rlogical Techsoft Pvt Ltd
 
PDF
PHPFrameworkDay 2020 - Different software evolutions from Start till Release ...
Alexandr Savchenko
 
PDF
"Different software evolutions from Start till Release in PHP product" Oleksa...
Fwdays
 
PDF
Best practices for using open source software in the enterprise
Marcel de Vries
 
PPTX
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...
Simplilearn
 
PDF
Top 6 DevOps Tools For Web Development In 2022.pdf
SatawareTechnologies6
 
PPTX
DevOps at Lean Apps
Lean Apps
 
PDF
How to Successfully Master the PHP Development Tools.pdf
Enterprise Wired
 
PPT
5-Must-Have-Tools-for-.NET-Application-Development-Services-pptx-.ppt
Moreyeahs
 
PPTX
Modern Software Architecture
Ahmed Marzouk
 
Buildmanagment tools mavenandgradle.pptx
praveena210336
 
DevOps Friendly Doc Publishing for APIs & Microservices
Sonatype
 
Top DevOps Tools You Should Know In 2023.pdf
SatawareTechnologies6
 
Comprehensive Guide to Hire DevOps Engineer.pdf
EcosmobTechnologies1
 
How To Become A DevOps Engineer | Who Is A DevOps Engineer? | DevOps Engineer...
Simplilearn
 
Full Stack Web Developer (MERN STACK Developer.pptx
RamudgarYadav
 
Ng spain
Christoffer Noring
 
Introduction to License Compliance and My research (D. German)
dmgerman
 
DevOps_1698587929.pdf cours ciCd automatique
khezzanehouria8
 
Top frontend web development tools
Benji Harrison
 
Popular Programming and Scripting Languages for DevOps Engineers
Rlogical Techsoft Pvt Ltd
 
PHPFrameworkDay 2020 - Different software evolutions from Start till Release ...
Alexandr Savchenko
 
"Different software evolutions from Start till Release in PHP product" Oleksa...
Fwdays
 
Best practices for using open source software in the enterprise
Marcel de Vries
 
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...
Simplilearn
 
Top 6 DevOps Tools For Web Development In 2022.pdf
SatawareTechnologies6
 
DevOps at Lean Apps
Lean Apps
 
How to Successfully Master the PHP Development Tools.pdf
Enterprise Wired
 
5-Must-Have-Tools-for-.NET-Application-Development-Services-pptx-.ppt
Moreyeahs
 
Modern Software Architecture
Ahmed Marzouk
 
Ad

Recently uploaded (20)

PDF
Chris Elwell Woburn, MA - Passionate About IT Innovation
Chris Elwell Woburn, MA
 
PDF
Building Real-Time Digital Twins with IBM Maximo & ArcGIS Indoors
Safe Software
 
PPTX
Top iOS App Development Company in the USA for Innovative Apps
SynapseIndia
 
PDF
Complete JavaScript Notes: From Basics to Advanced Concepts.pdf
haydendavispro
 
PDF
Log-Based Anomaly Detection: Enhancing System Reliability with Machine Learning
Mohammed BEKKOUCHE
 
PDF
HCIP-Data Center Facility Deployment V2.0 Training Material (Without Remarks ...
mcastillo49
 
PPTX
MSP360 Backup Scheduling and Retention Best Practices.pptx
MSP360
 
PDF
SFWelly Summer 25 Release Highlights July 2025
Anna Loughnan Colquhoun
 
PDF
Rethinking Security Operations - SOC Evolution Journey.pdf
Haris Chughtai
 
PPTX
Extensions Framework (XaaS) - Enabling Orchestrate Anything
ShapeBlue
 
PPTX
Building Search Using OpenSearch: Limitations and Workarounds
Sease
 
PDF
Human-centred design in online workplace learning and relationship to engagem...
Tracy Tang
 
PDF
Impact of IEEE Computer Society in Advancing Emerging Technologies including ...
Hironori Washizaki
 
PDF
SWEBOK Guide and Software Services Engineering Education
Hironori Washizaki
 
PPTX
WooCommerce Workshop: Bring Your Laptop
Laura Hartwig
 
PDF
Blockchain Transactions Explained For Everyone
CIFDAQ
 
PPTX
Building a Production-Ready Barts Health Secure Data Environment Tooling, Acc...
Barts Health
 
PDF
Apache CloudStack 201: Let's Design & Build an IaaS Cloud
ShapeBlue
 
PDF
Français Patch Tuesday - Juillet
Ivanti
 
PDF
Ampere Offers Energy-Efficient Future For AI And Cloud
ShapeBlue
 
Chris Elwell Woburn, MA - Passionate About IT Innovation
Chris Elwell Woburn, MA
 
Building Real-Time Digital Twins with IBM Maximo & ArcGIS Indoors
Safe Software
 
Top iOS App Development Company in the USA for Innovative Apps
SynapseIndia
 
Complete JavaScript Notes: From Basics to Advanced Concepts.pdf
haydendavispro
 
Log-Based Anomaly Detection: Enhancing System Reliability with Machine Learning
Mohammed BEKKOUCHE
 
HCIP-Data Center Facility Deployment V2.0 Training Material (Without Remarks ...
mcastillo49
 
MSP360 Backup Scheduling and Retention Best Practices.pptx
MSP360
 
SFWelly Summer 25 Release Highlights July 2025
Anna Loughnan Colquhoun
 
Rethinking Security Operations - SOC Evolution Journey.pdf
Haris Chughtai
 
Extensions Framework (XaaS) - Enabling Orchestrate Anything
ShapeBlue
 
Building Search Using OpenSearch: Limitations and Workarounds
Sease
 
Human-centred design in online workplace learning and relationship to engagem...
Tracy Tang
 
Impact of IEEE Computer Society in Advancing Emerging Technologies including ...
Hironori Washizaki
 
SWEBOK Guide and Software Services Engineering Education
Hironori Washizaki
 
WooCommerce Workshop: Bring Your Laptop
Laura Hartwig
 
Blockchain Transactions Explained For Everyone
CIFDAQ
 
Building a Production-Ready Barts Health Secure Data Environment Tooling, Acc...
Barts Health
 
Apache CloudStack 201: Let's Design & Build an IaaS Cloud
ShapeBlue
 
Français Patch Tuesday - Juillet
Ivanti
 
Ampere Offers Energy-Efficient Future For AI And Cloud
ShapeBlue
 

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 <[email protected]> License: Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Various names and trademarks copyright respective parties.
  • 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
  • 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. What funds my work?
  • 23. What funds my work?
  • 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
  • 36. Separate Concerns To achieve our goals I believe we MUST:
  • 37. Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns
  • 38. Separate Concerns To achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading)
  • 39. 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)
  • 40. 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)
  • 41. 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
  • 42. 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.
  • 43. 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:
  • 44. 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
  • 45. 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
  • 46. 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
  • 47. 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
  • 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 of indirection
  • 66. PINF JS Loader Overview
  • 67. PINF JS Loader Overview • Loads multiple module source formats:
  • 68. PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD)
  • 69. PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1
  • 70. PINF JS Loader Overview • Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft)
  • 71. 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
  • 72. 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
  • 73. 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:
  • 74. 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)
  • 75. 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)
  • 76. Where does the loader typically sit?
  • 77. Architecture & process of the loader
  • 78. Architecture & process of the loader
  • 79. Dependency trees afforded by the loader
  • 80. Demo Time! github.com/cadorn/ace-extjs github.com/pinf/test-programs-js
  • 81. Thank you! Slides and links will be made available at: github.com/pinf/loader-js/wiki

Editor's Notes