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 alrea
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 theore
Well, I have written a treemap implementation in PHP and JavaScript
(like the one of SequoiaView - http://www.win.tue.nl/sequoiaview/).
And in this application, there is a difference.
Of course, in most applications, there will be no difference. But
there are cases, in which you need a fast selec
What about the common "Grid"? When you have a table with 100-1000+ rows and
5-10+ columns and then you want to resize columns, or bind click functions
to them, or enable drag and drop or have collapsable rows, or sorting.
This is where selector speed should make a difference. The 1.0 version of
Klaus,
>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?
I think generally you're correct. Lo
I think you hit it on the head. From my perspective, I think if these
tests were never publicized, then most folks wouldn't even notice the
difference unless you were dealing with pages that had to manipulate
large amounts of selectors.
Rey
Klaus Hartl wrote:
Dan G. Switzer, II schrieb:
Dan G. Switzer, II schrieb:
* We need a plugin, that enables to speed up the core. It can be used
in web applications, which need a lot of perfomance. It doesn't
matter, if some core functions are not used any more (performance is
the goal). It is important, that the jquery style still remains a
>* We need a plugin, that enables to speed up the core. It can be used
>in web applications, which need a lot of perfomance. It doesn't
>matter, if some core functions are not used any more (performance is
>the goal). It is important, that the jquery style still remains and
>that other jquery plug
>
> _
>
> From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of Glen Lipka
> Sent: Monday, April 02, 2007 11:35 AM
> To: jquery-en@googlegroups.com
> Subject: [jQuery] Re: jQuery selectors speed improvements - A different
> perspective
>
> I agree. A
On Apr 2, 2007, at 9:05 PM, Joao Pedrosa wrote:
Hi,
We'd also like to hear your opinions on any issue that you think
merits
reconsideration. Whether it be file size, components that should
be in
core or site documentation, we want to hear about it.
In Ruby-land, RubyForge has been a ve
Hi,
We'd also like to hear your opinions on any issue that you think merits
reconsideration. Whether it be file size, components that should be in
core or site documentation, we want to hear about it.
In Ruby-land, RubyForge has been a very successful initiative. Together with
RubyGems for pa
[mailto:[EMAIL PROTECTED] On
Behalf Of Glen Lipka
Sent: Monday, April 02, 2007 11:35 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: jQuery selectors speed improvements - A different
perspective
I agree. At many big corporations you already have scripts that are
required. Google analytics s
The "selector turbo" plugin is a good idea. But, in this case, all the
selector code in the core will be useless using these plugin. Maybe it's a
good time to have custom builds.
On 4/2/07, Glen Lipka <[EMAIL PROTECTED]> wrote:
I agree. At many big corporations you already have scripts that ar
I agree. At many big corporations you already have scripts that are
required. Google analytics scripts, Survey scripts, offermatica scripts,
e-commerce scripts. Plus the general cruft of legacy scripts for a myriad
of purposes. Not to mention all the screenshots and 100K of marketing text.
Se
14 matches
Mail list logo
