jQuery vs. My Library
in [JavaScript]
|
From: Scott Sauyet on 8 Mar 2010 09:55 On Mar 6, 4:45 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Scott Sauyet wrote: > > David Mark wrote: > >> Scott Sauyet wrote: > >>> Things like this are very convenient: > >>> select("div.navigation a:not(li.special a)"); > >> Honestly, that looks ludicrous to me. > > > Okay, it might look that way to you. To me it is a very concise and > > intuitive way to say "select all the anchor elements that are inside > > divs with a class of navigation but are not inside list items with a > > class of special, and by the way, return them in document order, > > please." That was the requirement. > > The question remains, though, did the requirement make sense in the first > place? Was it really not possible to solve this problem differently, for > example with event bubbling, with using the CSS cascade, with using > standards-compliant event-handler attributes, or a combination of them? > And then, is the approach that had been chosen to meet the requirement more > or at least equally reliable than the alternatives? [ ... ] These, of course, are useful and important questions. I'm bothered, though, that a number of people here seem to feel they know the answers to them in the abstract without any knowledge of specifics of various situations. There seems to be a consensus among some of the regulars in c.l.j.s. that CSS selector engines are a bad idea; I'm not sure of the basis for that consensus. but it seems to be strong enough that people are willing to assume those who disagree have misunderstood either their own requirements or have failed to consider alternatives. There seems to be no room for the possibility that people have the requirements right, understand the alternatives, and choose to use selector engines. I'm reminded of when I came aboard a Java project just after a consultant had left. He was supposed to be an expert in Object- oriented development and design. He had radically reworked various sections of code, trying to fix code smells he saw. But he did so blindly, following some rote rules that might be fine in the abstract, but didn't always apply. One of his "code smells" was that OO systems should never need "switch" statements. He methodically went through the code base, adding little helper classes (this was before "enum" in Java) to replace the switch statements. In the end, he managed to replace a handful of poorly conceived switch statements with better designs. But he also replaced ten times as many switch statements with code that was longer, less readable, less performant, and far less maintainable than it started out. The trouble was that the system had been well-designed, and the choice to use a switch statement was made by people who usually did understand the trade-offs made. Sure, there have been times when I've used selector engines when there were other reasonable alternatives. But there are plenty of times when event delegation or other alternatives were not practical or even possible, times when -- with or without a selector engine -- I needed to operate on a collection of elements in the document. I'm wondering if people here regularly work in fairly ideal environments where they're in charge of all the mark-up and all the CSS as well as all the JS used. While I'm sometimes in that situation, it's much more common for me to be trying to squeeze some behavior into existing HTML/CSS, often interspersed with existing JS. It's often dictated by the project whether I can use inline JS. Often a JS library has been chosen, and I must use it. Often parts of my page are generated by black box systems. Is this sort of environment unusual here? -- Scott
From: Jorge on 8 Mar 2010 13:17 On Mar 7, 6:31 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > (...) I imagine the analysis > is much harder to do when global variables or global objects > are involved.(...) I wonder why you and Lasse keep saying this. ISTM that once the JS's single thread of execution enters that while () {} nothing is going to interrupt it, so it's safe to assume that nothing but the code inside the "while" is going to touch them (the globals), isn't it so ? -- Jorge.
From: Lasse Reichstein Nielsen on 8 Mar 2010 14:04 Jorge <jorge(a)jorgechamorro.com> writes: > On Mar 7, 6:31�pm, Antony Scriven <adscri...(a)gmail.com> wrote: >> (...) I imagine the analysis >> is much harder to do when global variables or global objects >> are involved.(...) > > I wonder why you and Lasse keep saying this. ISTM that once the JS's > single thread of execution enters that while () {} nothing is going to > interrupt it, so it's safe to assume that nothing but the code inside > the "while" is going to touch them (the globals), isn't it so ? Most of the time, yes. For certain: No. With global variables, any function call must be assumed to be able to change the value of any global variable - unless you do cross-function analysis. In Javascript, cross-function analysis is *hard* because functions are first class values, so function variables can vary. With ES5 getters and setters, any property access, including reading and writing global variables, can call a function that can change any global variable. On top of that, any object that sneaks into the loop might be coerced to a value by calling valueOf or toString on it - which can again change anything in the world. And any function called inside the loop, e.g., Math.floor, might have been overwritten by a malicious user. You really can't trust anything in Javascript except operators working on primitive values. This gives many, many cases where a simple one-function analysis must surrender, because it simply cannot guarantee anything about the usage of a global variable. On top of this, accessing global variables in browsers are likely to incur extra overhead from XSS security checks. In short: Don't use global variables in speed sensitive code. It's still not as bad as using eval or with, which means that you can pretty much not determine anything about the scope statically. And about the usage of any variable in scope of the eval. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Antony Scriven on 8 Mar 2010 14:35 On Mar 8, 6:17 pm, Jorge wrote: > On Mar 7, 6:31 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > > (...) I imagine the analysis [optimizing empty loops > > into a no-op] is much harder to do when global > > variables or global objects are involved.(...) > > I wonder why you and Lasse keep saying this. ISTM that > once the JS's single thread of execution Actually do you have a reference to the part in the standard that guarantees that? I can't for the life of me find it. I'm probably just being thick, sorry. > enters that while () {} nothing is going to interrupt it, > so it's safe to assume that nothing but the code inside > the "while" is going to touch them (the globals), isn't > it so ? Sorry, I was talking in more general terms. Consider for(i=0; i<5; ++i){} where 'i' is global. If 'i' is used at some point after the loop, then I'd expect the increments to take place. Whether 'i' is used at later is probably impossible to determine. It may also be inadvisable to replace the loop with 'i=5;' as an optimization. Certainly in Firefox you can do the following. this.watch('i', function(){ return 1000; }); for(i=0; i<5; ++i){} Thus changing 'i' here has a side effect. And then there's the case where the condition uses a global as well. for(i=0; i<imax; ++i){} I guess you could perform a run-time check on imax here. But if you don't know whether or not 'i' is going to be used later on it's probably pointless. --Antony
From: Jorge on 8 Mar 2010 17:09
On Mar 8, 8:35 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > On Mar 8, 6:17 pm, Jorge wrote: > > > On Mar 7, 6:31 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > > > > (...) I imagine the analysis [optimizing empty loops > > > into a no-op] is much harder to do when global > > > variables or global objects are involved.(...) > > > > I wonder why you and Lasse keep saying this. ISTM that > > once the JS's single thread of execution > > Actually do you have a reference to the part in the standard > that guarantees that? I can't for the life of me find it. > I'm probably just being thick, sorry. I can't find it either in the specs, but, have you ever seen one that isn't ? http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html -- Jorge. |