Sugar is a new Javascript library for working with native JS objects.

by Bowser • 15 years ago

57 16 15 years ago

mrspeaker• 15 years ago

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 ;)

Bowser7• 15 years ago

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...

tucaz• 15 years ago

Looks very nice. Will try it. Kudos!

geuis2• 15 years ago

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.

hubriz• 15 years ago

Writing in JS is a sacrifice of performance in the first place. Besides even the smartest, most performant library in the hands of inept programmer will produce a subpar result. If you're smart, you can write quality, performant code with both _ as well as Sugar, I bet. Besides sugar is a much more diverse set of functions as far as I can tell. I like the idea and are willing to try it out. :)

Bowser7• 15 years ago

Thank you much for your support of the concept. I have a great respect for _ and love what it does. We definitely have the same goal in mind, with different ideas of how to get there. I'm going to try to be humble and learn as much as I can from great code like theirs while at the same time trying to keep some hard lines about Sugar's commitment to intuitive and easy to understand syntax.

Bowser7• 15 years ago

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.

geuis2• 15 years ago

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?

jdost• 15 years ago

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).

jashkenas2• 15 years ago

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.

Bowser7• 15 years ago

First of all I'm impressed with you being objective and not gnawing my head off even after discovering probably the thorniest part of the library (and so soon too)! I am aware of and on your side about the issues with patching the Object.prototype.

So, to be perfectly clear, the Object prototype will NEVER be modified in any way by default! The "enableSugar" method you have found (so resourcefully, I might add :) ) is something I added in later as an "opt-in" way of using objects as hashes in pages where you ALREADY have assurance that it won't break. It is intended as something of the reverse of "noConflict" in jQuery. By using this method you're basically saying that you're ready to live on the edge and will take responsibility for what breaks. More importantly you can turn it off again if something does start to break.

Now that having been said, even though I've added this method there is ZERO reference in it to the documentation. A few reasons for this: one is the backlash I knew I would get for even MENTIONING the sacred Object prototype (you may have proved that point, heh)... the other is that I'm not sure I ever really want it used... in the first place I sort of intended it as more of an "easter-egg" and I'm not sure I ever want to mention it in the docs...

In any case though it will NEVER be a default, and for precisely the reasons you've mentioned.

Bowser7• 15 years ago

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.

jashkenas2• 15 years ago

Thanks for the edits. Much appreciated.

cdcarter• 15 years ago

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!

Bowser7• 15 years ago

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.

Sugar is a new Javascript library for working with native JS objects.

Related Stories