Баннер конференции о JS с ошибкой в JS

[@TheShock]

Вообще-то современные браузеры игнорируют эту ошибку)

[@ZimM]

Это не значит, что ошибка перешла в разряд фич)

[@Snipe]

Ну так это же конференция. На них обычно рассказывают о будущем.
А ECMAScript 5 допускает так ставить запятые.

Так что для конференции баннер нормальный. %)

[@Snipe]

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

Да и как часто на конференциях говорят «Вот теперь такая вишка есть, и она работает в IE»? )

[@ef_end_y]

На самом деле удобно, когда код JS формируется динамически другим приложением, не обрезать последнюю запятую

[@Sannis]

Удобно использовать join, а не поэлементный вывод.

[@ef_end_y]

с большими объемами данных не всегда рационально, проще приклеить следующий блок данных к текущему, чем вызывать join

[@taliban]

Не поверите, но с большими данными джоин массивов обычно справляются лучше канкатенации строк. Да и код выглядит приятней.

[@dmitry_dvp]

не поверите, но кроме больших объемов данных, бывают данные очень больших объемов или данные с неизвестным заранее объемом, потоки данных.

[@taliban]

Работа со строками более накладна чем с массивами. Бывают моменты когда работа со строками быстрей, но этих моментов меньше, поэтому можно их смело отложить в сторону до времен «когда будет тормозить». Работа с массивами более эстетична, и визуално более понятна.

for( key in items )
{
    buffer.push( items[key] );
}
return buffer.join( ' , ' ); // prepare where in conditions

for( key in items )
{
    in += ',' + items[key];
}
return in.slice(1); // prepare where conditions, not need first coma

По мне так работа с массивами выглядит аккуратней. И даже если бы она была медленней, я бы ее всеравно использовал бы чаще.

[@ef_end_y]

Хорошо. У вас есть функция, которая добавляет за раз к строке одну порцию данных. Через запятую. Вы будете организовывать через массив?

[@taliban]

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

Худший из вариантов, но в любом случае лучше чем просто конкатенация:

var str = "hello #{username}! You got an message '#{message_subject}' on #{message_date}."
q.replace( /#{(\w+)}/, function(text, match){ 
    return data[match] || '';
} )

Вариант хоть и на регулярке, но он лучше. А лучше он удобством, простотой и универсальностью. Конкатенация — неудобный вариант. Плюсики строк — убоги, и подходят лишь для лепки пары кусочков строки (имя фамилия и подобных).

[@taliban]

Опечатка
q.replace = str.replace

[@ef_end_y]

т.е вы приводите пример, с которым я-то и не спорю (join массива), а другие видеть не хотите, потому что у вас таких задач нет? А у меня недавно была задача. Нужно было на ajax запрос дать ответ: куча координат, разделенных запятой. В серверной части я посчитал нерациональным сначала получить массив координат, а потом джойнить их через запятую т.к. массив тут явно лишнее звено. Я просто сделал $result .= "$x,$y,"; и после цикла chop $result (убрал последнюю запятую). Получилось очень просто и удобочитаемо. Сереьрянной пули, как вы понимате, не существует в программировании. Имеют права на существование разные подходы

[@taliban]

А могли бы отдать массив =) Или аяксом гонять массив в наши времена некошерно? А еще я не понимаю какой смысл в строке:
2,3,54,324,5567,504,938,49578,3827,2384,48374,38484. Вы ее так в чистом виде и показывали клиенту? Или всетаки разбивали и делали с ними что-то? Если второе то какой смысл в строке, если можно передать массив? Если первое, то можно было просто сделать echo $x, ',', $y, ','; (Да, именно запятые, это не опечатка) и результат был бы таким же самым.

[@ef_end_y]

по http ходят-то не массивы и объекты, а строки. В любом случае, на клиентской стороне будет какой-то парсер. Например, json. Либо же, если не требуется сложной логики: приходит строка с числами через запятую — она же, вуаля, и интерпретируется как массив. Посмотрите внимательно мое первое сообщение: я говорю о методе формировании этой строки на серверной стороне.

[@taliban]

К чему я веду:
1. Конкатенация — зло, чтоб изменить что-то не в конце/начале строки, требуется потрудиться
2. Работа с массивами в разы удобней чем со строками, и быстрей.
3. Для того же аякса уже создано много средств (в Вашем случае json_encode — JSON.parse) они быстрей и сделаны специально для того чтоб передавать/получать данные в удобной форме.

