Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12390 > unrolled thread

multiple dynamic text fields

Back to article view | Back to comp.lang.javascript

Contents

  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 1 of 2  [1] 2  Next page →

#12390 — multiple dynamic text fields

Hi

I posted this question in comp.lang.php but I got redirected here.
I have a page with an autocomplete text field. This works fine. But what 
I actually want is adding more text fields with the same autocomplete 
options. It must be an orderpage with multiple order lines.
If I choose option 2 from the drop down, 2 text fields are chown. That is 
ok, but the autocomplete doesn't work.
But if I manually type "getuser.php?q=2" in a browser I get a page with 2 
text boxes where the autocomplete does work.
I don't think I need to show here my complete autocomplete code because I 
think this is not the point here.
When text boxes are generated dynamically is there an underlying id or 
something given to it? Hope someone can help.

index.php
---------

<!DOCTYPE html>

<html lang="en" >
    <head>
        <meta charset="utf-8" />
        <title>Test</title>
        <link href="css/main.css" rel="stylesheet" type="text/css" />   
	<link href="css/jquery.autocomplete.css" rel="stylesheet" 
type="text/css" />
        <script type="text/javascript" src="js/jquery-1.5.2.min.js"></
script>
        <script type="text/javascript" src="js/
jquery.autocomplete.pack.js"></script>
        <script type="text/javascript" src="js/scriptpg.js"></script>

<script type="text/javascript">
function showUser(str)
{
if (str=="")
  {
  document.getElementById("txtHint").innerHTML="";
  return;
  } 
if (window.XMLHttpRequest)
  {// code for IE7+, Firefox, Chrome, Opera, Safari
  xmlhttp=new XMLHttpRequest();
  }
else
  {// code for IE6, IE5
  xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
  }
xmlhttp.onreadystatechange=function()
  {
  if (xmlhttp.readyState==4 && xmlhttp.status==200)
    {
    document.getElementById("txtHint").innerHTML=xmlhttp.responseText;
    }
  }
xmlhttp.open("GET","getuser.php?q="+str,true);
xmlhttp.send();
}
</script>
</head>
<body>
<form>
<select name="users" onchange="showUser(this.value)">
<option value="">Select a number:</option>
<option value="1">1</option>
<option value="2">2</option>
<option value="3">3</option>
<option value="4">4</option>
</select>
</form>
<br />
<div id="txtHint"><b>Number info will be listed here.</b></div>
</body>
</html>

---------------------------------------------------------------

getuser.php
-----------

...

<body>
<?php
$q=$_GET["q"];
for($i=1;$i<=$q;$i++){
echo "<input class='article' type='text' autocomplete='off'><br>";
}
?>
</body>

[toc] | [next] | [standalone]

#12406

On Sun, 4 Mar 2012 13:00:20 +0000 (UTC), in comp.lang.javascript hipa
<hipa.invalid@telenet.be>
<jivp14$brm$1@speranza.aioe.org> wrote:

>| Hi
>| 
>| I posted this question in comp.lang.php but I got redirected here.
>| I have a page with an autocomplete text field. This works fine. But what 
>| I actually want is adding more text fields with the same autocomplete 
>| options. It must be an orderpage with multiple order lines.
>| If I choose option 2 from the drop down, 2 text fields are chown. That is 
>| ok, but the autocomplete doesn't work.

Maybe it doesn't work due to the attribute autocomplete='off'

>| But if I manually type "getuser.php?q=2" in a browser I get a page with 2 
>| text boxes where the autocomplete does work.

Your are running the php code directly. It has no DTD and therefore
the content is displayed in quirks mode. It is highly probable that
the browser doesn't understand the autocomplete attribute but is using
it's own autocomplete/autofill option.

Browsers have had this option for years so it would be interesting to
see if this attribute will override the browser setting (I doubt it
though).

>| I don't think I need to show here my complete autocomplete code because I 
>| think this is not the point here.
>| When text boxes are generated dynamically is there an underlying id or 
>| something given to it? Hope someone can help.

