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

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

jQuery and autosuggest and more

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

Contents

  jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-15 08:19 -0700
    Re: jQuery and autosuggest and more Gregor Kofler <usenet@gregorkofler.com> - 2012-09-15 20:02 +0200
      Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-15 12:11 -0700
        Re: jQuery and autosuggest and more Gregor Kofler <usenet@gregorkofler.com> - 2012-09-15 23:38 +0200
          Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-15 15:48 -0700
            Re: jQuery and autosuggest and more Gregor Kofler <usenet@gregorkofler.com> - 2012-09-16 23:15 +0200
    Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-17 12:51 -0700
      Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-17 14:42 -0700
        Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-17 15:38 -0700
          Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-17 16:31 -0700
            Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-17 17:01 -0700
              Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-17 17:58 -0700
                Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-17 18:19 -0700
                  Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-17 19:47 -0700
                    Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-17 22:17 -0700
                      Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-17 22:32 -0700
                        Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-17 23:22 -0700
                          Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-17 23:59 -0700
                        Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-18 02:08 -0700
                      Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-18 05:46 -0700
                        Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-18 07:50 -0700
                      Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-18 08:07 -0700
                        Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-18 12:03 -0700
                          Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-18 12:58 -0700
                            Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-18 13:42 -0700
                              Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-18 14:24 -0700
                                Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-18 15:34 -0700
                                  Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-18 15:40 -0700
                                    Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-19 09:30 -0700
                                      Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-19 11:45 -0700
            Re: jQuery and autosuggest and more Christoph Becker <cmbecker69@gmx.de> - 2012-09-18 02:04 +0200
              Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-17 17:52 -0700
                Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-17 18:17 -0700
                  Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-17 19:45 -0700
                Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-17 19:44 -0700
              Re: jQuery and autosuggest and more justaguy <lichunshen84@gmail.com> - 2012-09-17 18:00 -0700
              Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-17 20:12 -0700
                Re: jQuery and autosuggest and more Christoph Becker <cmbecker69@gmx.de> - 2012-09-19 01:54 +0200
                  Re: jQuery and autosuggest and more "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-09-18 17:45 -0700
                    Re: jQuery and autosuggest and more Christoph Becker <cmbecker69@gmx.de> - 2012-09-19 16:46 +0200
                      Re: jQuery and autosuggest and more Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-20 21:35 +0200
                        Re: jQuery and autosuggest and more Christoph Becker <cmbecker69@gmx.de> - 2012-09-21 17:14 +0200
                        Re: jQuery and autosuggest and more Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-21 19:05 +0200
                  Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-18 18:00 -0700
      Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-17 19:54 -0700
        Re: jQuery and autosuggest and more "S.T." <anon@anon.com> - 2012-09-17 22:53 -0700
          Re: jQuery and autosuggest and more David Mark <dmark.cinsoft@gmail.com> - 2012-09-17 23:34 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#15970

