На самом деле, во время выступления я специально подчеркнул, что не хочу сказать, что SVG это плохо, я делал акцент на том, что SVG не слишком хорошо подходит в случае, если в графике используется много небольших одноразовых элементов, именно поэтому я и приводил такие примеры. С выступления прошло достаточно много времени, я не помню в деталях, но мне казалось, что я подчеркнул что SVG хорошо подходит, если графике нужно добавить интерактивное взаимодействие с пользователем, например, реакцию на наведение, клики и прочее.
По поводу производительности вопрос спорный, canvas полностью перерисовывается достаточно быстро и, что важно, он делает это полностью на видеокарте, никак не затрагивая основной процессор, потому что он не является частью DOM, поэтому даже полная перерисовка всего графика будет быстрой, в примере с земным шаром это видно. Другое дело, что канвас это просто низкоуровневая графика и описывать интерактивное взаимодействие будет действительно непросто, потому что все ховеры, клики и прочее, что в SVG работает из коробки, нужно будет описывать руками: вычислять координаты, делать вывод, какой из элементов был нажат, обновлять соответствующие объекты и перерисовывать графику.
Всё верно, я действительно перепутал. На деле сервис-воркеры это частный случай веб-воркеров, предназначенный для проксирования запросов, но я рассказывал про них как про сами веб-воркеры. Спасибо за внимательность.
Такая проблема есть, кстати, не только в Consolas для windows. На маке почти у всех моноширинных шрифтов на нечетных значениях слетает кернинг. Я думаю, что проблема в сглаживании.
Ну они для разных задач создавались — перед PT Sans по умолчанию стоит задача сделать универсальный шрифт, который везде хорошо работает, а вот у Фиры очень узкая направленность — она должна хорошо выглядеть на девайсах с Firefox OS и я думаю, что с этой-то задачей они прекрасно справятся (не говорю справились, потому что не видел воочию).
И в случае таких шрифтов другим системам может повезти, а может и нет. Вот, Droid Sans тот же прекрасно работает где угодно, а с фирой получается что не повезло.
Наверное на windows (да и на маке) его и не тестировали особенно. Вообще, обычно шрифты затачиваются под ту систему в которой они будут использоваться, это легко проверить подключив Monaco на windows или наборот, например Ubuntu Mono на маке — сразу появляются проблемы со сглаживанием или чем-нибудь еще.
Поэтому я для себя остановился на старых добрых проверенных шрифтах которые используются везде и стараюсь не экспериментировать)
Может быть всему виной мое плохое знание английского или что-то другое, но я совершенно не могу понять почему добавление новых методов в прототип объекта не считается манки-патчингом и не попадает под определение: extend or modify the run-time code of dynamic languages.
И еще, я не могу понять откуда у взялось конкретное определение манки-патча как только изменение методов уже существующих классов-интерфейсов. Может быть виной всему то, что я вырываю куски из контекста и никогда не читаю ничего до конца, но вот я вырвал из статьи в вики кусок, в котором говорится «Monkey patching is used to… apply a patch at runtime to the objects in memory, instead of the source code on disk». Если я в прототипе Date объявлю дополнительное свойство, то оно появится у всех инстансов класса Date.
var myDate = new Date();
Date.prototype.isMonkeyPatched = true;
myDate.isMonkeyPatched; // true
Никакого противоречия — действительно код выше модификацирует объекты в памяти, поэтому я не могу понять, почему добавление свойства или метода является манки-патчингом, а изменение — нет.
А еще, в принципе мне сложно понять, как можно считать вполне себе утилитарный класс Date можно считать классом-интерфейсом, но спишем это еще на какой-нибудь мой недостаток, может быть я вообще не разбираюсь в программировании.
Я изначально-то говорил не об этом. Мой комментарий был совершенно не про трактовку определений, а про то, что изменения прототипа стандартного класса «на лету» (как бы они ни назывались, манки-патчинг или «загрязнение» ранее объявленных классов-интерфейсов новыми методами) — плохая практика для JavaScript'а и лучше найти любой другой способ, недостатка в которых нет.
Нет большой разницы, изменять в ран-тайме уже существующие методы или добавлять новые. Вот, например, Википедия встает на мою сторону:
> A monkey patch is a way to extend or modify the run-time code of dynamic languages without altering the original source code.
Но я не о названии, а о том, что такой путь неправилен и применять его можно только для быстрой отладки в консоли, а для промышленных решений он не годится.
Хочется сказать не про сам способ, а про то, как вы предлагаете его применять:
> Используя прекрассную возможность прототипирования в JavaScript можно расширить встроенный объект языка Date собственным методом
Это называется манки-патчинг (monkey patching) и лучше его избегать, потому что код, который вы напишете, рассчитывая на наличие этого патча, может быть использован где-то на стороне (не исключено что даже вами) и вместо желаемого результата, человек получит ошибку.
Уж лучше написать старую добрую простую функцию или если вам так нравится идея работать с классами, вы можете отнаследовать новый класс от стандартного Date, назвав его, например, ImprovedDate и работать с ним. Тогда, в его прототип вы сможете добавлять какие угодно методы и перекрывать любые стандартные уже объявленные.
На самом деле, во время выступления я специально подчеркнул, что не хочу сказать, что SVG это плохо, я делал акцент на том, что SVG не слишком хорошо подходит в случае, если в графике используется много небольших одноразовых элементов, именно поэтому я и приводил такие примеры. С выступления прошло достаточно много времени, я не помню в деталях, но мне казалось, что я подчеркнул что SVG хорошо подходит, если графике нужно добавить интерактивное взаимодействие с пользователем, например, реакцию на наведение, клики и прочее.
По поводу производительности вопрос спорный, canvas полностью перерисовывается достаточно быстро и, что важно, он делает это полностью на видеокарте, никак не затрагивая основной процессор, потому что он не является частью DOM, поэтому даже полная перерисовка всего графика будет быстрой, в примере с земным шаром это видно. Другое дело, что канвас это просто низкоуровневая графика и описывать интерактивное взаимодействие будет действительно непросто, потому что все ховеры, клики и прочее, что в SVG работает из коробки, нужно будет описывать руками: вычислять координаты, делать вывод, какой из элементов был нажат, обновлять соответствующие объекты и перерисовывать графику.
habrastorage.org/storage3/f01/964/c35/f01964c357a3ba287cc927802abb3c7d.png
Только странно что не работает в Я.Браузере.
И в случае таких шрифтов другим системам может повезти, а может и нет. Вот, Droid Sans тот же прекрасно работает где угодно, а с фирой получается что не повезло.
Поэтому я для себя остановился на старых добрых проверенных шрифтах которые используются везде и стараюсь не экспериментировать)
И еще, я не могу понять откуда у взялось конкретное определение манки-патча как только изменение методов уже существующих классов-интерфейсов. Может быть виной всему то, что я вырываю куски из контекста и никогда не читаю ничего до конца, но вот я вырвал из статьи в вики кусок, в котором говорится «Monkey patching is used to… apply a patch at runtime to the objects in memory, instead of the source code on disk». Если я в прототипе Date объявлю дополнительное свойство, то оно появится у всех инстансов класса Date.
Никакого противоречия — действительно код выше модификацирует объекты в памяти, поэтому я не могу понять, почему добавление свойства или метода является манки-патчингом, а изменение — нет.
А еще, в принципе мне сложно понять, как можно считать вполне себе утилитарный класс Date можно считать классом-интерфейсом, но спишем это еще на какой-нибудь мой недостаток, может быть я вообще не разбираюсь в программировании.
Я изначально-то говорил не об этом. Мой комментарий был совершенно не про трактовку определений, а про то, что изменения прототипа стандартного класса «на лету» (как бы они ни назывались, манки-патчинг или «загрязнение» ранее объявленных классов-интерфейсов новыми методами) — плохая практика для JavaScript'а и лучше найти любой другой способ, недостатка в которых нет.
> A monkey patch is a way to extend or modify the run-time code of dynamic languages without altering the original source code.
Но я не о названии, а о том, что такой путь неправилен и применять его можно только для быстрой отладки в консоли, а для промышленных решений он не годится.
> Используя прекрассную возможность прототипирования в JavaScript можно расширить встроенный объект языка Date собственным методом
Это называется манки-патчинг (monkey patching) и лучше его избегать, потому что код, который вы напишете, рассчитывая на наличие этого патча, может быть использован где-то на стороне (не исключено что даже вами) и вместо желаемого результата, человек получит ошибку.
Уж лучше написать старую добрую простую функцию или если вам так нравится идея работать с классами, вы можете отнаследовать новый класс от стандартного Date, назвав его, например, ImprovedDate и работать с ним. Тогда, в его прототип вы сможете добавлять какие угодно методы и перекрывать любые стандартные уже объявленные.