You need to specify this information when the element is created (see
getuser.php for alteration).

>| 
>| index.php
>| ---------

Why are you mixing HTML5 and XHTML elements? For example, the link
element does not have a closing element, only in XHTML is the />
required.

In HTML5 you can shorten your script elements by using
<script></script> i.e. 
<script src="js/jquery-1.5.2.min.js"></script>
<script src="js/jquery.autocomplete.pack.js"></script>

You are using jQuery which comes with it's own AJAX routines - why
re-invent the wheel?

>| <!DOCTYPE html>
>| 
>| <html lang="en" >
>|     <head>
>|         <meta charset="utf-8" />
>|         <title>Test</title>
>|         <link href="css/main.css" rel="stylesheet" type="text/css" />   
>| 	<link href="css/jquery.autocomplete.css" rel="stylesheet" 
>| type="text/css" />
>|         <script type="text/javascript" src="js/jquery-1.5.2.min.js"></
>| script>
>|         <script type="text/javascript" src="js/
>| jquery.autocomplete.pack.js"></script>
>|         <script type="text/javascript" src="js/scriptpg.js"></script>
>| 
>| <script type="text/javascript">
>| function showUser(str)
>| {
>| if (str=="")
>|   {
>|   document.getElementById("txtHint").innerHTML="";
>|   return;
>|   } 
>| if (window.XMLHttpRequest)
>|   {// code for IE7+, Firefox, Chrome, Opera, Safari
>|   xmlhttp=new XMLHttpRequest();
>|   }
>| else
>|   {// code for IE6, IE5
>|   xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
>|   }
>| xmlhttp.onreadystatechange=function()
>|   {
>|   if (xmlhttp.readyState==4 && xmlhttp.status==200)
>|     {
>|     document.getElementById("txtHint").innerHTML=xmlhttp.responseText;
>|     }
>|   }
>| xmlhttp.open("GET","getuser.php?q="+str,true);
>| xmlhttp.send();
>| }
>| </script>
>| </head>
>| <body>
>| <form>
>| <select name="users" onchange="showUser(this.value)">
>| <option value="">Select a number:</option>
>| <option value="1">1</option>
>| <option value="2">2</option>
>| <option value="3">3</option>
>| <option value="4">4</option>
>| </select>
>| </form>
>| <br />
>| <div id="txtHint"><b>Number info will be listed here.</b></div>
>| </body>
>| </html>
>| 
>| ---------------------------------------------------------------
>| 
>| getuser.php
>| -----------
>| 
>| ...
>| 
>| <body>
>| <?php
>| $q=$_GET["q"];
>| for($i=1;$i<=$q;$i++){
>| echo "<input class='article' type='text' autocomplete='off'><br>";

echo "<input class='article' type='text' name='orders[]'><br>";

The name of the element is transmitted on form submit.
Because there are multiple entries then send the information as an
array and handle this server-side.

>| }
>| ?>
>| </body>

[toc] | [prev] | [next] | [standalone]

#12508

Op Mon, 05 Mar 2012 14:33:29 +1100, schreef Jeff North:

> On Sun, 4 Mar 2012 13:00:20 +0000 (UTC), in comp.lang.javascript hipa
> <hipa.invalid@telenet.be>
> <jivp14$brm$1@speranza.aioe.org> wrote:
> 
>>| Hi
>>|
>>| I posted this question in comp.lang.php but I got redirected here. | I
>>have a page with an autocomplete text field. This works fine. But what |
>>I actually want is adding more text fields with the same autocomplete |
>>options. It must be an orderpage with multiple order lines. | If I
>>choose option 2 from the drop down, 2 text fields are chown. That is |
>>ok, but the autocomplete doesn't work.
> 
> Maybe it doesn't work due to the attribute autocomplete='off'

If I remove the autocomplete='off', the result is the same.
 
