jQuery vs. My Library
in [JavaScript]
|
From: Jorge on 8 Mar 2010 17:27 On Mar 8, 8:04 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: > Jorge <jo...(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. Ok ok ok. Thanks. -- Jorge
From: Antony Scriven on 8 Mar 2010 17:39 On Mar 8, 10:09 pm, Jorge wrote: > 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 ? No. I was just wondering if the standard specifically mentioned the issue. --Antony
From: Stefan Weiss on 8 Mar 2010 18:26 On 08/03/10 23:39, Antony Scriven wrote: > On Mar 8, 10:09 pm, Jorge wrote: > > On Mar 8, 8:35 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > > On Mar 8, 6:17 pm, Jorge wrote: > > > > 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 ? > > No. I was just wondering if the standard specifically mentioned > the issue. --Antony Concurrency wasn't one of the design goals of JavaScript (or later ECMAScript), and the language lacks any support for access synchronization. It's possible that some implementations (ActionScript, maybe, or some of the CommonJS server-side environments) do support multiple threads, but I think they'd have to extend the language to make a real multi-threaded system feasible. AFAIK, all browser script engines have a single main thread, but recently various implementations of background threads have surfaced (web workers), which effectively makes JS development on these browsers potentially multi-threaded. The main difference to most other multi-threaded platforms is that one thread is privileged (i.e., has full access to the DOM), while the other threads are intended for secondary, background calculation tasks. They communicate via a message passing system instead of sharing access to variables and properties, which more or less bypasses the need for synchronization. -- stefan
From: David Mark on 9 Mar 2010 00:14 Scott Sauyet wrote: > 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. But the answers are so obvious if you have experience. > 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. Then you haven't been paying attention to the discussions (or the test results). The test results alone should tell you that they are a bad idea. When you see "major" libraries using UA sniffing, just to make their engines "work" with this year's major browsers (quotes indicate they still fail many tests) and fail even worse in last year's. That doesn't give you pause? Imagine if SQL got worse and worse every year until all of your queries failed (at least without constant maintenance to "keep up" with the database developers). > 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. They have. > 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 refuse to believe impossible things. :) > > I'm reminded of when I came aboard a Java project just after a > consultant had left. Here we go again. It's not just you. Everybody new here wants to change the world (usually with irrelevant examples involving other languages). > He was supposed to be an expert in Object- > oriented development and design. Lot of supposed experts out there. I'll give you that. > He had radically reworked various > sections of code, trying to fix code smells he saw. Code smells? > But he did so > blindly, following some rote rules that might be fine in the abstract, > but didn't always apply. That's his problem. What does this have to do with querying the DOM by CSS selectors? [...] > > 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. Even if you couldn't use event delegation, you didn't need to use CSS selectors. > > 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. And I'm wondering if you understand that that would be the only situation where selectors would have a shot. In other words, if you don't have complete control of your markup and script, forget the selectors. > 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. And you definitely can't use selectors in that situation. Think about it. > 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. You still don't have to use CSS selectors to query the DOM (or to work with collections of elements). Trust me. I've been doing this stuff forever (in every conceivable situation) and I _never_ use CSS selector queries.
From: Jorge on 9 Mar 2010 03:52
On Mar 9, 12:26 am, Stefan Weiss <krewech...(a)gmail.com> wrote: > On 08/03/10 23:39, Antony Scriven wrote: > > > On Mar 8, 10:09 pm, Jorge wrote: > > > On Mar 8, 8:35 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > > > On Mar 8, 6:17 pm, Jorge wrote: > > > > > 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 ? > > > No. I was just wondering if the standard specifically mentioned > > the issue. --Antony > > Concurrency wasn't one of the design goals of JavaScript (or later > ECMAScript), and the language lacks any support for access > synchronization. It's possible that some implementations (ActionScript, > maybe, or some of the CommonJS server-side environments) do support > multiple threads, but I think they'd have to extend the language to make > a real multi-threaded system feasible. > > AFAIK, all browser script engines have a single main thread, but > recently various implementations of background threads have surfaced > (web workers), which effectively makes JS development on these browsers > potentially multi-threaded. The main difference to most other > multi-threaded platforms is that one thread is privileged (i.e., has > full access to the DOM), while the other threads are intended for > secondary, background calculation tasks. They communicate via a message > passing system instead of sharing access to variables and properties, > which more or less bypasses the need for synchronization. Yep. But -just nitpicking a little bit- you prolly shouldn't really call a worker a thread as it shares no context with its parent. It's a completely separate process with a completely independent separate JS context with which you communicate only via JSON texts -messages- passing. -- Jorge. |