canmove, Confirmed users
901
edits
WebAPI/DesignGuidelines: Difference between revisions
→Considerations
| Line 13: | Line 13: | ||
* 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, ...) | ||
* 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 | * 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 | |||
* bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers | * bringing existing technologies to the web gives a chance to mask details that aren't of interest or important to web developers | ||
* web APIs are "forever" so be very careful with what you expose to the web! | * web APIs are "forever" so be very careful with what you expose to the web! | ||