On Sep 18, 8:46 am, justaguy <lichunshe...@gmail.com> wrote:
> On Sep 18, 1:17 am, "S.T." <a...@anon.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 9/17/2012 7:47 PM, justaguy wrote:
>
> > > How do make multiple input fiels/elements using autosuggest?
>
> > > The following syntax is incorrect:
> > > $( "#tags","#tags2" ).autocomplete({
> > >    ...
> > > });
>
> > > And the following is correct but inefficient, what if I have 10 fields
> > > or 20 fields that need autosuggest
> > > $( "#tags").autocomplete({
> > >    ...
> > > });
>
> > > $( "#tags2" ).autocomplete({
> > >    ...
> > > });
>
> > > Thoughts?  Thanks
>
> > It's a little difficult to answer without a clearer idea of the end
> > goal, but as an example you can set the autocomplete based on one
> > selector - we'll use class name 'autocomplete' here, then change the
> > data source of that autocomplete event based on focus() events using the
> > data() method tied to a hard-coded attribute in the various inputs. See:http://jsfiddle.net/yrPRW/
>
> Ok, that makes sense, thank you.  But I ran into a problem when I
> attempted to implement it with a project.  That is, with identical
> code except field id difference and changed accordingly in the
> function references.
>
> The error msg is:
> TypeError: $("#productid").autocomplete is not a function
> [Break On This Error]
> select: function(event, ui) {
>
> Notes:
> I have a field with id of "productid" in the HTML form and have
> replaced "tags" references in the jQuery function references to
> "productid".  What could have caused it to misfire?
>
> Many thanks.

Pls ignore it.  Something quirky about it. The js code has to be below
HTML form.

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

#15971

On Sep 18, 1:17 am, "S.T." <a...@anon.com> wrote:
> On 9/17/2012 7:47 PM, justaguy wrote:
>
>
>
>
>
>
>
>
>
> > How do make multiple input fiels/elements using autosuggest?
>
> > The following syntax is incorrect:
> > $( "#tags","#tags2" ).autocomplete({
> >    ...
> > });
>
> > And the following is correct but inefficient, what if I have 10 fields
> > or 20 fields that need autosuggest
> > $( "#tags").autocomplete({
> >    ...
> > });
>
> > $( "#tags2" ).autocomplete({
> >    ...
> > });
>
> > Thoughts?  Thanks
>
> It's a little difficult to answer without a clearer idea of the end
> goal, but as an example you can set the autocomplete based on one
> selector - we'll use class name 'autocomplete' here, then change the
> data source of that autocomplete event based on focus() events using the
> data() method tied to a hard-coded attribute in the various inputs. See:http://jsfiddle.net/yrPRW/

Sorry, I think there's some misunderstanding about this requirement.
That is, I'd like to use the same data set to autosuggest for several
FORM elements.  For instance, we have a product list, so, field1,
field2... fieldN would all show the entire same product list.
The above example is nice but but after form submission we get only
one field data.

I'm thinking loud here... is there a way to bind or assign {current
DOM element} to ui item value?  If yes, then each field would have its
own value when the form is submitted.

Thanks.

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

#15972

On 9/18/2012 8:07 AM, justaguy wrote:
>>
>> It's a little difficult to answer without a clearer idea of the end
>> goal, but as an example you can set the autocomplete based on one
>> selector - we'll use class name 'autocomplete' here, then change the
>> data source of that autocomplete event based on focus() events using the
>> data() method tied to a hard-coded attribute in the various inputs. See:http://jsfiddle.net/yrPRW/
>
> Sorry, I think there's some misunderstanding about this requirement.
> That is, I'd like to use the same data set to autosuggest for several
> FORM elements.  For instance, we have a product list, so, field1,
> field2... fieldN would all show the entire same product list.
> The above example is nice but but after form submission we get only
> one field data.

This help?

http://jsfiddle.net/6kq9a/

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

#15974

On Sep 18, 3:02 pm, "S.T." <a...@anon.com> wrote:
> On 9/18/2012 8:07 AM, justaguy wrote:
>
>
>
> >> It's a little difficult to answer without a clearer idea of the end
> >> goal, but as an example you can set the autocomplete based on one
> >> selector - we'll use class name 'autocomplete' here, then change the
> >> data source of that autocomplete event based on focus() events using the
> >> data() method tied to a hard-coded attribute in the various inputs. See:http://jsfiddle.net/yrPRW/
>
> > Sorry, I think there's some misunderstanding about this requirement.
> > That is, I'd like to use the same data set to autosuggest for several
> > FORM elements.  For instance, we have a product list, so, field1,
> > field2... fieldN would all show the entire same product list.
> > The above example is nice but but after form submission we get only
> > one field data.
>
> This help?
>
> http://jsfiddle.net/6kq9a/

Very close.  I like the Simple Data option but we still need select
method because we need to automatically send the form submission upon
select.  What impedes me is this:
how to map {current DOM element/field}.value to ui item value (ok with
the express on the right
but not on the left)
The {current DOM element/field}.value could be "product name 1", could
be "product name 2" etc.
// the following syntax won't work
this.value=ui.item.value;
// then submit the form like
form.submit();

Thanks.

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

#15977

On Sep 18, 3:58 pm, justaguy <lichunshe...@gmail.com> wrote:
> On Sep 18, 3:02 pm, "S.T." <a...@anon.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 9/18/2012 8:07 AM, justaguy wrote:
>
> > >> It's a little difficult to answer without a clearer idea of the end
> > >> goal, but as an example you can set the autocomplete based on one
> > >> selector - we'll use class name 'autocomplete' here, then change the
> > >> data source of that autocomplete event based on focus() events using the
> > >> data() method tied to a hard-coded attribute in the various inputs. See:http://jsfiddle.net/yrPRW/
>
> > > Sorry, I think there's some misunderstanding about this requirement.
> > > That is, I'd like to use the same data set to autosuggest for several
> > > FORM elements.  For instance, we have a product list, so, field1,
> > > field2... fieldN would all show the entire same product list.
> > > The above example is nice but but after form submission we get only
> > > one field data.
>
> > This help?
>
> >http://jsfiddle.net/6kq9a/
>
> Very close.  I like the Simple Data option but we still need select
> method because we need to automatically send the form submission upon
> select.  What impedes me is this:
> how to map {current DOM element/field}.value to ui item value (ok with
> the express on the right
> but not on the left)
> The {current DOM element/field}.value could be "product name 1", could
> be "product name 2" etc.
> // the following syntax won't work
> this.value=ui.item.value;
> // then submit the form like
> form.submit();
>
> Thanks.

Actually,
 this.value=ui.item.value;
works.  Previously, I missed something... bomber.

Thanks.

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

#15979

On Sep 18, 4:42 pm, justaguy <lichunshe...@gmail.com> wrote:
> On Sep 18, 3:58 pm, justaguy <lichunshe...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 18, 3:02 pm, "S.T." <a...@anon.com> wrote:
>
> > > On 9/18/2012 8:07 AM, justaguy wrote:
>
> > > >> It's a little difficult to answer without a clearer idea of the end
> > > >> goal, but as an example you can set the autocomplete based on one
> > > >> selector - we'll use class name 'autocomplete' here, then change the
> > > >> data source of that autocomplete event based on focus() events using the
> > > >> data() method tied to a hard-coded attribute in the various inputs. See:http://jsfiddle.net/yrPRW/
>
> > > > Sorry, I think there's some misunderstanding about this requirement.
> > > > That is, I'd like to use the same data set to autosuggest for several
> > > > FORM elements.  For instance, we have a product list, so, field1,
> > > > field2... fieldN would all show the entire same product list.
> > > > The above example is nice but but after form submission we get only
> > > > one field data.
>
> > > This help?
>
> > >http://jsfiddle.net/6kq9a/
>
> > Very close.  I like the Simple Data option but we still need select
> > method because we need to automatically send the form submission upon
> > select.  What impedes me is this:
> > how to map {current DOM element/field}.value to ui item value (ok with
> > the express on the right
> > but not on the left)
> > The {current DOM element/field}.value could be "product name 1", could
> > be "product name 2" etc.
> > // the following syntax won't work
> > this.value=ui.item.value;
> > // then submit the form like
> > form.submit();
>
> > Thanks.
>
> Actually,
>  this.value=ui.item.value;
> works.

Near as you can tell, it *appears* to work. But with which version of
jQuery, which version of jQuery UI and what browser/configuration? In
short, your observation is insignificant.

Look how many times the "value" attribute/property is mentioned here:

http://stackoverflow.com/questions/5874652/prop-vs-attr/5876747

...and deep within this pile of scripts lies code that reads and
writes the "value" property and/or attribute. Are you really
comfortable placing blind faith in such code?

So what have you learned? Trying to figure out the DOM through trial
and error, using a dodgy stack of scripts like jQuery UI is a very
hard way to go. May lead to instant gratification once you happen on a
pattern that seems to work, but that quickly turns to disappointment
when your chosen black boxes are shaken up by their authors. In the
case of jQuery scripts, this happens all the time as the creators are
also trying to figure out the DOM through trial and error. ;)

Instead of trying to be a Jack of all trades, you might consider
writing your application with just HTML and CSS and then delegate
responsibility for the scripted enhancements that you are clearly
incapable of doing on your own. As a bonus, your application will then
work when scripting and/or the required host features are missing or
broken.

