Sorry, my gmail was screwing up the groups nature of the thread and i
was getting confused.

I enjoy using prototype.js i find it very nice how it fluidly
integrates with the core parts of javascript.

However i need better performance that prototype can offer so i've
been forced to fork the library and improve it myself to get the speed
gains i require. I'm just trying to post my speed improvements here.

I fully understand the argument for premature optimisation. But for me
it, its late optimisation, really i needed the performance out of the

For me, prototype is already stable and nicely rounded. What i need
from it is a lower memory usage footprint and faster code. the $$
upgrades being talked about in another thread are those kind of
optimisations i'm looking for (although i dont actually use $$)

I know prototype.js is the core part of the javascript for RoR, and so
it needs to keep in touch with the Ruby users. However for me, i tend
to find myself moving more and more away from any back end integration
and am now finding myself creating more standalone web apps, which
just transport data over JSON, so as the interactivity and the page
presence goes up i need the performance to keep up with me.

On 2/18/07, Marius Feraru <[EMAIL PROTECTED]> wrote:
> Hash: SHA1
> > I posted this in the spinoffs group as until 5 minutes i go i did'nt know
> >  this existed. a FYI on the website the mailing list url
> >  points there, not here.
> >
> > Please read this:
> >
> >  and possibly comment if you think my suggestions are worthy or not :)
> OK, you got it. Let's continue.. ;-)
> Mislav wrote:
> >> Wouldn't it make even more sense for instance to skip doing all these
> >> checks? How? By dynamically compiling different versions of those
> >> methods based on the capabilities of the browser running them. ;-)
> >
> > Well, duh! ;-P see
> OFC, that's what I was talking about, now hopefully Malard (or is it
> "Martin"?) understands what I meant ;-)
> Malard wrote:
> > How can you detect different versions of the browser dynamically and
> > compile them. You can easily change the user agent value that the browser
> >  sends to the server, but you cant change if certain parts of the
> > javascript engine exist or not. So i'm pretty confident that javascript
> > based checking is the only way to go.
> Check out the URL Mislav pointed out. It's the (very) basic technique (yet
> very efficient) I was talking about.
> 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 ;-)
> Martin Ellis wrote:
> > The quote you made, was not from myself.
> I don't really know if it's Mislav's fault as I've seen many such
> misplacements from Google Groups infrastructure. Sorry, no example at hand,
> AFAIR there were various differences in threading order when browsing NNTP
> group using Google Groups comparing to other NNTP clients :(
> > I dont believe that the web server should decide how to serve the
> > javascript.
> I really hope you got it right this time. I NEVER said that.
> By all means, I know my English is very poor, but is it THAT lousy as to
> make people think I really say such aberrations? :))
> > As for optimisations, you use include alot, its incredibly expensive to
> > use that function when just looking for 2 items in array.
> As a general principle, I, for one, am completely against premature
> optimization, even when done properly (meaning: really well
> argumented/commented), but I can understand (and favor) micro-optimizations.
> So, now that hopefully you know how to contribute to this project [2],
> please do try promoting such micro optimizations through patches (+ tests,
> benchmarks, etc - when necessary), I'm sure Prototype team would like that.
> > Do you think instead of just using rubyesque functions for the sake of
> > using them over performance is the best action to take, or should code
> > used in prototype use the fastest applicable.
> 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 ;-)
> > I was doing some tests, and the cheapest way to do this was to use an if
> > statement, i.e if (foo === 'bar' || foo === 'bar2')  {}
> This is a good example of micro-optimization but also a good example of
> premature optimization :))
> Good: it's very fast [3]
> Bad: maintenance is nightmare (when "foo" will accept more and more and more
> values) ;-)
> [1]
> [2]
> [3]
> cheers
> - --
> Marius Feraru
> AT6bT8AN5k4vZNGs2EucqQ0=
> =qexU
> >

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to