Вы тоже конечно правы, но непонимание как применить новый ЯП к своей работе тоже не является критерием истинности, согласитесь. Это все шоры, в какой-то степени узость мышления. Все потому что нам сложно оценить старые проблемы с новой стороны.
Вот вспомните, показательную как мне кажется, историю с XmlHttpRequest. Не ЯП, но все же история чем-то напоминает. Он был придуман и реализован в Microsoft на заре гегемонии, wiki утверждает что в IE5. И несколько лет не был вообще никому не нужен. Ну есть и есть, и реализован за это время был уже во всех браузерах, а все равно толком никто не пользовался. Пока Google не сделал с его помощью карты, а потом и gmail с динамическим интерфейсом. И тут вдруг все поняли что это не просто новый асинхронный способ выстрелить себе в ногу, а вполне себе работоспособный инструмент, который способен решать свой спектр задач. Не «убийца XXX», а просто новый инструмент, дающий новые возможности и в некоторых случаях экономящий кучу времени.
Я тоже долго сидел, нравилось что все вместе, еще и RSS туда же. Но стал замечать что при большом количестве писем/RSS-постов (полгода-год, до 30-40 000 писем/постов) браузер начинал значительно медленнее работать. И периодическое убивание всех накопившихся RSS-сообщений и некоторой ненужной части почты, все опять начинало «бегать».
После второй или третьей такой «чистки», каждая из которых значительно ускоряла браузер, я не выдержал и перенес почту в thunderbird, а rss на feedly.
Читаю ваши статьи и очень нравится ваш продукт, в частности android-приложение, но Днепропетровска нет :(. Из украинских городов, я так понял, есть карта только Донецка и Одессы (неожиданный набор, даже Киева нет).
Добавляйте города! Пусть пока без 3D-зданий, но хоть с картой.
Это всего-навсего значит что node.js не подходит для ваших типовых проектов.
Что же вы так по себе всех разработчиков ровняете? «Типовые проекты» — они разные бывают. Для кого-то «типовой проект» — это сайт-визитка на Юкозе, и он даже после появления вордпреса/джумлы на ноде будет говорить «Значит node.js не подходит для типовых веб-сайтов».
Иногда получается странный эффект совместно с адаптивным дизайном.
Там в примере есть раздел с колонками, которые занимают примерно четверть ширины, и шрифт «мельче обычного», выглядит как какая-нибудь «дополнительная информация». Пока ширина окна достаточная для отображения колонок, все нормально, но при уменьшении ширины колонки ставятся друг под другом и растягиваются на всю ширину, и в этот момент шрифт становится очень большой, крупнее обычного, почти заголовочный.
Т.е. на десктопе одна и та же информация выглядит как дополнительная, а на мобильнике будет выглядеть как доминирующая. Понятно что плагин лишь реализует алгоритм, но все же эффект может оказаться неприятный.
Вы правы отчасти. Вообще, с ИЕ8 все интересно: с одной стороны в нем уже есть querySelectorAll, но с другой стороны в нем все еще нет getElementsByClassName.
Поэтому если селектор простой (т.е. содержит только ид/классы/теги/неймы и отношения " " и >) то да, querySelectorAll справится и все будет гуд.
А вот если в селекторе будет что угодно кроме этого, то запустится Sizzle-овый внутренний поиск, который уже не пытается использовать querySelectorAll, а использует только getElementById, getElementsByClassName, и т.д. И поскольку getElementsByClassName в ИЕ8 нет, по факту довольно безобидный с виду запрос
$('.second-choice:checked')
превратится в
$('*').filter('.second-choice:checked');
а это нереально медленно, ибо перебирает совсем все элементы, начиная от html/head/body/script и заканчивая последней a/b/i/sup. И в этом случае простое добавление тега input в селектор ускорит его в ИЕ8 в сотни раз.
В современных браузерах селекторы будут обрататываться браузерным .querySelectorAll, а значит второй будет медленнее (ибо 2 вызова querySelectorAll + js-ный бутерброд между ними).
Кроме того разница будет заметна еще больше в старых ИЕ (6-8). Если вы хорошо относитесь к пользователям ИЕ 6-8, то да: стоит избегать ситуации когда самый правый элемент селектора состоит только из класса (в старых ИЕ из-за отсутсвия getElementsByClassName() это приведет к полному перебору ВСЕХ элементов, и проверке имеет ли элемент класс), и добавлять к самому правому элементу селектора хотя бы имя тега.
А вот второй ваш способ есть смысл применять только в случае когда в вашем селекторе есть нечто что 100% не может быть обработанно querySelectorAll. Обычно это Sizzle-овый селекторовый сахар, типа псевдоклассов :eq() :not() :contains(), :first, :last, :even, :odd, :gt, :lt, :eq (они перечислены на главной странице Sizzle). Тогда ту часть которая может быть распарсена querySelectorAll стоит запускать сначала через $(), а остальное через .find()
Sizzle всегда пытается вызвать querySelectorAll обернув его в try/catch и только в том случае если браузер упал при попытке это разобрать, запускает свой внутренний поиск.
А еще перед этим у него есть отдельные проверки если селектор является просто ID — запускается getElementById(), если просто класс — getElemenstByClassName() — это как раз случаи из статьи.
Т.е. здесь собственного поиска Sizzle не изменрялась. Измерялось время на обертки, регексп чтобы понять является ли селектор просто ид/классом/тегом и собственно вызов getElementById/getElemenstByClassName.
Поэтому становится еще непонятнее почему так медленно?
за эти деньги увеличивали можности, расли технологически
Вы думаете что без денег Apple Samsung бы медленнее развивался, и вообще «отъелся» как вы сказали именно на них?
Судя по вики Apple Inc. хоть и является вторым по величине клиентом Samsung Electronics но приносит лишь 2,6% дохода. Samsung Electronics — монстр, который производит вообще все от «мобилок» до холодильников с пылесосами, который растет давно, планомерно и отнюдь не только за счет того что… «они изначально чуть ли не половину телефона для Apple делали»
Наверное потому что среди программ, которыми я пользуюсь, очень немногие открыты не на весь экран (калькулятор, когда нужен раз в месяц, и всякие IM/Skype).
Если бы была реализована обратная возможность черчения — создание замкнутого объёма и только после этого присвоение коткретного атрибута (этот кубик — стена, а вот тот — ступенька) — проектирование можно бы было назвать более интуитивным.
У нас есть кухня и кто-то приносит, греет, и иногда готовит на месте. Кто-то ходит в ближайшую столовую «на комплексное питание», но большая часть заказывает еду в офис по телефону.
К нам как-то обратились представители Днепропетровского дома органной музыки с просьбой по саппорту их сайта. Если конкретно, то они хотели поменять текст на сайте, а со старыми разработчиками разругались.
Каково же было наше удивление когда мы зашли на сайт и увидели что он состоит просто из одной картинки. Если тут хотя бы текст поверх картинки и его, теоретически, можно поменять; то там он был вставлен прямо в фотошопе. Одна страница — одна картинка: логотип, wellcome, номера телефонов, все как положенно. Вот уж где, наверное, были проблемы с СЕО :)
Вы правы. Они сдирают много, а делают мало. Да. И вы в праве быть недовольным и перестать скажем платить налоги и уйти в тень с формулировкой
Сколько бы человек не платил в налоги эта система все равно все разворует.
Хорошо. А теперь представьте что вы всех уговорили. И представьте что все с нового года ушли в тень. ВСЕ. Никто не платит налоги! Нереально, но представьте.
И? Вы считаете станет лучше? Они сразу одумаются, возьмут из своего кармана денег, все восстановят (машины скорой помощи будут приезжать через 4 минуты, дороги, жилье, ЖЭКи) и скажут: «Ой, мы тут типа все поняли, ладно, пацаны. Теперь все будет хорошо, начинайте опять платить налоги». Вы так думаете? Да нет же. Все просто рухнет. Они свалят как с тонущего корабля, а мы останемся. Из нас тоже кто-то свалит, но все не успеют как минимум потому, что нет на планете места где вот так просто рады принять 45 миллионов человек.
Вот и получается что вы с одной стороны правы. А с другой стороны бороться с тем что вам не нравится ИМХО нужно по-другому. Голосовать против, быть недовольным вслух, выдвигать инициативы. Ну или хотя бы делать то что умеешь хорошо и по совести, без вот этих вот детских «а они первые начали». А то мы тут с вами посидели, потрындели, семки пожевали и разошлись… в тень, в надежде что это ж только я в тень ушел, все ж не уйдут, вот за их счет пусть скорые и докупают.
Кстати, если кто-то сталкивался, расскажите: как оно?
Вот вспомните, показательную как мне кажется, историю с XmlHttpRequest. Не ЯП, но все же история чем-то напоминает. Он был придуман и реализован в Microsoft на заре гегемонии, wiki утверждает что в IE5. И несколько лет не был вообще никому не нужен. Ну есть и есть, и реализован за это время был уже во всех браузерах, а все равно толком никто не пользовался. Пока Google не сделал с его помощью карты, а потом и gmail с динамическим интерфейсом. И тут вдруг все поняли что это не просто новый асинхронный способ выстрелить себе в ногу, а вполне себе работоспособный инструмент, который способен решать свой спектр задач. Не «убийца XXX», а просто новый инструмент, дающий новые возможности и в некоторых случаях экономящий кучу времени.
Я тоже долго сидел, нравилось что все вместе, еще и RSS туда же. Но стал замечать что при большом количестве писем/RSS-постов (полгода-год, до 30-40 000 писем/постов) браузер начинал значительно медленнее работать. И периодическое убивание всех накопившихся RSS-сообщений и некоторой ненужной части почты, все опять начинало «бегать».
После второй или третьей такой «чистки», каждая из которых значительно ускоряла браузер, я не выдержал и перенес почту в thunderbird, а rss на feedly.
Читаю ваши статьи и очень нравится ваш продукт, в частности android-приложение, но Днепропетровска нет :(. Из украинских городов, я так понял, есть карта только Донецка и Одессы (неожиданный набор, даже Киева нет).
Добавляйте города! Пусть пока без 3D-зданий, но хоть с картой.
Что же вы так по себе всех разработчиков ровняете? «Типовые проекты» — они разные бывают. Для кого-то «типовой проект» — это сайт-визитка на Юкозе, и он даже после появления вордпреса/джумлы на ноде будет говорить «Значит node.js не подходит для типовых веб-сайтов».
Там в примере есть раздел с колонками, которые занимают примерно четверть ширины, и шрифт «мельче обычного», выглядит как какая-нибудь «дополнительная информация». Пока ширина окна достаточная для отображения колонок, все нормально, но при уменьшении ширины колонки ставятся друг под другом и растягиваются на всю ширину, и в этот момент шрифт становится очень большой, крупнее обычного, почти заголовочный.
Т.е. на десктопе одна и та же информация выглядит как дополнительная, а на мобильнике будет выглядеть как доминирующая. Понятно что плагин лишь реализует алгоритм, но все же эффект может оказаться неприятный.
Более новых публикаций пока не встречал, если у кого есть — поделитесь.
Поэтому если селектор простой (т.е. содержит только ид/классы/теги/неймы и отношения " " и >) то да, querySelectorAll справится и все будет гуд.
А вот если в селекторе будет что угодно кроме этого, то запустится Sizzle-овый внутренний поиск, который уже не пытается использовать querySelectorAll, а использует только getElementById, getElementsByClassName, и т.д. И поскольку getElementsByClassName в ИЕ8 нет, по факту довольно безобидный с виду запрос
превратится в
а это нереально медленно, ибо перебирает совсем все элементы, начиная от html/head/body/script и заканчивая последней a/b/i/sup. И в этом случае простое добавление тега input в селектор ускорит его в ИЕ8 в сотни раз.
Кроме того разница будет заметна еще больше в старых ИЕ (6-8). Если вы хорошо относитесь к пользователям ИЕ 6-8, то да: стоит избегать ситуации когда самый правый элемент селектора состоит только из класса (в старых ИЕ из-за отсутсвия getElementsByClassName() это приведет к полному перебору ВСЕХ элементов, и проверке имеет ли элемент класс), и добавлять к самому правому элементу селектора хотя бы имя тега.
А вот второй ваш способ есть смысл применять только в случае когда в вашем селекторе есть нечто что 100% не может быть обработанно querySelectorAll. Обычно это Sizzle-овый селекторовый сахар, типа псевдоклассов :eq() :not() :contains(), :first, :last, :even, :odd, :gt, :lt, :eq (они перечислены на главной странице Sizzle). Тогда ту часть которая может быть распарсена querySelectorAll стоит запускать сначала через $(), а остальное через .find()
А еще перед этим у него есть отдельные проверки если селектор является просто ID — запускается getElementById(), если просто класс — getElemenstByClassName() — это как раз случаи из статьи.
Т.е. здесь собственного поиска Sizzle не изменрялась. Измерялось время на обертки, регексп чтобы понять является ли селектор просто ид/классом/тегом и собственно вызов getElementById/getElemenstByClassName.
Поэтому становится еще непонятнее почему так медленно?
Вы думаете что без денег Apple Samsung бы медленнее развивался, и вообще «отъелся» как вы сказали именно на них?
Судя по вики Apple Inc. хоть и является вторым по величине клиентом Samsung Electronics но приносит лишь 2,6% дохода. Samsung Electronics — монстр, который производит вообще все от «мобилок» до холодильников с пылесосами, который растет давно, планомерно и отнюдь не только за счет того что… «они изначально чуть ли не половину телефона для Apple делали»
Наверное потому что среди программ, которыми я пользуюсь, очень немногие открыты не на весь экран (калькулятор, когда нужен раз в месяц, и всякие IM/Skype).
У нас есть кухня и кто-то приносит, греет, и иногда готовит на месте. Кто-то ходит в ближайшую столовую «на комплексное питание», но большая часть заказывает еду в офис по телефону.
К нам как-то обратились представители Днепропетровского дома органной музыки с просьбой по саппорту их сайта. Если конкретно, то они хотели поменять текст на сайте, а со старыми разработчиками разругались.
Каково же было наше удивление когда мы зашли на сайт и увидели что он состоит просто из одной картинки. Если тут хотя бы текст поверх картинки и его, теоретически, можно поменять; то там он был вставлен прямо в фотошопе. Одна страница — одна картинка: логотип, wellcome, номера телефонов, все как положенно. Вот уж где, наверное, были проблемы с СЕО :)
Хорошо. А теперь представьте что вы всех уговорили. И представьте что все с нового года ушли в тень. ВСЕ. Никто не платит налоги! Нереально, но представьте.
И? Вы считаете станет лучше? Они сразу одумаются, возьмут из своего кармана денег, все восстановят (машины скорой помощи будут приезжать через 4 минуты, дороги, жилье, ЖЭКи) и скажут: «Ой, мы тут типа все поняли, ладно, пацаны. Теперь все будет хорошо, начинайте опять платить налоги». Вы так думаете? Да нет же. Все просто рухнет. Они свалят как с тонущего корабля, а мы останемся. Из нас тоже кто-то свалит, но все не успеют как минимум потому, что нет на планете места где вот так просто рады принять 45 миллионов человек.
Вот и получается что вы с одной стороны правы. А с другой стороны бороться с тем что вам не нравится ИМХО нужно по-другому. Голосовать против, быть недовольным вслух, выдвигать инициативы. Ну или хотя бы делать то что умеешь хорошо и по совести, без вот этих вот детских «а они первые начали». А то мы тут с вами посидели, потрындели, семки пожевали и разошлись… в тень, в надежде что это ж только я в тень ушел, все ж не уйдут, вот за их счет пусть скорые и докупают.
нет