
Sugar is a new Javascript library for working with native JS objects. - Bowser
http://sugarjs.com/
======
jashkenas
Before diving in -- it's always great to see more takes on utility programming
in JS, especially when there's a clear difference of philosophy. That said...

Underscore might be oriented towards performance, but really the main thing --
which it would be great for you to add to the paragraph -- is that Underscore
is oriented towards _not patching native objects_.

To quote from lib/sugar.js, inside of the Object.enableSugar() function:

    
    
          typeMethods.each(function(m){
            Object.prototype['is'+m] = function(){
              return instance(this, m);
            };
          });
          hashMethods.each(function(m){
            Object.prototype[m] = Hash.prototype[m];
          });
    

Extending Object might be perfectly fine on a webpage that you control, and
that you're 100% sure not to include any third-party JS libraries on. But it
also means that I'll never be able to use sugar.js in a library that I expect
others to use, or in a bookmarklet, or on a large website where third-party
code will be included.

Cheers, and nicely done with the great documentation site.

~~~
Bowser
Again, thanks for the input! I've changed the site to emphasize that point
about Underscore.js (as you suggested), and also added a page explaining more
about (not) patching Object.prototype. Still don't want to add docs for
"enableSugar"... not sure yet that's the direction I want... may remove it
later.

~~~
jashkenas
Thanks for the edits. Much appreciated.

------
geuis
This bit I find concerning, "Sugar is more concerned with convenience and
intuitive syntax, whereas Underscore.js is more oriented toward performance".

There are many libraries that enhance aspects of writing js apps that _dont_
sacrifice performance.

Additionally, and I may be wrong here, but in my experience any lib that
modifies native objects tends to be a bad idea.

~~~
Bowser
To be clear, "sacrificing" performance is not a goal (obviously) nor should it
need to be. The only point is that the ultimate goal is intuitive syntax, and
that performance will always take a second place to that. That doesn't mean
that I'm not thinking about performance, and it will be a goal of mine over
the coming days to improve weak spots and tighten up performance, as that is a
priority too. But I really wanted to nail the syntax first to the greatest
extent possible.

~~~
geuis
That's a fair rebuttal. What's your opinion about my second statement, where
the common wisdom that modifying native objects is a bad idea?

~~~
Bowser
Honestly, I find it to be more the common superstition rather than the common
wisdom. That is not to say there's no truth to it, but I find that I hear ppl
repeating it religiously without really knowing why. The main danger comes
from extending Object.prototype, which Sugar will never do. In response to a
lot of people with the same concerns as you, I've put up a page explaining
this in more detail (<http://sugarjs.com/native>). I think the idea of
extending other objects may have gotten a bad rap due to this, but the fact is
there is a marked difference, and frameworks like Prototype have known this
and found their niche here for many years.

Now of course there are other considerations like collisions with Prototype
itself or other libraries. But in the end, any library that modifies these
native types is generally speaking meant to exist on it's own, without having
to co-exist with other libraries of similar type. Now I realize that can't
ever be 100% guaranteed, but if that limits the environments where Sugar can
be included, then so be it. Now that having been said I am still going to
great lengths whenever possible to minimize these collisions and in more than
a few places have actually re-aligned Sugar syntax to match Prototype, so long
as it doesn't violate my first rule of having intuitive syntax that "reads".
Additionally it's worth restating that Sugar never overwrites methods that are
already defined, and so any page that includes Prototype will always get
Prototype methods in the case of a collision. I'm currently looking into an
elegant way of having devs manually override Prototype methods/classes if they
so desire. I also believe that the danger of modifying native objects can be
greatly mitigated by extensive unit testing, and this was the main reason I've
taken the unit tests as far as I have (to be honest I've gone a bit nuts with
them). To summarize, there is a certain extent to which I disagree with the
statement that "modifying native objects is bad" and a certain extent to which
I agree. To the extent that I agree I think that making good design decisions,
mitigating collisions, and having proper unit tests to tie it all together can
more than make up for anything that might be considered "bad".

Lastly I want to mention that I just released v0.9.1, which uses
Object.defineProperty to map these methods to the prototype. It's a long story
(check out MozDev for more info) but the result is that in modern browsers
including IE9, modifying the prototype object no longer breaks the for..in
loop. I actually had to put a new "warning" into the unit tests that include
Prototype because I wanted to put in a unit test assuring this, but Prototype
breaks it!

------
mrspeaker
Interesting, but it kind of feels like you've "PHP-erised" JavaScript: like
everybody's misc methods in one place. That's not a bad thing, but if it would
really need to be used instead of (not along side) any other niche library.

EDIT: I had quoted a line number figure, but it's mostly comments (except for
those few pages of Japanese characters ;)

~~~
Bowser
Trust me, no one wants to prevent it from becoming PHP more than me. If you
have to refer back to the docs every 2 seconds, it's not a good thing. My goal
is to be as intuitive as possible WITHOUT the docs. There's so much room for
improvement when it comes to JS but I'm also very keen about keeping spaghetti
methods that overlap one another out as well... it will definitely be a
balancing act...

------
jdost
I would think it could be beneficial to be able to streamline the .js file for
people (think like jQuery.ui) so if I were developing something not in
Japanese, the additional (and for me, useless) methods would not add to the
code size, (assuming that there is not some incredible interweaving between
the methods).

------
cdcarter
I don't think it's quite fair to say that _.js is focused on maintaining a
parallel with ruby syntax. It's more about maintaining a same functional
API...

But otherwise, good work. Library looks useful, and a great and very
descriptive website!

~~~
Bowser
I researched it quite a bit when first looking at what's out there and I think
if you look at it closely you'll definitely see a lot of ruby red in there.
However I think you're right that it's not a fair statement, so I just took
that part out.

------
tucaz
Looks very nice. Will try it. Kudos!