http://en.wikipedia.org/wiki/Cross-browser

If you listen to your fellow jQuery enthusiasts, you'll get the idea
that jQuery UI works in virtually every browser (save for a handful of
"older" mobile browsers) and for every user (nobody disables
scripting, right?).

Here's just one example:

http://en.wikipedia.org/wiki/Opera_Mini

"On March 2012, Opera reported 168 million unique Opera Mini active
users and 117 billion page views served during that month. This
represented an 60.4% increase since March 2011."

This is a rare case where browser usage statistics can be taken at
face value. Opera certainly knows how many users they have and how
many pages they peruse per month.

Pay particular attention to this section:

http://en.wikipedia.org/wiki/Opera_Mini#JavaScript_support

"Opera Mini has limited support for JavaScript. Before the page is
sent to the mobile device, its onLoad events are fired and all scripts
are allowed a maximum of two seconds to execute. The setInterval and
setTimeout functions are disabled, so scripts designed to wait a
certain amount of time before executing will not execute at all."

More importantly, assuming your stack of scripts even makes it to the
browser:

"After the scripts have finished or the timeout is reached, all
scripts are stopped and the page is compressed and sent to the mobile
device. Once on the device, only a handful of events are allowed to
trigger scripts:

onUnload: Fires when the user navigates away from a page
onSubmit: Fires when a form is submitted
onChange: Fires when the value of an input control is changed
onClick: Fires when an element is clicked"

Now, your average deluded jQuery abuser will shrug that off with "we
don't care about Opera Mini", but that's missing the point. This
represents one example that clearly contradicts the assertion that the
bloated jQuery UI framework will inconvenience only a handful of users
who are stuck with "older" mobile browsers. Furthermore, you've got to
consider whether it is prudent to flip off 168 million (and growing)
users.

May seem like a bitter pill, but it represents reality. I recommend
you swallow it and forget you ever heard about jQuery. This is the
same advice I'd have given if you'd asked five years ago. Such advice
looks better every year and it seems a good bet that trend will
continue. ;)

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

#15980

On 9/18/2012 2:24 PM, David Mark wrote:
> Furthermore, you've got to
> consider whether it is prudent to flip off 168 million (and growing)
> users.

http://i.imgur.com/N0Rsb.png

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

#15981

On Sep 18, 6:34 pm, "S.T." <a...@anon.com> wrote:
> On 9/18/2012 2:24 PM, David Mark wrote:
>
> > Furthermore, you've got to
> > consider whether it is prudent to flip off 168 million (and growing)
> > users.
>
> http://i.imgur.com/N0Rsb.png

What a pretty picture! :)

Now go back and read the parts you snipped. ;)

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

#16001

On 9/18/2012 3:40 PM, David Mark wrote:
> What a pretty picture! :)
>
> Now go back and read the parts you snipped. ;)

I read it. Same as always - total disconnect from the marketplace 
coupled with an over-valued opinion of your own understanding results in 
really bad advice.

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

#16007

On Sep 19, 12:30 pm, "S.T." <a...@anon.com> wrote:
> On 9/18/2012 3:40 PM, David Mark wrote:
>
> > What a pretty picture! :)
>
> > Now go back and read the parts you snipped. ;)
>
> I read it. Same as always - total disconnect from the marketplace
> coupled with an over-valued opinion of your own understanding results in
> really bad advice.

You must have missed the bit about how jQuery abusers would react to
such an example. I suggest you read it again. ;)

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

#15943

justaguy wrote:
> What am I missing here?  Many thanks.

You probably want:

	$( "#tags" ).autocomplete({
	   select: function(event, ui) {
		console.log(ui.item);
	   }
	});

And IMHO that's the /most/ basic problem with jQuery and similar
frameworks: they allow one to create amazing results by some trial and
error without even grasping the basics, i.e. what are the semantics of
the code.

About a year ago I've written a simple form generator using jQuery --
without jQuery I couldn't have done it.  But as I wasn't able to grasp
the basics of ECMAScript back then, the code is totally crappy, and I
vainly hope, that I'll never have to correct this...

