1) Согласен, пользователь становится все более нетерпелив, мониторинг UX и его аналитика очень важная вещь.
2) Большие компании пишут что-то свое — Angular, Flight, React и т.п. Баду не исключение — когда кода много и проекты нужно поддерживать годами — появляется что-то свое. Наше чем-то похоже сейчас на YouTube SPF идеологически (но в таком виде появилось на 2 года раньше). В ближайшее время будем переходить к более толстому клиенту и скорее всего к M,V,VC,C разбиению. Брать готовый фреймворк бессмысленно, адаптация к нашим задачам и ограничениям будет дороже дизайна архитектуры с нуля. А если речь о базовых фреймворках (починка расхождений в браузерах) то на большом проекте все равно должны быть свои обертки вокруг таких операций для большей управляемости и возможности воткнуть измерения (RUM) и перехватчики ошибок — а что внутри — по большей части привычки и вкусовщина.
3) Важен баланс. С одной стороны полифил querySelectorAll это write-only код — непонятный, дико оптимизированный, загружаешь целиком в мозг, правишь, выгружаешь — тут по-моему по-другому не получится. А какой-нибудь демультиплексор разнотипных реквестов должен быть понятным — возможно много правок потребуется со временем.
Таким образом низкоуровневое ядро может быть набором адцких черных ящиков, само ядро сбалансированным, но лучше читаемым, а код приложения — максимально понятным и экономия на спичках только вредна.
Если есть детальный мониторинг UX, то можно понять когда и где сесть вооружившись профайлером, а где накладные расходы в пределах погрешности.
оригинал — dpp.su/blog/reflow/
PS. вот за это habrahabr.ru/ppg/ принципиально ничего править не буду. уважаемая редакция, не нужно относиться к пользователям как к скоту.
про «другой код» — сама функция три строки, нужные куски либы несколько сотен строк. код не open-source. зачем это в статье? статья не про наш фреймворк.
то, что идея не понятна, я не удивлен. вы не первый.
«переключения классов» фигня очевидная, а вот чтобы применить когда надо и свести сложную задачу к этой простой, нужно понять о чем статья :)
dpp@www1.d3 ~/badoo> grep -rwoEh 'js[twe]' _templates|wc -l
498
и для всех этих случаев у нас 1 строка жс.
если писать каждый раз, то будут сотни функций делающие похожую работу
посмотрел delegate в 1.7.2 — принципиально тоже самое: копание в DOM в цикле (строки 3291, 3297). это и называется «классическая реализация live».
>А найти нужные элементы, это не так уже и долго.
как говорится it depends. но практика это плохая.
вот старый, не очень удачный (сохранен во время аварии) график: время инициализации страницы своего профиля my.dpp.su/badoo/cookie-5-js-1m-aggr.png (на графике среднее из миллионов хитов)
код гмыла не откажусь посмотреть. есть не пожатый?
все зависит от задачи, если посмотреть главную гугла то там и жс с цсс прям в хтмл засунути и всякие onclick атрибуты, но этоже не значит что так всегда и нужно делать.
это просто тестовый пример. а реализация делегирования не кончается одним jQ.live
в моей реализации скорость не зависит от количества обработчиков и является константой — в худшем случае 5 hash lookup, какое-либо взаимодействие с DOM только в случае если верстальщики не могут сверстать правильно, а это менее 10 случаев из нескольких сотен.
маштабируется уже 5й год просто отлично ;)
на счет «лучше все обойду» — не серьезно, хотя на мелких проектах может и допустимо.
> Во время вёрстки верстальщику не нужно знать, что переключение режима выполняется javascript'ом.
мы работаем в команде, понимать что ты делаешь и как это будет использовано коллегами — обязательное требование к хорошему сотруднику
Короткое уточнение: я из него выжал 25К одновременных коннектов, а нам надо 500К+.
сборщик неуправляемый, да. переписывание nodejs/lib/http.js сильно помогло, но не решило проблему полностью
ты когда с -o3 соберешь чтоб узнать каков же реальный выигрыш? мож там system один, а внутри то и там и там libev[ent]
а то с GC в v8 в nodejs у меня все кончилось письмом от одного из комитеров v8 с темой «не верю»
я на firstvds «Разгон» (проблем не было — они уронили всего один раз, правда в самый не подходящий момент). тариф truevds «True20» выглядят превлекательнее.
есть желание перекинуть пару простеньких проектов с шаред хостинга на тот же вдс и взять, например, «True30».
каковы ваши причины перехода? что знаете об их QoS?
это еще что...
как я уже писал мы ищем сотрудников. после этой статьи как-то так получилось, что читать резюме и собеседовать всех кандидатов "подписали" меня. я намного лучше стал понимать работодателей...
это было бы очень смешно, если бы не было так грустно... и что самое грустное - большинство (как, возможно, и афтор резюме из сабжа) даже не понимает "что не так"...
тут примерчик явного кэширования запроса. если совсем немного доточить, то можно хранить что угодно.
на самом деле решение предложенного вами примера не очень корректено. article_list - это основные и единственные данные страницы. если нельзя кэшировать всю страницу, то можно вынести их в тег и кэшировать его (при помощи cache_page). получится неленивая загрузка, но код будет выполняться только если данных нет в кэше.
2) Большие компании пишут что-то свое — Angular, Flight, React и т.п. Баду не исключение — когда кода много и проекты нужно поддерживать годами — появляется что-то свое. Наше чем-то похоже сейчас на YouTube SPF идеологически (но в таком виде появилось на 2 года раньше). В ближайшее время будем переходить к более толстому клиенту и скорее всего к M,V,VC,C разбиению. Брать готовый фреймворк бессмысленно, адаптация к нашим задачам и ограничениям будет дороже дизайна архитектуры с нуля. А если речь о базовых фреймворках (починка расхождений в браузерах) то на большом проекте все равно должны быть свои обертки вокруг таких операций для большей управляемости и возможности воткнуть измерения (RUM) и перехватчики ошибок — а что внутри — по большей части привычки и вкусовщина.
3) Важен баланс. С одной стороны полифил querySelectorAll это write-only код — непонятный, дико оптимизированный, загружаешь целиком в мозг, правишь, выгружаешь — тут по-моему по-другому не получится. А какой-нибудь демультиплексор разнотипных реквестов должен быть понятным — возможно много правок потребуется со временем.
Таким образом низкоуровневое ядро может быть набором адцких черных ящиков, само ядро сбалансированным, но лучше читаемым, а код приложения — максимально понятным и экономия на спичках только вредна.
Если есть детальный мониторинг UX, то можно понять когда и где сесть вооружившись профайлером, а где накладные расходы в пределах погрешности.
www.facebook.com/groups/feedme.ru/
Или в группу пускают по талонам?
PS. вот за это habrahabr.ru/ppg/ принципиально ничего править не буду. уважаемая редакция, не нужно относиться к пользователям как к скоту.
см #comment_4822637
про «другой код» — сама функция три строки, нужные куски либы несколько сотен строк. код не open-source. зачем это в статье? статья не про наш фреймворк.
то, что идея не понятна, я не удивлен. вы не первый.
«переключения классов» фигня очевидная, а вот чтобы применить когда надо и свести сложную задачу к этой простой, нужно понять о чем статья :)
dpp@www1.d3 ~/badoo> grep -rwoEh 'js[twe]' _templates|wc -l
498
и для всех этих случаев у нас 1 строка жс.
если писать каждый раз, то будут сотни функций делающие похожую работу
>А найти нужные элементы, это не так уже и долго.
как говорится it depends. но практика это плохая.
вот старый, не очень удачный (сохранен во время аварии) график: время инициализации страницы своего профиля my.dpp.su/badoo/cookie-5-js-1m-aggr.png (на графике среднее из миллионов хитов)
код гмыла не откажусь посмотреть. есть не пожатый?
все зависит от задачи, если посмотреть главную гугла то там и жс с цсс прям в хтмл засунути и всякие onclick атрибуты, но этоже не значит что так всегда и нужно делать.
но да, без тестов нет смысла обсуждать дальше
в моей реализации скорость не зависит от количества обработчиков и является константой — в худшем случае 5 hash lookup, какое-либо взаимодействие с DOM только в случае если верстальщики не могут сверстать правильно, а это менее 10 случаев из нескольких сотен.
маштабируется уже 5й год просто отлично ;)
на счет «лучше все обойду» — не серьезно, хотя на мелких проектах может и допустимо.
мы работаем в команде, понимать что ты делаешь и как это будет использовано коллегами — обязательное требование к хорошему сотруднику
это случайность, исторически так сложилось :)
сборщик неуправляемый, да. переписывание nodejs/lib/http.js сильно помогло, но не решило проблему полностью
а то с GC в v8 в nodejs у меня все кончилось письмом от одного из комитеров v8 с темой «не верю»
есть желание перекинуть пару простеньких проектов с шаред хостинга на тот же вдс и взять, например, «True30».
каковы ваши причины перехода? что знаете об их QoS?
зы: спасибо, заинтрегован.
только sidebar со списком окон и поиском по нему спасает
как я уже писал мы ищем сотрудников. после этой статьи как-то так получилось, что читать резюме и собеседовать всех кандидатов "подписали" меня. я намного лучше стал понимать работодателей...
это было бы очень смешно, если бы не было так грустно... и что самое грустное - большинство (как, возможно, и афтор резюме из сабжа) даже не понимает "что не так"...
на самом деле решение предложенного вами примера не очень корректено. article_list - это основные и единственные данные страницы. если нельзя кэшировать всю страницу, то можно вынести их в тег и кэшировать его (при помощи cache_page). получится неленивая загрузка, но код будет выполняться только если данных нет в кэше.