3 ms·

What happened with separating content and presentation. I thought everybody got over the jquery madness and went on with template based frameworks like react an

by Too 10y ago

What happened with separating content and presentation. I thought everybody got over the jquery madness and went on with template based frameworks like react and angular. Who would write code like this in 2016? this._label = shadowRoot.querySelector('.label'); this._label.textContent = newPercentage + '%';

oregondan 10y ago
It is a bit of an anachronism, yeah. Soon, though, we'll have template literals [1], and this example will just be out of date. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- rictic 10y ago
  <template> elements are also implemented everywhere but IE: http://caniuse.com/#feat=template http://caniuse.com/#feat=template The advantage of <template> over strings in JS is that the browser can parse the <template> as HTML in parallel with parsing your JS. Less JS to parse means faster cold loads.
Touche 10y ago
Custom elements are not related to templating. I suppose they did it this way because they were highlighting custom elements and not some templating thing.
greenyouse 10y ago
This looks like it's for the custom elements part of the web components spec. Doing HTML templates is already supported in most browsers [0]. I think they were just trying to show how to create custom HTML tags and left out other parts because it would be outside the scope of the article. webcomponents.org has tons more info about web components. I think it's pretty awesome to get templating, custom elements, scoped styling, and HTML imports as a browser feature without JS frameworks. It'll be neat to have as an option in the future when browser support gets better and people start using it. [0]http://caniuse.com/#feat=template http://caniuse.com/#feat=template
- Too 10y ago
  Html <template> doesn't do data binding as far as I can see? It's just a way to reinstantiate fragments of a page and then you are back to selectors and setting properties with js. When I say templates I mean declaratively defining the page with data binding in the html so the javascript code doesn't have to know anything about the html. There are two major reasons to use angular/react: rendering with data binding and reusable components. If web components is going to be a feasible replacement it has to both, when looking at it now it seems as it only does the component-part. Otherwise we will just end up with tons of web components that pull in angular as a dependency and we are back on square one. In fact it will probably be worse than before because it's so easy to use third party web components that you will not even think about all the different dependencies they pull in and at the end of the day your page will require doenload of both angular, jquery, react, polymer and vue. This is one step forward and two steps back. Unless web components can significantly improve the performance and code size of all these existing frameworks under the hood.
achairapart 10y ago
Maybe the whole thing here is that we are moving to a component based way to develop UIs with incapsulated and reusable elements but this somehow collides with the foundation of the www i.e. separation of concerns. React, a tool with a very sharp focus (help Facebook to scale), choose to get rid of the whole concern; W3C is trying to solve this with Web Components (Custom Elements are part of them) since 2011 (!) and specs are still in progress and changing from time to time because getting things right is difficult when those concern are at stake.

by Too 10y ago

oregondan 10y ago

It is a bit of an anachronism, yeah. Soon, though, we'll have template literals [1], and this example will just be out of date. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

rictic 10y ago
<template> elements are also implemented everywhere but IE: http://caniuse.com/#feat=template http://caniuse.com/#feat=template The advantage of <template> over strings in JS is that the browser can parse the <template> as HTML in parallel with parsing your JS. Less JS to parse means faster cold loads.

Touche 10y ago

Custom elements are not related to templating. I suppose they did it this way because they were highlighting custom elements and not some templating thing.

greenyouse 10y ago

This looks like it's for the custom elements part of the web components spec. Doing HTML templates is already supported in most browsers [0]. I think they were just trying to show how to create custom HTML tags and left out other parts because it would be outside the scope of the article. webcomponents.org has tons more info about web components. I think it's pretty awesome to get templating, custom elements, scoped styling, and HTML imports as a browser feature without JS frameworks. It'll be neat to have as an option in the future when browser support gets better and people start using it. [0]http://caniuse.com/#feat=template http://caniuse.com/#feat=template

Too 10y ago
Html <template> doesn't do data binding as far as I can see? It's just a way to reinstantiate fragments of a page and then you are back to selectors and setting properties with js. When I say templates I mean declaratively defining the page with data binding in the html so the javascript code doesn't have to know anything about the html. There are two major reasons to use angular/react: rendering with data binding and reusable components. If web components is going to be a feasible replacement it has to both, when looking at it now it seems as it only does the component-part. Otherwise we will just end up with tons of web components that pull in angular as a dependency and we are back on square one. In fact it will probably be worse than before because it's so easy to use third party web components that you will not even think about all the different dependencies they pull in and at the end of the day your page will require doenload of both angular, jquery, react, polymer and vue. This is one step forward and two steps back. Unless web components can significantly improve the performance and code size of all these existing frameworks under the hood.

achairapart 10y ago

Maybe the whole thing here is that we are moving to a component based way to develop UIs with incapsulated and reusable elements but this somehow collides with the foundation of the www i.e. separation of concerns. React, a tool with a very sharp focus (help Facebook to scale), choose to get rid of the whole concern; W3C is trying to solve this with Web Components (Custom Elements are part of them) since 2011 (!) and specs are still in progress and changing from time to time because getting things right is difficult when those concern are at stake.