Prev: IE 8 script injection and http[S]
Next: Can script determine if window.onload has already fired?
From: kangax on 19 Nov 2009 16:36 David Mark wrote: > On Nov 19, 2:40 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> David Mark wrote: >>> On Nov 19, 12:29 am, kangax <kan...(a)gmail.com> wrote: >>>> David Mark wrote: >>>>> The "base" parts. >>>> [...] >>>>> throw Error('Namespace "' + name + '" already declared.'); >>>>> Bad form. Throw new Error. >>>> Why? Isn't the result identical (as per 15.11.1)? Or are there >>>> deviations in "real world"? >>> Bad _form_. :) >> How do you quantify "bad _form_"? >> >> new Error over Error doesn't seem to make the code any more readable, >> doesn't observably affect performance or outcome, AFAIK. > > This is one where I agree with Crockford. You always use - new - with > Error and never with String, Number, etc. Imagine what String and > Number objects would do to this thing's is* methods. I don't see how using `new` with `Error` is anything but a personal preference ;) To me, the version with `new` is just as good of a form as the one without it, but yes, this is the least of evil in that library. Regardless, this is something that should probably be done by a minification tool like YUICompressor or Closure Compiler (that is, if omission of `new` is an argument for using it to save on code size). I've already filed few enhancements with Closure Compiler (http://code.google.com/p/closure-compiler/issues/detail?id=36) and just proposed `new Error` --> `Error` as well (http://code.google.com/p/closure-compiler/issues/detail?id=36#c12). [...] -- kangax
From: David Mark on 19 Nov 2009 16:45 On Nov 19, 4:36 pm, kangax <kan...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 19, 2:40 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> David Mark wrote: > >>> On Nov 19, 12:29 am, kangax <kan...(a)gmail.com> wrote: > >>>> David Mark wrote: > >>>>> The "base" parts. > >>>> [...] > >>>>> throw Error('Namespace "' + name + '" already declared.'); > >>>>> Bad form. Throw new Error. > >>>> Why? Isn't the result identical (as per 15.11.1)? Or are there > >>>> deviations in "real world"? > >>> Bad _form_. :) > >> How do you quantify "bad _form_"? > > >> new Error over Error doesn't seem to make the code any more readable, > >> doesn't observably affect performance or outcome, AFAIK. > > > This is one where I agree with Crockford. You always use - new - with > > Error and never with String, Number, etc. Imagine what String and > > Number objects would do to this thing's is* methods. > > I don't see how using `new` with `Error` is anything but a personal > preference ;) Form is personal preferences. There are lots of ways to do everything. Best to stick to a subset. If I want to construct a new object, I use the - new - operator, despite the fact that I could leave it off for some types of objects. > To me, the version with `new` is just as good of a form as > the one without it, but yes, this is the least of evil in that library. Technically it is every bit as good (and per the specs). But I don't have to remember that. > > Regardless, this is something that should probably be done by a > minification tool like YUICompressor or Closure Compiler (that is, if > omission of `new` is an argument for using it to save on code size). I really dislike this minification trend. If you don't test the minified result (which can be a pain), you are relying on blind faith. As we've seen that the Closure "compiler" can make a mockery out of JS, I can't see putting such faith in it. On the contrary, I see comments where people have "tested" it against YUI and declared Closure the winner because it made _their_ script(s) smaller without wrecking them (as far as they know). > > I've already filed few enhancements with Closure Compiler > (http://code.google.com/p/closure-compiler/issues/detail?id=36) and just > proposed `new Error` --> `Error` as well > (http://code.google.com/p/closure-compiler/issues/detail?id=36#c12). > Why are you bothering with this shipwreck?
From: kangax on 21 Nov 2009 00:20 David Mark wrote: > On Nov 19, 4:36 pm, kangax <kan...(a)gmail.com> wrote: [...] >> Regardless, this is something that should probably be done by a >> minification tool like YUICompressor or Closure Compiler (that is, if >> omission of `new` is an argument for using it to save on code size). > > I really dislike this minification trend. If you don't test the > minified result (which can be a pain), you are relying on blind It should be trivial to check well tested code. If there are functional tests (besides unit ones) � even better. > faith. As we've seen that the Closure "compiler" can make a mockery > out of JS, I can't see putting such faith in it. On the contrary, I > see comments where people have "tested" it against YUI and declared > Closure the winner because it made _their_ script(s) smaller without > wrecking them (as far as they know). Yeah, that's stupid. YUICompressor, on the other hand, does only safe translations (which is why its compression is not on par with Closure one). I've been using it all the time without any problems whatsoever. In any case, it IS possible to munge code in a "safe" way, as long as you know what you're doing. I'm sure Closure Compiler will get there one day ;) > >> I've already filed few enhancements with Closure Compiler >> (http://code.google.com/p/closure-compiler/issues/detail?id=36) and just >> proposed `new Error` --> `Error` as well >> (http://code.google.com/p/closure-compiler/issues/detail?id=36#c12). >> > > Why are you bothering with this shipwreck? I happen to enjoy language intricacies. And why is it a shipwreck? They are doing a good job (with compiler, not library, of course). If they make a safe compression tool, it would benefit everyone. -- kangax
From: David Mark on 21 Nov 2009 00:27 On Nov 21, 12:20 am, kangax <kan...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 19, 4:36 pm, kangax <kan...(a)gmail.com> wrote: > [...] > >> Regardless, this is something that should probably be done by a > >> minification tool like YUICompressor or Closure Compiler (that is, if > >> omission of `new` is an argument for using it to save on code size). > > > I really dislike this minification trend. If you don't test the > > minified result (which can be a pain), you are relying on blind > > It should be trivial to check well tested code. If there are functional > tests (besides unit ones) even better. If you have a complete set of unit tests (hard to measure), you can predict the success of the munged version. But any non-trivial app is going to require a lot to prove that everything survived the munging. > > > faith. As we've seen that the Closure "compiler" can make a mockery > > out of JS, I can't see putting such faith in it. On the contrary, I > > see comments where people have "tested" it against YUI and declared > > Closure the winner because it made _their_ script(s) smaller without > > wrecking them (as far as they know). > > Yeah, that's stupid. YUICompressor, on the other hand, does only safe > translations (which is why its compression is not on par with Closure > one). I've been using it all the time without any problems whatsoever. I've used it and never had a problem. When I use it now, I test the munged version only. > > In any case, it IS possible to munge code in a "safe" way, as long as > you know what you're doing. I'm sure Closure Compiler will get there one > day ;) Who knows? > > > > >> I've already filed few enhancements with Closure Compiler > >> (http://code.google.com/p/closure-compiler/issues/detail?id=36) and just > >> proposed `new Error` --> `Error` as well > >> (http://code.google.com/p/closure-compiler/issues/detail?id=36#c12). > > > Why are you bothering with this shipwreck? > > I happen to enjoy language intricacies. > > And why is it a shipwreck? They are doing a good job (with compiler, not > library, of course). If they make a safe compression tool, it would > benefit everyone. How are they doing a good job with the "compiler?" Okay, that one's more of a train wreck. Sure it might work some day and maybe it will make a tiny difference in some scripts. But it's the library is a mockery and ISTM that there is coupling between the two (something about the browser sniffing and filtering browser-specific script at "compile" time).
First
|
Prev
|
Pages: 1 2 Prev: IE 8 script injection and http[S] Next: Can script determine if window.onload has already fired? |