Даже если ограничиться этими тремя пунктами (а вообще по хттп ходят не строки а биты), то конкатенацию можно уже убрать на второй план, как убогий и неудобный способ составления данных.
Я согласен только в одном: конкатенацию удобно использовать когда лепишь данные типа имя и фамилия, город и страна и подобные.

[@taliban]

омг, тег забыл закрыть, вот блин :) Это случайность.

[@ef_end_y]

не может быть работы с массивом быстрее работы со строкой в принципе: скриптовые языки выделяют память под строку с запасом, в процессе может увеличиваться тоже с запасом, каждая итерация конкатенации к текущей строке делается гораздо быстрее чем обращение к элементу массива, поскольку не надо выделять память, просто копи несколько байт и все.

[@taliban]

Увеличить размер строки в памяти невозможно, при изменении строки, комп берет длину текущей строки + длину добавляемой строки и резервирует новое место в памяти такого размера, затем копирует туда новую слепленую строку и удаляет старую. Предвидеть длину он не может заранее. Работа же с массивами по другому немного работает, поэтому если Вы будете лепить строки постоянно, это сильно замедляет работу. Для этого в языках типа c# или java придуманы всевозможные string builder-ы, которые по сути массивы строк, и именно ими рекомендуют пользоваться при конкатенациях.
Если в массив добавлять в конец значения, это очень быстро, как и извлечение с конца. В таком случае он работает как стек, а это очень быстрые операции. + вместо циклического изменения строки в памяти он это делает один раз в конце при join-е. Поэтому именно для конкатенации массив подходит не плохо.

[@ef_end_y]

В шарпе будет медленнее та как строки неизменяемые. А вот, скажем, в перле будет быстрее конкатенация, я даже проверил это (больше чем в 2 раза быстрее, хотя зависит от конкретики), поскольку там именно такой алгоритм выделения памяти, средства языка позволяют это проверить даже, и я проверял. Если в какой-то реализации и/или языке конкатенация будет быстрее — это ли не доказательство, что ее иногда целесообразней использовать?

[@rassol]

Join (var a = ['qw','er','ty']; var res = a.join(',');)
— 498
========
Concat (var a = ['qw','er','ty']; var res = a[0]+','+a[1]+','+a[2];)
— 904
========
Result
— Difference concat vs join: -81.52610441767068%

Протестировано на 10 миллионах итераций

[@ef_end_y]

так, именно, метод «без join» позволяет не использовать массив, а обращение к элементу массива — слабое звено. Так что пример не в тему. Я совсем не против join (было бы глупо спорить против такого полезного оператора), но очевидно, что есть ситуации, когда эффективней будет конкатенация. Если пойдет жесткий спор, придется и мне приводить примеры и тесты

[@taliban]

Дело не только в скорости, дело еще и в удобстве. Иначе писали бы все сейчас на асемблере.

[@Uranium]

А еще удобнее — специализированные библиотеки. ;)

[@azproduction]

for (var i = 0; i < 10; i++) {
    i && process.stdout.write(','); // Магия ;)
    process.stdout.write(i);
}

[@eforce]

IE7 точно валиться, а его большинство сапортят пока…

[@AgentSmith]

Его и будут дальше поддерживать вне зависимости от того, любите ли вы его лично или нет.

[@chipp]

Поддерживать его дальше, чтобы люди пользовались им дальше и нам опять придется поддерживать IE7.

[@AgentSmith]

кому — вам?

[@chipp]

Веб-разработчикам, вестимо.

[@Isopropil]

С какого такого бодуна? Этот выкидыш практически нигде и никем не используется, да и мало чем отличается от шестого. Так что если поддерживать и будут — то «по остаточному принципу» и не весь функционал.

[@inossidabile]

Мы не поддерживаем. На достаточно посещаемых проектах. Его доля – крайне низка. Даже ниже IE6.

[@Zelgadis]

Браузеры могут и игнорировать, но человек не может.

[@4pcbr]

Им, походу, еще первый раз по количеству заметивших приглянулся такой способ )))

[@StrangeAttractor]

Мне кажется в английском тоже ошибка: не «theme», а «subject», «theme» — это «тема» совершенно в другом смысле.

[@Stdit]

И с табуляцией полный бардак.

[@azxc]

Не считаю это ошибкой. Тут «theme» вполне употребимо в смысле «основная идея конференции».

