On Feb 17, 4:22 pm, SteelRing <steelr...@gmail.com> wrote:
> I would love to get to the bottom of all these and figure out cases of
> "recommended" and "bad" uses of jquery selector. I came across jquery
> a couple months ago and got excited with how easy it is to use this
> framework rather than doing getElementFromMyAss all over the page,
> typing that long syntax get my fingers tired too, pun intended.

If a bit of extra typing is the issue, it is easy to alias the more
long-winded methods.  If you are doing a lot of getElementById, you
should review your design, likely you can get the references you need
some other way.


> Pretty
> soon, however, I got to the point where speed and efficiency becomes a
> visible matter when the document gets large (mostly with table cells).
> Come to think of it, I may be working towards something similar to
> google docs spreadsheet apps, but not meant as spreadsheet, just a
> huge table with some interactivity. It downs on me that I cannot take
> selector methods lightly and should try to use the most efficient way
> on how jquery operates, even if it takes of redoing the underlying
> structure of the document so that I can take the most advantage of
> jquery methods.

Have you considered approaches like event delegation, or using the
event object associated with an event to get the references you need?

It is very rare that you can design something without any
consideration for efficiency.  A little time spent on optimising a
design (don't sweat the minutia, make sure the big things are right)
often has great benefits later.

There are a number of factors to understand and consider - typing less
code doesn't necessarily mean better or faster code, nor does it
reflect maintainability.  Extensive use of selectors is a sign of poor
design to me, there are usually much more efficient ways to do
things.


--
Rob

Reply via email to