MaxKorz: значит у нас возникло недопонимание)
Для меня глубокие знания JS это примерно 4 по 5-бальной шкале.
Про SPA - как-то они не вписываются в этот ряд)
MaxKorz: единственное, на мой взгляд, где скорость будет иметь значение - игры на js в канвасе. Там может быть ситуация с огромными массивами и со всякими сложными вычислениями, которые должны быть очень быстрыми, но я скептически отношусь к возможности создания нормальных игр в браузере, поэтому даже не рассматривал этот вариант.
Если однажды мне захочется заняться созданием игр, то я точно не выберу для этого браузер и JS - есть более удобные и практичные инструменты, типа Unity.
MaxKorz: теперь разберем что из этого относится к JS:
1) это те самые базовые вещи для общего развития. Можно еще добавить BOM. Для JS разработчика тут интересны их методы, объекты и всякие особенности типа живых коллекций, событий и т.д. Глубже в устройство самого браузера лезть не придется.
2) это на этапе изучения верстки должно было быть изучено.
3) это так же к верстке можно отнести, к разделу парсинга HTML документа.
4) верстка (анимация)
5) базовое
6) верстка
7) верстка
Про удаление элементов - согласен, но это можно рассматривать как выстрел в ногу, о котором я упоминал.
Про быстрый код не соглашусь - давно я считал, что это важно: оптимизировал все подряд, избегал медленных селекторов, учитывал особенности передачи файлов по TCP, делал отложенную загрузку ассетов, стараясь всегда добиваться скорости загрузки страницы в 1 секунду на 3G соединении, выносил длину массива в отдельную переменную для использования в циклах и всякие прочие ухищрения))
А потом вся эта красота отдавалась для интеграции с CMS и все усилия рушились о жесткие реалии - никто не будет заморачиваться на поддержке вашего идеального кода.
- Сеошники повесят кучу скриптов от аналитики, онлайн консультантов, формы из CRM и прочие вещи, которые затормозят ваш идеальный код.
- Контент-менеджеры загрузят кучу огромных, неоптимизированных картинок.
- Пользователи навставляют айфреймов с ютуба.
В итоге, я бы сейчас назвал все эти оптимизации - борьбой с ветряными мельницами. О чем можно говорить, если у самого Гугла их сервис по тестированию скорости загрузки сайтов, сам набирает около 60 баллов всего)
Дмитрий Евграфович: по идее большие картинки не должны выглядеть хуже на простых экранах. У меня нет под рукой обычного монитора, чтобы это проверить, но чисто теоретически, когда делаешь фотографию размером 1000 на 1000, а потом 500 на 500 и затем уменьшаешь первую в редакторе до размера второй, то они становятся визуально не отличимы практически. Не представляю что там может смазываться.
nomta: там все просто с srcset и тегом img. Если у тебя максимальная ширина экрана 1200 и картинка должна быть на всю ширину, то либо грузи одну картинку шириною 2400 (в два раза больше чем требуется - это для ретины и для простых экранов одновременно), либо через srcset грузи две картинки (1200 для простых экранов и 2400 для ретины) или если хочешь чтобы картинка менялась на разных устройствах, то грузи через picture.
Islam Ibakaev: с моей точки зрения он лучше, так как более распространен. По нему есть больше туториалов и мануалов, да и все требуемые функции выполняет.
У чела по ссылке слишком примитивная реализация.
Она не учитывает момент, когда внутри "li > a" лежит span или другой инлайн тег, или li имеет паддинг / бордер. При делегировании недостаточно отлавливать e.target. Там надо проверять в каком li находится нажатый элемент или является ли сам li этим элементом. Короче этот способ лучше использовать в самом крайнем случае и с осторожностью, когда кликабельных элементов очень много и они предварительно структурированы
sim3x: в любом случае ща уже поздно все делать через brew)
PS:
нашел все что было установлено с помощью встроенной команды printenv в переменной PATH.
Теперь видимо в ручную надо все обновить, благо там не много
Dmitri Sinitsa: поэтому я и говорю, что массив придется сортировать, чтобы слева числа были меньше, а справа - больше. Словарь здесь не подойдет, так как искомого числа в нем может не оказаться и тогда понадобится вернуть другое число определенное компаратором.
Без описания функции findClosest непонятно почему возвращается (b - a) например в первом компараторе. Ну и не обязательно передавать только два параметра. Можно хоть десять, если они помогут решить задачу.
PS: Задачу уже решил сам. Если не увижу более лаконичного решения, то выложу свой вариант.
Для меня глубокие знания JS это примерно 4 по 5-бальной шкале.
Про SPA - как-то они не вписываются в этот ряд)