И еще забыли померить скорость работы, если это важно, то подход с подчеркиваниями остается единственным выбором (подход с символом тоже должен быть быстрым). Еще справедливо было бы написать про геттеры/сеттеры (проблему приватности не решает, но скрывать данные помогает)
Это как с template — не нужно дополнительно скрывать и браузер не будет обрабатывать эту часть до использования use. А так конечно — можно использовать, просто будут дополнительные затраты. В случае с анимацией так и приходится делать.
Панацеи нет. Вот тут сделан обзор разных методов подключения свг. По поводу размера набора — можно разделить иконки на уникальные для страницы и общие для 90% страниц. Так что это не большая беда.
Определяете иконки в одном шаблоне через symbol, а потом многократно используете через use со своими стилями. вот тут писали больше подробнее и обсуждали проблему с анимациями (в коментариях).
А вообще, если вы используете джангу не только как жсон апи (что почти наверняка так) то вообще можете подключать иконки инлайном прямо в серверных шаблонах.
Ну в строгом режиме к ней тоже нельзя обращаться всегда, так что ничего страшного — this как и super созданы для работы с классами где их и стоит применять.
Map, Set, Proxy, Reflect, Symbols, Promises, subclasses, generators, iterators, tail call optimisation — по моему достаточно киллер фич. Конечно в 2016 добавят намного больше, в том числе асинхронные функции которые помогут писать код в синхронном силе с помощью промисов. Но и 2015 — это большой шаг в нужную сторону (хотя я лично немного сомневаюсь на счет классов).
За исключением редких случаев которые не рекомендовались к использованию (типа блочного определения функций) будет полная обратная совместимость со старыми версиями. Можете продолжать писать хоть на ES3 и дальше. Введенные конструкции отчасти добавляют сахар для упрощения читаемости нового кода, отчасти призваны решить проблемы архитектуры больших приложений.
let [a, ...rest] = [1, 2, 3, 4, 5, 6, 7, 8];
let [b, c, d] = rest.splice(-3);
На самом деле не совсем понятно в чем разница при использовании между отсутствием всплытия и наличием ВМЗ. В реализации разница есть, но поведение как мне кажется от этого не меняется.
Определение функций внутри блока всегда было злом, но теперь удивительно, что область их видимости сузили до блока. Это хорошее решение, но оно потенциально может нарушить совместимость старого и нового кода.
В описаниях классов вообще противоречия:
Методы экземпляра new Foo().bar объявляются при помощи упрощенного синтаксиса литералов объекта class Foo { bar () {} }.
при этом такую конструкцию приводят в пример как замену Foo.prototype.bar. Насколько мне известно — верно второе, да и babel записывает данные методы в прототип, а не в экземпляр.
это не так со включенным флагом 'use strict';
А вообще, если вы используете джангу не только как жсон апи (что почти наверняка так) то вообще можете подключать иконки инлайном прямо в серверных шаблонах.
Обсуждали здесь — habrahabr.ru/company/devexpress/blog/269331
не работает и нужно его расписывать в 2 хода:
На самом деле не совсем понятно в чем разница при использовании между отсутствием всплытия и наличием ВМЗ. В реализации разница есть, но поведение как мне кажется от этого не меняется.
Определение функций внутри блока всегда было злом, но теперь удивительно, что область их видимости сузили до блока. Это хорошее решение, но оно потенциально может нарушить совместимость старого и нового кода.
В описаниях классов вообще противоречия:
при этом такую конструкцию приводят в пример как замену Foo.prototype.bar. Насколько мне известно — верно второе, да и babel записывает данные методы в прототип, а не в экземпляр.