Pull to refresh

Comments 320

>>все изменит лишь var внутри функции, который отделит внешнюю q от внутренней в функции
Какой var?
А сорри, недогнал после «пример как var может помешать ожиданиям:»
ну как минимум стоило бы прочитать про typeof
Для кого статья? Если для новичков, то ничего не понятно, если для тех кто понимает, что такое JS, то зачем им эти азы?

Прокомментирую. Вот вы рассказали о переменных. Здорово! Даже есть упоминание от какого языка эти переменные. И… куда мне их запихать? Как мне запустить пример программы, который вы написали? Какой смысл в этом Javascript?

Я знаю синтаксис более 6-ти языков программирования, но за всю жизнь написал дай бог 2,5 программы. Конечно в этом есть 90% моей лени, но 10% процентов вот таких вот статей и книг «для новичка», где дают знания и не объясняют как их применить. Именно по этой причине в свое время ушел в веб(там книжки с примерами).
Критикуешь – предлагай! =)
1. Возможно стоило бы вначале объяснить, зачем нужен JS, что такое и как применяется. Если об этом уже есть статья, то указать линк на нее в тексте. (Я, например пришел сюда с главной и ковырять блог желания особого не было).
2. Возможно, стоило бы указать как прикрепить свой скрипт к HTML-страничке и увидеть результат своих трудов.
=) я понимаю что Вы хотите сказать, но тут и скриптов как таковых нет, это просто описание типов в языке, скрипты будут во второй части, и описание как их запустить, и примеры, здесь же просто небольшое вступление по теории… куда Вы спешите?
Ок. Жду с нетерпением продолжения!
неужели Вы не знаете зачем нужен JS?
Знать базовый синтаксис языка программирования то же самое, как знать базовую грамматику иностранного языка. Только с помощью этого говорить не сможешь. Но и без этого говорить тоже сложно.
Поддерживаю это мнение! А не то кто-нибудь напишет undefined = 3; — и приехали.
Зачем сравнивать, если есть безопасный и простой 'typeof'?
банально запись короче
'typeof' — древнейший оператор, не требует строгого сравнения, плюс прощает несуществующее 'unqualified name'…

'void' также древнейший оператор, позволяющий отказаться от несуществующего в старых браузерах (IE4/5 etc) свойства 'undefined', которое к тому же можно переопределить, но требующий существования свойства и использующий строгое сравнение, плохо реализованное в некоторых версиях старых браузеров…

Некоторый плюс из 'void 0' можно извлечь при проверке редчайших свойств хоста, реализованных с причудами в отношении определения типа, например, в gecko:

alert([
(typeof document.all),
(document.all === void 0),
(document.all === undefined),
('all' in document)
]);

//-> undefined,false,true,true
такие причуды только в режиме совместимости, так что не слишком актуально.
Согласен, поэтому и ратую в общем случае за 'typeof'.
window.xxx === void 0
typeof xxx === 'undefined'

всё-равно войд короче и лаконичней :-P
Без глобального контекста слабо? ;-P
а что плохого в явном указании контекста?
Как с помощью void потрогать xxx внутри функции?
ну, если такая переменная там определена — то не проблема. а если мы не знаем определена ли она — то что-то не так в том самом королевсте ;-)
Дык мы ж и разбираемся, есть она или нет, а если есть, то тогда и в глобальном контексте 'window.' не нужен…
глобальный контекст — логово хаоса. тут действительно переменной может не быть.
а вот в локальном контексте отсутствие переменной означает ошибку.
Почему ошибку, мож свободная переменная.
Спасибо.
Очень интересно будет почитать про тип function.
UFO just landed and posted this here
исключения — это уже метод избежания ошибки, и если возражаете на формулировку, то говорите за обратное действие типа «не будет ошибки», а не упрекайте методом ее обхода через ексепшен.
Ибо фраза у автора не противоречит здравому смыслу, просто вопрос раскрыт не полностью (возможно оставлено для следующей части).
UFO just landed and posted this here
Поставил плюс в надежде на продолжение.
Как вариант:
javascript:alert(typeof(a)=='undefined'?5:2)
//Для проверки скопировать в адресную строку.
Для проверки правильнее использовать конструкцию
if (typeof (object) == 'undefined') {… }
В вашем же случае может оказаться вот такая «радость»:
var undefined = some_value;
И ваше сравнение if (undefined == ...) будет неверным
var NaN = 12;
var w = parseInt(«q»);
alert( «NaN — » + NaN )
alert( «w — » + w )
alert( «w == NaN — » + ( w == NaN ).toString() )
alert( «typeof( w ) — » + typeof( w ) )

я еще затрону типы
Ни о чем не говорящий пример.

var w = parseInt(«q»);
alert(w==w);
alert(w!=w);

NaN — это такое число (typeof w), которое не равно никакому другому числу, даже самому себе. Для проверки на NaN есть функция isNaN, которая по сути является
function isNaN(x) { return x != x; }
Язык изложения жуткий.

«NaN получить очень просто: «q» + 5» — с какого перепугу? «q» + 5 даст «q5».
Да да да. Автору надо еще о приведении типов вспомнить
да, я ошибся, это следствие кучи исправлений, спасибо что поправили
Мужик, parseInt(«q») сам по себе даёт NaN, нахрена там +5?

«Оно появляется при арифметических операциях, когда результат получается не числовой. ( “qw” + 5 )» — а это зачем осталось?
Фишка в том что на этом сайте было бы неплохо видеть действительно интересные статьи, новости. Не просто пресловутый «hello world», особенно на javascript. Этой информации навалом в рунете, причём гораздо развёрнутой. Вам действительно хочется продолжения — например «работа с массивами в javascript»?
> было бы неплохо видеть действительно интересные статьи

А какие статьи были бы интересны? Какого уровня? Направления? Больше теоретические, углублённые или же — практические?
Да, да, общеизвестные сведения мало кого интересуют.
Интересны именно практические вещи, на какие грабли чаще всего встают люди.

Вот я, вроде бы теорию про переменные знаю хорошо, а как доходит до дела ну хоть головой об стену бейся, не получается и все.
Крайний раз я не смог определить переменную следующим образом: var Some.Variable = 'string'
Ну хоть вешайся, пришлось использовать var Some = 'string' хорошо хоть скриптик небольшой был.
напишите что конкретно Вы хотели бы узнать, почему бы и нет? просто есть люди которые совсем не знают JS, и чтобы пользоваться чем-то большим чем «персловутый hello world» надо узнать именно его для начала
Хотим почитать, например. про замыкания в javascript и про тонкости использования this, хотя кажется про это уже кто-то писал.
про замыкания и this будет в статье с функциями и потом еще повторение с обьектами, хотя действительно про это очень много писали, это любимая тема всех кто пишет про JS
«Для начала определимся с моими мнениями: я не мастер в теории, поэтому чтобы Вас не нагружать лишними названиями (я буду указывать сомнения), я буду много чего упрощать.»

помойму, лучше пойти и купить нормальную книгу по яваскрипту, зачем сбивать с толку новичков?
если честно, хороших книг по js очень мало, я бы сказал их практически нет на русском, как следствие люди просто не понимают что это язык не похож на другие, и вырабатываюется антипатия к нему
У кого к нему антипатия, то:
1) тому он не нужен вообще, ибо когда он нужен люди его осваивают;
2) «если с первого раза не получилось, парашютный спорт не для вас».