So, even if using jQuery and the loads of jQuery plugins is very
tempting, you might reconsider this approach, and learn basic ECMAScript
*first*. *Then* you might go on using whatever framework you prefer.

-- 
Christoph M. Becker

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

#15944

On 9/17/2012 5:04 PM, Christoph Becker wrote:

>
> And IMHO that's the /most/ basic problem with jQuery and similar
> frameworks: they allow one to create amazing results by some trial and
> error without even grasping the basics, i.e. what are the semantics of
> the code.
>
> About a year ago I've written a simple form generator using jQuery --
> without jQuery I couldn't have done it.  But as I wasn't able to grasp
> the basics of ECMAScript back then, the code is totally crappy, and I
> vainly hope, that I'll never have to correct this...
>
> So, even if using jQuery and the loads of jQuery plugins is very
> tempting, you might reconsider this approach, and learn basic ECMAScript
> *first*. *Then* you might go on using whatever framework you prefer.
>

You make a valid point but it's a question of resources. Does someone 
who primarily does design and/or server-side really need to know, as in 
thoroughly know, JavaScript just to enhance the UI here and there and do 
some AJAX stuff? Certainly better to know a language than to not, but in 
my experience JavaScript's learning curve starts rather flat then gets 
steep - and the stuff designers care about nowadays (reliable 
cross-browser XHR and DOM manipulation) is towards the top of the steep 
section.

As browsers continue to head towards standards that curve will flatten 
but, for now, the return on investment just isn't there for most. Not 
when one can continue to improve design skills, writing skills, image 
retouching, typography, server-side and SQL efficiency, etc. instead of 
trying to master some of the more complicated aspects of JS. And not 
when their are more-than-adequate crutches like jQuery that provide a 
consistent API for others sharing the workload and handle the 
complicated stuff done behind the scenes - even if those crutches are 
flawed under some obscure scenarios.

There is some truly, truly awful code out there using jQuery - failures 
to cache heavily used objects, crazy traversing of the DOM and so on. 
Dead simple to find on the web. But even here, the DOM's they're working 
against are usually so simple that the horribly inefficient code doesn't 
even matter in most cases. It would be nice if more designers and 
server-side scripters had a solid JS background but hardly seems like 
it's holding the web back.

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

#15948

On Sep 17, 8:51 pm, "S.T." <a...@anon.com> wrote:
> On 9/17/2012 5:04 PM, Christoph Becker wrote:
>
>
>
> > And IMHO that's the /most/ basic problem with jQuery and similar
> > frameworks: they allow one to create amazing results by some trial and
> > error without even grasping the basics, i.e. what are the semantics of
> > the code.
>
> > About a year ago I've written a simple form generator using jQuery --
> > without jQuery I couldn't have done it.  But as I wasn't able to grasp
> > the basics of ECMAScript back then, the code is totally crappy, and I
> > vainly hope, that I'll never have to correct this...
>
> > So, even if using jQuery and the loads of jQuery plugins is very
> > tempting, you might reconsider this approach, and learn basic ECMAScript
> > *first*. *Then* you might go on using whatever framework you prefer.
>
> You make a valid point but it's a question of resources. Does someone
> who primarily does design and/or server-side really need to know, as in
> thoroughly know, JavaScript just to enhance the UI here and there and do
> some AJAX stuff? Certainly better to know a language than to not, but in
> my experience JavaScript's learning curve starts rather flat then gets
> steep - and the stuff designers care about nowadays (reliable
> cross-browser XHR and DOM manipulation) is towards the top of the steep
> section.
>
> As browsers continue to head towards standards that curve will flatten
> but, for now, the return on investment just isn't there for most. Not
> when one can continue to improve design skills, writing skills, image
> retouching, typography, server-side and SQL efficiency, etc. instead of
> trying to master some of the more complicated aspects of JS. And not
> when their are more-than-adequate crutches like jQuery that provide a
> consistent API for others sharing the workload and handle the
> complicated stuff done behind the scenes - even if those crutches are
> flawed under some obscure scenarios.
>
> There is some truly, truly awful code out there using jQuery - failures
> to cache heavily used objects, crazy traversing of the DOM and so on.
> Dead simple to find on the web. But even here, the DOM's they're working
> against are usually so simple that the horribly inefficient code doesn't
> even matter in most cases. It would be nice if more designers and
> server-side scripters had a solid JS background but hardly seems like
> it's holding the web back.

