Comments 31
спасибо, кеп(это я автору, а не переводчику).
Вопрос в том как научить программистов тому что javascript это не jQuery, как сказать что это достаточно интересный и своеобразный язык и в нём надо разораться а не применять вслепую.
Вопрос в том как научить программистов тому что javascript это не jQuery, как сказать что это достаточно интересный и своеобразный язык и в нём надо разораться а не применять вслепую.
Я с вам согласен, но к сожалению JavaScript приобрел такую популярность только после jQuery (или подобных), наверное. Еще 3 года назад многие с опасной рассматривали вариант внедрения js — так как не кроссбраузерно и т.д.
Я боюсь после jQuery javascript не получил популярности. Равно как после RoR не стала сильно популярнее первая R.
приобрел популярность? js не кроссбраузерно? есть альтернативы? опасность внедрения js? я в параллельной вселенной? o_O
аватар смените, косяки разметки напрягают на подсознательном уровне
да js ну просто очень опасен
А если серьезно, то привыкая к (а часто начиная с) jQuery, программисты забывают о всей красоте, изящности и возможностях javascript.
>>Вопрос в том как научить программистов тому что javascript это не jQuery, как сказать что это достаточно интересный и своеобразный язык и в нём надо разораться а не применять вслепую.
Тут скорее надо заинтересовать, люди часто ленятся взять хорошую книгу по языку и прочитать от корки до корки, гораздо проще ведь нагуглить что-то вроде «увеличение картинки плагин jQuery».
(function(){arguments.callee();})();
А если серьезно, то привыкая к (а часто начиная с) jQuery, программисты забывают о всей красоте, изящности и возможностях javascript.
>>Вопрос в том как научить программистов тому что javascript это не jQuery, как сказать что это достаточно интересный и своеобразный язык и в нём надо разораться а не применять вслепую.
Тут скорее надо заинтересовать, люди часто ленятся взять хорошую книгу по языку и прочитать от корки до корки, гораздо проще ведь нагуглить что-то вроде «увеличение картинки плагин jQuery».
>> привыкая к (а часто начиная с) jQuery, программисты забывают о всей красоте, изящности и возможностях javascript.
С чего вы взяли что забывают, скорее вообще не знали :)
С чего вы взяли что забывают, скорее вообще не знали :)
А по-моему все вокруг зазря сгущают краски вокруг JQuery. Я начал изучение JS именно с JQ. И лишь спустя время мне стало интересно, а что же у этого JQ внутри, раз он из такого жуткого (как мне тогда казалось) JS делает такую конфетку.
Начинать надо с простого. А JQ это просто и наглядно.
Начинать надо с простого. А JQ это просто и наглядно.
Вы не ошиблись ноликом? Я Уже 6 лет на JS пишу и альтернативы до сих пор никакой нет.
Учатся, как практика показывает, на ошибках. А ошибки обычно возникают с первым более-менее содержательным асинхронным вызовом.
Пост написан автором больше года назад, и там же, в комментах ему на пальцах объяснили, что это уже неактуально.
В jQuery, кстати, тоже возможны утечки, если, например, будет смешанное использование jQuery и стандартных вызовов (из-за использования jQuery.cache).
UFO just landed and posted this here
Это что же за сборщик мусора такой, который не умеет с циклическими зависимостями справляться? А что делать, если нужно использовать в обработчике element, а не только a и b?
В php со сборкой мусора с циклическими зависимостями тоже бывает беда.
Ага, ошибаюсь, видимо знания старее 5.3. Для тех, кто думал так же как и я — php.net/manual/ru/features.gc.collecting-cycles.php
Тут немного коряво, вообще говоря в as3 который тоже EcmaScript 262 циклические ссылки удаляются, но вот если хоть один элемент изх цикла висит на экране весь цикл и повиснет на одном элементе. Это очень частая причина утечек.
Если мне не изменяет память, в ECMAScript вообще не определен алгоритм работы сборщика мусора, потому все зависит от конечной реализации.
А что касается IE, то до восьмой версии сборщик хоть и работал по принципу mark&sweep, а значит, был способен чистить циклические ссылки, но из-за особенностей работы COM (в котором используется подсчет ссылок) наличие ссылок в expando DOM-элемента на объекты скриптового движка в одном замыкании с объектами, ссылающимися на этот DOM-элемент приводило к таким неразрешимым случаям.
А что касается IE, то до восьмой версии сборщик хоть и работал по принципу mark&sweep, а значит, был способен чистить циклические ссылки, но из-за особенностей работы COM (в котором используется подсчет ссылок) наличие ссылок в expando DOM-элемента на объекты скриптового движка в одном замыкании с объектами, ссылающимися на этот DOM-элемент приводило к таким неразрешимым случаям.
Насколько я помню, несвежие IE этим точно страдали
UFO just landed and posted this here
Фигня. И хром, и фф, и опера, и эксплорер версий 8+ нормально с такими утечками справляются.
Ну и для того, чтоб избавиться от них, не надо выносить обработчик наружу, можно в замыкании ссылку на элемент прибить:
Ну и для того, чтоб избавиться от них, не надо выносить обработчик наружу, можно в замыкании ссылку на элемент прибить:
function foo(element, a, b) {
element.onclick = function() { /* использует a и b */ };
element = null;
}
Это актуально только в части браузеров, а точнее — в старых FF и IE.
Такая утечка возникает только тогда, когда GC использует «счетчик ссылок» (в FF счетчик ссылок использовался для элементов DOM) и из-за этого не может разрешить циклические ссылки.
Такая утечка возникает только тогда, когда GC использует «счетчик ссылок» (в FF счетчик ссылок использовался для элементов DOM) и из-за этого не может разрешить циклические ссылки.
UFO just landed and posted this here
бред
Браузеры ведут себя по-разному в таких ситуациях, если открыть такой код через web inspector в хроме, то можно увидеть, что замыкание может и не сохранять те элементы, которые оно не использует, т.е. если внутри onclick колбэка не будет обращения к element, то замыкание не сохранит ссылку на него в разделе Scope variables это можно увидеть
Sign up to leave a comment.
Утечки памяти в замыканиях JavaScript