Как стать автором
Обновить

Комментарии 30

['rocksteady','and','bebop'].first(1); > ["rocksteady"]
['rocksteady','and','bebop'].from(1); > ["and","bebop"]


Честно говоря необходимость данных методов меня обескураживает.

['rocksteady','and','bebop'].slice(0, 1); > ["rocksteady"]
['rocksteady','and','bebop'].slice(1); > ["and","bebop"]


И кстати писать в тегах framework это кощунство.
В Sugar есть основные методы, такие как bind, который позволяет определить область видимости функции.

Вы хоть знаете что такое область видимости, Хаскелл Карри от этих слов в гробу перевернулся.
С удовольствие исправлю пеервод scope на более подходящий.
.bind просто делает так называемое каррирование.

Ну, а вообще порой так раздражает когда кто то использует слова не по их значению ( это я не про вас а про автора этой библиотеки :), Function.lazy довольно кощунственное название учитывая то что ленивыми вычислениями принято считать вычисления которые делаются по необходимости.
В первую очередь bind позволяет задать контекст для функции (this), а во вторую карирование или фолдинг.
Согласен с вами насчет lazy, правильное название должно быть defer или что-то вроде этого.
Пардон, что-то у автора много раз встречается framework на странице, вот и дописал. Удалили из тегов.
Согласен с вами, на этом список не заканчивается.

Не пойму, чем эти конструкции лучше нативных?
[1,2].add([2,3]); -> [1,2].push(2,3); или [1,2].concat(3,4)
'off with her head!'.each(/he.+?\b/g); -> 'off with her head!'.match(/he.+?\b/g);
'off with her head!'.startsWith(/[a-z]ff/); -> /^[a-z]ff/.test('off with her head!');
'off with her head!'.first(3); -> 'off with her head!'.substr(0, 3);
'off with her head!'.from(3); -> 'off with her head!'.substr(3);
(125.425).round(2); -> (125.425).toFixed(2);
Date.create('June 15, 2002'); -> new Date('June 15, 2002');
Date.create('2002/06/15'); -> new Date('2002/06/15');
Date.create('15 June, 2002'); -> new Date('15 June, 2002');
Date.create(888888888899); -> new Date(888888888899);

Сдается что люди уже не знают как выглядит нативный js и что в нем есть…

А следующее работает в браузерах последних лет и без sugar.
['a','b','c'].indexOf('c');
Object.keys({ broken: 'wear' });
(function(a) {
  /* this = 'wasabi', a = 'bobby' */
}).bind('wasabi', 'bobby')();
Date.create('2002-06-15'); -> new Date('2002-06-15');
Date.create().iso(); -> (new Date).toISOString()

У них на сайте написано, что основное отличие в том, что Sugar модифицирует нативные объекты и больше ориентируются на производительность. Интересно, так ли это и на много ли производительность выше, чем у underscore?
А я так понял, что наоборот сказано, что underscore.js ориентирован на производительность, а sugar — на интуитивно-понятный синтаксис.
Sugar modifies native objects, and is more concerned with intuitive syntax, whereas Underscore.js leaves native objects alone, and is more oriented toward performance.
Да, вы правы, не правильно прочитал

В таком случае, underscore выглядит предпочтительней, плюс весит в пять раз меньше
Выглядет неплохо, надо изучить по подробнее, может есть смысл заюзать :)
на сайте sugarjs.com/ когда нажимаю на Like Facebook, он автоматически убирает мой лайк… мм…
Это потому, что Like не от чистого сердца =)
НЛО прилетело и опубликовало эту надпись здесь
Очередной PrototypeJS
С первым согласен, со вторым (про «добавление кроссбраузерной функциональности») — нет. Сейчас уже вполне можно делать приложения, не оглядываясь на IE6/7 и даже 8, а для совместимости использовать подобные библиотеки. Необходимость в такого рода «ручной» оптимизации очень редка.
НЛО прилетело и опубликовало эту надпись здесь
А расшифруйте, если не трудно. И если можно, с примерами из реальной жизни.
Особенно расстраивают, так называемые, «доработки»:
[{ foo:'bar' }, { moo:'car' }].indexOf({ moo: 'car' });
Для минусующих:
{ moo:'car' } != { moo:'car' }; // true
потестил — «блин, круто»!
Штука интересная, но как для синтаксического сахара многовато весит, конечно, возможно, я недооцениваю его.
Для серверсайда — чудесно. А вот для клиента таки да.
53КБ сжатая версия и 184КБ распакованная. Это разве много?
Ну да, для microjs.com тяжеловат. Не всегда все нужно, кастомный билд бы ему…
Чем оно лучше Мутулз?
Понравилось, однако «влезание в прототипы» — практика мягко говоря опасная и уж тем более не добавляет библиотеке легкости во взаимодействии с другими библиотеками. Так что четвертый пункт надо бы вычеркнуть. Но даже без него библиотека смотрится довольно интересно. В своих проектах, пожалуй, буду использовать.
Расширять базовые объекты своими нестандартными свойствами (а их здесь валом) — ужасная практика.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.