[johnzabroski]

Also...

> 4. Strict semver all the things > 5. Tiny module all the things! > The smaller the feature set of the low-level modules, the easier it is to avoid breaking changes. > 6. Expose the simplest API possible.

This is great, but what I would rather see is strict code coverage guidelines on contributions. The whole point behind having micro libraries is that writing unit tests should be easier, because there are simpler dependencies and each simple dependency is easier to mock.

Similarly,

> 7. Optimize for minimal DOM manipulation and performance.

The best way to optimize for performance is to include various performance testing, and never let performance get slower when considering patch contributions.

In short, less marketing fluff, more community process.

[HenrikJoreteg]

4. we are enforcing this with jshint and pre-commit hooks (should better document that, but we are doing that).

7. Yup, we'll keep doing more here. We just announced it! :)

"less marketing fluff" well, it's an intro post attempting to explain something new. And hey, you're reading it so maybe the marketing worked ;) But, point taken.

API reference: http://ampersandjs.com/docs All the codez: https://github.com/AmpersandJS Guides: http://ampersandjs.com/learn/

I'm not saying you should use it, it's what we use and we're sharing it with the world. If you're already happy with your tools, just keep on keepin' on.