Just over two years after Fastdom was born, I’m happy to announce a formal V1 release.
Fastdom V1 is 20% smaller (600 bytes minified gzipped) than the previous release. This is largely due to code simplification and removal of some rarely used APIs.
Fastdom aims to be a tiny unopinionated library, for this reason, in order to meet everyone’s particular needs, we added the ability to
.extend() the core library to add additional functionality.
Fastdom ships with a couple of core-extensions that address some higher-level features people have been asking for.
Fastdom V1 comes with some (breaking) API name changes.
These name changes were suggested by Paul Irish in an effort to improve clarity over the type of code that should be contained in each block.
fastdom.defer() as its use-cases were ambiguous and it was rarely used.
It’s very important that all DOM mutations or measurements go through
fastdom to ensure good performance; to help you with this we wrote
fastdom-strict. When fastdom-strict.js is loaded, it will throw errors when sensitive DOM APIs are called at the wrong time.
This is useful when working with a large team who might not all be aware of
fastdom or its benefits. It can also prove useful for catching ‘un-fastdom-ed’ code when migrating an app to
fastdom-strictwill not throw if nodes are not attached to the document.
- You should use fastdom-strict in development to catch rendering performance issues before they hit production. It is probably not good to use fastdom-strict in production as it wraps APIs.