HTML Element versus Javascript Template Literals
Mozilla says Web components consist of three main technologies:
- Custom elements
- Shadow DOM
- HTML templates
Is number 3, "HTML templates", even necessary in light of ECMAscript's Template Literals?
Look at this example I got from James Milner:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Web Component</title>
<script type="text/javascript">
// We define an ES6 class that extends HTMLElement
class CounterElement extends HTMLElement{
constructor() {
super();
// Initialise the counter value
this.counter = 0;
// We attach an open shadow root to the custom element
const shadowRoot= this.attachShadow({mode: 'open'});
// We define some inline styles using a template string
const styles=`
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
`;
// We provide the shadow root with some HTML
shadowRoot.innerHTML = `
<style>${styles}</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
`;
// We can query the shadow root for internal elements
// in this case the button
this.incrementButton = this.shadowRoot.querySelector('#counter-increment');
this.decrementButton = this.shadowRoot.querySelector('#counter-decrement');
this.counterValue = this.shadowRoot.querySelector('#counter-value');
// We can bind an event which references one of the class methods
this.incrementButton.addEventListener("click", this.decrement.bind(this));
this.decrementButton.addEventListener("click", this.increment.bind(this));
}
increment() {
this.counter++
this.invalidate();
}
decrement() {
this.counter--
this.invalidate();
}
// Call when the counter changes value
invalidate() {
this.counterValue.innerHTML = this.counter;
}
}
// This is where the actual element is defined for use in the DOM
customElements.define('counter-element', CounterElement);
</script>
</head>
<body>
<counter-element></counter-element>
</body>
</html>
Notice how he doesn't use an HTML template, but instead uses an ecmascript template literal to set the innerHTML of the shadowRoot.
After this, he uses querySelector to get internal elements of the shadowRoot and he ultimately adds event listeners to the increment and decrement buttons.
If you were to use a HTML template, instead of an ecmascript template literal, what does this gain you?
Conceptually, I'm struggling to find a situation where I'd prefer an HTML Template Element over an Ecmascript Template Literal.
Please advise.
javascript web-component template-literals hyperhtml html-templates
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
add a comment |
Mozilla says Web components consist of three main technologies:
- Custom elements
- Shadow DOM
- HTML templates
Is number 3, "HTML templates", even necessary in light of ECMAscript's Template Literals?
Look at this example I got from James Milner:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Web Component</title>
<script type="text/javascript">
// We define an ES6 class that extends HTMLElement
class CounterElement extends HTMLElement{
constructor() {
super();
// Initialise the counter value
this.counter = 0;
// We attach an open shadow root to the custom element
const shadowRoot= this.attachShadow({mode: 'open'});
// We define some inline styles using a template string
const styles=`
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
`;
// We provide the shadow root with some HTML
shadowRoot.innerHTML = `
<style>${styles}</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
`;
// We can query the shadow root for internal elements
// in this case the button
this.incrementButton = this.shadowRoot.querySelector('#counter-increment');
this.decrementButton = this.shadowRoot.querySelector('#counter-decrement');
this.counterValue = this.shadowRoot.querySelector('#counter-value');
// We can bind an event which references one of the class methods
this.incrementButton.addEventListener("click", this.decrement.bind(this));
this.decrementButton.addEventListener("click", this.increment.bind(this));
}
increment() {
this.counter++
this.invalidate();
}
decrement() {
this.counter--
this.invalidate();
}
// Call when the counter changes value
invalidate() {
this.counterValue.innerHTML = this.counter;
}
}
// This is where the actual element is defined for use in the DOM
customElements.define('counter-element', CounterElement);
</script>
</head>
<body>
<counter-element></counter-element>
</body>
</html>
Notice how he doesn't use an HTML template, but instead uses an ecmascript template literal to set the innerHTML of the shadowRoot.
After this, he uses querySelector to get internal elements of the shadowRoot and he ultimately adds event listeners to the increment and decrement buttons.
If you were to use a HTML template, instead of an ecmascript template literal, what does this gain you?
Conceptually, I'm struggling to find a situation where I'd prefer an HTML Template Element over an Ecmascript Template Literal.
Please advise.
javascript web-component template-literals hyperhtml html-templates
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
1
Another issue is that template literals can be transpiled easily (and with Babel and polyfills, which any serious project will have, the project will work in IE), while<template>elements appear to be not supported in IE
– CertainPerformance
Nov 15 '18 at 2:48
1
A counter argument is for keeping your HTML as HTML, separation of concerns and all that. If you want to change your document structure, change your HTML document, not javascript. That is more intuitive for me . The lack of IE support for templates does indeed suck. There is a kind of workaround by using<script type="text/template" id="postTemplate">in place of<template>. For an example with jquery see: stackoverflow.com/questions/52376527/… . jQuery isn't actually required it's just first of my examples that I found.
– Jon P
Nov 15 '18 at 3:13
"Separation of concerns" has its place in general web page development. However, one of my favorite aspects of web components is that you can encapsulate all concerns (structure, style, and behavior) in one place. This simplifies reuse.
– Lonnie Best
Nov 15 '18 at 3:30
1
Possible duplicate of Template html and template string in web components
– Supersharp
Nov 15 '18 at 9:47
Template literals are a JS syntactic sugar thing and have nothing to do with HTML functionality.
– Bergi
Nov 25 '18 at 13:28
add a comment |
Mozilla says Web components consist of three main technologies:
- Custom elements
- Shadow DOM
- HTML templates
Is number 3, "HTML templates", even necessary in light of ECMAscript's Template Literals?
Look at this example I got from James Milner:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Web Component</title>
<script type="text/javascript">
// We define an ES6 class that extends HTMLElement
class CounterElement extends HTMLElement{
constructor() {
super();
// Initialise the counter value
this.counter = 0;
// We attach an open shadow root to the custom element
const shadowRoot= this.attachShadow({mode: 'open'});
// We define some inline styles using a template string
const styles=`
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
`;
// We provide the shadow root with some HTML
shadowRoot.innerHTML = `
<style>${styles}</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
`;
// We can query the shadow root for internal elements
// in this case the button
this.incrementButton = this.shadowRoot.querySelector('#counter-increment');
this.decrementButton = this.shadowRoot.querySelector('#counter-decrement');
this.counterValue = this.shadowRoot.querySelector('#counter-value');
// We can bind an event which references one of the class methods
this.incrementButton.addEventListener("click", this.decrement.bind(this));
this.decrementButton.addEventListener("click", this.increment.bind(this));
}
increment() {
this.counter++
this.invalidate();
}
decrement() {
this.counter--
this.invalidate();
}
// Call when the counter changes value
invalidate() {
this.counterValue.innerHTML = this.counter;
}
}
// This is where the actual element is defined for use in the DOM
customElements.define('counter-element', CounterElement);
</script>
</head>
<body>
<counter-element></counter-element>
</body>
</html>
Notice how he doesn't use an HTML template, but instead uses an ecmascript template literal to set the innerHTML of the shadowRoot.
After this, he uses querySelector to get internal elements of the shadowRoot and he ultimately adds event listeners to the increment and decrement buttons.
If you were to use a HTML template, instead of an ecmascript template literal, what does this gain you?
Conceptually, I'm struggling to find a situation where I'd prefer an HTML Template Element over an Ecmascript Template Literal.
Please advise.
javascript web-component template-literals hyperhtml html-templates
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
Mozilla says Web components consist of three main technologies:
- Custom elements
- Shadow DOM
- HTML templates
Is number 3, "HTML templates", even necessary in light of ECMAscript's Template Literals?
Look at this example I got from James Milner:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Web Component</title>
<script type="text/javascript">
// We define an ES6 class that extends HTMLElement
class CounterElement extends HTMLElement{
constructor() {
super();
// Initialise the counter value
this.counter = 0;
// We attach an open shadow root to the custom element
const shadowRoot= this.attachShadow({mode: 'open'});
// We define some inline styles using a template string
const styles=`
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
`;
// We provide the shadow root with some HTML
shadowRoot.innerHTML = `
<style>${styles}</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
`;
// We can query the shadow root for internal elements
// in this case the button
this.incrementButton = this.shadowRoot.querySelector('#counter-increment');
this.decrementButton = this.shadowRoot.querySelector('#counter-decrement');
this.counterValue = this.shadowRoot.querySelector('#counter-value');
// We can bind an event which references one of the class methods
this.incrementButton.addEventListener("click", this.decrement.bind(this));
this.decrementButton.addEventListener("click", this.increment.bind(this));
}
increment() {
this.counter++
this.invalidate();
}
decrement() {
this.counter--
this.invalidate();
}
// Call when the counter changes value
invalidate() {
this.counterValue.innerHTML = this.counter;
}
}
// This is where the actual element is defined for use in the DOM
customElements.define('counter-element', CounterElement);
</script>
</head>
<body>
<counter-element></counter-element>
</body>
</html>
Notice how he doesn't use an HTML template, but instead uses an ecmascript template literal to set the innerHTML of the shadowRoot.
After this, he uses querySelector to get internal elements of the shadowRoot and he ultimately adds event listeners to the increment and decrement buttons.
If you were to use a HTML template, instead of an ecmascript template literal, what does this gain you?
Conceptually, I'm struggling to find a situation where I'd prefer an HTML Template Element over an Ecmascript Template Literal.
Please advise.
javascript web-component template-literals hyperhtml html-templates
javascript web-component template-literals hyperhtml html-templates
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
edited Nov 15 '18 at 2:53
Lonnie Best
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
asked Nov 15 '18 at 2:41
Lonnie BestLonnie Best
2,77153145
2,77153145
1
Another issue is that template literals can be transpiled easily (and with Babel and polyfills, which any serious project will have, the project will work in IE), while<template>elements appear to be not supported in IE
– CertainPerformance
Nov 15 '18 at 2:48
1
A counter argument is for keeping your HTML as HTML, separation of concerns and all that. If you want to change your document structure, change your HTML document, not javascript. That is more intuitive for me . The lack of IE support for templates does indeed suck. There is a kind of workaround by using<script type="text/template" id="postTemplate">in place of<template>. For an example with jquery see: stackoverflow.com/questions/52376527/… . jQuery isn't actually required it's just first of my examples that I found.
– Jon P
Nov 15 '18 at 3:13
"Separation of concerns" has its place in general web page development. However, one of my favorite aspects of web components is that you can encapsulate all concerns (structure, style, and behavior) in one place. This simplifies reuse.
– Lonnie Best
Nov 15 '18 at 3:30
1
Possible duplicate of Template html and template string in web components
– Supersharp
Nov 15 '18 at 9:47
Template literals are a JS syntactic sugar thing and have nothing to do with HTML functionality.
– Bergi
Nov 25 '18 at 13:28
add a comment |
1
Another issue is that template literals can be transpiled easily (and with Babel and polyfills, which any serious project will have, the project will work in IE), while<template>elements appear to be not supported in IE
– CertainPerformance
Nov 15 '18 at 2:48
1
A counter argument is for keeping your HTML as HTML, separation of concerns and all that. If you want to change your document structure, change your HTML document, not javascript. That is more intuitive for me . The lack of IE support for templates does indeed suck. There is a kind of workaround by using<script type="text/template" id="postTemplate">in place of<template>. For an example with jquery see: stackoverflow.com/questions/52376527/… . jQuery isn't actually required it's just first of my examples that I found.
– Jon P
Nov 15 '18 at 3:13
"Separation of concerns" has its place in general web page development. However, one of my favorite aspects of web components is that you can encapsulate all concerns (structure, style, and behavior) in one place. This simplifies reuse.
– Lonnie Best
Nov 15 '18 at 3:30
1
Possible duplicate of Template html and template string in web components
– Supersharp
Nov 15 '18 at 9:47
Template literals are a JS syntactic sugar thing and have nothing to do with HTML functionality.
– Bergi
Nov 25 '18 at 13:28
1
1
Another issue is that template literals can be transpiled easily (and with Babel and polyfills, which any serious project will have, the project will work in IE), while
<template> elements appear to be not supported in IE– CertainPerformance
Nov 15 '18 at 2:48
Another issue is that template literals can be transpiled easily (and with Babel and polyfills, which any serious project will have, the project will work in IE), while
<template> elements appear to be not supported in IE– CertainPerformance
Nov 15 '18 at 2:48
1
1
A counter argument is for keeping your HTML as HTML, separation of concerns and all that. If you want to change your document structure, change your HTML document, not javascript. That is more intuitive for me . The lack of IE support for templates does indeed suck. There is a kind of workaround by using
<script type="text/template" id="postTemplate"> in place of <template>. For an example with jquery see: stackoverflow.com/questions/52376527/… . jQuery isn't actually required it's just first of my examples that I found.– Jon P
Nov 15 '18 at 3:13
A counter argument is for keeping your HTML as HTML, separation of concerns and all that. If you want to change your document structure, change your HTML document, not javascript. That is more intuitive for me . The lack of IE support for templates does indeed suck. There is a kind of workaround by using
<script type="text/template" id="postTemplate"> in place of <template>. For an example with jquery see: stackoverflow.com/questions/52376527/… . jQuery isn't actually required it's just first of my examples that I found.– Jon P
Nov 15 '18 at 3:13
"Separation of concerns" has its place in general web page development. However, one of my favorite aspects of web components is that you can encapsulate all concerns (structure, style, and behavior) in one place. This simplifies reuse.
– Lonnie Best
Nov 15 '18 at 3:30
"Separation of concerns" has its place in general web page development. However, one of my favorite aspects of web components is that you can encapsulate all concerns (structure, style, and behavior) in one place. This simplifies reuse.
– Lonnie Best
Nov 15 '18 at 3:30
1
1
Possible duplicate of Template html and template string in web components
– Supersharp
Nov 15 '18 at 9:47
Possible duplicate of Template html and template string in web components
– Supersharp
Nov 15 '18 at 9:47
Template literals are a JS syntactic sugar thing and have nothing to do with HTML functionality.
– Bergi
Nov 25 '18 at 13:28
Template literals are a JS syntactic sugar thing and have nothing to do with HTML functionality.
– Bergi
Nov 25 '18 at 13:28
add a comment |
1 Answer
1
active
oldest
votes
The template tag is not 'required' for Web Components per se. It probably made more sense when HTML Imports were being pushed, allowing for importing and reusing HTML snippets, but that has since ceased. Here you could have imported a template and reused that.
It's important to note the specifications are designed to be standalone and can be used interdependently of each other also, which makes them versatile. The HTML tag has use cases outside of the realm of Web Components; it's useful because it allows you to define a piece of markup that doesn't render until instantiated via JavaScript later on. Indeed you can use templates without using any of the other specifications (Custom Elements, Shadow DOM etc).
The template tag can certainly be used in conjunction with the other specs. For example, we could have used it in the example shown to arguably make the code less imperative and more markup focused like so:
<template id="counterTemplate">
<style>
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
</template>
And then use this later in JavaScript like so:
const template = document.querySelector('#counterTemplate');
const counter = document.cloneNode(template);
shadowRoot.appendChild(counter);
The downside here is that it would require that the template existed in the DOM prior to the instantiation as it is relying on the #counterTemplate template being there. In some ways this makes the Custom Element less portable, hence why template literal might be more desirable. I haven't tested the performance of both, but my gut tells me that the template would possibly be more performant.
Disclaimer: I wrote the original blog post
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
Indeed, it would make portability more burdensome.
– Lonnie Best
Nov 15 '18 at 15:57
Another topic, I haven't found information on is memory consumption when placing style in a shadow root.
– Lonnie Best
Nov 15 '18 at 15:58
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311660%2fhtml-template-element-versus-javascript-template-literals%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The template tag is not 'required' for Web Components per se. It probably made more sense when HTML Imports were being pushed, allowing for importing and reusing HTML snippets, but that has since ceased. Here you could have imported a template and reused that.
It's important to note the specifications are designed to be standalone and can be used interdependently of each other also, which makes them versatile. The HTML tag has use cases outside of the realm of Web Components; it's useful because it allows you to define a piece of markup that doesn't render until instantiated via JavaScript later on. Indeed you can use templates without using any of the other specifications (Custom Elements, Shadow DOM etc).
The template tag can certainly be used in conjunction with the other specs. For example, we could have used it in the example shown to arguably make the code less imperative and more markup focused like so:
<template id="counterTemplate">
<style>
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
</template>
And then use this later in JavaScript like so:
const template = document.querySelector('#counterTemplate');
const counter = document.cloneNode(template);
shadowRoot.appendChild(counter);
The downside here is that it would require that the template existed in the DOM prior to the instantiation as it is relying on the #counterTemplate template being there. In some ways this makes the Custom Element less portable, hence why template literal might be more desirable. I haven't tested the performance of both, but my gut tells me that the template would possibly be more performant.
Disclaimer: I wrote the original blog post
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
Indeed, it would make portability more burdensome.
– Lonnie Best
Nov 15 '18 at 15:57
Another topic, I haven't found information on is memory consumption when placing style in a shadow root.
– Lonnie Best
Nov 15 '18 at 15:58
add a comment |
The template tag is not 'required' for Web Components per se. It probably made more sense when HTML Imports were being pushed, allowing for importing and reusing HTML snippets, but that has since ceased. Here you could have imported a template and reused that.
It's important to note the specifications are designed to be standalone and can be used interdependently of each other also, which makes them versatile. The HTML tag has use cases outside of the realm of Web Components; it's useful because it allows you to define a piece of markup that doesn't render until instantiated via JavaScript later on. Indeed you can use templates without using any of the other specifications (Custom Elements, Shadow DOM etc).
The template tag can certainly be used in conjunction with the other specs. For example, we could have used it in the example shown to arguably make the code less imperative and more markup focused like so:
<template id="counterTemplate">
<style>
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
</template>
And then use this later in JavaScript like so:
const template = document.querySelector('#counterTemplate');
const counter = document.cloneNode(template);
shadowRoot.appendChild(counter);
The downside here is that it would require that the template existed in the DOM prior to the instantiation as it is relying on the #counterTemplate template being there. In some ways this makes the Custom Element less portable, hence why template literal might be more desirable. I haven't tested the performance of both, but my gut tells me that the template would possibly be more performant.
Disclaimer: I wrote the original blog post
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
Indeed, it would make portability more burdensome.
– Lonnie Best
Nov 15 '18 at 15:57
Another topic, I haven't found information on is memory consumption when placing style in a shadow root.
– Lonnie Best
Nov 15 '18 at 15:58
add a comment |
The template tag is not 'required' for Web Components per se. It probably made more sense when HTML Imports were being pushed, allowing for importing and reusing HTML snippets, but that has since ceased. Here you could have imported a template and reused that.
It's important to note the specifications are designed to be standalone and can be used interdependently of each other also, which makes them versatile. The HTML tag has use cases outside of the realm of Web Components; it's useful because it allows you to define a piece of markup that doesn't render until instantiated via JavaScript later on. Indeed you can use templates without using any of the other specifications (Custom Elements, Shadow DOM etc).
The template tag can certainly be used in conjunction with the other specs. For example, we could have used it in the example shown to arguably make the code less imperative and more markup focused like so:
<template id="counterTemplate">
<style>
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
</template>
And then use this later in JavaScript like so:
const template = document.querySelector('#counterTemplate');
const counter = document.cloneNode(template);
shadowRoot.appendChild(counter);
The downside here is that it would require that the template existed in the DOM prior to the instantiation as it is relying on the #counterTemplate template being there. In some ways this makes the Custom Element less portable, hence why template literal might be more desirable. I haven't tested the performance of both, but my gut tells me that the template would possibly be more performant.
Disclaimer: I wrote the original blog post
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
The template tag is not 'required' for Web Components per se. It probably made more sense when HTML Imports were being pushed, allowing for importing and reusing HTML snippets, but that has since ceased. Here you could have imported a template and reused that.
It's important to note the specifications are designed to be standalone and can be used interdependently of each other also, which makes them versatile. The HTML tag has use cases outside of the realm of Web Components; it's useful because it allows you to define a piece of markup that doesn't render until instantiated via JavaScript later on. Indeed you can use templates without using any of the other specifications (Custom Elements, Shadow DOM etc).
The template tag can certainly be used in conjunction with the other specs. For example, we could have used it in the example shown to arguably make the code less imperative and more markup focused like so:
<template id="counterTemplate">
<style>
:host {
position: relative;
font-family: sans-serif;
}
#counter-increment, #counter-decrement {
width: 60px;
height: 30px;
margin: 20px;
background: none;
border: 1px solid black;
}
#counter-value {
font-weight: bold;
}
</style>
<h3>Counter</h3>
<slot name='counter-content'>Button</slot>
<button id='counter-increment'> - </button>
<span id='counter-value'> 0 </span>
<button id='counter-decrement'> + </button>
</template>
And then use this later in JavaScript like so:
const template = document.querySelector('#counterTemplate');
const counter = document.cloneNode(template);
shadowRoot.appendChild(counter);
The downside here is that it would require that the template existed in the DOM prior to the instantiation as it is relying on the #counterTemplate template being there. In some ways this makes the Custom Element less portable, hence why template literal might be more desirable. I haven't tested the performance of both, but my gut tells me that the template would possibly be more performant.
Disclaimer: I wrote the original blog post
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
edited Nov 25 '18 at 12:46
Lonnie Best
2,77153145
2,77153145
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
answered Nov 15 '18 at 11:01
James MilnerJames Milner
4041714
4041714
Indeed, it would make portability more burdensome.
– Lonnie Best
Nov 15 '18 at 15:57
Another topic, I haven't found information on is memory consumption when placing style in a shadow root.
– Lonnie Best
Nov 15 '18 at 15:58
add a comment |
Indeed, it would make portability more burdensome.
– Lonnie Best
Nov 15 '18 at 15:57
Another topic, I haven't found information on is memory consumption when placing style in a shadow root.
– Lonnie Best
Nov 15 '18 at 15:58
Indeed, it would make portability more burdensome.
– Lonnie Best
Nov 15 '18 at 15:57
Indeed, it would make portability more burdensome.
– Lonnie Best
Nov 15 '18 at 15:57
Another topic, I haven't found information on is memory consumption when placing style in a shadow root.
– Lonnie Best
Nov 15 '18 at 15:58
Another topic, I haven't found information on is memory consumption when placing style in a shadow root.
– Lonnie Best
Nov 15 '18 at 15:58
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53311660%2fhtml-template-element-versus-javascript-template-literals%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Another issue is that template literals can be transpiled easily (and with Babel and polyfills, which any serious project will have, the project will work in IE), while
<template>elements appear to be not supported in IE– CertainPerformance
Nov 15 '18 at 2:48
1
A counter argument is for keeping your HTML as HTML, separation of concerns and all that. If you want to change your document structure, change your HTML document, not javascript. That is more intuitive for me . The lack of IE support for templates does indeed suck. There is a kind of workaround by using
<script type="text/template" id="postTemplate">in place of<template>. For an example with jquery see: stackoverflow.com/questions/52376527/… . jQuery isn't actually required it's just first of my examples that I found.– Jon P
Nov 15 '18 at 3:13
"Separation of concerns" has its place in general web page development. However, one of my favorite aspects of web components is that you can encapsulate all concerns (structure, style, and behavior) in one place. This simplifies reuse.
– Lonnie Best
Nov 15 '18 at 3:30
1
Possible duplicate of Template html and template string in web components
– Supersharp
Nov 15 '18 at 9:47
Template literals are a JS syntactic sugar thing and have nothing to do with HTML functionality.
– Bergi
Nov 25 '18 at 13:28