Насчет книг действительно соглашусь, еще не видел не одной нормальный. Но это справедливо вообще практически к любому языку. Что-то реально отличное выходит крайне редко и о таких книгах в соотвествующих кругах тут же становится известно.
да, да посоветуйте книжки, можно на английском!
2009-01-01 22:14:49 Ebook O.Reilly.-.Webdesign.mit.Javascript.und.Ajax.GERMAN.eBOOk-PDFWriters
2008-08-21 22:21:06 Ebook FriendsofED.Foundation.Website.Creation.with.CSS.XHTML.and.Javascript.Jul.2008.eBook-BBL
2008-08-20 21:47:44 Ebook Addison.Wesley.Dojo.Using.the.Dojo.Javascript.Library.to.Build.Ajax.Applications.Jun.2008.eBook-BBL
2008-08-10 22:12:08 Ebook Packt.Publishing.Object.Oriented.Javascript.Jul.2008.eBook-BBL
2008-05-01 23:45:13 Ebook OReilly.Javascript.The.Good.Parts.May.2008.eBook-BBL
2008-04-13 18:18:50 Ebook OReilly.Adobe.AIR.for.Javascript.Developers.Pocket.Guide.Apr.2008.eBook-BBL
2008-02-20 21:47:56 Ebook SitePoint.The.Art.and.Science.of.Javascript.Dec.2007.eBook-BBL
2008-01-11 19:46:16 Ebook Making.Use.of.Javascript.eBook-EEn
2008-01-09 22:19:20 Ebook Apress.Pro.Javascript.Design.Patterns.Dec.2007.eBook-BBL
2008-01-07 23:42:56 Ebook Apress.Pro.Javascript.Design.Patterns.RETAiL.eBOOk-sUppLeX
2007-12-07 20:10:15 Ebook Wordware.Advanced.Javascript.3rd.Edition.Nov.2007.eBook-BBL
2007-11-25 18:39:51 Ebook Apress.ZK.Ajax.without.the.Javascript.Framework.Aug.2007.eBook-BBL
2007-10-27 17:48:15 Ebook OReilly.Javascript.and.DHTML.Cookbook.2nd.Edition.Aug.2007.eBook-BBL
2007-07-31 22:38:51 Ebook Apress.Practical.Javascript.DOM.scripting.and.Ajax.Projects.Apr.2007.eBook-BBL
2007-07-26 23:00:06 Ebook Wrox.Beginning.Javascript.3rd.Edition.May.2007.eBook-BBL
2007-07-03 20:10:24 Ebook SitePoint.Simply.Javascript.Jun.2007.eBook-BBL
2006-10-15 21:29:44 Ebook Peachpit.Press.Javascript.and.Ajax.for.the.Web.6th.Edition.Aug.2006.eBook-BBL
2006-10-09 08:09:55 Ebook Sams.Javascript.Phrasebook.Essential.Code.and.Commands.Aug.2006.REPACK.eBook-BBL
2006-10-07 23:44:31 Ebook Sams.Javascript.Phrasebook.Essential.Code.and.Commands.Aug.2006.eBook-BBL
2006-09-18 04:56:51 Ebook Sams.Teach.Yourself.Javascript.in.24.Hours.4th.Edition.Jun.2006.eBook-BBL
2006-09-09 23:04:29 Ebook OReilly.Javascript.The.Definitive.Guide.5th.Edition.Aug.2006.eBook-BBL
2006-09-07 22:48:14 Ebook Prentice.Hall.PTR.AJAX.Creating.Web.Pages.with.Asynchronous.Javascript.and.XML.Aug.2006.eBook-BBL
2006-08-27 23:56:16 Ebook Apress.Beginning.Javascript.with.DOM.scripting.and.Ajax.From.Novice.to.Professional.Jul.2006.eBook-BBL
2006-04-20 01:45:25 Ebook Adobe.Press.Adobe.Illustrator.CS2.Official.Javascript.Reference.Oct.2005.eBook-B
2005-11-22 20:44:56 Ebook Adobe.Press.Adobe.InDesign.CS2.Official.Javascript.Reference.Oct.2005.eBook-BBL
2005-11-22 20:44:18 Ebook Adobe.Press.Adobe.GoLive.CS2.Official.Javascript.Reference.Oct.2005.eBook-BBL
2005-11-19 23:49:48 Ebook Adobe.Press.Adobe.Photoshop.CS2.Official.Javascript.Reference.Oct.2005.eBook-BBL
2005-11-16 15:40:25 Ebook Adobe.Press.Adobe.Illustrator.CS2.Official.Javascript.Reference.Oct.2005.eBook-BBL
2005-11-14 17:23:26 Ebook McGraw-Hill.Osborne.Media.Javascript.Demystified.May.2005.eBook-LinG
2005-10-26 03:07:32 Ebook Adobe.Press.Adobe.Bridge.Official.Javascript.Reference.Oct.2005.eBook-DDU
2005-06-15 15:55:24 Ebook Wordware.Publishing.Learn.Javascript.eBook-TLFeBOOK
2005-05-12 07:59:30 Ebook Wrox.Professional.Javascript.For.Web.Developers.Apr.2005.eBook-DDU
2001-01-01 01:01:01 Ebook John.Wiley.and.Sons.Javascript.Bible.5th.Edition.eBook-DDU
Да, кстати — порекомендуйте, пожалуйста, хорошую книгу по яваскрипту. Так, чтоб основательно и актуально.
«Javascript: The Definitive Guide» By David Flanagan
«Pro Javascript Techniques» By John Resig
Нашел упоминания этих книг когда-то именно здесь, на хабре. Очень доволен.

Ну и если не лень читать совсем официальную литературу — «Standard ECMA-262» :)
«Pro Javascript Techniques» By John Resig — крайне низкого качества книженция.
2006-09-09 23:04:29 Ebook OReilly.Javascript.The.Definitive.Guide.5th.Edition.Aug.2006.eBook-BBL

Читаю в данный момент. Она есть в русскоязычном варианте.
Считаю ее толковой и рекомендую.
>Типы данных:

Неточная линейка типов. Встроенные типы данных — это Undefined, Null, Boolean, Number, String, Object. Массив и функция относятся к последнему. Условно можно считать это «подтипом» типа Object.

>а можно обьявлять и без var

В строгом смысле переменные нельзя объявлять без 'var', именно это ключевое слово и характеризует объявление переменной. Конструкция 'x = 5' является обычным присваиванием и похожа на объявление переменной в глобальном контексте только тем, что и в том, и в другом случае глобальный объект получит новое свойство 'x', так устроено присвоение значения несуществующему свойству. Неточная формулировка по «объявление без вар, которое и не объявление вовсе» пошла с самых первых версий спеков Javascript (tm), тем самым разработчики просто упростили текст, не углубляясь в дебри, в дальнейшем это было исправлено и уточнено.

>появляется при арифметических операциях, когда результат получается не числовой. ( “qw” + 5 )...
>NaN получить очень просто: “q” + 5.

NaN тут не при чём вообще. Значение первого операнда — строка, значение второго будет конвертировано в строку, в итоге — конкатенация строк и строка в результате (тип String).

>это значение указывает что переменная (свойство) не существует (в отличии от null, где переменная есть, но значения у нее нет)

Значение 'undefined' такое же полновесное значение, как и 'null', если есть значение, то есть и свойство, его не может не быть… ;)

Можно подробнее про undefined?
Если выражение window.abrakadabra вернет undefined, это значит, что свойство существует? Тогда в какой момент свойство начинает существовать, если я заранее не присваивал ему никакого значения?
Нет свойств без значений, автор не прав, говоря про null, «где переменная есть, но значения у нее нет». Что касается 'undefined', то если 'typeof window.abrakadabra' возвращает строку 'undefined', это одно из двух:

a) свойство не существует вообще;
б) свойство есть и соответственно значение есть (тип Undefined).

После положительной проверки на 'undefined', вы обычно присваиваете свойству значение, и в этом смысле нет разницы есть свойство или нет, если нет — будет создано и присвоено значение, если есть — будет просто присвоено значение. Разница между существованием и несуществованием может быть заметна в других случаях, когда вы столкнётесь с наследуемыми свойствами и т.п.
вот скажите, зачем мне копировать книги? я хочу простым путем обьяснить людям что к чему
Если теория кажется чересчур академической, то умение объяснить простым языком — это хорошее умение. Главное — чтобы в этих упрощениях не нарушить идеологию и не «переврать» с основной теорией.
«я не волшебник, я только учусь», а вообще все приходит с опытом, я не могу сразу так взять и написать волшебную статью, и полезную и нужную и простую… я надеюсь методом проб и ошибок я этого добьюсь, благо всегда смогу исправить «перевранное» либо в этой же, либо в следующей статье, ориентируясь по коментариям, здесь не мало знающих людей, жаль что не все помогают, многие просто «умничают»
Когда вы обращаетесь к свойству объекту window, вы обращаетесь через геттер. А он может вам выдать undefined, если даже переменная не определена.
да, Вы правы, но я специально хочу упоростить, так проще обращать внимание людей на нужные мелочи, что плохого в том что есть грубое разделение типов, пусть и некорректное, это ведь не конце, ко всему прийдем (я надеюсь)
насчет undefined и null
var q = {'key': 'value'};
q.key1 = // неужели это свойство существует? хотя значение оно даст, с null так сделать нельзя
>хотя значение оно даст, с null так сделать нельзя

Кто оно? У свойства нет значения, не самого свойства. Нужно видеть разницу между значением свойства и возвращаемым 'undefined' при отсутствии свойства как такового.
null – ничего (пустое значение).
undefined – это значение указывает что переменная(свойство) не существует (в отличии от null, где переменная есть, но значения у нее нет)

а я не так написал в статье?
// у свойства 'x' есть значение (тип Null)
var x = null;

// у свойства 'y' есть значение (тип Undefined)
var y;