>>| But if I manually type "getuser.php?q=2" in a browser I get a page
>>with 2 | text boxes where the autocomplete does work.
> 
> Your are running the php code directly. It has no DTD and therefore the
> content is displayed in quirks mode. It is highly probable that the
> browser doesn't understand the autocomplete attribute but is using it's
> own autocomplete/autofill option.
> 
> Browsers have had this option for years so it would be interesting to
> see if this attribute will override the browser setting (I doubt it
> though).

Is have a DTD, but I didn't show it in this post. See the three dots 
(...). 
On the other hand, my autocomplete gets the results from a postgres 
database. This does work...
 
>>| I don't think I need to show here my complete autocomplete code
>>because I | think this is not the point here.
>>| When text boxes are generated dynamically is there an underlying id or
>>| something given to it? Hope someone can help.
> 
> You need to specify this information when the element is created (see
> getuser.php for alteration).

When I do it like this:

for($i=1;$i<=$q;$i++){
echo "<input id='article" . $i . "' name='article" . $i . "' 
type='text'>";
}

The same happens. It does work if I manually type "getuser.php?q=2" in a 
browser. But not when I open the page from the index page.

 
>>|
>>| index.php
>>| ---------
> 
> Why are you mixing HTML5 and XHTML elements? For example, the link
> element does not have a closing element, only in XHTML is the />
> required.
> 
> In HTML5 you can shorten your script elements by using <script></script>
> i.e.
> <script src="js/jquery-1.5.2.min.js"></script> <script
> src="js/jquery.autocomplete.pack.js"></script>
> 
> You are using jQuery which comes with it's own AJAX routines - why
> re-invent the wheel?
> 
>>| <!DOCTYPE html>
>>|
>>| <html lang="en" >
>>|     <head>
>>|         <meta charset="utf-8" />
>>|         <title>Test</title>
>>|         <link href="css/main.css" rel="stylesheet" type="text/css" />
>>| 	<link href="css/jquery.autocomplete.css" rel="stylesheet" |
>>type="text/css" />
>>|         <script type="text/javascript" src="js/jquery-1.5.2.min.js"></
>>| script>
>>|         <script type="text/javascript" src="js/ |
>>jquery.autocomplete.pack.js"></script> |         <script
>>type="text/javascript" src="js/scriptpg.js"></script> |
>>| <script type="text/javascript">
>>| function showUser(str)
>>| {
>>| if (str=="")
>>|   {
>>|   document.getElementById("txtHint").innerHTML=""; |   return;
>>|   }
>>| if (window.XMLHttpRequest)
>>|   {// code for IE7+, Firefox, Chrome, Opera, Safari |   xmlhttp=new
>>XMLHttpRequest();
>>|   }
>>| else
>>|   {// code for IE6, IE5
>>|   xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); |   }
>>| xmlhttp.onreadystatechange=function() |   {
>>|   if (xmlhttp.readyState==4 && xmlhttp.status==200) |     {
>>|     document.getElementById("txtHint").innerHTML=xmlhttp.responseText;
>>|     }
>>|   }
>>| xmlhttp.open("GET","getuser.php?q="+str,true); | xmlhttp.send();
>>| }
>>| </script>
>>| </head>
>>| <body>
>>| <form>
>>| <select name="users" onchange="showUser(this.value)"> | <option
>>value="">Select a number:</option> | <option value="1">1</option>
>>| <option value="2">2</option>
>>| <option value="3">3</option>
>>| <option value="4">4</option>
>>| </select>
>>| </form>
>>| <br />
>>| <div id="txtHint"><b>Number info will be listed here.</b></div> |
>></body>
>>| </html>
>>|
>>| --------------------------------------------------------------- |
>>| getuser.php
>>| -----------
>>|
>>| ...
>>|
>>| <body>
>>| <?php
>>| $q=$_GET["q"];
>>| for($i=1;$i<=$q;$i++){
>>| echo "<input class='article' type='text' autocomplete='off'><br>";
> 
> echo "<input class='article' type='text' name='orders[]'><br>";
> 
> The name of the element is transmitted on form submit. Because there are
> multiple entries then send the information as an array and handle this
> server-side.
> 
>>| }
>>| ?>
>>| </body>

