Comments 67
«С удивлением обнаружил, что на Хабре никто не упоминал...» — habrahabr.ru/post/125415/
Спасибо. Будем знать, где взять
Сейчас должны набежать адепты Кроукфорда, истошно вопя, что расширение прототипов — это великое зло))
В сайте есть даже специальное упоминание 'But Sugar modifies native objects! Isn't that Evil™?' с небольшими разъяснениями.
Мое мнение — нигде не мешает, удобно, выразительно — в топку всю эту теорию c расширением, не нравится — используй VanillaJS.
Не нужно быть адептом, чтобы понимать, насколько это зло, и почему так делать не стОит. Достаточно взглянуть на историю Protoype.
Не нужно смотреть на историю prototype. Сейчас при расширении прототипов используются совсем другие техники. Native method first. При отсутствии нативного метода используется polyfill, сделанный в соответствии со спецификацией. Сообщество следит за тем, чтобы код библиотеки обновлялся в соответствии со всеми апдейтами спецификаций. Если появляется нативный метод, которого раньше не было, это тут же учитывается в коде. Так что шанс того, что у вас что-то где-то накроется из-за расширенных прототипов при таком подходе сводится к минимуму, который можно вообще не брать в расчет.
Вы хотите сказать, что все используемые в библиотеке методы описаны в спецификации?
Может случиться такая ситуация в большом проекте, когда кодовая база на клиентской части стала достаточно объёмной и вдруг появляется встроенный метод, поведение которого отличается от поведения, добавляемого библиотекой, отчего сыпется всё приложение. В таком случае необходимо срочно заняться рефакторингом кода в проекте, что может сорвать планы и неблагоприятно повлиять на бюджет…
Может случиться такая ситуация в большом проекте, когда кодовая база на клиентской части стала достаточно объёмной и вдруг появляется встроенный метод, поведение которого отличается от поведения, добавляемого библиотекой, отчего сыпется всё приложение. В таком случае необходимо срочно заняться рефакторингом кода в проекте, что может сорвать планы и неблагоприятно повлиять на бюджет…
Да, такое может быть. Это неизбежный процесс. Чтобы идти в ногу со временем, нужно все время что-то обновлять, изменять, рефакторить в соответствии новыми технологиями. Потому что если холить и лелеять код, давным давно написанный и не выделять время и деньги на его усовершенствование, то можно быстро оказаться в ситуации, когда у конкурентов все будет быстрее, отзывчивей, легче в поддержке, менее ресурсоемко и т. д.
Проект необходимо всё время поддерживать, это верно, но в любом более-менее серьёзном проекте необходимо минимизировать риски. В связи с этим стараюсь не использовать расширение встроенных прототипов методами, не описаннными в специффикации.
Чтобы идти в ногу со временем, нужно писать универсальные решения, чтобы не переписывать их на каждый чих браузеростроителей и библиотекописателей. берите пример с ребят, которые писали математический код на Фортране, чьи библиотеки используются спустя 20 лет после написания. Они работают и решают поставленные задачи.
Web — слишком динамическая и нестабильная среда, что сравнивать ее с фортраном. Сегодняшнее бронебойное решение завтра уже будет пережитком прошлого.
Т.е. вот таки согласны с мыслью, что вот такие библиотеки — они на… не нужны, и через n-дней канут в лету!?
Что мешает обрамить логику в функцию? Оставьте примитивы в покое!
Что мешает обрамить логику в функцию? Оставьте примитивы в покое!
Все канет в лету. И jQuery канет в лету и многие другие решения, которые сегодня успешно используются web-сообществом. Но это не значит, что их не нужно использовать для того, чтобы упростить себе жизнь.
Ничего не мешает. Это просто разные подходы. И кто-то готов идти на небольшой риск, для того, чтобы сделать свой код более чистым, посредством неиспользования всяких лишних оберток. Я считаю, что если не подключать одновременно sugar, mootools и prototype, то риск возникновения каких-то проблем от расширенных прототипов меньше процента. Это вполне приемлемо.
Что мешает обрамить логику в функцию?
Ничего не мешает. Это просто разные подходы. И кто-то готов идти на небольшой риск, для того, чтобы сделать свой код более чистым, посредством неиспользования всяких лишних оберток. Я считаю, что если не подключать одновременно sugar, mootools и prototype, то риск возникновения каких-то проблем от расширенных прототипов меньше процента. Это вполне приемлемо.
Вроде как сейчас набирает популярность паттерн неймспейсов, тот же dojo полностью на нем. А расширения прототипов нативных объектов действительно зло, не раз уже сталкивался с этим. Проблемы начинаются от не совместимости библиотек и заканчиваются неожиданным поведением.
А вот и первый адепт Крокфорда — я! И как адепт Крокфорда я со всей ответственностью заявляю, что Крокфорд за разумное расширение прототипов, что он сам демонстрирует собственным кодом: github.com/douglascrockford/JSON-js/blob/master/json2.js#L175
А против расширения прототипов адепты Резига! :)
А против расширения прототипов адепты Резига! :)
Замечание про Резига – не в бровь, а в глаз. Столько проблем создает принципиальное нежелание жить в реальности, где кто-то может в старом браузере без defineProperty что-то добавить в прототип Object'а… Хотя казалось-бы разработчики таких фундаментальных библиотек _обязаны_ думать о других вероисповеданиях.
UFO just landed and posted this here
Теперь на работе будут приставать, чтобы я использовал это.
Интересно, почему
а не
?
'{n} and {r}'.assign({ n: 'Cheech' }, { r: 'Chong' }); // "Cheech and Chong"
а не
'{n} and {r}'.assign({ n: 'Cheech', r: 'Chong' }); // "Cheech and Chong"
?
(8).times(function(i) {
// Эта функция будет вызвана 8 раз.
});Вот и до JS добрались фанаты ruby…
Добавил в избранное ради работ со строками, числами и массивами. Попадаются иногда схожие задачи.
а почему не Undescore documentcloud.github.com/underscore/
Тогда уж и underscore.string
ну и moment.js к примеру — просто хочется использовать продукты с хорошей поддержкой
Что не так с поддержкой у Sugar.js? Только, если можно, без флейма. Я активно принимаю участие в развитие этого чуда. Как по мне, так Andrew Plummer один из самых лучших и адекватных мейнтейнеров, которых я когда-либо встречал.
Если честно, то я первый раз слышу о Sugar.js — от этого и такое впечатление, что это новинка и если я услышу о ней еще пару раз — возникнет и доверие.
В коде, как многие, я не копаюсь — я хочу брать и использовать — не думая о том, что через месяц мне придется все переделывать из-за какого-то досадного бага — что встречается например с плагинам для jQuery.
Но спасибо Вам за такой эмоциональный ответ — буду следить за Вашей работой — и попробую поюзать.
В коде, как многие, я не копаюсь — я хочу брать и использовать — не думая о том, что через месяц мне придется все переделывать из-за какого-то досадного бага — что встречается например с плагинам для jQuery.
Но спасибо Вам за такой эмоциональный ответ — буду следить за Вашей работой — и попробую поюзать.
Вагон и маленькая тележка причин. Я назову те, которые особенно важны для нас:
1) Синтаксис андерскора высосан из пальца – мой мозг отказывается воспринимать вот это _(_(...) / _(...)). Против этого не помогает даже CoffeeScript.
2) При использовании Coffee-HAML синтаксис один в один руби с ActiveSupport. И это очень-очень хорошо.
3) Гораздо больше функций. Нет этого больного стремления уложить все в 1 килобайт. Спасибо, я лучше уберу одну картинку, но не буду страдать из-за отсутствия флексий (камелизация, плюрализация, етц).
Если хотите развернуто услышать мою позицию: borisstaal.com/post/24270017179/please-use-sugar-js. Но на английском.
1) Синтаксис андерскора высосан из пальца – мой мозг отказывается воспринимать вот это _(_(...) / _(...)). Против этого не помогает даже CoffeeScript.
2) При использовании Coffee-HAML синтаксис один в один руби с ActiveSupport. И это очень-очень хорошо.
3) Гораздо больше функций. Нет этого больного стремления уложить все в 1 килобайт. Спасибо, я лучше уберу одну картинку, но не буду страдать из-за отсутствия флексий (камелизация, плюрализация, етц).
Если хотите развернуто услышать мою позицию: borisstaal.com/post/24270017179/please-use-sugar-js. Но на английском.
Довольно спорная либа. Чтото есть чего то нет. По сути выжимка из набора библиотек, таких как underscorejs и datejs. Хотя может быт весьма полезна.
'Добро пожаловать!'.hasCyrillic(); // trueСерьёзно? И на каждый язык так?
Methods:
isArabic
isCyrillic
isGreek
isHangul
isHan
isKanji
isHebrew
isHiragana
isKana
isKatakana
isKatakana
isThai
isDevanagari
isArabic
isCyrillic
isGreek
isHangul
isHan
isKanji
isHebrew
isHiragana
isKana
isKatakana
isKatakana
isThai
isDevanagari
Какой ад.
У разработчиков библиотеки свой взгляд на паттерны проектирования :)
Они беспощадны
string.prototype.isLocale = function(locale) {
if (('is' + locale) in this && this['is' + locale] instanceOf Function)
return this['is' + locale]();
return false
}
isArmenian, isOriya, isBengali, isJavanese, isLao, isSinhala, isCherokee… где же всё это?
Да, прекрасная библиотека. Читал код.
// Вообще говоря, у меня ко многим JS-библиотекам интересный подход — вместо документации мне нравится читать код).
// Вообще говоря, у меня ко многим JS-библиотекам интересный подход — вместо документации мне нравится читать код).
Читая код трудно оставаться беспристрастным, лучше читать сначала интерфейсы, а потом уже код. Тов. Макконнелл в «Совершенном коде» описывал проблему, из-за которой не стоит смотреть код сторонних библиотек. Точно не перескажу, но суть в том, что это как читтинг при написании своего кода, который использует чужой. Зная что скрывается за интерфейсом, можно плддаться соблазну использовать недокументируемые возможности. Я, честно сказать, тоже люблю читать исходники, но стараюсь ориентироваться по юзергайдам к использованию.
Хорошая, в некоторых местах библиотека, но такого полезного метода как ES6 String.prototype.repeat нету :(
с Якартами конфликтует)
Не вижу (по примерам) разницы между функциями для работы со строками insert/add и to/first
Javascript чем-то неуловимо напоминает С++ в его худших чертах. Наверное, отсутствием стандартных реализаций общепринятых вещей…
Библиотека из серии «я бы сам такое написал, если бы мне позволили исать фреймворки без обсуждения с командой, а тут, слава Богу, есть внешнее решение, за которое мы не должны нести ответственностть в части работоспособности и тестирования».
Библиотека из серии «я бы сам такое написал, если бы мне позволили исать фреймворки без обсуждения с командой, а тут, слава Богу, есть внешнее решение, за которое мы не должны нести ответственностть в части работоспособности и тестирования».
Sign up to leave a comment.
SugarJS — Синтаксический сахар для JavaScript