На данный момент ts мы не используем, но другие проекты, особенно с общим кодом, частично используют, и у нас есть все шансы поучаствовать в этом празднике.
Строгих KPI по скорости нет. В основном следим за производительностью по своим ощущениям, отзывам коллег и пользователей. Разумеется, при разработке стараемся не засорять код лишними операциями с большими временными затратами.
Но и мониторинги имеются (Grafana). Критичные нагруженные места смотрим и по ним. Например, список файлов в Облаке. Мониторится чуть ли не каждый чих. К примеру, загрузка/догрузка/обновление списка файлов, отрисовка и перерисовка файлов, вставка и изъятие, сортировки, загрузка превью, загрузка данных и т.д. Смотрим и на количество и на время, по которым следим, чтобы показатели улучшались.
Вижу только пару таких мест, подходящих под Ваше определение. Да и как Вы предполагаете было бы лучше? Приводить сотню-другую строк кода, оторванных от статьи, вместо простого схематичного init()? Или расписывать, что за elements.show() стоит перебор элемента и вызов соответствующей функции в их контексте?
Большой нужды не было. Установка соединения не была узким местом. А с приходом SSL место стало значительно уже. Handshake требует гораздо больше времени, потому надо было приблизить скорость загрузки к предыдущим значениям.
Изначально запаздывания не было. Но Samsung сделал подарок. У него в Galaxy S III (к сожалению, не помню в какой версии прошивки) при паралелльных анимациях (перелистывание страницы и прокрутка табов/заголовков) половина страницы попросту скрывалась на время анимации. Потому разнесли по времени.
Надо будет перепроверить на досуге, вдруг поправили в каком из обновлений.
Неплохо слайдится. Но. Попробуйте проскроллить, например, первую демку по вертикали, начав движение касанием кастомизированного блока.
Не получится. Будет пытаться перелистнуть карточку.
Представьте себе страницу с такими блоками на всю ширину и без больших отступов между ними. Epic fail надо сказать.
Именно по-этому пишутся свои решения. Как говориться, «хочешь сделать хорошо то, что надо...»
Не без приключений и багов, конечно.
Довольно сильно отличается. От самих событий (например, у IE есть MSGestureTap и MSPointerHover) до данных в объекте события.
Как всегда заточено под Windows.
Подробнее почитать можно здесь.
Поддерживается, начиная с IE10
Но и мониторинги имеются (Grafana). Критичные нагруженные места смотрим и по ним. Например, список файлов в Облаке. Мониторится чуть ли не каждый чих. К примеру, загрузка/догрузка/обновление списка файлов, отрисовка и перерисовка файлов, вставка и изъятие, сортировки, загрузка превью, загрузка данных и т.д. Смотрим и на количество и на время, по которым следим, чтобы показатели улучшались.
Надо будет перепроверить на досуге, вдруг поправили в каком из обновлений.
Но смысл моего посыла, я думаю, все равно проглядывается :)
Не получится. Будет пытаться перелистнуть карточку.
Представьте себе страницу с такими блоками на всю ширину и без больших отступов между ними. Epic fail надо сказать.
Именно по-этому пишутся свои решения. Как говориться, «хочешь сделать
хорошото, что надо...»Не без приключений и багов, конечно.
Как всегда заточено под Windows.
Подробнее почитать можно здесь.
Поддерживается, начиная с IE10