Hacker News Reader

Comment by Too | Hacker News Reader

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 + '%';

View on HN

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

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.

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.

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.

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/Refe...

<template> elements are also implemented everywhere but IE: 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.

Reply on news.ycombinator.com