Klaus Hartl wrote:
I have the feeling that the whole speed discussion is somewhat
theoretical, isn't it? I guess in a real life app, e.g. with some
normal selections, you will hardly notice any difference between
jQuery, Prototype, DOMQuery and others.
Am I wrong?
It is not at all just theoretical for all cases, although it is true that
for most web apps it very well might be. I've suggested a "Turbocharged"
speed-optimization plugin before both here and on the dev-list.
For larger web applications, especially if you want to go one step further
and do lots of dynamic stuff on the page the speed differences start to
show. I've already had to strip out some features of our internal
application that would have made it if the engine was faster. I don't see it
as a problem for most current applications and needs at all. Its more about
the fact that the faster the engine is, the more complicated and clever
stuff you can make it do. With a highly optimized engine you can make stuff
that you wouldn't otherwise. It lets you reap even more benefits from the
library.
I absolutely agree that the core should stay fast as it is, and I wouldn't
go as far as declare that we would need two totally different selector
engines. However, John himself has quite often pointed out that the reason
some other libraries are faster is that they have more optimizations that we
can't or won't fit into jQuery. We could fit them to a plugin, though, that
would be geared towards heavier web applications where you want to take it
to the next level.
Currently doing lots of dynamic selections and calls runtime, making most UI
elements really affect each other purely based on classnames etc can get
really heavy if you overdo it. The point is that by overdoing I'm not
meaning that they would not be extremely useful for either the user or the
developer (making development more rapid when you can attach behavior to
most elements just through classes). Overdoing because currently the engine
is not fast enough for them, therefore the user experience degrades. For a
moment imagine if all javascript happened instantaneously with no delays
whatsoever. You could do pretty amazing stuff with it all the time. There
would be a million new possibilities.
Now I totally realize that whatever speed improvements such a plugin could
offer are limited, and would not make stuff instantaneous. Therefore it
would not create a million new possibilities, but would still create some.
That alone, IMO, is reason enough for such a plugin.
Bottom line for me: Currently the speed differences definately are
noticeable, especially if you want to do a lot of stuff with jquery or any
other library. The only reason not to do so much stuff is the execution
speed. If it were faster, I would get to do more stuff, automate more
processes, deliver better.
I also understand that it would propably take lots of time and js-expertize
to do the plugin. It would add some speed, but maybe not wonders. And I know
some stuff is beyond the creators of the library but would rather require
speed optimizations from the browsers etc. And by no means am I saying that
jQuery is doing badly, quite the contrary. The reason I want more is because
its so good :)
--
Suni
