As I said, Function does not do scope resolution except the global one so in
my opinion should be always preferred for JSON evaluations. Firefox does not
care about implicit returned value plus brackets plus scope, it simply
create the anonimous function doing a syntax check and returns errors only
JQuery.fn.forEach = Array.prototype.forEach || function(){ ... }; easy? :-)
On May 20, 2009 3:07 AM, "diogobaeder" wrote:
Matt,
I think your approach is usefull only if one wants to create a new
jQuery method... because checking everytime if forEach method exists
is not easily maintainable...
Function( 'return ' + data )() is also MUCH faster in Firefox than eval.
In a test case of JSON data containing 1000 names and addresses (about
112KB), eval() takes a full second to execute on my machine in Firefox 3. On
all other browsers (including IE!) it takes hardly any time at all.
The Fu
Interesting post but I wonder if results will be different without "new"
before Function. I noticed that firefox different as well but I did not know
in ie things were that different. Anyway, in rhino eval could be disabled
while function will work (I surprised a java developer with this "scoop", h
Matt,
I think your approach is usefull only if one wants to create a new
jQuery method... because checking everytime if forEach method exists
is not easily maintainable...
Maybe it could be a $.forEach, applying the Mozilla implementation if
the browser doesn't support the method... what do you
this is an interesting analysis of the runtime performance of the various
eval-like options. in general it's not big difference between eval and
Function across browsers.
http://weblogs.asp.net/yuanjian/archive/2009/03/22/json-performance-comparison-of-eval-new-function-and-json.aspx
On Tue, May
I don't remember the original discussion/change, off-hand. If YUIMin is
still able to generate an adequate file size using Function then I don't see
why we shouldn't switch.
--John
On Tue, May 19, 2009 at 6:46 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> John, can I ask you why
John, can I ask you why you did not chose Function(string)() ? YUIMin, if I
am not wrong, works with Function because there are less problems with the
external scope ( Function works in the global one, so the only problem is
"arguments" rather than possible variables that are not globals )
On Tue,
That's specifically being done to allow YUIMin to properly compress jQuery
(it sees an eval and assumes that it can't be compressed, but using that
technique allows it to work).
--John
On Tue, May 19, 2009 at 5:22 PM, Justin Meyer wrote:
>
> I assume there must be a good reason, but why is wind
In Rhino eval is usually not allowed, that could be a reason, on the other
hand, Function(someString) has always worked
On Tue, May 19, 2009 at 10:22 PM, Justin Meyer wrote:
>
> I assume there must be a good reason, but why is window['eval'] used
> as opposed to window.eval in httpData? This has
I assume there must be a good reason, but why is window['eval'] used
as opposed to window.eval in httpData? This has some issues in rhino
for reasons discussed here:
http://www.mail-archive.com/dev-tech-js-engine-rh...@lists.mozilla.org/msg00664.html
I know jQuery's tests run in rhino, but perh
On May 19, 4:40 pm, Matt Kruse wrote:
> The list I see is a little confusing and I'm not sure where it's all
> coming from.
>
> I also took a stab at "aggregating" jQuery info
> here:http://www.javascripttoolbox.com/gadget/jquery/
>
> I've been using it in my iGoogle page for a few weeks and it'
On May 19, 1:26 pm, "jquerypla...@gmail.com"
wrote:
> i started a new project called jplanet. it's a content aggregator
> about jquery.
> see more inhttp://jplanet.tumblr.com/
What are your sources?
The list I see is a little confusing and I'm not sure where it's all
coming from.
I also took a
May want to look at this as well:
http://planet.jquery.com/
--John
On Tue, May 19, 2009 at 2:26 PM, jquerypla...@gmail.com <
jquerypla...@gmail.com> wrote:
>
> hello people
>
> i started a new project called jplanet. it's a content aggregator
> about jquery.
>
> see more in http://jplanet.tumbl
thanks elijah!
subscribe the rss ;)
On May 19, 3:51 pm, Elijah Insua wrote:
> Thats pretty cool
>
> On Tue, May 19, 2009 at 2:26 PM, jquerypla...@gmail.com <
>
> jquerypla...@gmail.com> wrote:
>
> > hello people
>
> > i started a new project called jplanet. it's a content aggregator
> > about j
Thats pretty cool
On Tue, May 19, 2009 at 2:26 PM, jquerypla...@gmail.com <
jquerypla...@gmail.com> wrote:
>
> hello people
>
> i started a new project called jplanet. it's a content aggregator
> about jquery.
>
> see more in http://jplanet.tumblr.com/
>
> thanks
>
> >
>
--~--~-~--~~
hello people
i started a new project called jplanet. it's a content aggregator
about jquery.
see more in http://jplanet.tumblr.com/
thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group
Right, I think this is what Matt and I are getting at. Also, I think
it shouldn't be impossible to track jQuery changes. The internals
might change, but if we're mostly error checking published API, that
should be fairly stable.
-- dz
On Tue, May 19, 2009 at 11:02 AM, Andrea Giammarchi
wrot
rather than another branch with dirty code in the middle, I would prefer a
dedicated jQuery.debug.js as external file able to wrap "everything" and
redefine the library itself.
in this way you can use always latest jQuery version and add, locally, a
script with jQuery.debug.js file where inside yo
On May 19, 9:19 am, diogobaeder wrote:
> Brainstorming: what about a $.each2 method, to avoid messing with the
> original signature (name + parameters), but using
> Array.prototype.forEach?
Why not just call Array.prototype.forEach in your code if it exists?
Matt Kruse
--~--~-~--~
On May 19, 7:51 am, David Zhou wrote:
> I wonder if it's feasible to monkeypatch debugging wrappers around
> jQuery core methods. You don't even need it to throw errors -- a
> simple console.log warning would suffice.
Definitely feasible. See something I posted here a while ago:
http://groups.g
Hmmm... interesting... thanks, Andrea!
Brainstorming: what about a $.each2 method, to avoid messing with the
original signature (name + parameters), but using
Array.prototype.forEach?
Diogo
On May 18, 11:29 am, Andrea Giammarchi
wrote:
> it's not about the name, it's about arguments plus ret
Oh yes, I understood, I was just answering to the last statement you made in
your previous post about logging rather than throwing exceptions :)
2009/5/19 David Zhou
>
> Well, there's no reason not to throw exceptions too. The point was a
> script that monkeypatched jQuery to allow for some of
Well, there's no reason not to throw exceptions too. The point was a
script that monkeypatched jQuery to allow for some of the debugging
features being discussed.
-- dz
On Tue, May 19, 2009 at 9:00 AM, Julian Aubourg
wrote:
> I dunno.
> From what I witnessed, when jQuery starts to complain/h
I dunno.
>From what I witnessed, when jQuery starts to complain/halt, the problem is
generally elsewhere, especially when you keep references to nodes/select
results like I personnaly do. Exceptions would be nice imo, so that you get
the callstack. Logs are good as long as all of the application be
I wonder if it's feasible to monkeypatch debugging wrappers around
jQuery core methods. You don't even need it to throw errors -- a
simple console.log warning would suffice.
-- dz
On Tue, May 19, 2009 at 8:38 AM, Julian Aubourg
wrote:
> jquery.debug.js / jquery.release.js ? ;)
> I really lik
jquery.debug.js / jquery.release.js ? ;)
I really like this idea. When I first started using jQuery, I sometimes had
some issues determining what it was I was doing wrong when jQuery complained
deep in its internal functions.
2009/5/19 Matt Kruse
>
> On May 19, 5:32 am, DBJDBJ wrote:
> > This i
On May 19, 5:32 am, DBJDBJ wrote:
> This is an discussion on library develeopment philosophy.
> There are only two sides to this coin: fast and dangerous and safe and
> slow.
I think this is another use for a jQuery "development" build. One that
would generate warnings of empty selector results,
Thanks anyway ... DBJ
On May 18, 11:28 am, Adam wrote:
> No, I used Firefox so that I could do a quick check using console.time
> () in Firebug
>
> On May 18, 10:01 am, DBJDBJ wrote:
>
> > I am not surpised . And, I hope jQ team will take notice ?
>
> > Although improvement might be very diffic
@Peter
Always refreshing to meet a JavaScript guru, helping with a guru
device ;)
@ALL
This is an discussion on library develeopment philosophy.
There are only two sides to this coin: fast and dangerous and safe and
slow.
Library developers task is to find a balance between the two.
But, it is
Where am I blaming the jQuery ? I was not clear enough.
I suggest my strategy. Unashamedly.
Task : help to the company which tried to switch to jQuery but
failed.
1. have ready: jquery.1.3.2.safe.slow.js (with all the gotchas you can
think off, added )
2. impose it
3. when dust settles on the b
31 matches
Mail list logo
