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
Ad

Recommended

Docker introduction
Docker introduction
Chen Cheng-Wei
 
STC Summit 2015: API Documentation, an Example-Based Approach
STC Summit 2015: API Documentation, an Example-Based Approach
Lois Patterson
 
Spring Tools 4 - Eclipse and Beyond
Spring Tools 4 - Eclipse and Beyond
VMware Tanzu
 
Dynamic Languages on the JVM
Dynamic Languages on the JVM
elliando dias
 
SongYang-cv-frontend-15July
SongYang-cv-frontend-15July
Song YANG
 
OpenAPI Generator The Babel Fish of The API World - apidays Live Paris
OpenAPI Generator The Babel Fish of The API World - apidays Live Paris
Cliffano Subagio
 
Developing Great Apps with Apache Cordova
Developing Great Apps with Apache Cordova
Shekhar Gulati
 
DevOps：建造開發維運的跨界之橋 (@ C.C. Agile #37)
DevOps：建造開發維運的跨界之橋 (@ C.C. Agile #37)
Chen Cheng-Wei
 
Working effectively with OpenShift
Working effectively with OpenShift
Shekhar Gulati
 
Introduction to web development
Introduction to web development
Anh Nguyen
 
Publishing API documentation -- Presentation
Publishing API documentation -- Presentation
Tom Johnson
 
CI/CD: Lessons from LinkedIn and Mockito
CI/CD: Lessons from LinkedIn and Mockito
C4Media
 
Nexus Pro Customer Survey Findings
Nexus Pro Customer Survey Findings
Sonatype
 
Migrating to Angular 4 for Spring Developers
Migrating to Angular 4 for Spring Developers
VMware Tanzu
 
Engineering at bbc kl hpsd
Engineering at bbc kl hpsd
Gavin Barton
 
Survival Strategies for API Documentation: Presentation to Southwestern Ontar...
Survival Strategies for API Documentation: Presentation to Southwestern Ontar...
Tom Johnson
 
API Documentation Workshop tcworld India 2015
API Documentation Workshop tcworld India 2015
Tom Johnson
 
The next generation of google APIs (Ade Oshineye)
The next generation of google APIs (Ade Oshineye)
Ontico
 
API Workshop: Deep dive into code samples
API Workshop: Deep dive into code samples
Tom Johnson
 
API Description Languages: Which Is The Right One For Me?
API Description Languages: Which Is The Right One For Me?
ProgrammableWeb
 
Continuous Integration with Maven for Android apps
Continuous Integration with Maven for Android apps
Hugo Josefson
 
The Ring programming language version 1.8 book - Part 6 of 202
The Ring programming language version 1.8 book - Part 6 of 202
Mahmoud Samir Fayed
 
Salesforce: CI,CD & CT
Salesforce: CI,CD & CT
Agile Testing Alliance
 
API workshop: Introduction to APIs (TC Camp)
API workshop: Introduction to APIs (TC Camp)
Tom Johnson
 
不只自動化而且更敏捷的Android開發工具 gradle
不只自動化而且更敏捷的Android開發工具 gradle
sam chiu
 
Future of Grails
Future of Grails
Daniel Woods
 
Publishing API documentation -- Workshop
Publishing API documentation -- Workshop
Tom Johnson
 
Writer APIs in Java faster with Swagger Inflector
Writer APIs in Java faster with Swagger Inflector
Tony Tam
 
Javascript modules
Javascript modules
Ron Apelbaum
 
Web a Quebec - JS Debugging
Web a Quebec - JS Debugging
Rami Sayar
 

More Related Content

What's hot (20)

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

Viewers also liked (7)

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

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

Webdevcon Keynote hh-2012-09-18
Webdevcon Keynote hh-2012-09-18
Pierre Joye
 
CommonJS Everywhere (Wakanday 2011)
CommonJS Everywhere (Wakanday 2011)
cadorn
 
20120306 dublin js
20120306 dublin js
Richard Rodger
 
Building a full-stack app with Golang and Google Cloud Platform in one week
Building a full-stack app with Golang and Google Cloud Platform in one week
Dr. Felix Raab
 
JavaScript for Enterprise Applications
JavaScript for Enterprise Applications
Piyush Katariya
 
20 Most Helpful Node.JS Open Source Projects.pdf
20 Most Helpful Node.JS Open Source Projects.pdf
iDataScientists
 
Building businesspost.ie using Node.js
Building businesspost.ie using Node.js
Richard Rodger
 
TypeScript - Javascript done right
TypeScript - Javascript done right
Wekoslav Stefanovski
 
GTUG JS will save us all
GTUG JS will save us all
Mário Valente
 
Client Server Web Apps with JavaScript and Java Rich Scalable and RESTful 1st...
Client Server Web Apps with JavaScript and Java Rich Scalable and RESTful 1st...
zubinrlondoit
 
Node.js #digpen presentation
Node.js #digpen presentation
GOSS Interactive
 
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
FITC
 
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
FITC
 
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...
Ambassador Labs
 
Modern Architectures with Spring and JavaScript
Modern Architectures with Spring and JavaScript
martinlippert
 
Breaking out of the endless callback look - #jsday Italy keynote
Breaking out of the endless callback look - #jsday Italy keynote
Christian Heilmann
 
Jsday
Jsday
Christian Heilmann
 
Essential Node.js for Web Developers from Developer Week 2013
Essential Node.js for Web Developers from Developer Week 2013
CA API Management
 
Choosing Javascript Libraries to Adopt for Development
Choosing Javascript Libraries to Adopt for Development
Edward Apostol
 
IBM InterConnect: Java vs JavaScript for Enterprise WebApps
IBM InterConnect: Java vs JavaScript for Enterprise WebApps
Chris Bailey
 
Webdevcon Keynote hh-2012-09-18
Webdevcon Keynote hh-2012-09-18
Pierre Joye
 
CommonJS Everywhere (Wakanday 2011)
CommonJS Everywhere (Wakanday 2011)
cadorn
 
20120306 dublin js
20120306 dublin js
Richard Rodger
 
Building a full-stack app with Golang and Google Cloud Platform in one week
Building a full-stack app with Golang and Google Cloud Platform in one week
Dr. Felix Raab
 
JavaScript for Enterprise Applications
JavaScript for Enterprise Applications
Piyush Katariya
 
20 Most Helpful Node.JS Open Source Projects.pdf
20 Most Helpful Node.JS Open Source Projects.pdf
iDataScientists
 
Building businesspost.ie using Node.js
Building businesspost.ie using Node.js
Richard Rodger
 
TypeScript - Javascript done right
TypeScript - Javascript done right
Wekoslav Stefanovski
 
GTUG JS will save us all
GTUG JS will save us all
Mário Valente
 
Client Server Web Apps with JavaScript and Java Rich Scalable and RESTful 1st...
Client Server Web Apps with JavaScript and Java Rich Scalable and RESTful 1st...
zubinrlondoit
 
Node.js #digpen presentation
Node.js #digpen presentation
GOSS Interactive
 
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
FITC
 
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
DownTheRabbitHole.js – How to Stay Sane in an Insane Ecosystem
FITC
 
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...
Ambassador Labs
 
Modern Architectures with Spring and JavaScript
Modern Architectures with Spring and JavaScript
martinlippert
 
Breaking out of the endless callback look - #jsday Italy keynote
Breaking out of the endless callback look - #jsday Italy keynote
Christian Heilmann
 
Jsday
Jsday
Christian Heilmann
 
Essential Node.js for Web Developers from Developer Week 2013
Essential Node.js for Web Developers from Developer Week 2013
CA API Management
 
Choosing Javascript Libraries to Adopt for Development
Choosing Javascript Libraries to Adopt for Development
Edward Apostol
 
IBM InterConnect: Java vs JavaScript for Enterprise WebApps
IBM InterConnect: Java vs JavaScript for Enterprise WebApps
Chris Bailey
 
Ad

Recently uploaded (20)

" How to survive with 1 billion vectors and not sell a kidney: our low-cost c...
" How to survive with 1 billion vectors and not sell a kidney: our low-cost c...
Fwdays
 
cnc-processing-centers-centateq-p-110-en.pdf
cnc-processing-centers-centateq-p-110-en.pdf
AmirStern2
 
"Database isolation: how we deal with hundreds of direct connections to the d...
"Database isolation: how we deal with hundreds of direct connections to the d...
Fwdays
 
Cyber Defense Matrix Workshop - RSA Conference
Cyber Defense Matrix Workshop - RSA Conference
Priyanka Aash
 
Using the SQLExecutor for Data Quality Management: aka One man's love for the...
Using the SQLExecutor for Data Quality Management: aka One man's love for the...
Safe Software
 
The Future of Product Management in AI ERA.pdf
The Future of Product Management in AI ERA.pdf
Alyona Owens
 
Mastering AI Workflows with FME by Mark Döring
Mastering AI Workflows with FME by Mark Döring
Safe Software
 
Salesforce Summer '25 Release Frenchgathering.pptx.pdf
Salesforce Summer '25 Release Frenchgathering.pptx.pdf
yosra Saidani
 
Daily Lesson Log MATATAG ICT TEchnology 8
Daily Lesson Log MATATAG ICT TEchnology 8
LOIDAALMAZAN3
 
“MPU+: A Transformative Solution for Next-Gen AI at the Edge,” a Presentation...
“MPU+: A Transformative Solution for Next-Gen AI at the Edge,” a Presentation...
Edge AI and Vision Alliance
 
AI VIDEO MAGAZINE - June 2025 - r/aivideo
AI VIDEO MAGAZINE - June 2025 - r/aivideo
1pcity Studios, Inc
 
From Manual to Auto Searching- FME in the Driver's Seat
From Manual to Auto Searching- FME in the Driver's Seat
Safe Software
 
"Scaling in space and time with Temporal", Andriy Lupa.pdf
"Scaling in space and time with Temporal", Andriy Lupa.pdf
Fwdays
 
"How to survive Black Friday: preparing e-commerce for a peak season", Yurii ...
"How to survive Black Friday: preparing e-commerce for a peak season", Yurii ...
Fwdays
 
Securing AI - There Is No Try, Only Do!.pdf
Securing AI - There Is No Try, Only Do!.pdf
Priyanka Aash
 
Oh, the Possibilities - Balancing Innovation and Risk with Generative AI.pdf
Oh, the Possibilities - Balancing Innovation and Risk with Generative AI.pdf
Priyanka Aash
 
OWASP Barcelona 2025 Threat Model Library
OWASP Barcelona 2025 Threat Model Library
PetraVukmirovic
 
Lessons Learned from Developing Secure AI Workflows.pdf
Lessons Learned from Developing Secure AI Workflows.pdf
Priyanka Aash
 
Quantum AI Discoveries: Fractal Patterns Consciousness and Cyclical Universes
Quantum AI Discoveries: Fractal Patterns Consciousness and Cyclical Universes
Saikat Basu
 
Quantum AI: Where Impossible Becomes Probable
Quantum AI: Where Impossible Becomes Probable
Saikat Basu
 
" How to survive with 1 billion vectors and not sell a kidney: our low-cost c...
" How to survive with 1 billion vectors and not sell a kidney: our low-cost c...
Fwdays
 
cnc-processing-centers-centateq-p-110-en.pdf
cnc-processing-centers-centateq-p-110-en.pdf
AmirStern2
 
"Database isolation: how we deal with hundreds of direct connections to the d...
"Database isolation: how we deal with hundreds of direct connections to the d...
Fwdays
 
Cyber Defense Matrix Workshop - RSA Conference
Cyber Defense Matrix Workshop - RSA Conference
Priyanka Aash
 
Using the SQLExecutor for Data Quality Management: aka One man's love for the...
Using the SQLExecutor for Data Quality Management: aka One man's love for the...
Safe Software
 
The Future of Product Management in AI ERA.pdf
The Future of Product Management in AI ERA.pdf
Alyona Owens
 
Mastering AI Workflows with FME by Mark Döring
Mastering AI Workflows with FME by Mark Döring
Safe Software
 
Salesforce Summer '25 Release Frenchgathering.pptx.pdf
Salesforce Summer '25 Release Frenchgathering.pptx.pdf
yosra Saidani
 
Daily Lesson Log MATATAG ICT TEchnology 8
Daily Lesson Log MATATAG ICT TEchnology 8
LOIDAALMAZAN3
 
“MPU+: A Transformative Solution for Next-Gen AI at the Edge,” a Presentation...
“MPU+: A Transformative Solution for Next-Gen AI at the Edge,” a Presentation...
Edge AI and Vision Alliance
 
AI VIDEO MAGAZINE - June 2025 - r/aivideo
AI VIDEO MAGAZINE - June 2025 - r/aivideo
1pcity Studios, Inc
 
From Manual to Auto Searching- FME in the Driver's Seat
From Manual to Auto Searching- FME in the Driver's Seat
Safe Software
 
"Scaling in space and time with Temporal", Andriy Lupa.pdf
"Scaling in space and time with Temporal", Andriy Lupa.pdf
Fwdays
 
"How to survive Black Friday: preparing e-commerce for a peak season", Yurii ...
"How to survive Black Friday: preparing e-commerce for a peak season", Yurii ...
Fwdays
 
Securing AI - There Is No Try, Only Do!.pdf
Securing AI - There Is No Try, Only Do!.pdf
Priyanka Aash
 
Oh, the Possibilities - Balancing Innovation and Risk with Generative AI.pdf
Oh, the Possibilities - Balancing Innovation and Risk with Generative AI.pdf
Priyanka Aash
 
OWASP Barcelona 2025 Threat Model Library
OWASP Barcelona 2025 Threat Model Library
PetraVukmirovic
 
Lessons Learned from Developing Secure AI Workflows.pdf
Lessons Learned from Developing Secure AI Workflows.pdf
Priyanka Aash
 
Quantum AI Discoveries: Fractal Patterns Consciousness and Cyclical Universes
Quantum AI Discoveries: Fractal Patterns Consciousness and Cyclical Universes
Saikat Basu
 
Quantum AI: Where Impossible Becomes Probable
Quantum AI: Where Impossible Becomes Probable
Saikat Basu
 

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