Radical Modularity

Aria Stewart (@aredridel)

definition of a module:
- basic definition: bit of software with a defined interface to the rest of the system
- npm definition: basic definition + a name
defining a module: intentional act (-> name, interface, ...)
publishing a module: intentional act (-> version numbers, dependencies, ...)
two open source movements:
- laws, copyright, licenses
- sharing, extending, building
modules as art (e.g. a module depending on every other module, a module taking the name of a namespace away)
small modules > big modules (as big modules are only a bunch of small modules that are not clearly defined)
modularize everything
- css (dr-frankenstyle, atomify-css)
- svg (x-link)
- templates & helpers (e.g. handlebars: {{fromPackage @hugo/templates/willi.tpl .}})
- React (require)
- i18n
- websites
- licenses
- JSON schemas
- legal terms
how to make modularity
- resolve.sync('@hugo/assets/willi.svg')
- resolve paths by main entry points (different for technologies -- e.g. index.js for Javascript, asset.svg for svg, ...)
simple interfaces win (e.g. unix: everything is a file)

naming a package: (unique, meaningful, memorable)
- list keywords (e.g. handlebars-helper-svg)
- join keywords (e.g. proxy require => proxyquire)
- fancy memorable name
modules can be finished (often times half a dozen commits) -- they do one thing well

Provide feedback