// нет ни свойства 'z', ни значения у этого свойства
z;
согласен, я подниму это в дальнейшем, но я считаю что этим не стоит увлекаться (x = undefined)
Вы просто скоректируйте свою терминологию, в js работает делегирование, если вы будете продолжать говорить, что 'null' или там 'undefined' — это не значения вовсе или что-то такое пустое, то не сможете объяснить, как устроен алгоритм получения значения и проч.
да, Вы правы, я исправил
UFO just landed and posted this here
Да хотя бы для того, что бы образовалась дискуссия.
почему бы тогда было не написать просто «42»? :-)
Спасибо! Думаю, что этот цикл статей поможет многим жителям хабрасообщества(ну как минимум мне помогла). Удачи!
Неужели еще кто-то не знает про существование мануалов на mozilla developer center?
неужели кто-то не знает про существование книжных магазинов? Здесь происходит не навязчивое обучение
Продолжайте в том же духе, для новичков будет полезно. Чтоб они перестали думать, что жабаскрипт — игрушечный язык для подмены картинок при наведении на пункт меню. Лично я чем больше пишу на JS, тем больше в него влюбляюсь.

Осветите темы: всё — объекты, и функции тоже, и «классы» — объекты :), контекст вызова функции, замыкания, функции обратного вызова, работа с DOM, события, jQuery и т.д.
> всё — объекты

Почти всё ;)

> «классы» — объекты

Если «классом» Вы образно назвали связку «конструктор + прототип», то да — обе эти сущности — объекты. А в теории ECMAscript, понятия «класс» нет.

> jQuery

А что ж так выборочно? :)
Ну, во-первых, потому что лично мне он нравится, я воспринимаю его как минимально необходимую надстройку над жабаскриптом. Во-вторых, тут как-то был опрос относительно использования js-фреймворков, jquery с большим отрывом лидировал, насколько я помню. В-третьих, я написал «и т.д.», то есть если автору больше по душе другой фреймворк — ради бога, пусть пишет о нем. Хотя насчет jquery того же уже и книга на русском есть, так что тут имеет смысл написать для новичков только введение, затравку, чтоб показать, чем это лучше чистого js.
>чем больше пишу на JS, тем больше в него влюбляюсь.
>я воспринимаю jQuery как минимально необходимую надстройку над жабаскриптом.

Пока ещё не сильно влюбился..., можно и поизменять… ;)
Ну почему изменять… Я когда-то писал на чистом js, без использования фреймворков. А jquery освобождает меня от всякой рутины, отнимающей время, только и всего.
Нечеловеческим усилием воли заставил себя не отвечать про рутину. Холивару не быть. Холивару не быть. Холивару…
У меня тоже нет желания вести холивары, мне он помогает в работе, экономит время, так что я буду им пользоваться кто бы что ни говорил. Но все же было бы интересно выслушать ваше мнение по поводу рутины.
> ваше мнение по поводу рутины

Рутина никому не нужна. Никто за неё не ратует. Другой вопрос об исполнении, оптимальности и качестве кода по устранению этой рутины. А вот здесь уже начнётся бессмысленный холивор (насколько глубого Вы анализировали код jQuery?). Никто не говорит, что фреймворки не нужны, просто могут быть свои наработки, легче, оптимальней и быстрее. Но, естественно, это Ваше право, никто Вас насильно не отговаривает.

Можно, также, здесь рассуждения на эту тему почитать — javascript.ru/forum/offtopic/2813-storonnie-biblioteki-byt-ili-ne-byt.html
да ладно вам =) выходной же! давайте похоливарим!!! =))

Начну я.
БольшАя часть кода фреймворков лишь дублирует функционал яваскрипта в привычном синтаксисе. Юзать фреймворки, это как упортреблять иностранные слова в речи. Почти всегда можно обойтись без этого, но иногда очень нужны.
Вот это вот «иногда» — это критические дни (нехватка времени, лень, бабло, шеф сказал, не умею и т.д.) или что-то другое? Если первое, то почему веб-разработчики поголовно не только этого не стесняются, а, наоборот, бравируют этим, рекламируя фреймворки на каждом углу.
Неа. Иногда это когда требуется например аякс автозаполнение и голосование. Зачем нужно делать это самостоятельно, если можно взять нормальное готовое?
Никогда не встречал экспертных оценок о нормальности. ;)
А для этого я просто сравниваю сложность самостоятельного исполнения и пользу от самостоятельного исполнения. Если польза превышает сложность в 10 раз, то я исполняю самостоятельно)
П.С.
Если такого модуля нет в свободном распространении, то за значение пользы принимается положительная бесконечность)
Тратить время на реверс чужого скрипта и не тратить его на написание своего — почему?
Зачем реверс чужого?
Автозаполнение — там пару килобайт. Просмотрел чуток насчет дыр, и заюзал. В своем баги ловить в разных браузерах гораздо дольше.
Ну, так если вы уверены, что в разных браузерах чужой скрипт будет работать, то зачем искать дыры-то? Или полный реверс (что для универсальных либ несладко), или «на доверии», не глядя.
Если либы то я их не реверсю. А если готовое аякс автозаполнение, то я погляжу его код(хотя если он юзает фреймворк, то код фреймворка смотреть не буду)
Вооооот, раз не смотрим, то не даём оценок о нормальности. Согласны?
Неее. В таком случае я даю оценку нормальности исходя из поведения скрипта в браузере)
Ага, тогда всё-таки надо тестить ака «баги ловить в разных браузерах».
Ага, только запустить 4 браузера намного проще, чем писать с нуля.
Аааа, их всего четыре… и версия одна на всех и новых никогда не будет, тогда понятно, незачем лезть в божественный код… ;)
Я не понимаю, вы что яваскрипт на ядерных станциях используете? Если вам нужно аякс автозаполнение для поиска на сайте по бульдозерам вы будете его писать заного? А сколько времени займет написание и отлов багов?
Как обычно, плавно сползли к экономике. Если вы пишите много и разнообразно, то автозаполнение и проч. решения должны быть в вашей профессиональной копилке, отлаженные, проверенные, в стиле «отвечу за каждую строчку».

И когда вы станете продавать себя бульдозеристам или магазину табуреток, между вами произойдёт честный обмен, они вам настоящие деньги, а вы им — настоящий труд. ;)
Если так писать, то можно и на пхп, руби или питоне тоже фреймворки не использовать. И тогда сроки разработки будут крутыми и поддержку надо будет покупать. О, а я еще ОС использую в которой не могу ответить за каждую строчку, и вебсервер, и интерпретатор, ужас!
Я делаю проекты учитывая их бюджет. Дают мне денег за две недели работы, я делаю 2 недели. Дадут на полгода, прекрасно, я сделаю все эти автозаполнения с нуля и отлажу. У меня итак достаточно настоящего труда в создании сайта, чтобы искать себе еще проблемы на пятую точку.
П.С.
Почему бы не использовать готовые скрипты из профессиональных копилок других людей «отлаженные, проверенные». Всё-таки разделение труда фундаментальная основа человеческой цивилизации.
> П.С.
> Почему бы не…

Да нет, конечно, это замечательно, особенно, если Вы, как профи, готовы подписаться под «отлаженные, проверенные». Передача и синтез знаний — это хорошо.

> О, а я еще ОС использую в которой не могу ответить за каждую строчку, и вебсервер, и интерпретатор, ужас!

О, а эту тему я называю «уровни абстракции», на которых программист подключается к своему творческому пути.
Я не профи, но за обычного специалиста сойду. И я перестал страдать синдромом идеального кода)
Я, наоборот, страдаю. Вот чем больше брожу по тормозным еле шевелящимся слоноподобным сайтам, тем больше страдаю.
Ну дык самоделки же)
Самоделки. Пропиаренные. Куда ни плюнь…
Ага, например YASS и прочие глючные поделки)
Не знаю YASS. Точно не ругательство?
> Зачем нужно делать это самостоятельно, если можно взять нормальное готовое?

А если что-то сломается? Сможете адекватно разобраться в скрипте, расширить его, подкорректировать под меняющиеся нужды, расширить и т.д.?
Ну, тогда Вы профи, и, возможно, даже (скорей всего), доработали и соптимизировали сторонний скрипт, так, что он у вас летает во всех браузерах. В этом случае — да, почему бы не использовать эти скрипты, если Вы полностью за них в ответе и сможете по изменившейся ситуации сделать нужную коррекцию.
А зачем?
Мне достаточно того, что он нормально работает на основных браузерах. Большинство скриптов имеют не сложную логику, так что я смогу их изменить.
Да и переписать всегда время есть, это ведь не гигантские программы по десятку миллионов строк. Там 500 то еле набирается в большинстве.
Мне не нужен идеал, мне достаточно приемлевого качества в приемлемые сроки.
> нормально
> качество

