Why cant prototype have elegant code and optimised code. I'm not talking about milliseconds of optimisation, even i am not that machocistic.
But when a function gets so much use like setStyle, should asthetically pleasing code give way to optimisations to save seconds or even minutes. Code can still 'look good' and be fast. Slightly OT, but to Douglas Crockford said something on the lines of, javascript has emense expressive power which allows you to make javascript feel like any other language. But instead of trying to make javascript something it isnt, use it for what it is. I might have got it a tad wrong, but i hope you get the idea of what i am trying to say. When i write javascript i write it so that it is beautiful javascript. Not beautiful java, python or ruby. i would guess 99% of the people who use the prototype library dont care about the innards, they infact dont even realise prototype exists, most users (i.e RoR users) just have <%= javascript_includes :defaults %> and dont look any further than that. Can't prototype.js be elegant without it looking like ruby code? On Feb 18, 7:25 pm, "Andrew Dupont" <[EMAIL PROTECTED]> wrote: > On Feb 18, 12:22 pm, Marius Feraru <[EMAIL PROTECTED]> wrote: > > > So, the only issue still standing in this paragraph is "how to detect > > different versions". People [1] think the right choice is not "browser > > detection", but "object detection". This is a very weary subject, I don't > > really want to reiterate it. > > FWIW, I'll just say Prototype folks did the (almost) right thing by > > never-saying-never (to "browser detection") and you have seen examples right > > in "setStyle" (kludging "opacity" with "filter" for all versions of MSIE, or > > choosing to replace "full opacity" - 1 - with 0.999999 for all Geckos). > > Yes, it's a real PITA, but we really have to deal with all these annoying > > bugs. I'm sure there are better ways, we just have to discover them. > > So, please help us ;-) > > We recognize this issue and are working on a better way to handle the > browser checks in Prototype. Ticket #6800 [1] is our attempt to > standardize browser checks and remove redundancy. I expect Sam to > apply this patch soon, at which point we can change nasty stuff > like... > > if (/Konqueror|KHTML|Safari/.test(navigator.userAgent)) > > to... > > if (Prototype.Browser.WebKit) > > I also think Mislav's patch (moving the browser checks from "inside" > the functions to "outside") is a very important one. The patch itself > is outdated, but I think it's an issue we need to revisit. > > > Depends on your purposes. Now that you mentioned "ruby", AFAICT ruby folks > > don't give a rat's ass about performance (yet), they want to create an > > elegant programming language. Performance? Later on, they're still young. > > Maybe that is (should be) the case with Prototype too ;-) > > The modus operandi for Prototype these days is to optimize after the > fact. First we try to write elegant code; only then do we make > sacrifices in the name of optimization. On the small scale, this > often means replacing Enumerables with ordinary for loops; on the > large scale, it means a total rewrite of $$ like the one that's > happening right now. > > To illustrate: I'm not interested in making $$ the fastest selector > query engine on Earth. To shave milliseconds off of DomQuery or > dojo.query would take far more lines of code than I'm willing to > write. I'm interested in making $$ *fast enough* that it's practical > to use on a regular basis. Performance is not our chief goal, but it > shouldn't be a deal-breaker. > > Cheers, > Andrew --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
