Confirmed users
157
edits
WebAPI/DesignGuidelines: Difference between revisions
→Design considerations
| Line 65: | Line 65: | ||
* work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives) | * work with the strengths of the web and JavaScript (e.g. IndexedDB works directly with JS objects and doesn't require serialization to SQL primitives) | ||
* use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...) | * use new features instead of old ones (e.g. Promises instead of DOMRequests, WebIDL, ...) | ||
** | ** But there is nothing wrong with events and such. | ||
** Don't use new features just for the sake of being cool and hip. Use them when they make sense. | |||
* the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered | * the design of APIs only exposed to privileged or certified apps is less important to get right the first time than those that will be exposed to the web at large but if this route is chosen, future standardization efforts will be hampered | ||
* standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors | * standardization is sometimes not necessary for APIs designed for very narrow use cases or those that have no hope of being implemented by other UA vendors | ||