Не представляю, как можно компетентно это определить без тотального реверса чужого скрипта, который может занять больше времени, чем написание или адаптация своего.
Допустим вы используете в вашем не веб проекте библиотеку sdl или qt. Вы будете делать тотальный реверс?
Йахуу в общем, я предпочитаю пользоваться наивысшим доступным уровнем абстракции.
В качестве примера:
Если мне надо использовать виджет на сайте, я использую готовый.
Если же мне надо сделать редактор диаграмм я его напишу на чистом яваскрипте, просто потому что нету выгоды от использования фреймворков и нет готовых решений.
Ну, если Вы в силах расширить, дописать, виджет, почему нет? Значит Вы отлично знаете предыдущий уровень абстракции, и нечего волноваться. «Это» вписывается в Ваше относительное «нормально» — ну и всё.
> я предпочитаю пользоваться наивысшим доступным уровнем абстракции

Да, туда, в принципе, всё движется.

Хотя, зависит это от задач. Если у Вас какой-то среднестатистический сайт — то вполне подойдут обобщённые, не оптимальные, решения, если высоконагруженный проект, где нужно выжимать мелочи, то Вы будете оптимизировать эти скрипты, либо напишите свои. Главное, чтобы вы действительно смогли доработать, расширить и т.д. стороннюю разработку. А иначе, можно услышать: «Этот фреймворк такого не поддерживает :(, мы не можем это реализовать, т.к. наш проект полностью завязан на него». Если это не про Вас — смело используйте любую абстракцию на относительно приемлемом для Вас уровне.
Большинство фреймворков довольно таки простые, поэтому можно не парится и легко дописать нужное.
Каким боком это соотносится с browser scripting? Вы же не станете верстать в раннем FrontPage (почти абстракция), на каком основании вы полностью доверяете скрипту, обычному очень-сильно-зависимому-от-внешней-среды скрипту, который должен без ошибок работать в неконечном списке движков (имя им легион), должен быть вам досконально понятен, т.к. вы его внедряете, сопровождаете и т.д.

Экономя время, вы разумно не изучаете скрипт в должной степени, значит, не можете уверенно сказать ни о его качестве, ни о кроссбраузерности, почти ни о чём, кроме api. Вы просто верите, доверяете, предполагаете — вроде многие используют, вроде работает, вроде не жаловались…
Я использую Lightbox, MIT Simile Web Widgets, Raphaël. Скажите ваше мнение относительности разумности использования этих скриптов.
Чтобы этот сделать ответственно мне нужно разобрать скрипты. В любом случае к узким скриптам я отношусь с гораздо большей теплотой, чем к универсальным либам, их разумность априори выше, т.к. меньше избыточность. А сам код нужно смотреть.
Ну MIT — нормальное заведение, так что их скрипт я изнутри только бы проглядел пару минут.
> так что их скрипт я изнутри только бы проглядел пару минут

На предмет чего?
На предмет ярковыраженных идиотизмов. И комментариев о работе скрипта)
Ну вот очень вероятно, что при таких Ваших высоких знаниях и профессионализме (ну а как же? — в сторонней либе легко быстро разберусь, допишу, адаптирую, просмотрю, проанализирую, оптимизирую и т.д. ;)), у Вас, к тому моменту, как Вы столкнулись с этими библиотеками, должны были существовать свои — отточенные и надёжно работающие. Я не прав? ;)
Неа)
Тут не у меня очень высокие знания, тут яваскрипт пока довольно новая технология, и большинство либ занимают не больше 100 килобайт из которых половина комментарии.
А знания я повышал используя яваскрипт не совсем в обычных условиях)
А, т.е., всё-таки, JS для Вас — новая технология? И своими наработками, интересными решениями (возможно, сторонними) и т.д. к моменту появления либ типа jQuery, Prototype и т.д. Вы не успели обрасти? Ну это не страшно, вероятно наработки сторонних либ показались изящней ;)
Конечно новая, она серьезно начала использоваться лет 7-8 назад только. Ну и сам я программирую на яваскрипте всего 3 года.
> мне достаточно приемлевого качества в приемлемые сроки

ну да, на данный относительный критерий посягать вряд ли стоит
Вы уж простите, но про библиотеки я не буду писать =) в идеале, к концу статей люди должны будут сами разбираться на ура в библиотеках
Напишите лучше про SVG)
) по SVG материалов на русском в сети нет ;), даже спецуху до сих пор читаем в оригинале )
Ну дык поэтому и предлагаю.
Дык поэтому и не будет )
Ну дык тогда придется самому написать)
Ой ли… все обещаю, только до сих пор ни кто так и не взялся. Видимо все же не так еще актуально в свете поддежки.
если честно, я с SVG никогда и не работал, поэтому если и буду писать то это получится просто какая-то копия статьи
Ничего страшного, я сам тогда напишу.
Только далеко вперед не забигайте. Придерживайтесь ритма. )
Только далеко вперед не забигайте. Придерживайтесь ритма. )
Чтобы получить NaN надо выполнить parseInt('five') или 0/0;
Есть еще интересное спецзначение Infinity, которое получается при 1/0;
Javascript это не PHP — изучать его по таким мануалам не получится.
Его можно изучать по любым мануалам, главное чтобы было желание понять механизмы. ;) Alert-ы и consol-и в помощь.
дело в том что JS не такой как остальные языки, это и пугает многих, они не понимают его
Что значит «не такой»? А тогда какой это «такой»? Типа не PHP? ;) JS к слову тоже ОО, просто базируется он на прототипах, а не классах и содержит элементы функциональных языков (тот же объект-функция aka безымянная).

Если уж быть совсем педантом, то абсолютно ОО на данным момент на сколько я знаю нельзя назвать ни один из массовых языков.
> тот же объект-функция aka безымянная

не только безымянная

> абсолютно ОО

Нет такого. Любая реализация вправе вносить свои коррективы и новшества, если они технологически и идеологически обоснованы.

Да уж более естесственный, чем тот же PHP.
Как-то более по душе писать нечто вроде
var arr = new Array();
arr.push("d"); arr.push("c");
var str = arr.join(",");

Чем
$arr = new Array();
array_push($arr,"d");
array_push($arr,"c");
$str = join(",",$arr); // Почему не array_join ?
Зачем Вам new Array(); и array_push в PHP?

P.S.: посмотрите, также, Ruby и Python, они похожи на JS.
php притерпел изменения со времен функциональности, в нем можно элементарно сделать класс и инкапсулировать все функции для работы с массивами и будет Вам полноценный массив =)
кстати об этом я писал уже: taliban.habrahabr.ru/blog/48697/
Вот такой вопрос: если вы для объектов используете JSON, зачем для массивов оставили традиционный синтаксис?
чтоб человек знал что и так и так можно создать массив
признаться я не сразу понял, что там две формы объявления массива, но тогда с объектами полная фигня — приведенные json и классический вариант описывают не одно и то же действие.
Факт.
> приведенные json и классический вариант описывают не одно и то же действие.
Факт.

В смысле?
Должно быть как-то так:
var objectVariable = new Object();
objectVariable.key = 'value';
objectVariable.key2 = 'value2';

// или

var objectVariable = { 'key': 'value', key2: 'value2' };
Ах, Вы про конкретику. Мне показалось, Вы говорите, что var obj = {}; и var obj = new Object() — не одно и то же. Пардон. ;)
Ну разумеется :)
Когда говоришь, что одно и тоже можно делать по разному, то на выходе таки должно быть одно и тоже =)
в статье ведь не ставится упор на то чтоб создать похожие обьекты, а описывается какими способами их можно создать
я не понял что Вы имеете ввиду, возможно создание обьектов:
var someObj = {'key': 'var'};
var someObj = new someClass();

типа это не одно и то же действие? вообще это одно и тоже, тоже самое что и:
var intVal = 5;
var intVal = new Number( 5 );

при таком раскладе получаются 2 похожих обьекта
var someObj = {'key': 'var'};
var someObj = new function someClass(){ this.key = 'var' }
просто первый вариант короче
Вот здесь вы все правильно написали.
Не совсем правильно. В случае с intVal на выходе значения разных типов. В случае с someObject на выходе разные конструкторы, разная цепь прототипов, разные наследуемые свойства.
> типа это не одно и то же действие? вообще это одно и тоже, тоже самое что и:
> var intVal = 5;
> var intVal = new Number( 5 );

Здесь не одно и тоже. В первом случае — примитив, во втором — объект.
разница будет только в typeof, все остальное переопределено чтоб максимально совпадать с примитивом, но я человеку показывал лишь способ создания числа
Да нет, второй вариант — это полноценный объект, у него могут быть свои свойства (в отличии от первого). Первый же — примитив, при вызове операций которого создаётся объектный wrapper.
именно, но ведь в итоге я буду работать с врапером так же как с обьектом, буду иметь те же методы и свойства, визуально разницу увижу только при помощи typeof, я это имел ввиду
> я это имел ввиду

да я понимаю, просто уточняю, чтобы не было путаницы, потому что фраза «это одно и тоже» здесь не подходит:

