SugarJS — Синтаксический сахар для JavaScript

[eka]

«С удивлением обнаружил, что на Хабре никто не упоминал...» — habrahabr.ru/post/125415/

[VasiliyIsaichkin]

Охтыж, специально ведь в поиске искал…

[Dima_Sharihin]

Спасибо. Будем знать, где взять

[smashercosmo]

Сейчас должны набежать адепты Кроукфорда, истошно вопя, что расширение прототипов — это великое зло))

[VasiliyIsaichkin]

В сайте есть даже специальное упоминание 'But Sugar modifies native objects! Isn't that Evil™?' с небольшими разъяснениями.

[VasiliyIsaichkin]

Мое мнение — нигде не мешает, удобно, выразительно — в топку всю эту теорию c расширением, не нравится — используй VanillaJS.

[creage]

Не нужно быть адептом, чтобы понимать, насколько это зло, и почему так делать не стОит. Достаточно взглянуть на историю Protoype.

[smashercosmo]

Не нужно смотреть на историю prototype. Сейчас при расширении прототипов используются совсем другие техники. Native method first. При отсутствии нативного метода используется polyfill, сделанный в соответствии со спецификацией. Сообщество следит за тем, чтобы код библиотеки обновлялся в соответствии со всеми апдейтами спецификаций. Если появляется нативный метод, которого раньше не было, это тут же учитывается в коде. Так что шанс того, что у вас что-то где-то накроется из-за расширенных прототипов при таком подходе сводится к минимуму, который можно вообще не брать в расчет.

[Istergul]

Вы хотите сказать, что все используемые в библиотеке методы описаны в спецификации?
Может случиться такая ситуация в большом проекте, когда кодовая база на клиентской части стала достаточно объёмной и вдруг появляется встроенный метод, поведение которого отличается от поведения, добавляемого библиотекой, отчего сыпется всё приложение. В таком случае необходимо срочно заняться рефакторингом кода в проекте, что может сорвать планы и неблагоприятно повлиять на бюджет…

[smashercosmo]

Да, такое может быть. Это неизбежный процесс. Чтобы идти в ногу со временем, нужно все время что-то обновлять, изменять, рефакторить в соответствии новыми технологиями. Потому что если холить и лелеять код, давным давно написанный и не выделять время и деньги на его усовершенствование, то можно быстро оказаться в ситуации, когда у конкурентов все будет быстрее, отзывчивей, легче в поддержке, менее ресурсоемко и т. д.

[Istergul]

Проект необходимо всё время поддерживать, это верно, но в любом более-менее серьёзном проекте необходимо минимизировать риски. В связи с этим стараюсь не использовать расширение встроенных прототипов методами, не описаннными в специффикации.

[Goder]

Чтобы идти в ногу со временем, нужно писать универсальные решения, чтобы не переписывать их на каждый чих браузеростроителей и библиотекописателей. берите пример с ребят, которые писали математический код на Фортране, чьи библиотеки используются спустя 20 лет после написания. Они работают и решают поставленные задачи.

[smashercosmo]

Web — слишком динамическая и нестабильная среда, что сравнивать ее с фортраном. Сегодняшнее бронебойное решение завтра уже будет пережитком прошлого.

[creage]

Т.е. вот таки согласны с мыслью, что вот такие библиотеки — они на… не нужны, и через n-дней канут в лету!?

Что мешает обрамить логику в функцию? Оставьте примитивы в покое!

[smashercosmo]

Все канет в лету. И jQuery канет в лету и многие другие решения, которые сегодня успешно используются web-сообществом. Но это не значит, что их не нужно использовать для того, чтобы упростить себе жизнь.

Что мешает обрамить логику в функцию?

Ничего не мешает. Это просто разные подходы. И кто-то готов идти на небольшой риск, для того, чтобы сделать свой код более чистым, посредством неиспользования всяких лишних оберток. Я считаю, что если не подключать одновременно sugar, mootools и prototype, то риск возникновения каких-то проблем от расширенных прототипов меньше процента. Это вполне приемлемо.