[toc] | [prev] | [next] | [standalone]

#12521

On Thu, 8 Mar 2012 18:14:52 +0000 (UTC), in comp.lang.javascript hipa
<hipa.invalid@telenet.be>
<jjasus$a5t$1@speranza.aioe.org> wrote:

>| Op Mon, 05 Mar 2012 14:33:29 +1100, schreef Jeff North:
>| 
>| > On Sun, 4 Mar 2012 13:00:20 +0000 (UTC), in comp.lang.javascript hipa
>| > <hipa.invalid@telenet.be>
>| > <jivp14$brm$1@speranza.aioe.org> wrote:
>| > 
>| >>| Hi
>| >>|
>| >>| I posted this question in comp.lang.php but I got redirected here. | I
>| >>have a page with an autocomplete text field. This works fine. But what |
>| >>I actually want is adding more text fields with the same autocomplete |
>| >>options. It must be an orderpage with multiple order lines. | If I
>| >>choose option 2 from the drop down, 2 text fields are chown. That is |
>| >>ok, but the autocomplete doesn't work.
>| > 
>| > Maybe it doesn't work due to the attribute autocomplete='off'
>| 
>| If I remove the autocomplete='off', the result is the same.
>|  
>| >>| But if I manually type "getuser.php?q=2" in a browser I get a page
>| >>with 2 | text boxes where the autocomplete does work.
>| > 
>| > Your are running the php code directly. It has no DTD and therefore the
>| > content is displayed in quirks mode. It is highly probable that the
>| > browser doesn't understand the autocomplete attribute but is using it's
>| > own autocomplete/autofill option.
>| > 
>| > Browsers have had this option for years so it would be interesting to
>| > see if this attribute will override the browser setting (I doubt it
>| > though).
>| 
>| Is have a DTD, but I didn't show it in this post. See the three dots 
>| (...). 
>| On the other hand, my autocomplete gets the results from a postgres 
>| database. This does work...
>|  
>| >>| I don't think I need to show here my complete autocomplete code
>| >>because I | think this is not the point here.
>| >>| When text boxes are generated dynamically is there an underlying id or
>| >>| something given to it? Hope someone can help.
>| > 
>| > You need to specify this information when the element is created (see
>| > getuser.php for alteration).
>| 
>| When I do it like this:
>| 
>| for($i=1;$i<=$q;$i++){
>| echo "<input id='article" . $i . "' name='article" . $i . "' 
>| type='text'>";
>| }
>| 
>| The same happens. It does work if I manually type "getuser.php?q=2" in a 
>| browser. But not when I open the page from the index page.
>| 

In your getuser.php file remove all the fluff that is before <?php and
after ?>

See if that helps.

[snip]

[toc] | [prev] | [next] | [standalone]

#12548

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.

[toc] | [prev] | [next] | [standalone]

#12566

On Fri, 9 Mar 2012 18:46:34 +0000 (UTC), in comp.lang.javascript hipa
<hipa.invalid@telenet.be>
<jjdj6a$5e4$1@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.

[toc] | [prev] | [next] | [standalone]

#12597

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.invalid@telenet.be>
> <jjdj6a$5e4$1@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.
I tested it while adding text fields true javascript, that also didn't 
work. That got me thinking.
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 () {
	var newTextBoxDiv = $(document.createElement('div')).attr("id", 
'TextBoxDiv' + counter);
	newTextBoxDiv.html('<label>Article '+ counter +':</label><input 
type="text" name="article' + counter + '" id="article' + counter + '">');
	newTextBoxDiv.appendTo("#TextBoxesGroup");
 	$('#article' + counter + '').autocomplete('datapg.php?
mode=sqlarticle', {width: 200, max: 10});
	counter++;
     });

[toc] | [prev] | [next] | [standalone]

#12633

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).

