Комментарии 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 довольно кощунственное название учитывая то что ленивыми вычислениями принято считать вычисления которые делаются по необходимости.
Ну, а вообще порой так раздражает когда кто то использует слова не по их значению ( это я не про вас а про автора этой библиотеки :), Function.lazy довольно кощунственное название учитывая то что ленивыми вычислениями принято считать вычисления которые делаются по необходимости.
Пардон, что-то у автора много раз встречается framework на странице, вот и дописал. Удалили из тегов.
Согласен с вами, на этом список не заканчивается.
Не пойму, чем эти конструкции лучше нативных?
Сдается что люди уже не знают как выглядит нативный js и что в нем есть…
А следующее работает в браузерах последних лет и без sugar.
Не пойму, чем эти конструкции лучше нативных?
[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()
Нечто похожее documentcloud.github.com/underscore/.
У них на сайте написано, что основное отличие в том, что 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.
Выглядет неплохо, надо изучить по подробнее, может есть смысл заюзать :)
на сайте sugarjs.com/ когда нажимаю на Like Facebook, он автоматически убирает мой лайк… мм…
НЛО прилетело и опубликовало эту надпись здесь
Очередной PrototypeJS
С первым согласен, со вторым (про «добавление кроссбраузерной функциональности») — нет. Сейчас уже вполне можно делать приложения, не оглядываясь на IE6/7 и даже 8, а для совместимости использовать подобные библиотеки. Необходимость в такого рода «ручной» оптимизации очень редка.
Особенно расстраивают, так называемые, «доработки»:
[{ foo:'bar' }, { moo:'car' }].indexOf({ moo: 'car' });
потестил — «блин, круто»!
Штука интересная, но как для синтаксического сахара многовато весит, конечно, возможно, я недооцениваю его.
Для серверсайда — чудесно. А вот для клиента таки да.
53КБ сжатая версия и 184КБ распакованная. Это разве много?
Ну да, для microjs.com тяжеловат. Не всегда все нужно, кастомный билд бы ему…
Сладко
Чем оно лучше Мутулз?
Понравилось, однако «влезание в прототипы» — практика мягко говоря опасная и уж тем более не добавляет библиотеке легкости во взаимодействии с другими библиотеками. Так что четвертый пункт надо бы вычеркнуть. Но даже без него библиотека смотрится довольно интересно. В своих проектах, пожалуй, буду использовать.
Расширять базовые объекты своими нестандартными свойствами (а их здесь валом) — ужасная практика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Sugar — подслащённый Javascript