[Goder]

Вот только библиотеки через одну тянут по несколько зависимостей, в т.ч. prototype, mootools, signals, Zepto и пр.

[Ganesh]

Вроде как сейчас набирает популярность паттерн неймспейсов, тот же dojo полностью на нем. А расширения прототипов нативных объектов действительно зло, не раз уже сталкивался с этим. Проблемы начинаются от не совместимости библиотек и заканчиваются неожиданным поведением.

[smashercosmo]

Меня убивают неймспейсы. Когда код заполнен конструкциями вида mainNamespace.subNamespace.someObject.someMethod(), на это даже эстетически неприятно смотреть, я молчу уже о количестве писанины.

[alist]

А вот и первый адепт Крокфорда — я! И как адепт Крокфорда я со всей ответственностью заявляю, что Крокфорд за разумное расширение прототипов, что он сам демонстрирует собственным кодом: github.com/douglascrockford/JSON-js/blob/master/json2.js#L175

А против расширения прототипов адепты Резига! :)

[inossidabile]

Замечание про Резига – не в бровь, а в глаз. Столько проблем создает принципиальное нежелание жить в реальности, где кто-то может в старом браузере без defineProperty что-то добавить в прототип Object'а… Хотя казалось-бы разработчики таких фундаментальных библиотек _обязаны_ думать о других вероисповеданиях.

[Alinaki]

они никому ничего не обязаны.

[Istergul]

Простите, что понимать под шимом?

[k12th]

Теперь на работе будут приставать, чтобы я использовал это.

[arnold-sakhnov]

Интересно, почему

'{n} and {r}'.assign({ n: 'Cheech' }, { r: 'Chong' }); // "Cheech and Chong"

а не

'{n} and {r}'.assign({ n: 'Cheech', r: 'Chong' }); // "Cheech and Chong"

?

[ibnteo]

Доработайте библиотеку.

[inossidabile]

Оба варианта сработают. И второй, собственно, предпочтителен.

[Quilin]

(8).times(function(i) { // Эта функция будет вызвана 8 раз. });

Вот и до JS добрались фанаты ruby…

[xeLL]

В купе с кофе :)

[Keyten]

и с питоном.

sugarjs.com/libs/

[Flammar]

Ну, в купе с динамическим добавлением методов этот приём смотрится не так отвратительно, как если бы это было на Java…

[murr]

Вы так говорите, как будто это что-то плохое :)

[Stepler]

Добавил в избранное ради работ со строками, числами и массивами. Попадаются иногда схожие задачи.

[porcelanosa]

а почему не Undescore documentcloud.github.com/underscore/

[xeLL]

Тогда уж и underscore.string

[porcelanosa]

ну и moment.js к примеру — просто хочется использовать продукты с хорошей поддержкой

[inossidabile]

Что не так с поддержкой у Sugar.js? Только, если можно, без флейма. Я активно принимаю участие в развитие этого чуда. Как по мне, так Andrew Plummer один из самых лучших и адекватных мейнтейнеров, которых я когда-либо встречал.

[porcelanosa]

Если честно, то я первый раз слышу о Sugar.js — от этого и такое впечатление, что это новинка и если я услышу о ней еще пару раз — возникнет и доверие.
В коде, как многие, я не копаюсь — я хочу брать и использовать — не думая о том, что через месяц мне придется все переделывать из-за какого-то досадного бага — что встречается например с плагинам для jQuery.
Но спасибо Вам за такой эмоциональный ответ — буду следить за Вашей работой — и попробую поюзать.

[Keyten]

