>>> I think as a best practice we should prefer prototype.js accessors
>> versus. a
>>> mix of prototype helpers and native DOM properties. It's more consistent
>> and
>>> more bug-proof in my opinion. I tend to always assume elements have been
>>> extended by prototype, but when the code mixes prototype.js and native
>>> accessors, you have greater chances to introduce non-extended elements as
>>> variables / members of your class that another developer will maybe miss.
>>>
>>> Here you would do
>>>
>>> this.currentImage.up().setStyle({
>>> lineHeight: height + 'px'
>>> })
>>
>> I prefer to use native JavaScript APIs whenever possible and use
>> Prototype only when:
>> * it simplifies my code
>> * it fixes a cross browser issue.
>>
>> You can make a proposal but I'd be -0 for using Prototype in any situation.
>>
>
>
> I'm curious to know the rationale behind your reasoning.
>
> I see mostly advantages in preferring prototype over native APIs :
>
> * Browser issues can be tricky, I personally would not assume that I always
> know when to use prototype to avoid one. I admit I don't test my code in all
> browsers (Konqueror, Opera, etc. you name it.), but I know prototype.js is
> extensively tested including in exotic browsers.
>
> * Using prototype.js selectors you should get the best of breed of browsers
> selectors, so overall the performance is better. When you use
> getElementsByTagName I guess you assume it runs faster than prototype
> selector. Maybe it's true today (but I would think not by far) but I will
> pretty likely not be tomorrow (and let's hope by far) - when most browsers
> will have a good implementation of querySelectorAll (like Opera has for
> example) ; which prototype selector will certainly rely on (when it's
> available) in future versions (if not already, haven't checked).
> The advantage of using prototype.js here is the same argument of having a
> unified API and hiding implementation details. Native JS APIs is
> unfortunately always a moving target, since browsers implement
> specifications at their own pace, not in the same order, etc. Only a using a
> library's API you can abstract this and be pretty safe your code will run
> fine everywhere and with maximized performance.
>
> * Where do you place the bar ? Why $('element') simplifies your code over
> .getElementById('element') but not .select('img') over
> .getElementsByTagName('img')
>
> * RE my argument about not extended elements
>
> I won't make a proposal to enforce that, but again I'm curious to hear what
> you think.
Personally I prefer to always use Prototype whenever possible, as indeed
mixing Prototype with native methods created a lot of problems. It's
true that sometimes it looks like unneeded overhead, but it's hard to
predict how variables will be used later.
IMO, the performance gain is not worth the effort of analyzing whether
or not an object is extended or not.
And it helps having a uniform coding style.
>> I agree, but I don't like the fact that gallery.js would depend on the
>> presence of the mainContentArea element. Is this element part of the
>> public "API"?
Not officially.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
