Well, I have a real life, highly dynamic application based on the use of jQuery and specially selectors: a WYSIWYG Forms designer. The application is so nice and intuitive that users adopted it right away and started building really complex forms (+100 complex components). In general, as you already know, queries are relatively faster (depending on the CPU), in the order on milliseconds. However, as Juha mentions, we're "overdoing" them, and therefore the user experience degrades. As a simple example, any component will make about 10 queries (constrained on certain part of the DOM). Let's say these queries add up to 25ms, which for 100 component means 2.5 secs spent in queries!
My point is that performance is not a theoretical matter, but one of the most practical points in a library, for any library. Specially with the power that jQuery provides, I think one of the goals of the library is not only speed up the development process but also encourage and support the creation of richer (i.e. more dynamic) client side applications. Is performance something that should be included in the core library or added as a plugin? really depends on what's the intended use of the library, how it's used by most of the community and what do we expect from it in the future. If most of the people uses it to build not-so-heavy applications, and that's the intended use in the future then I guess performance could be added as a plugin. If not (which I think it's the case), performance upgrades should be done directly into the core framework. Right now I'm in a huge struggle within my development group about the use of jQuery because of this issue. They say real life, professional applications have to perform, and we cannot use something that doesn't. I agree with that, but I do think there's still lots of things to do with jquery and that performance can be improved considerably. A big reason we got to build such a complex, dynamic and cool app. in a short amount of time is because of jQuery. In my case, as I mentioned, all queries are done over a constrained part of the DOM (not the entire document). But, even with that, performance is not good enough; even worst I've noticed that queries still take more time as the markup grows. I don't know exactly how the selector's engine works but the issue doesn't surprise me (same behavior as with other quering frameworks like xpath). However, that doesn't mean it's good. I think that a true constrained query mechanism would be a great addition in terms of performance. That would provide the developer with a way to control the performance of the application, and being able to grow the complexity of it having some certainty that performance will scale in a constant manner. Many good points towards having better performance have been said in this thread, so I won't repeat them. My intention was to provide a real-life scenario. Regards, On 4/4/07, Juha Suni <[EMAIL PROTECTED]> wrote:
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
