If you read my previous post, The time is right for a DOM templating API, you might be wondering what such an API would look like.
Let's dive into that question now.
What are we building?
First, let's clarify what we're trying to design here, because when people hear the abstract template API idea described, before there's a concrete proposal or examples, they can sometimes think of very different things.
In webcomponents/1069 I propose that we add a "declarative JavaScript templating API"
Declarative means that the developer is describing what they want, not how to achieve it. What exactly constitutes "declarative" is often debatable, and under every declarative API is an imperative implementation, but hopefully people can align on the spirit of the word.
By "templating" we mean the ability to describe the DOM that the developer wants to create and update in a form that resembles the output. This includes syntaxes like JSX and lit-html, which for some people count as something other than templating. For our purposes, they are.
Taken together, "declarative DOM templating" is something that is very, very common. All major frameworks today have declarative templating at their core.
But we're going to narrow our focus a bit JavaScript APIs.
By "JavaScript API" we mean methods, classes, etc. that are part of the overall DOM JavaScript API surface. Something that's a sibling and alternative to innerHTML , importNode() , and a bunch of other DOM APIs that web developers and frameworks use to create and update DOM. But also, we mean that script-like abilities will be left to JavaScript, not added to markup.
... continue reading