feature request || idea about sugar HOT 10 CLOSED

I have to admit that this is a feature I am interested in and have wanted in the past. After having a quick look, however, the bottom line is that Sugar would have to abandon IE support < IE8 ... The support currently goes back to IE6 and I'm not sure if I'm ready to give this up yet...

It's a very interesting idea though... let me think about it some more...

from sugar.

Maybe, add this features as a plugin.

I´m personally working on a webapp that won´t support IE at all. Since it has a strong focus on mobile, but will be used on desktops too.

Since we can now use sugar.js in node.js, we don´t have to care about IE, atleast on the server side, too.

from sugar.

This could be easily accomplished with getters/setters isn't it (when we don't count IE support) ?

from sugar.

That's a good point (about node.js) ... I agree that it's a feature that definitely has potential... let me think about this a bit more...

from sugar.

+1

from sugar.

It would be a shame if IE held back sugar.js. Perhaps there needs to be a version of sugar.js that is explicitly incompatible with IE<9 thus letting sugar.js move toward the future with node.js on the backend and modern browsers on the frontend.

That forward-looking space is more used every day around the world and provides for more interesting features like this one, not to mention that Sugar.js becomes more fun to work on/contribute to for us devs.

I'm not doubting there is an audience that needs IE<9 support but they do not represent the trend, future majority, or creators of cutting-edge programs (be it games, tools, social networks, etc.). I don't think supporting IE<8 is a sustainable path for a forward-looking library/framework IMO. In 3 months it will be 2012. Cut the cord with the past.

from sugar.

I agree with all your statements and I agree that every day we're heading more toward common standards and that's great. There are 2 big reasons for this, though, one is IE9 and the other is the node environment.

The problem though is think about it from the (client-side) developer's perspective. If you're trying to support IE7/8 then any feature that can't be used is interesting, it's nice, but in the end it's worthless. I agree that it's not the TREND to support IE7/8... naturally the trend is to move away from them and thank god for that. But the trend begins with people doing experimental stuff in an environment that has the leaway to allow it. Sugar is going for something a bit more stable than that. In most cases these two concepts don't have to conflict, but they do in this case, and it would be far too damaging for Sugar to have to say something like "may not work in IE7/8 in all cases". That being said, the server-side dimension adds a different light on the issue.

I think that we're nearing a tipping point and we're almost there when we can abandon IE7/8 entirely, but we're not quite there yet. I'm still considering this idea but I'm not sure how I'd want it to be presented...

Anyway I haven't abandoned the idea or anything but still unsure about adding it....

from sugar.

Perhaps the right time to stop 100% support for IE<9 is when IE 10 comes out? Or 11?

Edit:

But... I realize the issue might also relate to the fact that IE8 is as far as the browser goes for XP users.

from sugar.

@jasonkuhrt That's part of the reason... yes timing-wise it might be a good time and all that, but for most people who are seriously supporting IE7/8 in the first place, they will keep on supporting it as long as there is an incentive (ie. money) in them for doing so, so it's never going to be a 100% ready in that sense.

There's a number of things to think about here so I'll keep both sides in mind. I'm leaning toward doing it but we'll see.

from sugar.

OK! This feature is now in v1.0 of Sugar. The method is Object.watch, like the non-standard Mozilla method of the same name (re: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/watch). Unlike other Sugar methods, watch WILL overwrite the native method, as they have different implementations and intentions (despite having identical syntax). It is unfortunate to have to lose < IE8 support in this one method only, but I think the benefits justify it here.

from sugar.