var a = new Number(10);
a.b = 20; // ok

var c = 10;
c.b = 20; // error
кстати, вопрос на засыпку =) как отделить обьект от массива?:)
Да, «со 100% гарантией — никак», поскольку обе сущности — нативные объекты. Но, если сильных «мутаций» не происходило, то можно проверять свойство .constructor; также, массивы имеют {DontEnum}-свойство .length, которое изменяется автоматически при работе методов массива и добавлении свойств, имена которых являются правильными индексами массива (числа, приводимые к строке). Хотя, можно устроить ситуацию, когда любой объект будет иметь в прототипе свойство .constructor === Array, и свойство length.
Угу, спасибо за инфу (все комменты, правда, не дочитал). Интересная реализация. Заодно посмотрел релизацию .concat'а (в Spider Monkey) и как там эта проверка сделана:

if (aobj && OBJ_GET_CLASS(cx, aobj) == &js_ArrayClass) {
… и т.д.
}
> instanceof

тоже ненадёжно; instanceof работает с цепью прототипов, можно создать «мутацию», когда и «число» будет «массивом».
ну, если кто-то такое сделал — значит это ему было нужно ;-)
> ну, если

да кабы ;)

Я и говорю, если нет «сильных» мутаций, то и простая проверка .constructor'a может подойти.
ну всё правильно =) ты ж передаёшь массив…
> ну всё правильно =) ты ж передаёшь массив…

ой, ну здрасте! массив =) Еще раз — туда же, куда и instanceof относится — анализируется цепь прототипов.

isArray(new Number(1).__proto__ = []); — и это массив, ага :) Это «мутанты». Ы )
var x= {a:1}.__proto__=[];
alert( x.a )
А, чёрт! Конечно, массив, пардон, не доглядел (сказалось, что ночь уже была и спать охота было). Кстати, очень интересное решение. Поскольку .apply делает проверку аргумента на уровне реализации (например, в Spider Monkey):

if (!js_IsArrayLike(cx, aobj, &arraylike, &length))
    return JS_FALSE;

В свою очередь, функция js_IsArrayLike делает следующую проверку:

clasp = OBJ_GET_CLASS(cx, obj);
*answerp = (clasp == &js_ArgumentsClass || clasp == &js_ArrayClass);
if (!*answerp) {
    *lengthp = 0;
    return JS_TRUE;
}
return js_GetLengthProperty(cx, obj, lengthp);

Т.е. проверку внутреннюю проверку пройдут массивы и объекты типа «arguments». Но внутренняя проверка (с instanceof) отсеет arguments. Только, если не задать прототип arguments массивом:

function c() {
  var data = arguments;
  alert(isArray(data)); // false
  data.__proto__ = [];
  alert(isArray(data)); // true
}

Но в целом, эта проверка весьма действенна. +1
Единственное, что можно соптимизировать, конечно — создавать функцию проверки не каждый раз, а единожды, и вызывать argeuments.callee.testFn, например.
> Т.е. проверку внутреннюю проверку пройдут массивы и объекты типа «arguments». Но внутренняя проверка (с instanceof) отсеет arguments.

Блин, каша какая-то из опечаток получилась.

Т.е. внутреннюю проверку (на уровне реализации) пройдут массивы и объекты типа «arguments». Но проверка в JS (с instanceof) отсеет arguments.
А, нет :( Зависит от реализаций. Поэтому — снова — 100% не получится утверждать.
Хотя, там небольшие заморочки (arguments отсеивается в Опере сразу). Определённо, хорошее решение.
опера — единственный браузер в котором массив не является отдельным типом =) тобишь везде, где требуется массив можно передавать объект, который ведёт себя как массив. проверка на instanceof нужна лишь, чтобы гарантировать, что объект действительно реализует интерфейсы массива.
Да нет, просто всё дело в реализации .apply'я в Опере. Жаль, но эта проверка не работает для её.

с тем же

var X = function () {};
X.prototype = [];
var x = new X();

isArray(x); // true :(

В общем случае, полагаться на реализации тоже не стабильно — хрен знает, насколько та или иная реализация отойдёт от стандарта.
в опере массив — это не тип, а интерфейс. соответственно реализуя этот интерфейс ты создаёшь массив.
> в опере массив — это не тип, а интерфейс

Ты про исходники движка JS в Опере? Не знаю, может быть, я не смотрел их (только Sdiper Monkey и Rhino смотрел). В Spider Monkey, там однозначно можно определить по типу (js_ArrayClass).

Ну, а, если говорить об ECMA, то там тип Array не выделяется отдельно.
хотя нет, вру, с конкатом не прокатывает…

function isArray( val ){ return [].concat( val )[0] !== val }
Вы можете столкнуться с кучей ситуаций, сравнение объектов, if(объект) и проч., когда тип будет иметь значение и разница щёлкнет по носу.
Тяжеловато воспринимается текст
Из мануала совсем неясно, почему в примере

> if( undefined === someVar )

используется оператор "===".

К тому же, про опреаторы сравнения вообще ничего не сказано (как они работают, что это такое, как вычисляются).

Это не мануал.
Операторы сравнения подробнейшим образом разобраны в обязательном к прочтению стандарте ECMAscript. Строгое равенство используется в вышеупомянутом случае и-за необходимости отделить 'undefined' от 'null'.
Сейчас-то бестолку отвечать, я знаю что к чему. А тому, кому предназначен этот горе-мануал неясно совсем.

зы. Человек, способный самостоятельно найти, прочитать и понять стандарт, не нуждается в мануалах beginner-уровня.
UFO just landed and posted this here
Что лучше, яблоко или апельсин?
UFO just landed and posted this here
Согласитесь, ваш прошлый комментарий распологает немного к другому)
UFO just landed and posted this here
несколько человек уже обращало внимание на NaN.
как корректный пример:

isNaN
отправилось сообщение раньше чем хотелось:

NaN получить очень просто: “q” * 5
а функция isNaN() используется для сравнения.
да, спасибо, я поправил, о функциях подобного типа я собирался дальше рассказать, здесь только типы и специальные значения
Функция и массив — также являются обьектами, по большому счёту :)

Также пропущен тип RegExp.
Нет типа RegExp, есть «подтип/вариант/назови-как-хош» типа Object.
Этот тип надо выделять отдельно, так как он встроенный.

Равно как и function, равно как array.
Это спеки такие? A я думал это забытый драфт недоделанного классового js2.0 от вольдемара… ;)
первое, что попалось под руку :)
array не совсем тип, я его отделил скорее видуально чем технически
UFO just landed and posted this here
> а можно обьявлять и без var
> numberVariable = 4;
> stringVariable = “text”;

а ты в курсе, что если в IE назвать переменную с подчеркиванием и определить её без var то IE будет ругаться на синктическую ошибку?

shop_cart_count = 0 — скажет «непонятный символ в строке такой-то»

> так они становятся глобальными и видны везде
да ладно? а не в пределах видимости функции ли?
var не влияет на глобальность.
>> так они становятся глобальными и видны везде
> да ладно? а не в пределах видимости функции ли?
> var не влияет на глобальность.

var a = 10; — объявляет переменную в контексте и присваивает ей значение;

— если контекст — функция, то эта переменная будет видна в пределах функции (если только не будет замкнута);

— если глобальный контекст — везде;

Для этих двух контекстов переменная не может быть удалена посредством delete (в отличии от объявления свойства в глобальном объекте через a = 10 — эти «переменные» могут быть удалены (правда, не везде)). Так же есть контекст eval, там var'ы не получают {DontDelete} и, соотвественно, могут быть удалены.
> а ты в курсе, что если в IE назвать переменную с подчеркиванием и определить её без var то IE будет ругаться на синктическую ошибку?

shop_cart_count = 0 — скажет «непонятный символ в строке такой-то»

Это еще что за новость? Может у вас есть DOM-элемент с таким же id? Просто IE может маппитить id'шники в глобальную область.
IE какой версии ругается на ошибку? проверил в 6-й и 8-й версиях — нет никакой ошибки

без var переменная будет свойством объекта window, то есть глобальной переменной.
Большое спасибо за тему. Не то, что бы Вы открыли мне глаза. Просто давно ждал хороший цикл статей по js на Хабре.
Хотя Вас и погромили маленько, не унывайте. Исправляйте ошибки и в бой.
Что ж это вы про DOM ничего не сказали, голубчик? Если не понимать, что такое DOM и из чего он состоит, от джаваскрипта мало толку.
если Вы не заметили, голубчик, я вообще собрался мусолить не одной статьей сабж, и про дом будет, и про все остальное… всему свое время
Тогда и начинать нужно было с описания что где и к чему относится. Что бы в дальнейшем было понятно, о чем вообще идет разговор.
ну я так и написал в самом начале: Итак часть первая: основы основ.
DOM не имеет никакого отношения к языку Javascript.
Спасибо за статью! Мне как новичку в JS очень пригодится, жду еще публикаций! Молодец!
На мой взгляд незачет. То, что тут описано есть в любом мануале на русском языке даже в наше время. На веб эксперименте достаточно давно есть материал который по качеству может и нелучший, но он хорошо структирирован и им удобно пользоваться как справочником experiment.net.ru/js2/index.php