> 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() {

Do you really need more than one click listener for this button?

>         var newTextBoxDiv = $(document.createElement('div')).attr("id",
> 'TextBoxDiv' + counter);


var newTextBoxDiv = document.createElement('div');
newTextBoxDiv.id = 'TextBoxDiv' + counter;

Yes, it's taller, but yours is wider. Also, code in listeners needs to
be as efficient as possible as they react to user input. The "true"
version will be about a hundred times faster (and avoids the
mysterious and misunderstood "attr" method). Far easier to read
too. ;)


>         newTextBoxDiv.html('<label>Article '+ counter +':</label><input
> type="text" name="article' + counter + '" id="article' + counter + '">');

newTextBoxDiv.innerHTML = ...

>         newTextBoxDiv.appendTo("#TextBoxesGroup");

document.getElementById('TextBoxesGroup').appendChild(newTextBoxDiv);

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.

>         $('#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).

>         counter++;

That works. :)

[toc] | [prev] | [next] | [standalone]

#12659

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.

> Do you really need more than one click listener for this button?
>
>>         var newTextBoxDiv =
>>         $(document.createElement('div')).attr("id",
>> 'TextBoxDiv' + counter);
> 
> 
> var newTextBoxDiv = document.createElement('div'); newTextBoxDiv.id =
> 'TextBoxDiv' + counter;

Also nothing happens when the button is clicked.

> Yes, it's taller, but yours is wider. Also, code in listeners needs to
> be as efficient as possible as they react to user input. The "true"
> version will be about a hundred times faster (and avoids the mysterious
> and misunderstood "attr" method). Far easier to read too. ;)
> 
> 
>>         newTextBoxDiv.html('<label>Article '+ counter
>>         +':</label><input
>> type="text" name="article' + counter + '" id="article' + counter +
>> '">');
> 
> newTextBoxDiv.innerHTML = ...
> 
>>         newTextBoxDiv.appendTo("#TextBoxesGroup");
> 
> document.getElementById('TextBoxesGroup').appendChild(newTextBoxDiv);
> 
> 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?
And why is jQuery so bad? I find the autocomplete function pretty 
handy :-)


>>         $('#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.

> 
>>         counter++;
> 
> That works. :)

Thanks for the reply!

[toc] | [prev] | [next] | [standalone]

#12663

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
};

>
> > 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

> 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.

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]

#12667

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.

3. Where are the jquery users to give a different view of the tests/results?

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#12671

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.

In jQuery?

>
> 3. Where are the jquery users to give a different view of the tests/results?
>

On StackOverflow and YCombinator. Resig told his flock to ignore this
group as this group sees right through his BS. There's a whole
generation of JS programmers who see jQuery developers as
"everyone" (as in U think UR smarter than everyone) and CLJ as a
Google Grouyp with "just a few bitter old users". And oddly enough,
they do favor IRC. :)

[toc] | [prev] | [next] | [standalone]

#12673

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.  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).

Then there's the long since conceded point that jQuery is terrible at
attribute manipulation (i.e. it comes up with a lot of wrong
answers).  Granted, most jQuery users don't understand that issue
(which is largely confined to IE 6/7) or how it can affect them.

And, of course, most of the jQuery examples are neither concise nor
easily understood at a glance.

Meanwhile, the "fast, concise, etc." line continues to be parroted by
neophytes who never tried anything else.  Show them tests like that
and they'll show you an even less readable example (a lot of $.fn.*
calls) that is slightly faster.  Then they'll blither about early
optimization, saving developer time, etc.  Of course, a site is
developed once but used many times, but then Web developers generally
have disdain for their users and consider their time far more
valuable.  Add up all of the time spent "upgrading", retesting,
redeploying, etc., plus the inevitable cost of pissing off users with
slow or broken pages and all of those "arguments" fall apart.

