Antelle А не знаете случайно они asm совсем забросили или будут развивать параллельно с wasm? Сейчас довольно удобно критические по производительности вещи оборачивать в asm, но не хватает i64 и прочих радостей, да и asm -> wasm достаточно удачная компиляция, в отличии от c -> wasm создает намного меньше мусора (без i64 конечно). Опять же типизация рано или поздно появится и тогда asm сможет выглядет по приличнее, так что интересна его судьба.
Полезен чтоб разделить методы и данные, убрать коллизию имен, привести API к одному виду. Хороший замах на перегрузку операторов (возможно появится как раз благодаря символу (уже сейчас можно переопределять например for of с помощью Symbol.iterator)).
Плохо поживает =) В смысле они то развиваются понемногу, но вот модули у них все еще слабые и как-то нескладно выглядят что-ли + еще и не работают часто (пробовал как раз авторизацию с правами включить и это было сомнительное удовольствие). Кроме того вряд ли они успеют перестроится на промисы, генераторы (и возможно асинхронные функции). Я больше надеюсь на что-то совершенно новое, но пока кандидатов на фреймворк мечты не видно.
Да, это было предсказуемо. Вопрос в том — что не барахло среди серверных nodejs фреймворков? Попыток что-то сделать было много, а чего-то уровня django так и не построили. С микрофреймворками все по лучше, но иногда не хочется в очередной раз делать авторизацию, рест и прочие стандартные вещи снова и снова.
IV — анимировать позицию с помощью изменения box model в принципе плохая идея которая в любом случае будет просаживать производительность на мобильных устройствах. Для этого есть более удачные способы с использованием видеокарты translate3d, например.
II. Объединяйте манипуляции с DOM и выполняйте их отдельно от обновления DOM:
Уже тоже не слишком актуально. Браузеры уже научились это вполне сносно оптимизировать и если раньше сортировка таблицы вне дом с последующей вставкой занимала в разы меньше времени, чем та же операция в дом, то сейчас разница не так заметна (можно посмотреть приер у Ильи Кантора).
Тем не менее этот пунк все равно правильнее сделать, но не стоит рассчитывать на заметный прирост производительности.
Это должно быть в библиотеке так что конечному пользователю это действительно незачем и он об этом и не думает (ну разве что деструктор непривычный добавляется). А в общем — есть разные подходы к разработке, многие переходят в жс из других языков и тянут свои идеи, цезарю — цезарево.
Ну это не совсем сборщик мусора, сборщик как раз родной браузерный, но для нашего кеша — в конструкторах счетчик ссылок на объекте увеличиваем, в деструкторе — уменьшаем, при достижении нуля — чистим область кеша. Если что-то захочет проверить на равенство ему прийдется или держать инстанс объекта (счетчик ссылок в кеше на него будет не нулевым) или создать новый (тогда он или создастся или возьмется из кеша).
Не знаю есть ли но можно сделать и вместо return {...} будет return new Immutable({...}) а в конструкторе уже нужно будет проверять есть такой объект или его нужно создавать и возвращать ссылку. Я б для координаты в игре вообще не пользовался бы иммутабельными структурами, но в принципе тоже можно, просто кешь нельзя только лишь заполнять, его и чистить нужно Immutable.destroy({x: 0.1, y: 0.2}).
Так const не решает проблему просто. В нормальной реализации объект {r: 0, g: 0, b: 0} будет зарезирвирован в памяти и обе переменные получат ссылку именно на него. Тут на самом деле будет перенос сложности из сравнения в создание.
В худшем случае это S = sum(ln k, 1, n) и это не линейное время так как предел lim S/n видимо бесконечный.
Уже тоже не слишком актуально. Браузеры уже научились это вполне сносно оптимизировать и если раньше сортировка таблицы вне дом с последующей вставкой занимала в разы меньше времени, чем та же операция в дом, то сейчас разница не так заметна (можно посмотреть приер у Ильи Кантора).
Тем не менее этот пунк все равно правильнее сделать, но не стоит рассчитывать на заметный прирост производительности.
Так что в этом случае так лучше не делать — это плохо читается и никак не оптимизирует процесс.
А профит от кеша — быстрое сравнение естественно.