CommonJS via PINF JavaScript Loader - Introduction

941 views
851 views

Published on

The PINF JavaScript Loader is one extrapolated interpretation of the CommonJS standards that realizes the dream of portable JavaScript applications composed of libraries from all over the internet today. You don't need to wait for platform implementors to incorporate CommonJS standards. By building on PINF you bring CommonJS with you and in the process build momentum for CommonJS.

Christoph will give us a brief overview of CommonJS and then dive deep into PINF for JavaScript. He will communicate the motivation behind PINF and where it fits into the CommonJS community outlined above. You will walk away with practical advice you can apply immediately to build CommonJS based applications and libraries for production deployment.

Published in: Technology, Business
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
941
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • CommonJS via PINF JavaScript Loader - Introduction

    1. 1. CommonJS via BETAPINF JavaScript Loader github.com/pinf/loader-js (MIT Licensed) Introduction Boston JavaScript - October 14, 2011 by Christoph Dorn Copyright (c) 2011 Christoph Dorn <christoph@christophdorn.com> License: Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Various names and trademarks copyright respective parties.
    2. 2. About Christoph
    3. 3. About Christoph• 15+ years experience (web apps & business)
    4. 4. About Christoph• 15+ years experience (web apps & business)• Self taught developer
    5. 5. About Christoph• 15+ years experience (web apps & business)• Self taught developer• Independent
    6. 6. About Christoph• 15+ years experience (web apps & business)• Self taught developer• Independent• Playing with and integrating toolchains for years
    7. 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. 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. 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. 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. 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 managementFocus: Toolchain Design & Efficient Workflows
    12. 12. What drives me?
    13. 13. What drives me? I believe a major factor constraining software evolution isthe lack of refactorability as a core design goal of toolchains.
    14. 14. What drives me? I believe a major factor constraining software evolution isthe 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. 15. What drives me? I believe a major factor constraining software evolution isthe 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. 16. What drives me? I believe a major factor constraining software evolution isthe 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. 17. What drives me? I believe a major factor constraining software evolution isthe 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. 18. What drives me? I believe a major factor constraining software evolution isthe 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 itCommonJS: Developers seeking to build a JavaScript Ecosystem which allows for:
    19. 19. What drives me? I believe a major factor constraining software evolution isthe 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 itCommonJS: Developers seeking to build a JavaScript Ecosystem which allows for: • Code-sharing, interoperable libraries and portable applications
    20. 20. What drives me? I believe a major factor constraining software evolution isthe 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 itCommonJS: 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. 21. What drives me? I believe a major factor constraining software evolution isthe 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 itCommonJS: 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. 22. What funds my work?
    23. 23. What funds my work?
    24. 24. CommonJS Ecosystem Goals
    25. 25. CommonJS Ecosystem Goals• Consistent low-level APIs across platforms
    26. 26. CommonJS Ecosystem Goals• Consistent low-level APIs across platforms• Interoperable libraries
    27. 27. CommonJS Ecosystem Goals• Consistent low-level APIs across platforms• Interoperable libraries• Securable module sandboxes
    28. 28. CommonJS Ecosystem Goals• Consistent low-level APIs across platforms• Interoperable libraries• Securable module sandboxes• Portable applications
    29. 29. CommonJS Ecosystem Goals• Consistent low-level APIs across platforms• Interoperable libraries• Securable module sandboxes• Portable applications• Arbitrary & re-configurable program composition
    30. 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. 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. 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. 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. 34. CommonJS Ecosystem Goals• Consistent low-level APIs across platforms• Interoperable libraries• Securable module sandboxes• Portable applications• Arbitrary & re-configurable program composition• Non-conflicting namespaces• Publish code to URIs• Depend on code from URIs• Distributed package registry and repository• Consistent tooling interface
    35. 35. Separate Concerns
    36. 36. Separate ConcernsTo achieve our goals I believe we MUST:
    37. 37. Separate ConcernsTo achieve our goals I believe we MUST: • Clearly separate concerns
    38. 38. Separate ConcernsTo achieve our goals I believe we MUST: • Clearly separate concerns • Logically (within runtime by using different API methods vs overloading)
    39. 39. Separate ConcernsTo 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. 40. Separate ConcernsTo 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. 41. Separate ConcernsTo 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. 42. Separate ConcernsTo 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 indirectionWe are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle.
    43. 43. Separate ConcernsTo 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 indirectionWe 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. 44. Separate ConcernsTo 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 indirectionWe 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. 45. Separate ConcernsTo 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 indirectionWe 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. 46. Separate ConcernsTo 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 indirectionWe 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. 47. Separate ConcernsTo 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 indirectionWe are talking about layered re-configurability of a program from the outside in at any point of the program’s pre-run lifecycle.It must be: • Easy to learn and understand • Restrict only where absolutely necessary • Lightweight and easily implemented
    48. 48. A/The Solution
    49. 49. A/The SolutionCommonJS/Modules/2.0 (draft)
    50. 50. A/The SolutionCommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory
    51. 51. A/The SolutionCommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id)
    52. 52. A/The SolutionCommonJS/Modules/2.0 (draft) • function (require, exports, module) {} - Factory • require(“./<id>”); - Static linking (rel_id) • module.load($rel_id, function callback() {}); - Dynamic linking
    53. 53. A/The SolutionCommonJS/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. 54. A/The SolutionCommonJS/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. 55. A/The SolutionCommonJS/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. 56. A/The SolutionCommonJS/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); - TransportCommonJS/Package/Mappings/C (proposal; amendment required)
    57. 57. A/The SolutionCommonJS/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); - TransportCommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators
    58. 58. A/The SolutionCommonJS/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); - TransportCommonJS/Package/Mappings/C (proposal; amendment required) • {“archive”:”<url>”}, {“location”:”<path>”}, ... - Locators • package.json ~ {“mappings”: {“<alias>”:<locator>}} - Pkg. Descriptor
    59. 59. A/The SolutionCommonJS/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); - TransportCommonJS/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. 60. A/The SolutionCommonJS/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); - TransportCommonJS/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. 61. A/The SolutionCommonJS/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); - TransportCommonJS/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. 62. A/The SolutionCommonJS/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); - TransportCommonJS/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. 63. A/The SolutionCommonJS/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); - TransportCommonJS/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. 64. Logically separate concerns Plain Module Lazy ASYNC Strict ASYNC
    65. 65. Physical layers of indirection
    66. 66. PINF JS Loader Overview
    67. 67. PINF JS Loader Overview• Loads multiple module source formats:
    68. 68. PINF JS Loader Overview• Loads multiple module source formats: • Asynchronous Module Definition (AMD)
    69. 69. PINF JS Loader Overview• Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1
    70. 70. PINF JS Loader Overview• Loads multiple module source formats: • Asynchronous Module Definition (AMD) • CommonJS Modules 1.1 • CommonJS Modules 2.0 (draft)
    71. 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. 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. 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. 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. 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. 76. Where does the loader typically sit?
    77. 77. Architecture & process of the loader
    78. 78. Architecture & process of the loader
    79. 79. Dependency trees afforded by the loader
    80. 80. Demo Time! github.com/cadorn/ace-extjsgithub.com/pinf/test-programs-js
    81. 81. Thank you!Slides and links will be made available at:github.com/pinf/loader-js/wiki

    ×