Ну не такая уж и новинка, на хабре про sugar есть пост годовой давности (http://habrahabr.ru/post/125415/).

[inossidabile]

Вагон и маленькая тележка причин. Я назову те, которые особенно важны для нас:

1) Синтаксис андерскора высосан из пальца – мой мозг отказывается воспринимать вот это _(_(...) / _(...)). Против этого не помогает даже CoffeeScript.
2) При использовании Coffee-HAML синтаксис один в один руби с ActiveSupport. И это очень-очень хорошо.
3) Гораздо больше функций. Нет этого больного стремления уложить все в 1 килобайт. Спасибо, я лучше уберу одну картинку, но не буду страдать из-за отсутствия флексий (камелизация, плюрализация, етц).

Если хотите развернуто услышать мою позицию: borisstaal.com/post/24270017179/please-use-sugar-js. Но на английском.

[MrSLonoed]

Довольно спорная либа. Чтото есть чего то нет. По сути выжимка из набора библиотек, таких как underscorejs и datejs. Хотя может быт весьма полезна.

[bolk]

'Добро пожаловать!'.hasCyrillic(); // true

Серьёзно? И на каждый язык так?

[VasiliyIsaichkin]

Methods:

isArabic
isCyrillic
isGreek
isHangul
isHan
isKanji
isHebrew
isHiragana
isKana
isKatakana
isKatakana
isThai
isDevanagari

[bolk]

Какой ад.

[Istergul]

У разработчиков библиотеки свой взгляд на паттерны проектирования :)

[VasiliyIsaichkin]

кому удобно то юзает, кому не — не юзает. Колхоз — дело добровольное.

[Dima_Sharihin]

Они беспощадны

string.prototype.isLocale = function(locale) { 
   if (('is' + locale) in this && this['is' + locale] instanceOf Function) 
      return this['is' + locale]();
   return false
}

[bubuq]

isArmenian, isOriya, isBengali, isJavanese, isLao, isSinhala, isCherokee… где же всё это?

[inossidabile]

Не удержусь чтобы не процетировать автора:

@_inossidabile lol, isCherokee actually used to exist!! I took it out because come on right? I can add again when a Cherokee complains :) :)

[Keyten]

И клингонский не забудьте

[Keyten]

Да, прекрасная библиотека. Читал код.

// Вообще говоря, у меня ко многим JS-библиотекам интересный подход — вместо документации мне нравится читать код).

[ich]

Читая код трудно оставаться беспристрастным, лучше читать сначала интерфейсы, а потом уже код. Тов. Макконнелл в «Совершенном коде» описывал проблему, из-за которой не стоит смотреть код сторонних библиотек. Точно не перескажу, но суть в том, что это как читтинг при написании своего кода, который использует чужой. Зная что скрывается за интерфейсом, можно плддаться соблазну использовать недокументируемые возможности. Я, честно сказать, тоже люблю читать исходники, но стараюсь ориентироваться по юзергайдам к использованию.

[termi]

Хорошая, в некоторых местах библиотека, но такого полезного метода как ES6 String.prototype.repeat нету :(

[inossidabile]

Добавляйте ишью, пожалуйста. Сделаем.

[termi]

Я вам сделаю pull request

[inossidabile]

Низкий Вам поклон :)

[termi]

Запулил быструю версию. Торопился (работы много), поэтому не выделял в отдельную ветку

[termi]

Есть в либе, что на github. Только медленная реализация

[inossidabile]

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

[alternativshik]

с Якартами конфликтует)

[vitalets]

Касательно работы с датами:
вот почему каждая js-обертка стремится выдумать свои спецификаторы в формате?
date.js, moment.js теперь еще и sugar.js — формат нигде не совместим!

[smashercosmo]

А есть разве какой-то стандарт?

[vitalets]

в том и дело, что нет.
Есть вот это
www.unicode.org/reports/tr35/#Date_Format_Patterns

[rednaxi]

Не вижу (по примерам) разницы между функциями для работы со строками insert/add и to/first

[Flammar]

Javascript чем-то неуловимо напоминает С++ в его худших чертах. Наверное, отсутствием стандартных реализаций общепринятых вещей…

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

[Flammar]

… писать фреймворки…