[@Wolverine]

Вообще человек прав :)

theme
1. A topic of discourse or discussion. See Synonyms at subject.

www.thefreedictionary.com/theme

[@Shedal]

Или вот: lingvopro.abbyyonline.com/en/Translate/en-ru/theme

1) тема, предмет, вопрос (обсуждения, лекции и т. п.)

[@Antilogic]

pro100tak заслужил инвайт на конференцию!

[@pro100tak]

Сорри, ответил ниже

[@pro100tak]

До конференции остался 51 день
А у меня аккурат через 2 месяца дочь родится (прогноз — 4 июня +- 2 недели). Куда уж мне :)

[@pro100tak]

Извините, это ответ на этот комментарий

[@Homakov]

linked array

[@klz]

у меня сын должен был родиться 5-го мая, я родился позавчера :) Скучно ему, видимо, стало

[@IgorMats]

Я вам хочу сказать это сто процентов такой маркетинговый ход, потому что я определенно долго не мог увести глаз с аналогичной, но другой картинки с не закрытой фигурной скобкой.

[@sap1ens]

Видимо писали питонщики…

[@mark_ablov]

Это не ошибка :)
w3c не имеет отношения к стандарту языка ECMAScript.
Да, афаик, IE глючит на этом коде, но это полностью соответствует спеке:

ObjectLiteral = { } | { PropertyNameAndValueList } | { PropertyNameAndValueList , }
PropertyNameAndValueList = PropertyAssignment | PropertyNameAndValueList , PropertyAssignment
...

Обратите внимание на первую строку, последнюю продукцию, там есть запятая после декларации всех свойств.

[@zavyrylin]

Совершенно верно. Помнится, какой-то редактор всё время ругался на такие вот запятые. После штудирования стандарта я отправил этот редактор на свалку.

[@mark_ablov]

Инспектор в JetBrains хоть и помечает красненьким, но объяснение верное:
«Checks JavaScript source code for last comma in object literal. Such object could have problem in certain JavaScript engine implementations. The validation works in JavaScript, html or jsp files.»

[@eatart]

искал я как-то на чужом сайте такую ошибку. дня 3 искал…

[@DenisZ]

ИЕ выдает ее сразу. Почему 3 дня искали?

[@eatart]

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

[@mark_ablov]

в консольку глянуть?

[@ohifck]

Вчера не мог зарегистрироваться на событие из за ошибок в js на форме.

[@Shedal]

А ещё, на этом баннере в качестве фона выступает, как бы, листик в линию. Но строки кода находятся не на линиях.

[@ha2bj]

fixed;

[@bubuq]

осталось выяснить, кто такой «тоцтеп» ;)

[@ohifck]

Может на работу к ним попроситься :-)

[@mark_ablov]

всё ок, utf-16, все дела :)

[@how]

у меня баннер не открывается в IE, что там написано?

[@easterism]

[@Meks65]

Не стоит забывать о том, что изготовление и размещение баннера — это священнодейство маркетологов. А им глубоко фиолетово как именно оно сделано, главное, чтобы:
1. Креативно.
2. В срок
3. С минимальным бюджетом.

Все эти критерии, на взгляд рекламщика были соблюдены.

На моей памяти только один менеджер от заказчика при приемке всегда проверял результат на нескольких браузерах.

P.S. А может быть это был продуманный ход, для привлечения большего внимания?

[@ShadowPrince]

Если убрать var то это же стиль Python!

[@Litiy]

К слову, заметил на руби-тостере, что сайт тостера сжирает 50-100% цпу на маке в хроме даже в неактивной вкладке. Не знаю с чем связано, наверняка лишний код по таймеру или в цикле. Есть еще страдающие этим?

[@dyakov]

Это не ошибка, ошибку выдаст только IE, потому что не поддерживает спецификацию

[@ozzycv]

Моё маленькое ИМХО :) Не люблю когда строки пишут в одинарных ковычках :)
Не знаю почему, но мне это режет глаз. Это наверное у меня пошло от С, С++, где одинарные это один символ, а двойные строки. Поэтому всегда придерживаюсь писать строки в двойных ковычках, даже когда щас больше пишу на PHP, Ruby, Python, JS :)

[@TheShock]

А у меня рзделение — одинарные кавычки для яп, двойные — для хтмл

[@ozzycv]

Да, тоже интересно. У каждого свои заморочки :)