Templates and Component Development
Editable templates are the default
Modern AEM Sites projects use editable templates: a template node of type cq:template under /conf/<project>/settings/wcm/templates with three parts - structure (locked layout pieces such as header/footer), initial content (what a newly created page starts with), and policies (design-time configuration bound to a template or its components). Editable templates are only offered for creation where the site's cq:allowedTemplates and template type allow it. Static templates (under /apps/.../templates) still appear in exam questions; recognise them as the legacy pattern with a cq:design_dialog and design stored under /etc/designs.
Components: proxy, dialog, HTL, models
Best practice is a proxy component under /apps with sling:resourceSuperType pointing at a Core Component in /libs, so you inherit logic and only override what you need. Authoring UI comes from cq:dialog (page-level, per-instance) versus cq:design_dialog/policies (shared configuration). Rendering uses HTL (Sightly): data-sly-use to bind a Sling Model or JS use-object, data-sly-test, data-sly-list, data-sly-repeat, data-sly-resource, data-sly-template/data-sly-call. HTL auto-contextualises output (html, attribute, uri), so avoid context='unsafe' unless sanitised.
Traps: confusing sling:resourceSuperType (inheritance) with sling:resourceType (dispatch); assuming a design dialog setting is per-component-instance (it is not - policies are shared); using data-sly-use where data-sly-resource is needed to include another component.
Worked example: a teaser component - create /apps/mysite/components/teaser with sling:resourceSuperType = core/wcm/components/teaser/v2/teaser, add a cq:dialog that hides inherited fields via sling:hideProperties, and a policy mapping dialogs to the component on the template. Result: Core Component logic, custom authoring fields, per-template configuration.