Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #12390 > unrolled thread
| Started by | hipa <hipa.invalid@telenet.be> |
|---|---|
| First post | 2012-03-04 13:00 +0000 |
| Last post | 2012-03-14 23:46 -0700 |
| Articles | 7 on this page of 27 — 4 participants |
Back to article view | Back to comp.lang.javascript
multiple dynamic text fields hipa <hipa.invalid@telenet.be> - 2012-03-04 13:00 +0000
Re: multiple dynamic text fields Jeff North <jnorthau@yahoo.com.au> - 2012-03-05 14:33 +1100
Re: multiple dynamic text fields hipa <hipa.invalid@telenet.be> - 2012-03-08 18:14 +0000
Re: multiple dynamic text fields Jeff North <jnorthau@yahoo.com.au> - 2012-03-09 17:38 +1100
Re: multiple dynamic text fields hipa <hipa.invalid@telenet.be> - 2012-03-09 18:46 +0000
Re: multiple dynamic text fields Jeff North <jnorthau@yahoo.com.au> - 2012-03-10 17:19 +1100
Re: multiple dynamic text fields hipa <hipa.invalid@telenet.be> - 2012-03-11 13:55 +0000
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 20:16 -0700
Re: multiple dynamic text fields hipa <hipa.invalid@telenet.be> - 2012-03-13 20:08 +0000
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 15:36 -0700
Re: multiple dynamic text fields Andrew Poulos <ap_prog@hotmail.com> - 2012-03-14 10:51 +1100
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 18:12 -0700
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 18:55 -0700
Re: multiple dynamic text fields Andrew Poulos <ap_prog@hotmail.com> - 2012-03-14 15:05 +1100
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 21:38 -0700
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 21:56 -0700
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 22:49 -0700
Re: multiple dynamic text fields Andrew Poulos <ap_prog@hotmail.com> - 2012-03-14 17:05 +1100
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 00:23 -0700
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 22:06 -0700
Re: multiple dynamic text fields Andrew Poulos <ap_prog@hotmail.com> - 2012-03-14 17:07 +1100
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 00:28 -0700
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 22:11 -0700
Re: multiple dynamic text fields hipa <hipa.invalid@telenet.be> - 2012-03-14 21:56 +0000
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 14:58 -0700
Re: multiple dynamic text fields hipa <hipa.invalid@telenet.be> - 2012-03-15 06:27 +0000
Re: multiple dynamic text fields David Mark <dmark.cinsoft@gmail.com> - 2012-03-14 23:46 -0700
Page 2 of 2 — ← Prev page 1 [2]
| From | Andrew Poulos <ap_prog@hotmail.com> |
|---|---|
| Date | 2012-03-14 17:07 +1100 |
| Message-ID | <zOydnQGOrYsOqP3SnZ2dnUVZ_hcAAAAA@westnet.com.au> |
| In reply to | #12687 |
On 14/03/2012 4:06 PM, David Mark wrote: > On Mar 14, 12:05 am, Andrew Poulos<ap_p...@hotmail.com> wrote: >> On 14/03/2012 12:55 PM, David Mark wrote: >> >> >> >> >> >> >> >> >> >>> On Mar 13, 7:51 pm, Andrew Poulos<ap_p...@hotmail.com> wrote: >>>> On 14/03/2012 9:36 AM, David Mark wrote: >> >>>>> Because jQuery is very poorly written. I recently posted some >>>>> examples of this on the JSPerf site, pitting one-liner cross-browser >>>>> functions vs. My Library (a four-year-old library) vs. jQuery. >>>>> Unbelievably, jQuery was consistently 10-100 times slower at basic >>>>> tasks. Attaching listeners was particularly slow (not to mention >>>>> awkward). Not long after, they copied my concise on/off methods, but >>>>> I doubt that syntactic sugar improved their performance any. :( >> >>>>> http://jsperf.com/browse/david-mark >>>>> http://jsperf.com/adding-and-removing-listeners-part-2 >> >>>> 1. Its unbelievable that jquery is so much slower in the 'setting the >>>> style attribute' test. It completed about 145K operations/sec versus >>>> 3.2M operations/sec for the cross browser way. The cross browser way is >>>> more that 22 times faster! >> >>>> 2. Some of the tests give a script error when run in Firefox 10.0.2. >> >>> I only saw an error caught and reported in a pink box (with no >>> pertinent info) on loading the first test (and only the first time). >>> The site doesn't seem to be recording results for FF 10 either. >> >> The error with no pertinent info comes in Firefox 10.0.2 while its >> running the 'My Library' tests on: >> Removing Element Attributes Optimized >> Setting inner HTML of DIV (2) >> And then there's this error >> Has Class (1) >> ReferenceError: MJ is not defined. >> fileName:http://jsperf.com/bind-jquery-vs-addevent-mjlib/3 >> lineNumber: 1 >> >> [Enough testing for now] >> >> >> >> >> >> >> >> >> >>> Here is a typical result from FF 10:- >> >>> Chrome 13.0.782 2,885,834 898,102 78,951 1 >>> Chrome 14.0.835 1,622,298 434,627 25,368 3 >>> Chrome 15.0.874 2,450,642 807,696 68,140 3 >>> Chrome 17.0.963 3,155,691 1,474,550 101,658 3 >>> Firefox 6.0.2 1,129,588 435,858 32,674 3 >>> Firefox 8.0 3,135,401 913,051 54,460 2 >>> Firefox Beta 12.0a2 1,874,259 500,396 49,073 1 >>> IE 9.0 720,506 375,765 3,689 1 >>> Opera 11.51 340,953 201,199 2,333 1 >>> Safari 5.1.2 6,167,981 1,614,097 114,380 1 >> >>> http://jsperf.com/removing-element-attributes-optimized >> >>> Should be apparent which column is which. Safari 5 is over 6 >>> *million* attributes removed for the cross-browser rendition. My >>> Library comes in second with over 1.6 million. jQuery is just over >>> 100 thousand. Think of those numbers in terms of dollars. Not just >>> for effect, but those seeking to create the next "Facebook Killer" (or >>> a basic Website that is responsive on battery-powered mobile devices) >>> should realize that the jQuery authors have been asleep at the switch >>> for a long time (and this is the latest version, after numerous well- >>> publicized "optimizations" that reportedly increased performance >>> hundreds of times over). >> >> I don't disagree with your comments about jQuery. What I can't reconcile >> is why my computer theorist friends who can write in a huge number of >> languages believe that jQuery serves them well and can't see any issues. > > Yes, I've heard the "I've never had any problems with...[insert > library name here]" argument many times. Ask how what browsers they > tested and they'll say the ones that the library authors told them > were safe (per the friendly browser icons). Ask if they tested > anything else (like an older, less capable browser) and they'll say it > doesn't matter to them. Ask if they think that testing exclusively > where the results are a foregone conclusion indicates anything about > future environments and they'll say nobody's perfect, nothing is > assured, etc. It's like there's no grey area; everything is black and > white. If everything is assumed to fail in the future, then there's > really nothing to debate. > > But history shows that cross-browser scripts give you the best chance > at avoiding costly rewrites. And even without the history, common > sense should be enough to see through the above "arguments". Alas its something that time and not I can prove to them. >> Each app they build appears to be well received. > > Based on what? A feedback form that only works if jQuery cooperates, > scripting is turned on, etc.? :) Its not a scientific response. The client's happy so I guess they are too. Andrew Poulos
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2012-03-14 00:28 -0700 |
| Message-ID | <cb03ceff-1bbc-4d65-9bce-68d5f7cc7f8e@j5g2000yqm.googlegroups.com> |
| In reply to | #12694 |
On Mar 14, 2:07 am, Andrew Poulos <ap_p...@hotmail.com> wrote: > On 14/03/2012 4:06 PM, David Mark wrote: > > > > > > > > > > > On Mar 14, 12:05 am, Andrew Poulos<ap_p...@hotmail.com> wrote: > >> On 14/03/2012 12:55 PM, David Mark wrote: > > >>> On Mar 13, 7:51 pm, Andrew Poulos<ap_p...@hotmail.com> wrote: > >>>> On 14/03/2012 9:36 AM, David Mark wrote: > > >>>>> Because jQuery is very poorly written. I recently posted some > >>>>> examples of this on the JSPerf site, pitting one-liner cross-browser > >>>>> functions vs. My Library (a four-year-old library) vs. jQuery. > >>>>> Unbelievably, jQuery was consistently 10-100 times slower at basic > >>>>> tasks. Attaching listeners was particularly slow (not to mention > >>>>> awkward). Not long after, they copied my concise on/off methods, but > >>>>> I doubt that syntactic sugar improved their performance any. :( > > >>>>>http://jsperf.com/browse/david-mark > >>>>>http://jsperf.com/adding-and-removing-listeners-part-2 > > >>>> 1. Its unbelievable that jquery is so much slower in the 'setting the > >>>> style attribute' test. It completed about 145K operations/sec versus > >>>> 3.2M operations/sec for the cross browser way. The cross browser way is > >>>> more that 22 times faster! > > >>>> 2. Some of the tests give a script error when run in Firefox 10.0.2. > > >>> I only saw an error caught and reported in a pink box (with no > >>> pertinent info) on loading the first test (and only the first time). > >>> The site doesn't seem to be recording results for FF 10 either. > > >> The error with no pertinent info comes in Firefox 10.0.2 while its > >> running the 'My Library' tests on: > >> Removing Element Attributes Optimized > >> Setting inner HTML of DIV (2) > >> And then there's this error > >> Has Class (1) > >> ReferenceError: MJ is not defined. > >> fileName:http://jsperf.com/bind-jquery-vs-addevent-mjlib/3 > >> lineNumber: 1 > > >> [Enough testing for now] > > >>> Here is a typical result from FF 10:- > > >>> Chrome 13.0.782 2,885,834 898,102 78,951 1 > >>> Chrome 14.0.835 1,622,298 434,627 25,368 3 > >>> Chrome 15.0.874 2,450,642 807,696 68,140 3 > >>> Chrome 17.0.963 3,155,691 1,474,550 101,658 3 > >>> Firefox 6.0.2 1,129,588 435,858 32,674 3 > >>> Firefox 8.0 3,135,401 913,051 54,460 2 > >>> Firefox Beta 12.0a2 1,874,259 500,396 49,073 1 > >>> IE 9.0 720,506 375,765 3,689 1 > >>> Opera 11.51 340,953 201,199 2,333 1 > >>> Safari 5.1.2 6,167,981 1,614,097 114,380 1 > > >>>http://jsperf.com/removing-element-attributes-optimized > > >>> Should be apparent which column is which. Safari 5 is over 6 > >>> *million* attributes removed for the cross-browser rendition. My > >>> Library comes in second with over 1.6 million. jQuery is just over > >>> 100 thousand. Think of those numbers in terms of dollars. Not just > >>> for effect, but those seeking to create the next "Facebook Killer" (or > >>> a basic Website that is responsive on battery-powered mobile devices) > >>> should realize that the jQuery authors have been asleep at the switch > >>> for a long time (and this is the latest version, after numerous well- > >>> publicized "optimizations" that reportedly increased performance > >>> hundreds of times over). > > >> I don't disagree with your comments about jQuery. What I can't reconcile > >> is why my computer theorist friends who can write in a huge number of > >> languages believe that jQuery serves them well and can't see any issues. > > > Yes, I've heard the "I've never had any problems with...[insert > > library name here]" argument many times. Ask how what browsers they > > tested and they'll say the ones that the library authors told them > > were safe (per the friendly browser icons). Ask if they tested > > anything else (like an older, less capable browser) and they'll say it > > doesn't matter to them. Ask if they think that testing exclusively > > where the results are a foregone conclusion indicates anything about > > future environments and they'll say nobody's perfect, nothing is > > assured, etc. It's like there's no grey area; everything is black and > > white. If everything is assumed to fail in the future, then there's > > really nothing to debate. > > > But history shows that cross-browser scripts give you the best chance > > at avoiding costly rewrites. And even without the history, common > > sense should be enough to see through the above "arguments". > > Alas its something that time and not I can prove to them. It's been something like five years since the thing came out. There's an avalanche of evidence out there for those who look past the blogs and cartoons. > > >> Each app they build appears to be well received. > > > Based on what? A feedback form that only works if jQuery cooperates, > > scripting is turned on, etc.? :) > > Its not a scientific response. The client's happy so I guess they are too. > The client has no frame of reference either and no easy way to measure the impact of something like jQuery on their site. One thing is for sure, it can only get in the way of sales (by excluding visitors) as it's sure not going to generate any. ;)
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2012-03-13 22:11 -0700 |
| Message-ID | <a2c8bb56-8f98-49b1-83dc-fd5e49daeef9@k4g2000yqa.googlegroups.com> |
| In reply to | #12673 |
On Mar 13, 9:55 pm, David Mark <dmark.cins...@gmail.com> wrote: > On Mar 13, 7:51 pm, Andrew Poulos <ap_p...@hotmail.com> wrote: > > > > > > > > > > > On 14/03/2012 9:36 AM, David Mark wrote: > > > > Because jQuery is very poorly written. I recently posted some > > > examples of this on the JSPerf site, pitting one-liner cross-browser > > > functions vs. My Library (a four-year-old library) vs. jQuery. > > > Unbelievably, jQuery was consistently 10-100 times slower at basic > > > tasks. Attaching listeners was particularly slow (not to mention > > > awkward). Not long after, they copied my concise on/off methods, but > > > I doubt that syntactic sugar improved their performance any. :( > > > >http://jsperf.com/browse/david-mark > > >http://jsperf.com/adding-and-removing-listeners-part-2 > > > 1. Its unbelievable that jquery is so much slower in the 'setting the > > style attribute' test. It completed about 145K operations/sec versus > > 3.2M operations/sec for the cross browser way. The cross browser way is > > more that 22 times faster! > > > 2. Some of the tests give a script error when run in Firefox 10.0.2. > > I only saw an error caught and reported in a pink box (with no > pertinent info) on loading the first test (and only the first time). > The site doesn't seem to be recording results for FF 10 either. > > Here is a typical result from FF 10:- > > Chrome 13.0.782 2,885,834 898,102 78,951 1 > Chrome 14.0.835 1,622,298 434,627 25,368 3 > Chrome 15.0.874 2,450,642 807,696 68,140 3 > Chrome 17.0.963 3,155,691 1,474,550 101,658 3 > Firefox 6.0.2 1,129,588 435,858 32,674 3 > Firefox 8.0 3,135,401 913,051 54,460 2 > Firefox Beta 12.0a2 1,874,259 500,396 49,073 1 > IE 9.0 720,506 375,765 3,689 1 > Opera 11.51 340,953 201,199 2,333 1 > Safari 5.1.2 6,167,981 1,614,097 114,380 1 > > http://jsperf.com/removing-element-attributes-optimized > > Should be apparent which column is which. Safari 5 is over 6 > *million* attributes removed for the cross-browser rendition. Ops/sec of course. :)
[toc] | [prev] | [next] | [standalone]
| From | hipa <hipa.invalid@telenet.be> |
|---|---|
| Date | 2012-03-14 21:56 +0000 |
| Message-ID | <jjr45i$3rc$1@speranza.aioe.org> |
| In reply to | #12663 |
Op Tue, 13 Mar 2012 15:36:23 -0700, schreef David Mark:
> On Mar 13, 4:08 pm, hipa <hipa.inva...@telenet.be> wrote:
>> Op Mon, 12 Mar 2012 20:16:17 -0700, schreef David Mark:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > On Mar 11, 9:55 am, hipa <hipa.inva...@telenet.be> wrote:
>> >> Op Sat, 10 Mar 2012 17:19:46 +1100, schreef Jeff North:
>>
>> >> > On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript
>> >> > hipa <hipa.inva...@telenet.be>
>> >> > <jjdj6a$5e...@speranza.aioe.org> wrote:
>>
>> >> >>| Op Fri, 09 Mar 2012 17:38:23 +1100, schreef Jeff North: | | > In
>> >> >>your getuser.php file remove all the fluff that is before <?php
>> >> >>and |
>> >> >>> after ?>
>> >> >>| >
>> >> >>| > See if that helps.
>> >> >>|
>> >> >>| Still the same.
>>
>> >> > The only think left is there might be an error in the scriptpg.js
>> >> > file which is causing the non-execution of all the scripts on the
>> >> > page.
>>
>> >> I found the problem.
>>
>> > A problem.
>>
>> >> I tested it while adding text fields true javascript, that also
>> >> didn't work. That got me thinking.
>>
>> > There is no such thing as "true Javascript". If you want to
>> > pigeonhole scripts, use good/bad qualifiers (e.g. jQuery contains bad
>> > Javascript).
>>
>> Can you explain this one?
>>
>> >> Everytime I add a text field I need to append .autocomplete. When
>> >> the autocomplete gets set up when the page loads it will not work on
>> >> a text field that is dynamically added. So this is what I do.
>>
>> >> $("#addButton").click(function () {
>>
>> > document.getElementById('addButton').onclick = function() {
>>
>> Nothing happens when I click the button.
>
> Sorry, I assumed you were further along. You have to piece it all
> together:
>
> document.getElementById('addButton').onclick = function() {
> // Put the rest in here
> };
>
Yes I know that, I looked over the closing parentheses at the end. Works
now, thanks!
>
>> > Feel free to write a wrapper for gEBI if you are worried about typing
>> > (shouldn't be). Will just slow things down, but not nearly to the
>> > extent that jQuery does. It's one function call vs. hundreds and
>> > function calls are expensive.
>>
>> How is that?
>
> Because jQuery is very poorly written. I recently posted some examples
> of this on the JSPerf site, pitting one-liner cross-browser functions
> vs. My Library (a four-year-old library) vs. jQuery. Unbelievably,
> jQuery was consistently 10-100 times slower at basic tasks. Attaching
> listeners was particularly slow (not to mention awkward). Not long
> after, they copied my concise on/off methods, but I doubt that syntactic
> sugar improved their performance any. :(
>
> http://jsperf.com/browse/david-mark
> http://jsperf.com/adding-and-removing-listeners-part-2
>
I'll take a look at this one, but have the feeling that you are far more
advanced than me :-)
>> And why is jQuery so bad? I find the autocomplete function pretty handy
>> :-)
>
> I don't believe that's a jQuery function. Alone, jQuery does little more
> than queries and "event normalization" (quotes indicate there's no
> "normal" for events like change). Hell, they don't even allow for
> setting the - this - object without calling an additional "proxy"
> function. :(
>
>
>> >> $('#article' + counter + '').autocomplete('datapg.php?
>> >> mode=sqlarticle', {width: 200, max: 10});
>>
>> > You'd be better off with no widget at all as anything built atop
>> > jQuery is highly suspect (it's too slow, not cross-browser and has a
>> > terrible DOM abstraction layer). If that's unacceptable, hand this
>> > part off to somebody else (preferably not a jQuery enthusiast).
>>
>> Oh you explained it :-)
>> How would someone else do it. I could off course also just cut the
>> jQuery part.
>
> Well, if you have thousands of rows that need to populate a dropdown of
> some sort, you will need something along the lines of an
> autocomplete/suggest. Somebody more familiar with DOM scripting
> (particularly keyboard handling) should be able to bang one out in a day
> or two.
That sounds logical, when thousands of rows need to populate a dropdown.
I kept this in mind, my db isn't very big. It can/will grow, but not to
the extend of thousands and thousands of records.
> A canned widget for jQuery is going to be hampered by jQuery and is
> likely to include lots of unneeded features as those projects aim to
> appeal to as many users as possible. This is because of ego and a myth
> that the presence of lots of users ensures a bug-free script (all those
> eyes and all). :)
>
>
>>
>>
>> >> counter++;
>>
>> > That works. :)
>>
>> Thanks for the reply!
>
> NP.
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2012-03-14 14:58 -0700 |
| Message-ID | <e21f6c10-f25d-4f23-975d-286dfeefa80e@k24g2000yqe.googlegroups.com> |
| In reply to | #12730 |
On Mar 14, 5:56 pm, hipa <hipa.inva...@telenet.be> wrote:
> Op Tue, 13 Mar 2012 15:36:23 -0700, schreef David Mark:
>
>
>
>
>
>
>
>
>
> > On Mar 13, 4:08 pm, hipa <hipa.inva...@telenet.be> wrote:
> >> Op Mon, 12 Mar 2012 20:16:17 -0700, schreef David Mark:
>
> >> > On Mar 11, 9:55 am, hipa <hipa.inva...@telenet.be> wrote:
> >> >> Op Sat, 10 Mar 2012 17:19:46 +1100, schreef Jeff North:
>
> >> >> > On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript
> >> >> > hipa <hipa.inva...@telenet.be>
> >> >> > <jjdj6a$5e...@speranza.aioe.org> wrote:
>
> >> >> >>| Op Fri, 09 Mar 2012 17:38:23 +1100, schreef Jeff North: | | > In
> >> >> >>your getuser.php file remove all the fluff that is before <?php
> >> >> >>and |
> >> >> >>> after ?>
> >> >> >>| >
> >> >> >>| > See if that helps.
> >> >> >>|
> >> >> >>| Still the same.
>
> >> >> > The only think left is there might be an error in the scriptpg.js
> >> >> > file which is causing the non-execution of all the scripts on the
> >> >> > page.
>
> >> >> I found the problem.
>
> >> > A problem.
>
> >> >> I tested it while adding text fields true javascript, that also
> >> >> didn't work. That got me thinking.
>
> >> > There is no such thing as "true Javascript". If you want to
> >> > pigeonhole scripts, use good/bad qualifiers (e.g. jQuery contains bad
> >> > Javascript).
>
> >> Can you explain this one?
>
> >> >> Everytime I add a text field I need to append .autocomplete. When
> >> >> the autocomplete gets set up when the page loads it will not work on
> >> >> a text field that is dynamically added. So this is what I do.
>
> >> >> $("#addButton").click(function () {
>
> >> > document.getElementById('addButton').onclick = function() {
>
> >> Nothing happens when I click the button.
>
> > Sorry, I assumed you were further along. You have to piece it all
> > together:
>
> > document.getElementById('addButton').onclick = function() {
> > // Put the rest in here
> > };
>
> Yes I know that, I looked over the closing parentheses at the end. Works
> now, thanks!
>
>
>
>
>
>
>
>
>
>
>
> >> > Feel free to write a wrapper for gEBI if you are worried about typing
> >> > (shouldn't be). Will just slow things down, but not nearly to the
> >> > extent that jQuery does. It's one function call vs. hundreds and
> >> > function calls are expensive.
>
> >> How is that?
>
> > Because jQuery is very poorly written. I recently posted some examples
> > of this on the JSPerf site, pitting one-liner cross-browser functions
> > vs. My Library (a four-year-old library) vs. jQuery. Unbelievably,
> > jQuery was consistently 10-100 times slower at basic tasks. Attaching
> > listeners was particularly slow (not to mention awkward). Not long
> > after, they copied my concise on/off methods, but I doubt that syntactic
> > sugar improved their performance any. :(
>
> >http://jsperf.com/browse/david-mark
> >http://jsperf.com/adding-and-removing-listeners-part-2
>
> I'll take a look at this one, but have the feeling that you are far more
> advanced than me :-)
>
>
>
>
>
>
>
>
>
> >> And why is jQuery so bad? I find the autocomplete function pretty handy
> >> :-)
>
> > I don't believe that's a jQuery function. Alone, jQuery does little more
> > than queries and "event normalization" (quotes indicate there's no
> > "normal" for events like change). Hell, they don't even allow for
> > setting the - this - object without calling an additional "proxy"
> > function. :(
>
> >> >> $('#article' + counter + '').autocomplete('datapg.php?
> >> >> mode=sqlarticle', {width: 200, max: 10});
>
> >> > You'd be better off with no widget at all as anything built atop
> >> > jQuery is highly suspect (it's too slow, not cross-browser and has a
> >> > terrible DOM abstraction layer). If that's unacceptable, hand this
> >> > part off to somebody else (preferably not a jQuery enthusiast).
>
> >> Oh you explained it :-)
> >> How would someone else do it. I could off course also just cut the
> >> jQuery part.
>
> > Well, if you have thousands of rows that need to populate a dropdown of
> > some sort, you will need something along the lines of an
> > autocomplete/suggest. Somebody more familiar with DOM scripting
> > (particularly keyboard handling) should be able to bang one out in a day
> > or two.
>
> That sounds logical, when thousands of rows need to populate a dropdown.
> I kept this in mind, my db isn't very big. It can/will grow, but not to
> the extend of thousands and thousands of records.
>
So how many rows do you have in the lookup table? A plain old SELECT
might do the trick (and wouldn't require scripting to work).
[toc] | [prev] | [next] | [standalone]
| From | hipa <hipa.invalid@telenet.be> |
|---|---|
| Date | 2012-03-15 06:27 +0000 |
| Message-ID | <jjs24o$au9$2@speranza.aioe.org> |
| In reply to | #12731 |
Op Wed, 14 Mar 2012 14:58:31 -0700, schreef David Mark: >> That sounds logical, when thousands of rows need to populate a >> dropdown. I kept this in mind, my db isn't very big. It can/will grow, >> but not to the extend of thousands and thousands of records. >> >> > So how many rows do you have in the lookup table? A plain old SELECT > might do the trick (and wouldn't require scripting to work). The largest table at this moment has about 160 rows.
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2012-03-14 23:46 -0700 |
| Message-ID | <6156d1a8-2737-4fda-8adb-36a2a302d3f5@h12g2000yqi.googlegroups.com> |
| In reply to | #12747 |
On Mar 15, 2:27 am, hipa <hipa.inva...@telenet.be> wrote: > Op Wed, 14 Mar 2012 14:58:31 -0700, schreef David Mark: > > >> That sounds logical, when thousands of rows need to populate a > >> dropdown. I kept this in mind, my db isn't very big. It can/will grow, > >> but not to the extend of thousands and thousands of records. > > > So how many rows do you have in the lookup table? A plain old SELECT > > might do the trick (and wouldn't require scripting to work). > > The largest table at this moment has about 160 rows. Then just use a SELECT for the moment. If you decide you want an autocomplete/suggest in the future, use script to hide the SELECT and create a text INPUT (and an OL for the dropdown). If your number of rows grows significantly, you might want to consider another interface as an XHR-driven widget will not be usable without scripting. In any event, no jQuery required. ;)
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.javascript
csiph-web