Комментарии 20
Меньше сторонних либ => меньший трафик для пользователя => скорейшая загрузка страницы
Больше костылей. Больше велосипедов. Больше времени на дебаг и багфикс. Больше времени, чтоб вспомнить через год, как это работает. Больше времени другому разработчику разобраться, как это работает.
Uncaught ReferenceError: xDown is not defined
Ошибку поправил, спасибо!
Если Вы умеете читать код и писать комментарии, то проблем ни у Вас, ни у другого разработчика не будет
Это ошибочное мнение. Необходимость читать код (свой или чужой) — уже проблема, а лучший код тот, который не написан.
Ошибочное мнение – считать мнение другого человека ошибочным. Я понимаю, есть такие случаи, когда ошибочность действительно очевидна, но здесь не так. К тому же, как ни крути, в среднем jQuery выполняет все действия медленнее в два раза, и пора бы уже в 2017 году отказаться от бессмысленной на данный момент библиотеки.
Думаю статья сыровата, чтобы выкладывать ее. Надо довести код до ума.
И перед тем как выкладывать на всеобщее обозрение — было бы неплохо самому все протестировать. Например заявленные тач-события не работают должным образом.
Получилась карусель «Доделай сам».
И перед тем как выкладывать на всеобщее обозрение — было бы неплохо самому все протестировать. Например заявленные тач-события не работают должным образом.
Получилась карусель «Доделай сам».
Еще бы не загружать картинки, которые пользователь не видит.
Помню был клиент, у которого не обрабатывались картинки, редакторы вручную их тоже не обрабатывали. В итоге на главной странице сразу 200 мгб грузилось))
Помню был клиент, у которого не обрабатывались картинки, редакторы вручную их тоже не обрабатывали. В итоге на главной странице сразу 200 мгб грузилось))
Мне вот все больше и больше непонятен смысл этих велосипедов. Для себя, саморазвития, учебных целей, да, да, и еще раз — да. Но пользоваться в продакшене этим, такое себе развлечение. Потому что, потом это разрастается до несколько k строчек кода, без документации, тестов, и прочих радостей жизни белых людей. Зато сэкономим ~60кб(хочу заметить экономим при этом на ГАЛЕРЕЕ картинок, которая будет весить явно больше, нивелируя оверхед по весу) на один единственный запрос, который потом будет грузить уже из кэша эти же скрипты.
Насчет тормознутости jQ — нуу, я честно говоря не знаю, как же надо строить код, чтобы лагал ИМЕННО jQuery. Тут по моему проблема не в либе, а в девелопере.
Насчет тормознутости jQ — нуу, я честно говоря не знаю, как же надо строить код, чтобы лагал ИМЕННО jQuery. Тут по моему проблема не в либе, а в девелопере.
Конечно, лучше притащить за собой МБайты кода, избыточного кода, чем написать свой велосипед и покрыть его тестами. По поводу загрузки из кэша… Любому энджайну нужно время на распарс скрипта, даже из кэша
Пример из жизни.
Нужно было сделать тултип. Простенький, но с фичей одной. Библиотек как-то сходу не нашёл с этой фичей, да и зачем, когда там всё просто. Написали, Ззпустили в продакшн. Вроде сэкономили несколько килобайт трафика, но…
Каждый месяц руководство придумывало что-то новое, тултип становился неповоротливым и сложным в понимании, т.к. изначально он не был рассчитан на всё это, а так же оброс костылями.
Через год он стал весить больше готовой библиотеки, которая имеет несколько тысяч звёзд на гитхабе и покрывает на 100% текущие возможности самописного. Так ещё и поддерживать и изменять готовый проще, т.к. его написал человек с куда большим опытом во фронтенде, чем мы. К сожалению, перевести тултип на плагин так и не вышло, т.к. я ушёл оттуда. Но вот мне жалко ребят, которые тратят время и нервы на разбор сложной и непонятной логики вместо включения опций при инициализации плагина. И да, багов там в разы меньше, т.к. репозиторий довольно живой и активно всё исправляется с подсказками сообщества.
Нужно было сделать тултип. Простенький, но с фичей одной. Библиотек как-то сходу не нашёл с этой фичей, да и зачем, когда там всё просто. Написали, Ззпустили в продакшн. Вроде сэкономили несколько килобайт трафика, но…
Каждый месяц руководство придумывало что-то новое, тултип становился неповоротливым и сложным в понимании, т.к. изначально он не был рассчитан на всё это, а так же оброс костылями.
Через год он стал весить больше готовой библиотеки, которая имеет несколько тысяч звёзд на гитхабе и покрывает на 100% текущие возможности самописного. Так ещё и поддерживать и изменять готовый проще, т.к. его написал человек с куда большим опытом во фронтенде, чем мы. К сожалению, перевести тултип на плагин так и не вышло, т.к. я ушёл оттуда. Но вот мне жалко ребят, которые тратят время и нервы на разбор сложной и непонятной логики вместо включения опций при инициализации плагина. И да, багов там в разы меньше, т.к. репозиторий довольно живой и активно всё исправляется с подсказками сообщества.
Согласен, что если есть готовая либа, которая покрывает тз, то лучше её использовать.
Но если Вам нужна простенькая карусель, то проще и быстрее написать своё и покрыть её тестами
Требовался тоже очень простенький тултип изначально :)
Но если Вам нужна простенькая карусель, то проще и быстрее написать своё и покрыть её тестами
Проще и быстрее взять простенькую и готовую карусель на 7.4КБ (после минификации, но до gzip), которая уже написана, покрыта тестами, документирована и имеет гораздо меньше багов.
Для 99% типовых задач есть 100500 библиотек на всякий вкус и смысла их писать самому, кроме как самообучение (за счёт работодателя, как предлагаете вы) — нет.
Как объект для статьи — карусель подходит отлично, достаточно много разных знаний нужно иметь, чтобы оно адекватно работало. И, тем не менее, статья, состоящая из листингов кода без комментариев — как-то неочень.
1. Все дело в том, что на среднестатистическом современном сайте таких «да кто там заметит те лишние 60 кб!» легко может набраться несколько.
2. Библиотеку нужно не только загрузить, но и распаковать, распарсить, откомпилировать, выполнить, проинстансить экземпляры объектов, занять память. Всё по отдельности — вроде бы копеечные затраты, но — см. пункт 1.
2. Библиотеку нужно не только загрузить, но и распаковать, распарсить, откомпилировать, выполнить, проинстансить экземпляры объектов, занять память. Всё по отдельности — вроде бы копеечные затраты, но — см. пункт 1.
В каком месте в jQ «МБайты кода»? Локальный тест на слабенькой машинке выдал 15мс на парсинг. Лучше для кого? Сейчас даже дешевейшая китайская мобилка распарсит эти жалкие 80кб кода незаметно для пользователя, чего уж говорить о десктопах и планшетах, т.е. юзеру по большому счету фиолетово(не считая багов само собой, от которых юзер потом будет страдать). Лучше ли разработчику? Навряд ли. Если так надо, напишите готовую либу, протестированную, отдокументированную, и выливайте в опенсорс, вам только спасибо скажут (хотя конечно спорно, этих либ не пересчитать уже), а так, «жквери тяжелая и тормознутая, напишу свое, непонятное, зато родное» и спустя месяц/если придет другой разраб, то будет потрачено время и нервы с целью выяснить, как же оно все работает.
задумываться об альтернативах и оптимизации — ок.
переизобретать что-то для изучения — ок
показывать это кому-то вперёд наставника — не ок
заявлять фичи и не реализовывать — не ок
не выкладывать код ссылкой в конце — не ок
поэтому я проголосовал за вариант «нет», но это не значит что тебе надо валить с хабра. ты молод и можешь во многом себя попробовать, а сейчас получишь только критику, которая тебе не понравится.
переизобретать что-то для изучения — ок
показывать это кому-то вперёд наставника — не ок
заявлять фичи и не реализовывать — не ок
не выкладывать код ссылкой в конце — не ок
поэтому я проголосовал за вариант «нет», но это не значит что тебе надо валить с хабра. ты молод и можешь во многом себя попробовать, а сейчас получишь только критику, которая тебе не понравится.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Карусель на Vanilla.JS. Часть 2