Спасибо за тест, правда сравнительное быстродействие логических операторов мне известно уже давно. В данных тестах, кстати, у меня показатель 5%, а не 35%. Правда такие тесты несут мало прикладной пользы.
Во-первых, в клиентских (браузерных) приложениях узким местом в быстродействии, как правило, является либо неправильная работа с DOM/стилями (лишние reflows), либо косяки в построении алгоритмов (типа описанного в статье). Мелочи вроде циклов, логических операторов, скорости парсинга и т.д. и т. п. имеют на 3-6 порядков более высокие показатели, и на их быстродействие можно смело закрыть глаза.
Во-вторых, если вы используете компилятор, как это следовало бы делать, (а может даже компилируемый язык типа CoffeeScript, как не следовало бы делать?), то вы можете смело игнорировать быстродействие отдельных команд, так как оптимизацию этого всего компилятор берет на себя.
Поэтому вопрос остается в удобстве чтения/написания кода, а также в оптимизации алгоритмов. Я считаю, что если создатель библиотеки придерживается определенных конвенций в коде, гарантирует корректное функционирование API и поддерживает продукт, то претензии к заумности кода к нему неуместны.
1. С чего вы решили, что ваш «совет» про другие языки вообще применим? То, что в других языках это работает по-другому, не значит, что теперь надо игнорировать прекрасно задокументированные языковые конструкции. Не вижу ниодной причины js-программистам подстраивать код под персонажей, не знающих JS, но рассказывающих, как кто-то должен писать код; или под какие-либо неведомые стандарты людей не из JS. Хотите писать на универсальном языке всего — это лично ваш выбор.
2. Хороший код необязательно должен быть написан по стандартам. Неудивительно, почему вас беспокоят расходы заказчика — если каждую строчку сверять со всеми возможными интерпретаторам, да еще и со стандартом…
3. У меня другое мнение на этот счет. Посмотрите код jquery, который полон данных приемов, или raphael, и расскажите их авторам, что они — неумелые и ленивые.
4. Печально, что для вас мир полон непрофессионалов и неприятных конструкций.
Насколько многие? В принципе, если вы имеете ввиду «секретарш» людей без технического образования, пишущих код «для веб-страничек» — я абсолютно согласен, надо все предельно пояснять, я уже упомянул об этом ниже.
Но если вы делаете сложный или уникальный продукт, требующий специальные знания, типа парсера каких-нибудь нотаций, или библиотеки/фреймворка — то странным будет пытаться кому-то угодить (в части, не касающейся API).
Стоит просто иметь ввиду, что у «многих» завышенное самомнение и склонность к лени, что может отражаться в такой вот прихотливости. Очевидно, что человек противится знаниям в этой области. Возможно, ему не по пути программирование. Вот под таких персонажей я лично подстраиваться не собираюсь.
Меня вот нисколько не смущало увидеть в коде jQuery, jQuery UI, Raphael и т. п. такие конструкции и приемы. Даже наоборот — узнавал новое, познавал грани языка.
Как хотите. Только имейте в виду, что не существует объективной меры понятности кода — вам придется постоянно идти наповаду у опытности «читателей», которым и элементарные вещи могут стать поводом для спора.
Скорее так. Если вам важно писать понятный для среднячков популярный код, естественно вы будете писать вербозно, jshint'ить и т.д.
1. var data = (c && c.data) ? c.data : defaultData; — для кого-то это также покажется ребусом, встречал как минимум двух человек с таким отзывом об этой конструкции.
2. Closure compiler на выходе все приводит к таким конструкциям: пример. Этот аргумент имеет смысл только в девиантных случаях написания js-скриптов под фотошоп или еще какой невероятный диалект. В целом — притянуто за уши, так как работает взде и одинаково.
3. Аргумент ленивого/неумелого разработчика. Если такие конструкции для разраба сложны — работодателю имеет смысл не тратить деньги на такого разработчика вообще — экономии больше. Ну или учить писать код вместо нытья.
Ниодна из ваших причин, к сожалению, не является аргументом против того, что интуитивнее и проще профессионалу писать короткие конструкции.
Если вы прочитаете внимательнее, я не сказал противоречие вашим доводам, а как раз основание — у неподготовленного человека возникнут сложности с пониманием этого. Видимо у полярно настроенного хабрасообщества мало терпения видеть суть комментариев, легче видеть то, что хочется видеть и оценивать.
А вместо давания советов лучше пишите код — выглядит, будто недавно программировать на js начали, раз такие батхерты.
Порог становления хомячков js-рами. Болевой порог, если угодно.
Это перестает быть ребусом после первого-второго использования.
Для кого-то конструкции типа var data = c && c.data || defaultData тоже ребус, но это не значит, что они плохие.
Не страсть к запутыванию, а банальная лень. !~[1,2,3,4].indexOf(getInt()) короче и интуитивнее в написании, чем [1,2,3,4].indexOf(getInt()) == -1. При чтении, конечно, сложности, у неподготовленного человека.
Это как английские конструкции типа I'm gonna nail it, etc. Не более, чем увеличивает порог входа для понимания.
Да, в нем не все так просто. Но потратив час, можно все проблемы решить. Экономия до 50%.
Если все-же решитесь, вот вам пара хинтов.
1. Можно декларировать вещи, которые не должны менять имя:
options: {
/** @expose */
"offset": 0,
...
}
2. Также можно обращаться через строковый литерал:
this.options["offset"]
и с jQuery соотв-но:
$['fn'][pluginName] = function (arg) {
return this['each'](function(i,e){ ... }
}
Тяжеловат вышел. Для 14kb можно было написать jquery-less версию. Элементарный самописный календарь вместе с moment.js выйдет полегче. (5kb unminified + 8.9kb).
Попробуйте closure compiler c включенным advanced optimizations.
Крутая штука, использовал в плагинчике, весьма успешно. Упрощает API в разы: не нужны всякие методы add, etc, с DOM можно работать напрямую, а плагин возьмет всю работу на себя.
Проблема в том, что под старые браузеры (оперу и IE в первую очередь) надо писать жуткий фолбэк в виде сначала обработки событий DOMNodeChanged, DOMNodeRemoved, ..., а затем и вообще реализуя соответствующие методы.
Хотя сейчас ситуация уже получше: caniuse.
Можете уточнить, что вы имеете в виду под поддержкой создания плагинов?
Чтобы буквально работали приведенные три строчки кода. С первой возможно как-то по-другому.
Это некоторые случаи неконсистентности, с которыми пришлось столкнуться на практике при создании универсальных плагинов под jQuery/Zepto/Vanilla.
Название слишком узкое, правда, для библиотеки выбрали. Её можно было бы использовать вообще как микро-замену jQuery — с удовольствием бы внедрил на текущем проекте и тестировал плагины на ней. А jBone привязывает к бэкбону, что не клево. А может и клево :)
А как такая статистика может быть, если бэкбон невозможно использовать без jQuery и underscore? А если jQuery и underscore уже подключены — то почему бы их не использовать? Т.е. даже в случаях, где можно обойтись без _ и $, они все равно будут использоваться, просто потому что они уже навязаны бэкбоном. В таком случае как вы определите использование/неиспользование $ и _?
Гораздо яснее такую статистику покажут просто аналоги функций jQuery/underscore на VanillaJS. А сейчас практически все от jQuery достаточно просто делается на DOM API, а недостатки покрываются полифилами, а не jQuery.
Во-первых, в клиентских (браузерных) приложениях узким местом в быстродействии, как правило, является либо неправильная работа с DOM/стилями (лишние reflows), либо косяки в построении алгоритмов (типа описанного в статье). Мелочи вроде циклов, логических операторов, скорости парсинга и т.д. и т. п. имеют на 3-6 порядков более высокие показатели, и на их быстродействие можно смело закрыть глаза.
Во-вторых, если вы используете компилятор, как это следовало бы делать, (а может даже компилируемый язык типа CoffeeScript, как не следовало бы делать?), то вы можете смело игнорировать быстродействие отдельных команд, так как оптимизацию этого всего компилятор берет на себя.
Поэтому вопрос остается в удобстве чтения/написания кода, а также в оптимизации алгоритмов. Я считаю, что если создатель библиотеки придерживается определенных конвенций в коде, гарантирует корректное функционирование API и поддерживает продукт, то претензии к заумности кода к нему неуместны.
2. Хороший код необязательно должен быть написан по стандартам. Неудивительно, почему вас беспокоят расходы заказчика — если каждую строчку сверять со всеми возможными интерпретаторам, да еще и со стандартом…
3. У меня другое мнение на этот счет. Посмотрите код jquery, который полон данных приемов, или raphael, и расскажите их авторам, что они — неумелые и ленивые.
4. Печально, что для вас мир полон непрофессионалов и неприятных конструкций.
«секретарш»людей без технического образования, пишущих код «для веб-страничек» — я абсолютно согласен, надо все предельно пояснять, я уже упомянул об этом ниже.Но если вы делаете сложный или уникальный продукт, требующий специальные знания, типа парсера каких-нибудь нотаций, или библиотеки/фреймворка — то странным будет пытаться кому-то угодить (в части, не касающейся API).
Стоит просто иметь ввиду, что у «многих» завышенное самомнение и склонность к лени, что может отражаться в такой вот прихотливости. Очевидно, что человек противится знаниям в этой области. Возможно, ему не по пути программирование. Вот под таких персонажей я лично подстраиваться не собираюсь.
Меня вот нисколько не смущало увидеть в коде jQuery, jQuery UI, Raphael и т. п. такие конструкции и приемы. Даже наоборот — узнавал новое, познавал грани языка.
1.
var data = (c && c.data) ? c.data : defaultData;— для кого-то это также покажется ребусом, встречал как минимум двух человек с таким отзывом об этой конструкции.2. Closure compiler на выходе все приводит к таким конструкциям: пример. Этот аргумент имеет смысл только в девиантных случаях написания js-скриптов под фотошоп или еще какой невероятный диалект. В целом — притянуто за уши, так как работает взде и одинаково.
3. Аргумент ленивого/неумелого разработчика. Если такие конструкции для разраба сложны — работодателю имеет смысл не тратить деньги на такого разработчика вообще — экономии больше. Ну или учить писать код вместо нытья.
4. Не работайте?
Если вы прочитаете внимательнее, я не сказал противоречие вашим доводам, а как раз основание — у неподготовленного человека возникнут сложности с пониманием этого. Видимо у полярно настроенного хабрасообщества мало терпения видеть суть комментариев, легче видеть то, что хочется видеть и оценивать.
А вместо давания советов лучше пишите код — выглядит, будто недавно программировать на js начали, раз такие батхерты.
Это перестает быть ребусом после первого-второго использования.
Для кого-то конструкции типа
var data = c && c.data || defaultDataтоже ребус, но это не значит, что они плохие.!~[1,2,3,4].indexOf(getInt())короче и интуитивнее в написании, чем[1,2,3,4].indexOf(getInt()) == -1. При чтении, конечно, сложности, у неподготовленного человека.Это как английские конструкции типа I'm gonna nail it, etc. Не более, чем увеличивает порог входа для понимания.
Не понимает «Вечером сделать ужин жене»
Если все-же решитесь, вот вам пара хинтов.
1. Можно декларировать вещи, которые не должны менять имя:
2. Также можно обращаться через строковый литерал:
и с jQuery соотв-но:
Скомпиленный код не сменит эти названия.
Попробуйте closure compiler c включенным advanced optimizations.
Проблема в том, что под старые браузеры (оперу и IE в первую очередь) надо писать жуткий фолбэк в виде сначала обработки событий
DOMNodeChanged, DOMNodeRemoved, ..., а затем и вообще реализуя соответствующие методы.Хотя сейчас ситуация уже получше: caniuse.
Чтобы буквально работали приведенные три строчки кода. С первой возможно как-то по-другому.
Это некоторые случаи неконсистентности, с которыми пришлось столкнуться на практике при создании универсальных плагинов под jQuery/Zepto/Vanilla.
Было бы еще здорово, чтобы простая поддержка условий для создания jQuery-плагинов имелась:
Название слишком узкое, правда, для библиотеки выбрали. Её можно было бы использовать вообще как микро-замену jQuery — с удовольствием бы внедрил на текущем проекте и тестировал плагины на ней. А jBone привязывает к бэкбону, что не клево. А может и клево :)
Гораздо яснее такую статистику покажут просто аналоги функций jQuery/underscore на VanillaJS. А сейчас практически все от jQuery достаточно просто делается на DOM API, а недостатки покрываются полифилами, а не jQuery.