I completely agree.

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

#15951

On Sep 17, 9:17 pm, justaguy <lichunshe...@gmail.com> wrote:
> On Sep 17, 8:51 pm, "S.T." <a...@anon.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 9/17/2012 5:04 PM, Christoph Becker wrote:
>
> > > And IMHO that's the /most/ basic problem with jQuery and similar
> > > frameworks: they allow one to create amazing results by some trial and
> > > error without even grasping the basics, i.e. what are the semantics of
> > > the code.
>
> > > About a year ago I've written a simple form generator using jQuery --
> > > without jQuery I couldn't have done it.  But as I wasn't able to grasp
> > > the basics of ECMAScript back then, the code is totally crappy, and I
> > > vainly hope, that I'll never have to correct this...
>
> > > So, even if using jQuery and the loads of jQuery plugins is very
> > > tempting, you might reconsider this approach, and learn basic ECMAScript
> > > *first*. *Then* you might go on using whatever framework you prefer.
>
> > You make a valid point but it's a question of resources. Does someone
> > who primarily does design and/or server-side really need to know, as in
> > thoroughly know, JavaScript just to enhance the UI here and there and do
> > some AJAX stuff? Certainly better to know a language than to not, but in
> > my experience JavaScript's learning curve starts rather flat then gets
> > steep - and the stuff designers care about nowadays (reliable
> > cross-browser XHR and DOM manipulation) is towards the top of the steep
> > section.
>
> > As browsers continue to head towards standards that curve will flatten
> > but, for now, the return on investment just isn't there for most. Not
> > when one can continue to improve design skills, writing skills, image
> > retouching, typography, server-side and SQL efficiency, etc. instead of
> > trying to master some of the more complicated aspects of JS. And not
> > when their are more-than-adequate crutches like jQuery that provide a
> > consistent API for others sharing the workload and handle the
> > complicated stuff done behind the scenes - even if those crutches are
> > flawed under some obscure scenarios.
>
> > There is some truly, truly awful code out there using jQuery - failures
> > to cache heavily used objects, crazy traversing of the DOM and so on.
> > Dead simple to find on the web. But even here, the DOM's they're working
> > against are usually so simple that the horribly inefficient code doesn't
> > even matter in most cases. It would be nice if more designers and
> > server-side scripters had a solid JS background but hardly seems like
> > it's holding the web back.
>
> I completely agree.

Of course you do. :)

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

#15950

On Sep 17, 8:51 pm, "S.T." <a...@anon.com> wrote:
> On 9/17/2012 5:04 PM, Christoph Becker wrote:
>
>
>
> > And IMHO that's the /most/ basic problem with jQuery and similar
> > frameworks: they allow one to create amazing results by some trial and
> > error without even grasping the basics, i.e. what are the semantics of
> > the code.
>
> > About a year ago I've written a simple form generator using jQuery --
> > without jQuery I couldn't have done it.  But as I wasn't able to grasp
> > the basics of ECMAScript back then, the code is totally crappy, and I
> > vainly hope, that I'll never have to correct this...
>
> > So, even if using jQuery and the loads of jQuery plugins is very
> > tempting, you might reconsider this approach, and learn basic ECMAScript
> > *first*. *Then* you might go on using whatever framework you prefer.
>
> You make a valid point but it's a question of resources. Does someone
> who primarily does design and/or server-side really need to know, as in
> thoroughly know, JavaScript just to enhance the UI here and there and do
> some AJAX stuff?

Of course. Regardless of what canned scripts you include, you still
have to write JS.


> Certainly better to know a language than to not, but in
> my experience JavaScript's learning curve starts rather flat then gets
> steep - and the stuff designers care about nowadays (reliable
> cross-browser XHR and DOM manipulation) is towards the top of the steep
> section.

That's ridiculous. The FAQ has had the basic cross-browser XHR code
for many years. And what sort of DOM manipulation?

>
> As browsers continue to head towards standards that curve will flatten
> but, for now, the return on investment just isn't there for most.

You have missed the boat. If you wrote cross-browser code (unlike the
crap found in jQuery), you could simply serve static content to legacy
IE versions. Other than that, you have very little to worry about.
It's just that projects like jQuery make it seem so hard (part of
their marketing).

> Not
> when one can continue to improve design skills, writing skills, image
> retouching, typography, server-side and SQL efficiency, etc. instead of
> trying to master some of the more complicated aspects of JS.

Is this an argument or your CV? Regardless, none of that adds anything
to the discussion of jQuery.

> And not
> when their are more-than-adequate crutches like jQuery that provide a
> consistent API for others sharing the workload and handle the
> complicated stuff done behind the scenes - even if those crutches are
> flawed under some obscure scenarios.

You just have no clue what you are talking about. You don't know what
"complicated stuff" jQuery is handling, nor do you have any idea when/
where/how it will make the stuff more complicated. Google my name +
"Javascript tips". Invest an hour or so reading and you'll realize
that jQuery isn't helping you at all with any of the "complicated
stuff". Furthermore, the (terrible) API that you've professed to like
in the past is trivial to recreate. It's done (much better) in My
Library, which has been out there for perusal for almost five years.

If you continue to use jQuery as a (broken) crutch, you'll never learn
anything. That's why you continue to see basic DOM scripting as
"obscure" and "complicated stuff".

>
> There is some truly, truly awful code out there using jQuery - failures

If you were qualified to make such an assessment (however accurate),
you'd know that there is some "truly, truly awful" code *inside* of
jQuery, as well as an inappropriate API that just confuses the hell
out of basic issues. Again, read my tips (and if already have, read
them again).

> to cache heavily used objects, crazy traversing of the DOM and so on.

Crazy. :)

> Dead simple to find on the web.

Dead simple. Should be right up your alley. :)

> But even here, the DOM's they're working
> against are usually so simple that the horribly inefficient code doesn't
> even matter in most cases.

Except that the user had to download it, the agent (often a battery-
powered mobile device these days) had to parse and execute it and
(surprise) most of it is unneeded BS. You'd know that if you'd paid
attention the last few years.

> It would be nice if more designers and
> server-side scripters had a solid JS background but hardly seems like
> it's holding the web back.

It's made a colossal, unwieldy mess of the Web (and scrambled the
brains of prospective JS developers). You simply have no frame of
reference.

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

#15947

On Sep 17, 8:03 pm, Christoph Becker <cmbecke...@gmx.de> wrote:
> justaguy wrote:
> > What am I missing here?  Many thanks.
>
> You probably want:
>
>         $( "#tags" ).autocomplete({
>            select: function(event, ui) {
>                 console.log(ui.item);
>            }
>         });
>
> And IMHO that's the /most/ basic problem with jQuery and similar
> frameworks: they allow one to create amazing results by some trial and
> error without even grasping the basics, i.e. what are the semantics of
> the code.
>
> About a year ago I've written a simple form generator using jQuery --
> without jQuery I couldn't have done it.  But as I wasn't able to grasp
> the basics of ECMAScript back then, the code is totally crappy, and I
> vainly hope, that I'll never have to correct this...
>
> So, even if using jQuery and the loads of jQuery plugins is very
> tempting, you might reconsider this approach, and learn basic ECMAScript
> *first*. *Then* you might go on using whatever framework you prefer.
>
> --
> Christoph M. Becker

console.log(ui.item);

Yeah, that's the key debugging thing for what I need here.  I got it
working per my most recent post.  Thanks.

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

#15955

