Technical Analysis: Client Side Dependency Management about mock-crud-app HOT 2 CLOSED

Resources

https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/
https://requirejs.org/docs/start.html

Past

• Libraries like jQuery were "imported" by assigning them to global variables
  • Global scope presents security risk due to hijacking
• All subsequent scripts needed to be in a specific order
  • Hard to see dependencies, usually not explicitly stated
• Mandatory Synchronous script loading

Modules

• Provide organization of related code
• Import/Export syntax provides dependency graph
• Common JS
• ECMA Script Modules

ES Module Spec

• Import/Export dependency graph
• File -> Module Record
• Module Record -> Module Instance (Code + State)
• 3 steps
  1. Construction
  • Files are converted to module records
  2. Instantiation
  • Module records are linked
  3. Evaluation
  • Code is ran and values are filled
• The 3 steps can be ran asynchronously based on implementation
  • ES Modules spec: States how to get module records & instantitate & evaluate (Doesn't state how to get files)
  • Loader is what fetches the files (eg. HTML spec specifies loader in the browser)
• Loader puppeteers the ES Module Spec (Calls Parse, Instantiate, Evaluate)

Common JS Spec

• Node JS uses Common JS specs
• Synchronous
  • Modules & Dependencies run the 3 steps all at once (no breaks in between)
• Loading files from the filesystem takes less time than downloading files from the internet

Require JS

• Asynchronous module loader
  • Advantageous when speed is a concern on the client-side, we don't want to block page rendering
  • eg. Node JS uses synchronous script loading on the serverside
• AMD (Asynchronous Module Definition)
  • Has some extra quirks outside of Common JS specs (Haven't looked deeply into these)

Browserify

• Common JS
• Can be managed by npm

from mock-crud-app.

We'll go with Require JS as our solution

from mock-crud-app.