So how does this please so many?  Marketing, plus pigeonholing all
scripts as either "perfect" (seen as impossible) or "imperfect" (all
scripts then) and mistaking empirical evidence (e.g. works today in my
installed browsers!) for proofs.  Looking at the code is seen as a
waste of time as how many users are going to look at the code? :)

I've been saying the same thing since 2007 (when I first encountered
the script and before I wrote the "competing" library) while most
others took a "give it a few years and they'll get it right" stance
(which I imagine most regret at this point).

It was never about writing the most efficient and "perfect" code or
patching the most "cross-browser" issues.  It's always been about the
reaction I got from the authors (and their fans) after that first
review.  That alone told me they'd never get anywhere (and the same
for Prototype, MooTools, etc.)  On the contrary, many argue that
convincing lots of beginners to adopt it as a "standard" is getting
somewhere, but it's not anywhere I ever wanted to go and hasn't
improved the code logic or performance a whit.

Seeing them in action (acting on tips I sent over) further convinced
me that they just didn't understand what they were doing and were
virulently opposed to learning (too busy bringing lousy code to
market).

[toc] | [prev] | [next] | [standalone]

#12683

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. 
Each app they build appears to be well received.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#12685

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

Read that URI carefully (or click the link). That's not a mylib test.
It's an mjlib (whatever that is) test (and not mine).

I thought I added a comment to that to ask that it be deleted from my
tests. How it got there is a bit of a mystery; perhaps a revision that
I abandoned.

[toc] | [prev] | [next] | [standalone]

#12686

On Mar 14, 12:38 am, David Mark <dmark.cins...@gmail.com> 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)

http://jsperf.com/removing-element-attributes-optimized
http://jsperf.com/setting-inner-html-of-div/5
http://jsperf.com/setting-inner-html-of-div

None of these display that pink box on load and none of them indicate
any errors with My Library (or anything else at the moment) in FF
10.0.2 (Windows 7).

I saw the blank error once on load and it didn't indicate anything
wrong with My Library (which subsequently passed its tests).  I
suspect I had an old copy of the JSPerf script(s) in my cache that
didn't agree with the current page(s).  That can happen if cache
settings are incorrect on the server.

[toc] | [prev] | [next] | [standalone]

#12692

On Mar 14, 12:38 am, David Mark <dmark.cins...@gmail.com> 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
>
> Read that URI carefully (or click the link). That's not a mylib test.
> It's an mjlib (whatever that is) test (and not mine).
>
> I thought I added a comment to that to ask that it be deleted from my
> tests. How it got there is a bit of a mystery; perhaps a revision that
> I abandoned.

Should add that I don't get any errors in FF 10.0.2 (or the just
updated 11) with that library either.  I think you may have an FF plug-
in issue (JSPerf uses both Quicktime and Flash).  Disable other plug-
ins and see if that clears up the problem.

[toc] | [prev] | [next] | [standalone]

#12693

On 14/03/2012 4:49 PM, David Mark wrote:
> On Mar 14, 12:38 am, David Mark<dmark.cins...@gmail.com>  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
>>
>> Read that URI carefully (or click the link). That's not a mylib test.
>> It's an mjlib (whatever that is) test (and not mine).
>>
>> I thought I added a comment to that to ask that it be deleted from my
>> tests. How it got there is a bit of a mystery; perhaps a revision that
>> I abandoned.
>
> Should add that I don't get any errors in FF 10.0.2 (or the just
> updated 11) with that library either.  I think you may have an FF plug-
> in issue (JSPerf uses both Quicktime and Flash).  Disable other plug-
> ins and see if that clears up the problem.

I updated to 11.0 and the error still occurs. I disabled QT and Flash 
and the errors no longer appear.

Testing in Firefox 11.0 on Windows Server 2008 / Vista

jQuery     10,626 ops/sec
My Lib OO  69,459 ops/sec
My Lib    109.413 ops/sec
Cross Br  157,055 ops/sec

Who'd a thunk that jQuery would be so far behind!

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#12696

On Mar 14, 2:05 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
> On 14/03/2012 4:49 PM, David Mark wrote:
>
>
>
>
>
>
>
>
>
> > On Mar 14, 12:38 am, David Mark<dmark.cins...@gmail.com>  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
>
> >> Read that URI carefully (or click the link). That's not a mylib test.
> >> It's an mjlib (whatever that is) test (and not mine).
>
> >> I thought I added a comment to that to ask that it be deleted from my
> >> tests. How it got there is a bit of a mystery; perhaps a revision that
> >> I abandoned.
>
> > Should add that I don't get any errors in FF 10.0.2 (or the just
> > updated 11) with that library either.  I think you may have an FF plug-
> > in issue (JSPerf uses both Quicktime and Flash).  Disable other plug-
> > ins and see if that clears up the problem.
>
> I updated to 11.0 and the error still occurs. I disabled QT and Flash
> and the errors no longer appear.

Thanks for the confirmation.

>
> Testing in Firefox 11.0 on Windows Server 2008 / Vista
>
> jQuery     10,626 ops/sec
> My Lib OO  69,459 ops/sec
> My Lib    109.413 ops/sec
> Cross Br  157,055 ops/sec
>
> Who'd a thunk that jQuery would be so far behind!

Yes, "everyone" is chasing and I've been standing still for four
years. :)

I seem to recall a lot of arguments back in 2007 about how jQuery was
open source and the whole world was behind them and surely it'll get
better, and blah, blah, blah. Didn't work for jQuery or Prototype or
Dojo or any of them. The number of developers involved is not an
indication of present or future quality. It's just a meaningless
metric. Even more irrelevant is the number of users. I once had a guy
tell me Ext JS couldn't have bugs as it was x years old with y number
of users, etc. What can you say to something like that? :(

Still, if the authors/marketers had acted like rational adults and
weren't lying through their teeth about their capabilities and their
script's alleged benefits, I would have been much easier on them.
Wasn't long after the first review that Resig posted his missive about
avoiding CLJ at all costs because it was filled with unfair jerks (or
whatever). The fact that most of his users bought that for years gives
you an idea of the sort of "developers" something like jQuery attracts
(similar to the type of "investors" that Ponzi schemes and buy-real-
estate-for-no-money-down books attract). Some things never change.

Even funnier is that some of these pissed off users/friends/marketers
of jQuery posted links to the reviews to demonstrate... something.
Seems they wanted people to feel sorry for them; of course, they only
demonstrated their own naivete. A more rational explanation for this
bonus coverage is that they were angry because they'd invested time
and money in jQuery, plastered it all over their CV and were worried
about diminished earning potential. Somehow, they want to push the
idea that I'm the angry one; but, oddly enough, I'm quite happy about
jQuery's continuous buffoonery (it's certainly paid to sell it
short). :)

Recently some jackass in the Ext JS forums "fended off" a scathing
review of Sencha Touch by posting a link to a years-old jQuery review.
No answer to the many troubling issues raised in the review, other
than he didn't understand a word of it (!), just a painfully
transparent misdirection. A couple of people responded that they would
like to see better handling of feedback by the company and were buried
in a bunch of marketing babble (e.g. we just love *constructive*
feedback!). They were then accused of being "sock puppets" (as if I am
the only one on the planet that sees through their BS). And seeing all
of the echos of Usenet posts on various Websites made them wonder why
I was going to so much trouble to smear their good names. :(

Yet there are still ostensibly intelligent, experienced (in other
languages and disciplines) programmers out there that fall for this
stuff. I mean, look at all of those happy users; can't be bad. Still,
give them alternatives and they will figure it out soon enough.

[toc] | [prev] | [next] | [standalone]

#12687

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".

> 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.? :)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web