On Sep 17, 8:03 pm, Christoph Becker <cmbecke...@gmx.de> wrote:
> justaguy wrote:
> > What am I missing here?  Many thanks.
>
> You probably want:
>
>         $( "#tags" ).autocomplete({
>            select: function(event, ui) {
>                 console.log(ui.item);
>            }
>         });
>
> And IMHO that's the /most/ basic problem with jQuery and similar
> frameworks: they allow one to create amazing results by some trial and
> error without even grasping the basics, i.e. what are the semantics of
> the code.
>
> About a year ago I've written a simple form generator using jQuery --
> without jQuery I couldn't have done it.  But as I wasn't able to grasp
> the basics of ECMAScript back then, the code is totally crappy, and I
> vainly hope, that I'll never have to correct this...
>
> So, even if using jQuery and the loads of jQuery plugins is very
> tempting, you might reconsider this approach, and learn basic ECMAScript
> *first*. *Then* you might go on using whatever framework you prefer.
>

You need to learn both the language and the DOM. The libraries and
frameworks paint the DOM as a "terrible" set of interfaces, but then
they are trying to sell you on their wonderful "normalization"
solutions. The libraries and frameworks do nothing for the language,
which still must be used when programming with these things.

As for "trial and error", that's exactly what is done with these
things. It's not programming to rearrange patterns of code until they
seem to work (typically in just the browsers on hand).

And ultimately, as anyone with experience will tell you, once you
reach a certain point on the learning curve, you realize that most of
the libraries and frameworks are written by developers that don't know
the language or the DOM well enough to help you.

For example, reading jQuery's code is absolutely cringe-inducing. Five
minutes is enough to realize it can only hinder you. Same for
Mootools, Dojo and the rest of the usual suspects.

Why would this be? Because experienced developers know that monolithic
libraries and frameworks are the exact opposite of what is required
for competent solutions. This is more true today than six years ago
when these things started coming out of the woodwork. So it makes
sense that most of experienced developers stay away from such efforts.
Furthermore, it's very hard to gain practical experience monkeying
around on one of these projects as most of your feedback will come
from fellow inexperienced developers.

The proof is simple: if these things were time-savers, they wouldn't
require endless maintenance. Bad assumptions in the code invariably
lead to unexpected results. These results may be very hard to spot and
you can't rely on user feedback to find them. All you can do is
periodically "upgrade" a large mess of complicated JS and cross your
fingers that the goofs behind these things have *finally* figured out
how to write cross-browser scripts. It's programming by (somebody
else's) crystal ball.

http://en.wikipedia.org/wiki/Cross-browser

Multi-browser designs lead to endless tinkering, which leads to
perpetually unstable projects. Cross-browser designs give you the best
chance of avoiding such instability and therefore save time in the
long run. And as virtually none of the "popular" libraries and
frameworks have ever been cross-browser (though many claim to be),
their dubious results over the last half-dozen years were entirely
predictable.

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

#15983

David Mark wrote:
> You need to learn both the language and the DOM.

Thank you for clarifying this. :-)  My wording was mistaken, as I meant
not the language (ECMAScript), but in fact the hosting environment
(DOM).  Even if jQuery gives some functions such as jQuery.map(), which
IMHO should be available in ECMAScript "directly".

-- 
Christoph M. Becker

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

#15984

On Sep 18, 6:53 pm, Christoph Becker <cmbecke...@gmx.de> wrote:
> David Mark wrote:
> > You need to learn both the language and the DOM.
>
> Thank you for clarifying this. :-)  My wording was mistaken, as I meant
> not the language (ECMAScript), but in fact the hosting environment
> (DOM).  Even if jQuery gives some functions such as jQuery.map(), which
> IMHO should be available in ECMAScript "directly".

Array.map() exists in JavaScript 1.6+

Array.prototype.map() is defined in the current ECMAScript standard
<http://es5.github.com/#x15.4.4.19>

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

#15998

Michael Haufe (TNO) wrote:
> Array.map() exists in JavaScript 1.6+
> 
> Array.prototype.map() is defined in the current ECMAScript standard
> <http://es5.github.com/#x15.4.4.19>

Thanks for the correction.  I was not yet aware of the ECMAscript 5
improvements regarding applicative programming -- the set seems quite
complete. :-)

BTW: I wanted to look up browser compatibility information on
<https://developer.mozilla.org/>, but the DNS lookup fails.  Has anybody
some information about that?

-- 
Christoph M. Becker

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web