А уж после того, как открылся javascript.ru, то в принципе где либо писать о ней уже не очень правильно ибо там и полно качественно материала на русском (в том числе и особенности реализации в каждом браузерном движке), да и на форуме собрался вполне адекватный и компетентный народ. Поэтому, имхо, материалы на хабре о Javascript как о языке это шлак. Гораздо интереснее и полезнее было бы писать и своих опытах, скриптах и прочих фич которые познаются только на практике и что невозможно обычно найти в документации.

По структуре. Хвалиться не буду, просто приведу пример того, как, имхо, правильно структурировать статью: habrahabr.ru/blogs/erlang/52493/, т.е. список всех базовых типов в начале и потом по подразделам полное описание типов. И всегда считал, что так материал воспринимается лучше + в нем проще ориентироваться как справочником.
> А уж после того, как открылся javascript.ru, то в принципе где либо писать о ней уже не очень правильно

Да ну. Какая разница, где знающий человек пишет?
Есть нормальная логичная тенденция связанные вещи/понятия складировать в одном месте. Ты не будешь, если в здравом уме, хранить молоток в суповой кастрюле, а гвозди в муке. Домкрат к автомобилю в одном гараже, а колеса в другом. Потому что в машанине найти что либо бывает трудно.

Именно поэтому блоги подобные хабру (в том числе и поэтому) стали популярны. Не нужно рыться в поиске хороших материалов, они могут быть собраны в одном месте. Но при этом на хабре зацикливаться не стоит. Если в каком либо другом месте сложилось уже нормальная, вполне компетентное сообщество, а не куча нубов учащих друг друга, то нормальный разработчик будет именно там. И не более.
а я, например, не знал что есть javascript.ru, за это, конечно, спасибо, но есть такая важная составляющая — время, Вы всеравно зайдете на хабр, и 10 минут прочтения очередной статьи не помешает ничему, а вот ходить _просто так_ по сайтам не всегда найдется время, писали ведь про буби, перл, я пропускаю их и все, не мое, а вот человек который совсем не знает JS, за 5 минут узнает пару новых вещей
> писали ведь про буби,… я пропускаю их и все, не мое

А, кстати, если JS нравится, посмотрите и на Ruby (и Python), они идеологически похожи.
не всегда желания совпадают с возможностями =)
И где логика?
Если человек хочет целенаправленно изучить js, то он еще как походит по сайтам — и набредет на javascript.ru

А если человеку не нужен javascript, то ваши статьи ему ничем не помогут (это не считая того, что он, скорее всего, их пропустит).

В общем, я согласен с автором ветки — уже есть получше написанные статьи.
есть конечно, я ж не спорю, я не претендую на идеал написания статей, просто даю некий минимум, а почему мои статьи ничем не помогут?
> уже есть получше написанные статьи

относительно это тоже
А в чем разница между сравнениями "==" и "==="
Мне как человеку знакомому только с С/С++ это вообще не понятно
так как в JS нет четкого определения типа (он выводится по значению в переменной), то и сравнение можно произвести двумя способами с учетом типов и без учета:
var strValue = «5»;
var intValue = 5;

пример сравнения без учета значения:
strValue == intValue // JS не учитывает типы, и пытается значения привести к одному общему типу, результат будет true ( он переводит оба значения в инт и видит что они равны)

пример сравнения без с учетом значения:
strValue === intValue // JS сперва смотрит на типы, сравнивает их и только потом если они равны сравнивает значения (в даном случае одна переменная — строка, другая — число)

об этом я во второй статье буду писать =)
блин, каламбур написал =)
пример сравнения без учета типов:

пример сравнения с учетом типов:
Так язык же не типизированный. При "===" получаем true только когда у нас не только значения равны, но и переменные являются переменными одного типа (int там). В PHP к слову тоже самое. На сколько я понимаю подобный оператор сравнение есть в любом не типизированном языке (в том же Erlangе к примеру есть).
как пример, проверка вхождения подстроки:
strpos($str1,str2);
вернет 0, если строка $str1 начинается с подстроки $str2.
вернет false, если вхождения нет вообще
тут === как нельзя кстати.
UFO just landed and posted this here
UFO just landed and posted this here
можно, но проблемма не в undefined, при такой проверке не сработают null, 0 и "", это слишком глобально =) а я проверял просто на существование переменной
UFO just landed and posted this here
Благими намерениями вымощена дорога сами знаете куда.
Подозреваю что вы не знаете джаваскрипт на том уровне, чтобы учить других. Подобными статьями вы воспитаете новое поколение js-быдлокодеров.
из книг тоже возникает куча быдлокодеров, здесь я хотябы смогуответить на вопросы, а если ответов не буду знать, то будет причина узнать их, это называется симбиоз, кое чему я научу, кое чему мне придется научиться
> Подозреваю что вы не знаете джаваскрипт на том уровне, чтобы учить других. Подобными статьями вы воспитаете новое поколение js-быдлокодеров.

Может быть Вы знаете на «должном» уровне? Вы себя позиционируете не как «js-быдлокодер»?
>Может быть Вы знаете на «должном» уровне?
Может быть. Но т.к. мало кто может сам себя оценить адекватно — утверждать не берусь. В конце концов я не учу людей джаваскрипту.

>Вы себя позиционируете не как «js-быдлокодер»?
Позиционирую. Я неплохо знаю js, хотя сейчас практически перестал на нём писать.

Это уже не первая статья в стиле «изучи ххх за 5 минут» на хабре. Проблема таких статей — они пишутся новичками для новичков. Потому что гуру обычно пишут о более интересных вещах. А новички ничего интересного не знают, но хотят о чем-то написать. Вот и пишут о самом примитивном. Что из этого получается — мы видим на примере PHP.
> я не учу людей джаваскрипту.

Ну тогда (коль скоро Вы взялись судить/критиковать), надо, «критикуя, предлагать» (хотя бы советы по улучшению, указание на недочёт). Просто говорить, что кто-то не знает JS на относительном уровне «неплохо» и называть их быдлокодерами — какой толк?
>надо, «критикуя, предлагать» (хотя бы советы по улучшению, указание на недочёт)
Если вы хотите и рыбку съесть, и косточкой не подавиться — мне нечего предложить. Хотите хорошо знать js — читайте книжки, в комментариях привели несколько. Хотите знать js как-нибудь — обучайтесь на таких статьях.
Рад бы найти хорошую книжку, но облом'c. А вообще… есть два вида полезных статей — очень хорошая и очень плохая. C первой и так всё ясно, а вторая бывает запускает такой базар-вокзал, что по ценности не уступит дельной статье. Да и на хабре невозможно писать только! для новичков, аудитория слишком разная, болоту не зацвести, придут и накажут взбаламутят…
> Если вы хотите и рыбку съесть, и косточкой не подавиться — мне нечего предложить

Только без демагогии ;)

> Хотите хорошо знать js — читайте книжки

Да и в приведённых книжках куча недочётов. Если Вы хотите более-менее глубоко знать JS — прочтите стандарт.

> Хотите знать js как-нибудь — обучайтесь на таких статьях

Да бросьте, Вы, я лишь отметил, что, если Вы достигли уровня «неплохо» (по Вашей мерке), нет смысла говорить сверху о других, как о «js-былокодерах» ;)
>в приведённых книжках куча недочётов
Во всём есть куча недочетов. Закон Старджона можем еще вспомнить. Интересно, какие недочёты, имеющиеся в книжках, отстутвуют в данной статье?

