| 1 | sg
|
| 2 | ==
|
| 3 |
|
| 4 | sg is short for singularity -- having only to include one module to get all
|
| 5 | the functional programming goodness for Node.js you need. But 'sg' was taken
|
| 6 | on npm, so I had to use 'sgsg' -- how ironic is that?
|
| 7 |
|
| 8 | sg is a _semi-opinionated_, _functional_, _feed-forward_ network application meta-framework.
|
| 9 |
|
| 10 | * Semi-opinionated: If you use sg, you're pretty much forced to adopt a handful of
|
| 11 | conventions that sg uses. But you're probably using them anyway.
|
| 12 | * Functional -- sg almost never uses `new`, `prototype`, or other OO-isms.
|
| 13 | * Functional: Pass the subject as the first parameter.
|
| 14 | * Feed-forward: Programmers understand code that is active much more than they
|
| 15 | understand declarative code.
|
| 16 |
|
| 17 |
|
| 18 | ## Giants
|
| 19 |
|
| 20 | sg leverages a lot of the best functional modules for Node.js, like underscore, async, etc.
|
| 21 | My intention is not to steal any of those libraries' thunder, but to give them the
|
| 22 | credit they are due. sg does, however, sometimes re-wrap the interfaces to be
|
| 23 | consistent, and to name things using the functional naming conventions that I learned.
|
| 24 |
|
| 25 | The un-changed libraries that sg uses are available as `sg.extlibs.yourfavoritelibrary`.
|
| 26 |
|
| 27 |
|