Внешние тулкиты и фреймворки

[dzz]

По моим наблюдениям, в последнее время у разработчиков веб-сайтов сложилась практика не размещать у себя на сайтах различные JS-фреймворки и тулкиты, а давать ссылки прямо на URL авторских сайтов. В итоге, работоспособность сайта начинает зависеть от доступности не столько самого целевого web-сервера, сколько от неконтролируемго окружения. И никого, судя по всему, это не парит.

Может быть, я слоупок, но лет пять назад, по-моему, такого не было. В своих проектах, так или иначе касающихся web-а, я всегда перетягивал "библиотечную" часть клиентских скриптов на собственный ресурс.

Занятно, в общем.

Comments

[kholod.livejournal.com]

Ага.
Пример. На сайте ссылки на сторонние ресурсы (не только js, но и графика!), причём в формате "\\domain\path\…", т.е. без явного указания протокола. На самом сайте поднимают SSL и оставляют только "https:", а про то, что на стороннем сайте ресурсы доступны только через "http:", даже не думают. В результате кроссбраузерности - ноль, а функционал работает только у избранных. Наверное, у разработчиков всё работает, и у заказчиков.

[avnik.livejournal.com]

Поветрие пошло от jquery и bootstrap, у которых был cdn спонсированый гуглом и твиттером.

[dzz.livejournal.com]

Но зачем? Ведь и то, и другое отлично ставится локально. Мы bootstrap пихали в светофорный контроллер без проблем.

[dzz.livejournal.com]

У меня по умолчанию ноускрипт в браузере включен, так что я регулярно наблюдаю списки нелокальных ссылок, которые нужно разрешать, чтобы сайт отображался "как задумано".

[avnik.livejournal.com]

в целях тупой оптимизации я полагаю, потому что cdn гугла быстрее среднестатистичекого хостаю