>Если Вы хотите более-менее глубоко знать JS — прочтите стандарт
Во-первых каждый браузер по-своему отклоняется от стандарта.
Во-вторых — само по себе знание стандарта ничего не даёт. Вы можете досконально изучить кирпич, но это не сделает вас хорошим строителем. Поэтому я и говорю — читайте книги. Стандарт — это чистая теория. То что написал автор — это чистая практика. В книгах — и то и другое, в правильном сочетании.
Эх, только я хотел вас поддержать, а тут выпад в сторону стандарта и укол. Стандарт — не кирпич, а буквальное описание того, как именно строить, подробное, обязательное, соблюдаемое всеми в той или иной степени (очень близко). Незамутнённая слеза. Книги же по js — полнейшее, унылое *овно. Современные книги по js ещё страшнее — безграмотный гуглокопипаст в детективном стиле дарьи донцовой. При всём при этом я бы порекомендовал прочитать все найденные книги по js, т.к. с нуля важен посыл автора, методика подачи материала, разжёвывание и не так важно качество.
>выпад в сторону стандарта и укол
Я ничего не имею против стандарта. Но просто прочитав стандарт, вы не узнаете, в каких случаях лучше использовать массив, а в каких — объект/хеш. Вы не узнаете как делать профайлинг и оптимизировать скрипт. Вы даже не узнаете как очистить куки или повесить событие на нажатие кнопки.
Нужно понимать, что стандарт создан не для изучения языка, а для его реализации. И если вы не собираетесь писать свой js-движок, то чтение стандарта вам принесет гораздо меньше пользы, чем качественная книга по JS.
Именно стандарт когда-то раскрыл мне глаза на то, что такое оптимизация, что хешей в js нет и проч. Что касается повесить событие и кукисы, то это «browser scripting», во всём своём сделай-кросс-браузерном уродстве, изучать это не нужно (нужно коллектить инфу, как собирают хаки и быть круглосуточно на острие), это совершенно не интересно и делается или с закрытыми глазами (чёнить простенькое), или через тест-тест-тест (чёнить сложненькое). Ни одна книга не принесет вам такой пользы, как доки-спеки-стандарты. Весь остальной живой scripting нагугливается на раз и приобретается с собственным опытом и путём постоянного общения с коллегами и калеками.
почему бы Вам, вместо того чтоб сидеть в сторонке и кричать как все плохо, не помочь? да, я не гений, я не знаю досконально JS, но я пытаюсь хоть че то помочь тем которые его вообще не знают, не RTFM-ами, а кусочком знания, все что я напишу не так, другие увидят и поправят, в итоге выйдет нормальный мануал, что в этом плохого?
Женщина с ребенком приходит к врачу и обьясняет, что у ребенка понос, дикий кашель, страшная аллергия, кривые ножки, он плохо видит и слышит и т.д. Врач все это молча выслушивает и начинает расстегивать пуговицы у себя на штанах.
— Доктор!!! Что Вы делаете? — спрашивает удивленно женщина
— Чем лечить такого ребенка, так лучше сделать нового.

Надеюсь намёк понятен.
у вас логика женщины — «либо встречу динозавра, либо не встречу» (она еще булева называется)
Очевидно, намёк вы не поняли. Тогда поясню — ваша статья настолько бестолково написана, что я не вижу смысла её исправлять. Как можно объясняя объявление переменных, использовать условные операторы, циклы и функции? Чёрт с ними с ошибками, их вам указали в комментариях. Но если у вас нет ни малейшего понимания о том как нужно излагать материал — о каких обучающих статьях может идти речь? Вам педагогику в ВУЗе читали? Про дидактику что-нибудь рассказывали? Впрочем, я забыл, вы же не пытаетесь _научить_ джаваскрипту, вы хотите чтоб люди умели подключать библиотеки и писать скрипты. Успехов.
я Вам написал — я не преподаватель, я закончил технический вуз, о какой педагогике может быть речь? нас учили находить и делать, ничего больше… А вы разговаривать умели с рождения? неужели нет? неужели Вы научились разговаривать с помошью родителей, разговаривая с ними?… я надеюсь Вы поймете мой сарказм в правильной форме, спасибо.
>я закончил технический вуз
И у вас не было ни одной гуманитарной дисциплины? Вы уверены что вы ВУЗ окончили?
политология была, подойдет? мож философию рассмотреть в роли обучающей дисциплины?
> В книгах — и то и другое, в правильном сочетании.

Хорошо, если б это было так. Но это не так ;)

> Стандарт — это чистая теория.

Незание/непонимание этой теории может приводить к белиберде и искажённому восприятию технологии.
>Хорошо, если б это было так. Но это не так
А аргументировать можно?
Открываю Professional Javascript for Web Developers. Первые 50 страниц — описание основ ECMAscript. Затем еще 50 — описание ООП, применительно к js. Затем еще 500 — последовательное описание различных тонкостей применения js, и решение часто возникающих задач с его помощью. Что здесь «не так»?

>Незание/непонимание этой теории может приводить к белиберде и искажённому восприятию технологии.
Я где-то утверждал обратное?

По-моему, Вы противопоставляли стандарт (aka «кирпич» ;)), который «ничего не даст» и книги, где «очень успешное сочетание практики и теории». Никто не говорит, что книги читать не нужно, нужно просто правильно (относительно притязаний и текущего уровня — «так себе», «неплохо» (у Вас, как Вы отметили), «высокий», «профессионально», «академический» и т.д. (под последние три — подойдёт стандарт)) выбирать.
>По-моему, Вы противопоставляли стандарт (aka «кирпич» ;)), который «ничего не даст» и книги,
Именно так. Попробуйте человеку, который не знает JS, дать почитать ECMA-262. Сможет ли он после этого сразу пойти работать каким-нибудь js-программером? Однозначно нет. А если дать упомянутую мной книгу — вполне.

>«так себе», «неплохо» (у Вас, как Вы отметили), «высокий», «профессионально», «академический»
Мда, это круто. Отличная подмена понятий. И вы мне еще говорили не заниматься демагогией…
Интересно, с чего вы решили что я оценил свой уровень в «неплохо», именно по вашей шкале? Телепаты из отпуска вернулись? Вы действительно считаете что я оценил свой уровень знаний в 2 из 5?
> 2 из 5?

Оу, пардон! Ни в коем разе это была не градация, всего лишь перечисление (причём, некоторые можно поменять местами). Цифры (от 2 до 5) просто совпали.

> Попробуйте человеку, который не знает JS, дать почитать ECMA-262. Сможет ли он после этого сразу пойти работать каким-нибудь js-программером? Однозначно нет. А если дать упомянутую мной книгу — вполне.

Да нет, это Вы подменяете понятия. Я не говорю, что новичку нужно садиться и изучать только лишь стандарт и идти сразу работать после этого. Стандарт — будет следующей стадией на пути к глубокому изучению технологии, но никак не «кирпичом».
А я говорю, что читая книги, человек будет понимать 99% того что написано в стандарте. А с оставшимся процентом, он либо никогда не столкнется, либо поймёт его сам (принцип наименьшего удивления обычно работает). Естественно я не против изучения стандарта, но считаю что это время практически всегда можно будет потратить с большей пользой.
> А я говорю…

Да пожалуйста, кто мешает? :D

> 99%

Смотря что за литература. Может быть и 100%. А может и 34%.

> Естественно я не против изучения стандарта, но считаю что это время практически всегда можно будет потратить с большей пользой

Я не против, Вы сами решаете.

Но, в любом случае, стандарт — не «кирпич» ;)
Вы привели пример не самой неудачной книжки, я её когда-то рекомендовал почитать в части парадигм наследования. Но правильность сочетания — вопрос субъективный, вот я её сейчас открыл наугад, там у него псевдо-объекты какие-то:

The interesting thing about ECMAscript primitive values for Booleans, numbers, and strings is that they are pseudo-objects, meaning that they actually have properties and methods.

… классы:

It is the base class from which all ECMAscript classes inherit.

… глобальные переменные ака «идентификаторы, которые не были объявлены»:

«When the ECMAscript interpreter sees an identifier that hasn’t been declared, it creates a global variable with the given name of the identifier and initializes it with the value specified.»

Плюс к этому автор книжки не является экспертом (сам об этом пишет), не знает некоторых базовых вещей вроде того, создаются ли элементы массива при пропусках (elisions), а это чёрным по-белому написано в стандарте. Полагаться при таком раскладе на его знание тонкостей и корректное изложение основ или не полагаться — ваш выбор. Какие-то вещи мне понравились, но в целом… ;)
Именно из-за удачного разъяснения ООП в js, я и рекомендую эту книгу другим. Самые большие трудности возникают у людей именно из-за непривычности прототипного программирования. Все остальное либо аналогично другим языкам, либо довольно просто понять.
> из-за непривычности прототипного программирования

Сравните его с классовой моделью в Pyhton'e (или Ruby); увидите много общего.
А кому писать для новичков, если гуру заняты своими «возвышенными» интересами? Вот Вы знаете JS, ждя вас кажда мелоч важна, Вы не смотрите на эту статью глазами новичков, которым не вдомек что такое undefined и вообще как несуществующая переменная может возвращать значение, я не хочу нагружать людей с начала, да, я не гуру, но и не сказал бы что быдлокодер, я не знаю все что можно знать, и я тоже читая коментарии возможно узнаю что нибудь интересное от более умных людей, но это не значит что те кто прочитает это станут обязательно быдлокодерами, тут покрайней мере есть кому поправить в отличии от книг и статей без ответов
>А кому писать для новичков, если гуру заняты своими «возвышенными» интересами
Гуру пишут книги, не статьи для новичков. Не потому что они заняты «возвышенными» интересами, и у них нет времени, а потому что понимают как должен быть построен процесс обучения.

