[Javascript] Javascript - Form value undefined

Tue Nov 11 12:50:01 CST 2003

I want me some of that!  H Magnusson has got a heck of a lot faster system (and/or data connection) than I do, or my primary customers have.  Any chance you can share some of the "zip" with us peasants?

In all seriousness, a single clean loop should run fairly quickly in any language (JavaScript, ASP, or whatever). What tends to bog things down is when folks write loops inside of loops inside of loops, sometimes creating millions of possible iterations
-- particularly onerous when they don't use embedded returns to exit as soon as appropriate conditions are met, but wait for the end of the outer loop to return.  [Bad programming practice in any language].

Also, some processes (such as createElement) tend to take substantially longer than a straight document.write(...) call, and embedding such things inside a 3000 iteration loop can cause an appreciable delay.  Similarly, when writing a wide table with lots
of columns, any iterative loop is likely to get exercised a lot when it is wrapped around every TD object.

In general, I would not equate the use of the ".all" construct with good programming practice, under any circumstances whatsoever.  I'm sure someone will come back with an absolutely sexy usage which can't be handled any other way, but I haven't seen one
yet -- and I've been coding in JavaScript practically since the first JavaScript-ready version of Netscape appeared.  [Probably before half of you guys were born].

It never hurts to clock your code (say, versus a blank page), and see how long your stuff takes to complete loading.  Execution is usually not a problem unless you are using a REALLY baroque coding methodology.  Most of my clients complain more about the
former than the latter -- particularly when I've included some Java applets in the mix.  But that's another story...

Thanks for the feedback.

-- Dave Lovering

Håkan Magnusson wrote:
> 
> Since creating, duplicating and then removing 3,000 separate nodes in
> the DOM takes less than a second on an average PC (pick your favorite
> browser), I doubt that form handling is the critical spot for
> optimization. Unless your form has 3,000+ elements that all require (a
> lot) more complex code than what the browsers is doing when creating,
> copying or moving within the DOM-tree, I can't see the use.
> 
> I'd say do the form checking correctly, not the fastest way around.
> Forms are one of the things that remain somewhat tricky even with todays
> "modern" (cough) browsers, so putting effort into creating them "the
> right way" is more important, all according to my humble opinion.
> 
> David Lovering wrote:
> > Re-reading my earlier remarks, it appears I left some of the context out of
> > the discussion.
> >
> > Yes, Chris is correct -- client side scripts run independently of the server
> > (thank God!).
> >
> > What I was thinking of in more general terms was the total "forms-handling
> > delay" which
> > includes the latency to download the Javascript in the first place, the time
> > for it to execute
> > on the client machine, and the time to validate and/or return the results to
> > the server once
> > the form has been completed and submitted for processing.  The first two
> > criteria will
> > depend on the number of JavaScript routines, their complexity, and the
> > intrinsic operation
> > time required to execute.
> >
> > Given that a big chunk of any JavaScript processing cycle will be largely
> > contingent on the
> > size and complexity of its major loops, doing anything to stream-line the
> > number of steps
> > and/or elements contained in these loops will be time well spent.  This is
> > one reason why I
> > generally discourage knee-jerk insertions of "document.forms[0].all" style
> > objects, particularly
> > when the invocation is followed immediately by a loop that checks EVERYTHING
> > inside
> > the .all object set.  If you've got a really gnarly form (like the IRS 1040
> > electronic tax form),
> > this could add a LONG delay.
> >
> > I would encourage developers to use a stop-watch to clock the
> > download/build/execution
> > cycle for their scripts, average it over many trials on different browsers
> > and/or OS platforms,
> > and develop a "working average" delay expectation.  A lot of "canned" build
> > environments
> > (like ASP and ColdFusion) look real sexy, but don't do well in real-time
> > clocked benchmarks.
> >
> > -- Dave Lovering
> >
> > ----- Original Message -----
> > From: "Chris Tifer" <christ at saeweb.com>
> > To: "[JavaScript List]" <javascript at LaTech.edu>
> > Sent: Tuesday, November 11, 2003 7:51 AM
> > Subject: Re: [Javascript] Javascript - Form value undefined
> >
> >
> >
> >>>This runs a LOT faster, particularly if your web page gets a lot of hits
> >>
> >>How would a client-side script run faster or slower depending on the
> >
> > number
> >
> >>of hits to a site? Everything is processed on individual's computers so
> >
> > site
> >
> >>traffic would mean absolutely nothing when determining execution speed.
> >
> > It's
> >
> >>all dependant on the client.
> >>
> >>Chris Tifer
> >>
> >>_______________________________________________
> >>Javascript mailing list
> >>Javascript at LaTech.edu
> >>https://lists.LaTech.edu/mailman/listinfo/javascript
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Javascript mailing list
> > Javascript at LaTech.edu
> > https://lists.LaTech.edu/mailman/listinfo/javascript
> >
> > .
> >
> 
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript