А зачем обсуждать нулевую вероятность чего-либо? При минификации этого скрипта не происходит синтаксических ошибок, если не использовать сломанный минификатор. Google Closure, UglifyJS и другие распространенные программы превосходно справляются с валидным JS, как и все графические браузеры (даже, не к ночи будь помянут, MSIE6), Node.js и другие JS-окружения. Проверьте и убедитесь сами.
Это имеет сразу несколько экономических смыслов: повторное использование существующих наработок, стоимость поддержки и доводки напильником, не в последнюю очередь job security.
По моему опыту, около 100% сайтов выходят за рамки типового проекта. (Выборка нерепрезентативна.)
На WP классно сажать школьников лепить дорвеи — взял бесплатный шаблон, алгоритм Маркова для текстов, SEO-плагин, тяп-ляп — готов сайт. Доработка WP до чего-то концептуально отличающегося — это боль и унижение. В такой ситуации (которая нередко возникает в самом конце проекта / на стадии поддержки) Django становится дешевле и привлекательнее, см. выше.
Страховаться от внезапных «доделок» железобетонным техзаданием тоже не всегда выход.
Да, в старых браузерах JSON3.js или аналог нужно подключать отдельно.
Спасибо, я читал этот пост в оригинале пару лет назад. Более того, он полностью подтверждает мою позицию. Возможно, вы хотели запостить ссылку на какой-то другой, опровергающий пост.
«Правилом хорошего тона» является при работе с заимствованным кодом сохранять стиль кода. Про расстановку никчемных знаков препинания ничего не слышал, хотя, безусловно, можно писать и так:
;;var a = 9;;;
Как я и писал выше, в коде расставлены все нужные точки с запятой. Ненужные, в полном соответствии со стандартом языка, не расставлены.
«Подходящесть» платформы — это функция рынка.
Есть ли потребность в бложиках на ассемблере? Нет. Значит, ассемблер для бложиков «не подходит».
То же самое на Node.js? Есть, за это платят деньги. Значит, Node.js (Django, Ruby, вставить нужное) подходит.
Как-то так.
Требует, почему не требует. Это компоненты стоимости, не более того.
А как стоимость проекта коррелирует с его классификацией? По-моему никак.
Типовый айфон стоит несколько дороже, чем типовая нокия-3310, в его производстве (вероятно) участвуют более квалифицированные китайцы, но это не меняет сути товара ширпотреба.
Рискну не согласиться: когда переменных много, такая запись явно предпочтительнее.
Например, кошмарные конструкции вида ..."'+str+'"
Мне сложно представить, что кому-то активно нравится набирать эти хитросплетения кавычек (а это еще очень простой случай):
Типовый проект — это не CMS, а все-таки сайт, построенный на CMS. Необходимость доработки напильником не меняет сути проекта.
Скажем, я поднял достаточное количество типовых проектов на Python/Django, и ни один из них не был сделан на готовом «движке» вроде WordPress. Этот факт не делает унылые бложики менее типовыми, не делает процесс их развертывания сложнее, т.е. вообще ничего не меняет. Просто немного отличается подход.
В почту присылают список проблем, мне прислали штук 20.
Пост-обсуждение же, мне правда интересно, как относится сообщество к этим вещам. Никогда не знаешь, с какой стороны баррикад окажешься завтра.
Или использовать CoffeeScript, например.
А почему загрузка файлов не подходит? Я обычно именно это делаю, когда есть куча html или другой фигни, которой в коде быть совершенно необязательно.
Но да, безусловно, ошибиться можно.
Про нравится / не нравится не стану спорить, мне просто не встречалась такая точка зрения.
Именно для этого существует стандарт языка.
По моему опыту, около 100% сайтов выходят за рамки типового проекта. (Выборка нерепрезентативна.)
На WP классно сажать школьников лепить дорвеи — взял бесплатный шаблон, алгоритм Маркова для текстов, SEO-плагин, тяп-ляп — готов сайт. Доработка WP до чего-то концептуально отличающегося — это боль и унижение. В такой ситуации (которая нередко возникает в самом конце проекта / на стадии поддержки) Django становится дешевле и привлекательнее, см. выше.
Страховаться от внезапных «доделок» железобетонным техзаданием тоже не всегда выход.
Спасибо, я читал этот пост в оригинале пару лет назад. Более того, он полностью подтверждает мою позицию. Возможно, вы хотели запостить ссылку на какой-то другой, опровергающий пост.
Как я и писал выше, в коде расставлены все нужные точки с запятой. Ненужные, в полном соответствии со стандартом языка, не расставлены.
Есть ли потребность в бложиках на ассемблере? Нет. Значит, ассемблер для бложиков «не подходит».
То же самое на Node.js? Есть, за это платят деньги. Значит, Node.js (Django, Ruby, вставить нужное) подходит.
Как-то так.
А как стоимость проекта коррелирует с его классификацией? По-моему никак.
Типовый айфон стоит несколько дороже, чем типовая нокия-3310, в его производстве (вероятно) участвуют более квалифицированные китайцы, но это не меняет сути товара ширпотреба.
Например, кошмарные конструкции вида
..."'+str+'"Мне сложно представить, что кому-то активно нравится набирать эти хитросплетения кавычек (а это еще очень простой случай):
И то же самое по версии CoffeeScript, ошибиться просто негде:
Никакой злой шутки правильная расстановка точек с запятой в JS сыграть не может; в коде стоят все нужные точки с запятой.
Кеширование регулярки завтра попробую измерить, спасибо.
Эх, была бы
sprintf()нативной — все проблемы решились бы сами собой.Для полноценных шаблонов (сайтов, например) я обычно mustache как раз и использую.
Скажем, я поднял достаточное количество типовых проектов на Python/Django, и ни один из них не был сделан на готовом «движке» вроде WordPress. Этот факт не делает унылые бложики менее типовыми, не делает процесс их развертывания сложнее, т.е. вообще ничего не меняет. Просто немного отличается подход.