>я не хочу нагружать людей с начала
>в отличии от книг и статей без ответов
Уже порядком надоели такие «учителя», которые считают что в книгах написано сухо и неинтересно, а вот они сейчас напишут то же самое простым доступным языком. И каждый из них пишет «я не хочу нагружать людей». Терпеть не могу лицемерие. Признайтесь хотя бы самому себе, что вам попросту нечем «нагружать».
> Гуру пишут книги, не статьи для новичков.

Почему это? Смотря, какая аудитория, и запросы.

> потому что понимают как должен быть построен процесс обучения

Не факт, умение преподавать — это тоже талант и опыт (и может быть не связан с очень глубокими знаниями).
>Не факт, умение преподавать — это тоже талант и опыт (и может быть не связан с очень глубокими знаниями).
Да-да-да. Именно поэтому книг по джаваскрипту написана тысяча, а рекомендуют только десять из них (условно). И эти десять написаны как раз теми, у кого есть и знания, и умение преподавать.
Вот у автора статьи, к примеру, умение преподавать полностью отсутствует. Для того чтобы рассказать как объявлять переменные, он использует условные операторы, циклы и функции. Это по-вашему статья для новичков?
> рекомендуют только десять из них

Лично я рекомендую полторы. Да, всё вы правильно пишите, забывая о главном — в отличие от книги, вы можете 2-мя дельными комментариями укатать любую, самую кошмарную статью. Не надо писать статью-опровержение, рецензию, просто критикуйте, в этом ценность данного формата, ваше недовольство станет частью материала. Чего никогда не будет с книгой. К примеру, на хабре обсуждалась книга, которая в интересующей меня части была «написана» из рук вон плохо. Тут можно об этом написать, а вот посылать вслед уже готовой книге зелёные лучи ненависти — поздно и бесполезно…
а я и не преподаватель, я даже не теоретик, я практик, я много чего могу сделать, а обьяснить плохо получается, у некоторых наоборот бывает, но я вот хочу научиться обьяснять, и я не вижу в этом ничего плохого
> Именно поэтому книг по джаваскрипту написана тысяча, а рекомендуют только десять из них

Ну это во многих областях так ;) Глубоких теоретических и практических профессионалов мало.
Вы злой человек =) я просто пытаюсь помочь хоть чем-то, и хоть кому-то, кто хочет всерьез заняться этим языком, беузсловно возьмется за книги, а тем кто хочет уметь писать скрипты на JS эти статьи должны будут помочь

зы: нагрузка — понятие растяжимое, одним null как обьект — сложно, другие замыканиями жанглируют… а если человек просто элементарную проверку формы хочет перед валидацией? ему книгу для этого надо прочитать? нет, достаточно библиотеку написанную найти, а как ее подключить, как ей оперировать? нужны хоть какие то знания… это как пример
Полностью с вами согласен.
Теперь давайте вспомним, как называют людей, пишут код, не зная тонкостей языка, которые умеют подключать библиотеки, но не понимают как они работают? Правильно, быдлокодеры. А теперь перечитайте мой первый комментарий, и скажите с чем вы несогласны?
я не согласен с тем (уже писал выше) что вместо того чтоб показать недостатки, и дать понять что не так, вы плюете на человека с высоты, на которой скорее всего и не находитесь, смотрите как бы такие плевки, летящие вверх, не попадали под силой тяжести на вас же…
Раз народ спрашивает про книжки, то вот что я бы порекомендовал:

В большинстве случаев более чем достаточно:
1. https://developer.mozilla.org/en/Core_Javascript_1.5_Guide.
2. https://developer.mozilla.org/en/Core_Javascript_1.5_Reference

Кое-какие тонкости есть в книжке:
3. Java script. The goog parts by Douglas Crockford — довольно неплохая книжка, описаны кое-какие тонкости, которые в других книжках

Много полезного про события есть на quircks mode:
4. www.quirksmode.org/js/introevents.html и далее по ссылкам.
а как же книжки O'Reilly, Wiley/Wrox, FriendsofED, Apress, SitePoint ???
Книжек много и все они так или иначе повторяют друг друга. Если назовете книжку, в которой есть что-то, чего нет на упомнятых ресурсах, скажу спасибо.
Спеки обычно звучат сухо и также построены, книжки же могут системно преподать материал, несмотря на плохое качество и неточности. В них всегда «есть что-то, чего нет на упомянутых ресурсах» и наоборот. Если человек вообще не программировал никогда, то с книгой в руках ему легче сделать первый шаг. Дальше лучше работать с э… первоисточниками.
ну во-первых из перечисленного мною спеками является лишь один пункт, все остальное написано вполне нормальным языком, во-вторых во многих книжках очень много воды, толку от нее довольно мало,
Новичок как раз страдает от сухости, ему вода показана. Другое дело, что потом он должен выбираться на сухие места из мутной жижи. :)
давайте не будем заниматься демагогией, если вы можете порекомендовать нормальную книжку, рекомендуйте. рассуждать об абстрактных новичках можно долго.
Фланагановская «Javascript: The Definitive Guide» и ффсё. Есть удачная по структуре, но не по качеству «Javascript 2.0: The Complete Reference».
Пожалуйста продолжайте, не останавливайтесь. Те кто все это знает, пусть просто пропускают и все, читают что либо еще. Здесь все это вполне уместно. Потому что много критики по существу и делегаты очень активные.

1. if( undefined === someVar )
2. {
3. // если переменной нет, мы ее создаем
4. var someVar = 1;
5. }

var'ы создаются до начала выполнения скрипта. Поэтому someVar уже будет создана, и ей будет присвоено значение undefined. Далее, происходит (= 1) лишь присвоение нового значения, а не создание переменной.
Хех, я даже не заметил такого перла. Ужас-ужас-ужас.
var'ы не создаются до начала выполнения скрипта.
«The scope of a variable is the current function or, for variables declared outside a function, the current application. „
Почитайте пункт 10.1.3 стандарта
«до начала выполнения» == «on entering an execution context»
А, слово «скрипт» сбило с толку. Хорошо, перефразирую — при входе в контекст исполнения, но до начала его исполнения. Если контекст один — глобальный, то тут можно сказать и «весь скрипт».

> The scope of…

А тут уже говорится про scope (область видимости).
<тут находиться небольшое определение «переменной»>

--простые типы-------------------

boolean – булево значение, оно имеет 2 варианта, либо true (правда), либо false (ложь)

number – целое число, либо число с дробной частью.

--составные типы-------------------

string(строка) – некая последовательность символов.

object (объект) – фундаментальное понятие ООП, может содержать в себе другие переменные (в том числе и объекты) — свойства, так же имеет методы — особый вид объектов — функции. Является по сути контейнером.

function (функция) – тип, обладающий свойствами объекта, а так же имеющий независимый участок кода, обладающий собственным участком видимости. Помимо этого, функции могут возвращать некоторые значения, а так же получать их в качестве аргументов (например: a = cos(90), в данном случае функция cos(x) вернет 0 и переменная а станет равна нулю).

array (массив) – тип, обладающий свойствами объекта, в котором удобно хранить однотипные данные.

возможно как то так будет лучше для новичков?
function makeSomeAction( someVariable )
{
for( q = 0; q < 3; q++ )
{
alert( someVariable );
}
}
for( q = 0; q < 3; q++)
{
makeSomeAction( q );
}

что значят все эти строки?
ну реально не понятно откуда и как ожидать многие должны были 000111222?
можно комменты к каждой строке?
makeSomeAction( someVariable ) — это просто так захотелось назвать или чтото значит?
> что значят все эти строки?

Инструкции, выражения JS. Код JS.

> ну реально не понятно откуда и как ожидать многие должны были 000111222?

Всё дело в глобальных и локальных переменных. Переменные внутри функции с ключевым словом var считаются локальными в пределах этой функции:

function test() {
  var a = 10; // локальная переменная, видна только внутри функции test
  alert(a);
}

test(); // 10
alert(a); // ошибка, нет такой переменной в глобальной области

В свою очередь, если в коде встречается присвоение «переменной» без ключевого слова var, то такая переменная всегда будет глобальной (выполните код выше, только без var, просто a = 10; увидите, что переменная «a» стала глобальной и доступна за пределами функции).

Поэтому цикл, запускаемый в глобальной области, сработает всего один раз, т.к. условие «q < 3» будет истинно после первого выполнения функции «makeSomeAction( q );» (внутри функции используется та же глобальная переменная, которая по выходу из внутреннего цикла, будет иметь значение 3).

> makeSomeAction( someVariable ) — это просто так захотелось назвать или чтото значит?

Просто название функции, так захотелось.
Ага, опечатка, спасибо =)

Articles