А вы хотя бы ознакомились со статьями, перед тем, как громко кричать о том, что кто-то у кого-то украл. Даже при беглом просмотре видно, что в статьях есть общие моменты, а есть индивидуальные. Да и при обсуждении одних и тех же проблем, у авторов различные объяснения и примеры. С каких пор обсуждение одних и тех же вопросов стало плагиатом? Можете написать о своем видение основных ошибок при разработке на ноде, мы все с радостью почитаем!
Да, текущая версия ноды 0.12.2 (Stable) поддерживает промисы нативно. 0.10.38 (Maintenance), если я не ошибаюсь, не поддерживает. Также вы можете попробовать IO.js
Вы можете спросить это у автора напрямую www.toptal.com/resume/mahmud-ridwan.
А как проблема использования console.log при отладке связана с логированием работы приложения?
Да, описание решения на промисах было бы куда уместнее. Видимо автор решил, что если человек заметит у себя callback hell, то сможет найти подходящее решение сам.
Большинство начинающих программистов путаются в тонкостях языка и скорее не из-за незнания, а из-за неопытности. Статьи подобного рода помогают избежать лишней путаницы.
Ваш пример некорректен (но, как будет видно дальше, доказывает ваши слова). Вы сравниваете работу разных функций. Первая функция полностью копирует объект, вторая — копируют только те свойства объекта, которые существовали на момент определения функции. Я доработал ваш тест, чтобы результат работы функций был идентичен jsfiddle.net/kuv8m8na/2/.
Вариант с использование конструктора выигрывает приблизительно в 2 раза (50мс на моей машине). Красивый пример, не поспоришь.
Но, за это вы платите абсолютно нечитаемым кодом, проблемами при отладке (тела функции как такового нет, функция записана в одну строчку, остановиться на конкретной строчке вы не можете) и сложностью в поддержке.
На мой взгляд это гораздо важнее, чем выигрыш 50мс на 100000 итераций.
PHP не избавит вас от мук клиентского программирования. И вы не думайте, что на серверной стороне все так просто)
А зачем вы запоминаете костыли? Большую часть проблем кроссбраузерности решает тот самый jQuery.
Про замыкания очень много статей на просторах рунета. Каждый человек пытается объяснить их по-своему. Чем больше подобных материалов вы прочитаете, тем выше вероятность, что вы найдете подходящий именно вам вариант и разберетесь в этом страшном звере по имени «замыкание». Кому-то хватает объяснения Флэнагана, кому-то нужны картинки и объяснение на пальцах.
this никогда не бывает undefined. this — это не переменная, а ключевое слово, которое дает доступ к контексту исполнения функции. Если функция вызывается как метод некоего объект, то она будет исполняться в контексте этого объекта и this в данном случае будет ссылаться на этот объект. Судя по вопросам, который вы задается, вам интересен язык и вы планируете всерьез им заниматься. В таком случае, без тщательного изучения языка вам не обойтись. А для полного осознания замыканий я бы рекомендовал вам тщательно проработать примеры из того же Флэнагана, пусть он и занудный, но раскладывает все по полочкам. Ну и конечно практика, без нее все эти книги просто макулатура.
Позволю себе не согласиться, в JS ООП не эмулируется. JS — самый что ни на есть объектно-ориентированный язык. Наверное вы имели в виду эмулирование классического наследования?! Знать об этом не помешает, но лично я бы не советовал углубляться в эту область.
Я бы посоветовал еще вот эту книгу shop.oreilly.com/product/9780596806767.do
А что касается jQuery-программирования, то это тупиковая ветвь. jQuery — потрясающий инструмент, но без знаний самого языка вам будет крайне сложно развиваться.
Никто и не отрицает, что такая операция корректна. Я не исключаю, что в каких-то жизненных ситуациях без Function не обойтись, но в 99% его использования стоит избегать.
Если вас не затруднит, приведите пожалуйста пример, когда использование конструктора ускоряет выполнение программы по сравнению с литеральной формой записи функции.
Вот простой синтетический тест (очень синтетический), и в нем итеративное создание одной и той же функции через конструктор просто трещит по швам: jsfiddle.net/kuv8m8na/ против jsfiddle.net/cb51fzp2/
И не мудрено, потому что конструктор Function компилирует функцию на каждой итерации, в то время как при использование функционального литерала этого не происходит.
Хотел было привести простой пример, где использование DocumentFragment дает прирост, но не тут то было. Судя по всему, современные браузеры настолько все оптимизируют, что в большинстве случаев разницу не почувствуешь. В моем тесте, о котором я говорил, тестируется производительность моей библиотеки. Сам тест получился очень массивный и в нем действительно использование DocumentFragment дает выигрыш чуть ли не в 2 раза. В попытках докопаться до того, где же все-таки проседает, я остановился на месте, где в одной из функций jQuery есть обращение к свойству объекта CSSStyleDeclaration. И именно это обращение просаживает производительность в варианте без DocumentFragment.
Если мне удастся вычленить эту проблему и сделать под нее наглядный пример, я об этом обязательно напишу.
поскольку присвоение нового объекта мгновенно обрезает связь.
Если я правильно понял, то вы имеете в виду присвоение нового объекта экземпляру?!
В таком случае собственное свойство экземпляра скрывает свойство прототипа (если по-простому). Если это вам кажется странным и неуместным, то значит вы мало знакомы с наследованием на базе прототипов и пытаетесь превратить его в наследование на базе классов.
Не надо тащить в JS терминологию из других языков (КЛАССических) и пытаться сделать JS похожим на эти языки. В JS всё является объектами и функции тоже. В прототипе вы можете хранить все что вам вздумается. Прототип — это объект и не более того. Не надо к нему относиться как к чему-то особенному и накладывать на него ограничения. Хранить в нем объект — отличный способ получить к этому объекту доступ из всех экземпляров.
Только immutable данные могут быть прописаны в прототипе.
Вы слишком категоричны. Т.е. функции в прототип класть нельзя?
Да и в объектах, находящихся в прототипе, я вижу ничего страшного, если это сделано осознанно.
Вообще правда. Было бы лучше, если бы автор статьи обобщил (я не стал менять, хотя и очень хотелось) — если значение одного типа используется в контексте, требующем значение некоего другого типа, интерпретатор JavaScript автоматически пытается преобразовать это значение.
Операторы равенства имеют свою логику при сравнении. Т.е. нельзя сказать, что операнды оператора равенства используются в том или ином контексте.
в количестве 5000 штук с использованием DocumentFragment отрисовывается за 3-4 секунды, без него — 8-9 секунд.
Можно взять более сложный html-блок и уменьшить количество.
А как проблема использования console.log при отладке связана с логированием работы приложения?
Вариант с использование конструктора выигрывает приблизительно в 2 раза (50мс на моей машине). Красивый пример, не поспоришь.
Но, за это вы платите абсолютно нечитаемым кодом, проблемами при отладке (тела функции как такового нет, функция записана в одну строчку, остановиться на конкретной строчке вы не можете) и сложностью в поддержке.
На мой взгляд это гораздо важнее, чем выигрыш 50мс на 100000 итераций.
А зачем вы запоминаете костыли? Большую часть проблем кроссбраузерности решает тот самый jQuery.
Я бы посоветовал еще вот эту книгу
shop.oreilly.com/product/9780596806767.do
А что касается jQuery-программирования, то это тупиковая ветвь. jQuery — потрясающий инструмент, но без знаний самого языка вам будет крайне сложно развиваться.
Если вас не затруднит, приведите пожалуйста пример, когда использование конструктора ускоряет выполнение программы по сравнению с литеральной формой записи функции.
Вот простой синтетический тест (очень синтетический), и в нем итеративное создание одной и той же функции через конструктор просто трещит по швам:
jsfiddle.net/kuv8m8na/ против jsfiddle.net/cb51fzp2/
И не мудрено, потому что конструктор Function компилирует функцию на каждой итерации, в то время как при использование функционального литерала этого не происходит.
Если мне удастся вычленить эту проблему и сделать под нее наглядный пример, я об этом обязательно напишу.
Если я правильно понял, то вы имеете в виду присвоение нового объекта экземпляру?!
В таком случае собственное свойство экземпляра скрывает свойство прототипа (если по-простому). Если это вам кажется странным и неуместным, то значит вы мало знакомы с наследованием на базе прототипов и пытаетесь превратить его в наследование на базе классов.
Вы слишком категоричны. Т.е. функции в прототип класть нельзя?
Да и в объектах, находящихся в прототипе, я вижу ничего страшного, если это сделано осознанно.
Операторы равенства имеют свою логику при сравнении. Т.е. нельзя сказать, что операнды оператора равенства используются в том или ином контексте.
в количестве 5000 штук с использованием DocumentFragment отрисовывается за 3-4 секунды, без него — 8-9 секунд.
Можно взять более сложный html-блок и уменьшить количество.