Я понимаю, о чём вы. Да, уже существует множество решений проблем шаблонов. На любой вкус и цвет, и работают они довольно быстро.
По поводу подхода var html = '<img src="' + image +'>"'. Он может быть только временным решением. Библиотеки шаблонов, по сути, делают тоже самое, только эскейпят данные. Вариант сносный, но выглядит скорее как хак.
От работы с DOM в любом случае не уйти. Даже если мы собрали строку с данными, её нужно вставить в DOM. Давайте сравним два подхода пошагово.
Строки
Получить строку шаблон.
a). Загрузить AJAX-ом
б). Найти в DOM элемент, содержащий шаблон, извлечь шаблон оттуда.
Провернуть множество операций со строками. Эскейпить данные вручную.
Вставить получившуюся строку в DOM. Браузер парсит строку, рендерит содержимое.
<template>
Получить содержимое <template>.
Найти в DOM тег <template> с нужным шаблоном. Его содержимое уже распаршено, с ним можно работать как с любым элементов в DOM.
Подставить данные, используя DOM API. Нет необходимости заботится о вредоностности данных.
Вставить элемент DOM в… DOM. Браузеру не нужно ничего парсить, он сразу рендерит содержимое.
Сложно сказать, какой подход будет быстрее, пока нет бенчмарков. Но вариант с <template> определённо однородней и «чище».
Да, скорость работы DOM пока ещё проблема. Но мы, в случае с <template> работаем на очень ограниченном его «участке».
Уже сейчас все это лаконично и шустро работает, даже без shadow dom.
Для работы с условиями, циклами и прочим мы по-прежнему можем использовать любимые template-библиотеки, вроде Mustache. <template> просто держит ваш шаблон «на готове», как его заполнять данными — дело ваше.
Polymer используют Mustache совместно с <template> и Object.observe для подстановки данных в шаблоны: polymer data-bindings.
Такого рода стандартизация по-моему будет скорее мешать. Умный ход — выпустить API которое позволяет программистам делать всё что они хотят, а потом взять лучшие практики и сделать их стандартом. Поступать наоборот — риск.
Я надеюсь, если web components пойдут в народ, появятся библиотеки элементов, вроде bootstrap, yui и т.д. У них будут свои, внутренние, стандарты и лучшие практики.
Очень много «низкоуровнего» кода. Shadow DOM позволяет скрыть детали реализации элемента и инкапсулировать его стили, чтобы они не конфликтовали с документом. Таким образом в документе строка поиска будет выглядеть как-то так:
<div class="google-search"></div>
Или так, с использованием custom elements:
<google-search></google-search>
Детали реализации будут изолированны и лежать где-то в другом месте. Это похоже на разделение интерфейс/реализация в объектно-ориентированных языках.
Подобие custom elements можно написать самому, тут вы правы. Они уже есть в некоторых фреймворках. Ничего нового, только теперь браузер будет поддерживать это нативно.
<template> это не совсем шаблонизатор. Его задача не в том, чтобы взять данные и подставить их в разметку. Это скорее «хранилище» html кода, который вы планируете использовать не сразу, как только документ загрузится, а позже.
API у него сводится к одному свойству content. Сомневаюсь что браузеры тут могут накуролесить.
Могу только догадываться почему назвали именно так. В источниках эта информация не попадалась.
В примерах к этой статье, например здесь (код) и тут (код) я переиспользую самописный элемент <wc-example>, его код лежит здесь.
Получившийся TODO-виджет также можно переиспользовать. Импортим html-файл на страницу, и браузер будет рисовать виджет на месте <x-todo> элементов.
Тег <template> это не совсем темплейтинг. Скорее механизм отложить фрагмненты разметки, пока они не пригодятся. Подставлять данные в содержимое <template> нужно вручную, с помощью js.
В голову сходу приходят три сценария, которые могли бы к этому привести:
1. Использование __slots__ может привести к такой ошибке, при попытке установить атрибут с именем, не перечисленным в __slots__
2. Использование __setattr__, в нём явный raise AttributeError()
3. Использование дескриптора данных, с raise AttributeError() в методе __set__
Статья, на мой взгляд, и так разрослась сверх меры. А mro довольно крупная тема, которую я планировал рассмотреть отдельно (вместе с super(), множественным наследованием, и, возможно, метаклассами).
Спасибо за полезный линк. Насколько я знаю, в python3 протокол атрибутов практически не изменился по сравнению с 2.6. По крайней мере вся информация в этой статье будет актуальна для new-style objects в 2.6. Примеры на python3 — робкая попытка внести небольшой вклад в его популизацию.
Я понимаю, о чём вы. Да, уже существует множество решений проблем шаблонов. На любой вкус и цвет, и работают они довольно быстро.
По поводу подхода
var html = '<img src="' + image +'>"'. Он может быть только временным решением. Библиотеки шаблонов, по сути, делают тоже самое, только эскейпят данные. Вариант сносный, но выглядит скорее как хак.От работы с DOM в любом случае не уйти. Даже если мы собрали строку с данными, её нужно вставить в DOM. Давайте сравним два подхода пошагово.
Строки
a). Загрузить AJAX-ом
б). Найти в DOM элемент, содержащий шаблон, извлечь шаблон оттуда.
<template><template>.Найти в DOM тег
<template>с нужным шаблоном. Его содержимое уже распаршено, с ним можно работать как с любым элементов в DOM.Сложно сказать, какой подход будет быстрее, пока нет бенчмарков. Но вариант с
<template>определённо однородней и «чище».Да, скорость работы DOM пока ещё проблема. Но мы, в случае с
<template>работаем на очень ограниченном его «участке».Shadow DOM не влияет на работу шаблонов.
jqueryиquerySelector()это подтверждает. Promises возможно когда-нибудь попадут в стандарт.Об остальном сложно спорить. Поживём — увидим…
<template>просто держит ваш шаблон «на готове», как его заполнять данными — дело ваше.Polymer используют Mustache совместно с
<template>иObject.observeдля подстановки данных в шаблоны: polymer data-bindings.Я надеюсь, если web components пойдут в народ, появятся библиотеки элементов, вроде bootstrap, yui и т.д. У них будут свои, внутренние, стандарты и лучшие практики.
Я имел ввиду, если браузер загружает документ, в котором есть такой код:
alert(1);не выполнится до тех пор, пока мы не сделаем импорт содержимого шаблона:Очень много «низкоуровнего» кода. Shadow DOM позволяет скрыть детали реализации элемента и инкапсулировать его стили, чтобы они не конфликтовали с документом. Таким образом в документе строка поиска будет выглядеть как-то так:
Или так, с использованием custom elements:
Детали реализации будут изолированны и лежать где-то в другом месте. Это похоже на разделение интерфейс/реализация в объектно-ориентированных языках.
<template>это не совсем шаблонизатор. Его задача не в том, чтобы взять данные и подставить их в разметку. Это скорее «хранилище» html кода, который вы планируете использовать не сразу, как только документ загрузится, а позже.API у него сводится к одному свойству
content. Сомневаюсь что браузеры тут могут накуролесить.applyAuthorStyles = false)Наружу у «кастомного элемента» торчит только JS API, определённое разработчиком.
Реимпорт не происходит. Полагаю, это один из багов. Импорты работают не так хорошо, как всё остальное.
В примерах к этой статье, например здесь (код) и тут (код) я переиспользую самописный элемент
<wc-example>, его код лежит здесь.Получившийся TODO-виджет также можно переиспользовать. Импортим html-файл на страницу, и браузер будет рисовать виджет на месте
<x-todo>элементов.Тег
<template>это не совсем темплейтинг. Скорее механизм отложить фрагмненты разметки, пока они не пригодятся. Подставлять данные в содержимое<template>нужно вручную, с помощью js.1. Использование __slots__ может привести к такой ошибке, при попытке установить атрибут с именем, не перечисленным в __slots__
2. Использование __setattr__, в нём явный raise AttributeError()
3. Использование дескриптора данных, с raise AttributeError() в методе __set__
возможно, есть ещё варианты
если бы getter_only был дескриптором не данных, значение записалось бы в __dict__ экземпляра