| OLD | NEW |
| (Empty) | |
| 1 Design Principles |
| 2 ================= |
| 3 |
| 4 * There should be no objects that represent live state that reflects |
| 5 some other state, since they are expensive to maintain. e.g. no |
| 6 HTMLCollection. |
| 7 |
| 8 * Property getters should be efficient. If an operation is inefficient |
| 9 it should be a method instead. e.g. document.getForms(), not |
| 10 document.forms. |
| 11 |
| 12 * There should be no APIs that require synchronously computing layout |
| 13 (or other expensive operations). |
| 14 |
| 15 * Any API that can be implemented in terms of another is a convenience |
| 16 API and should be implemented in a framework, not as part of the |
| 17 core. e.g., no document.forms. |
| 18 |
| 19 - having APIs for performance reasons is fine (e.g. querySelector() |
| 20 could be implemented by crawling but it would be so much faster if |
| 21 it could use the runtime's ID hashtables that it's ok to support |
| 22 natively) |
| 23 |
| 24 * APIs that encourage bad practices should not exist. e.g., no |
| 25 document.write(), innerHTML, insertAdjacentHTML(), etc. |
| 26 |
| 27 * If we expose some aspect of a mojo service (e.g. touch events) we |
| 28 should expose/wrap all of it (e.g. mousewheel) so that there's no |
| 29 cognitive cliff when interacting with that service |
| 30 |
| 31 * APIs should always spell acronyms like words (findId, not findID; |
| 32 XmlHttpRequest, not XMLHttpRequest) |
| OLD | NEW |