Axel, here ... that chapter is really a tiny one and every dev should read
that at least once if JS is, by accident, their programming language:
http://webreflection.blogspot.com/2010/10/javascript-coercion-demystified.html
br
On Sun, Jan 6, 2013 at 6:10 PM, Axel Rauschmayer wrote:
> Note that
> Note that == does not respect truthiness or falsiness:
>
> > 2 == true
> false
> > 2 == false
> false
>
> > '2' == true
> false
> > '2' == false
> false
>
> None of these (above) abstract comparison operations represents "truthy" or
> "falsy" behaviour.
>
> 0
On Sunday, January 6, 2013, Axel Rauschmayer wrote:
> > Exactly Brendan, I could not agree more and this is my No. 1 pitfall
> about JS: developers often not doing real work complaining about stuff that
> developers doing real work don't even care about or never ever had to worry
> about.
>
> I do
>>
>> On Sun, Jan 6, 2013 at 5:06 AM, Axel Rauschmayer wrote:
>>>
>>> This is not about pointing out how bad JavaScript is, it is about
>>> collecting things that confuse people who are new to the language. They
>>> help those people to learn what you already know. Many people really ha
[cc-ing es-discuss again]
Yes. I like the idea of JS(L|H)int as a teacher for newcomers!
On Jan 6, 2013, at 15:52 , Andrea Giammarchi
wrote:
> I think for your latter point and about haters, JSLint can help there. Put in
> this way ... I hate JSLint :D
>
>
> On Sun, Jan 6, 2013 at 5:06 AM,
Axel, it wasn't referred to you explicitly, rather to all those developers
still wining about this == null problem which has never been in my daily,
real work, code.
choose one:
value === undefined || value === null
in a language where undefined and null are different and for a good reason
(not d
> Exactly Brendan, I could not agree more and this is my No. 1 pitfall about
> JS: developers often not doing real work complaining about stuff that
> developers doing real work don't even care about or never ever had to worry
> about.
I don’t follow. Who are these people not doing “real work”?
:-) Well put Andrea.
Benoit
On Jan 5, 2013, at 22:38, Andrea Giammarchi wrote:
> Exactly Brendan, I could not agree more and this is my No. 1 pitfall about
> JS: developers often not doing real work complaining about stuff that
> developers doing real work don't even care about or never ever
Exactly Brendan, I could not agree more and this is my No. 1 pitfall about
JS: developers often not doing real work complaining about stuff that
developers doing real work don't even care about or never ever had to worry
about.
In any case they can learn and understand the feature/problem using th
I'm still amazed to see people rant about other people's perfectly fine
coding styles, when those are an overtly subjective matter, and therefore
no argumentation on whether "Yes ASI" or "Nay ASI" can be right.
The only facts about ASI are:
1.) It's a syntax error;
2.) Such syntax error is spec'd
Yes, see the thread starting at
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027419.html
if you haven't.
The SpiderMonkey implementation was "first", for what it's worth -- from
1997. ES3 did not specify any function in block production, of course.
The intersection with IE semant
I've just discovered that someone is fallen in the following pit:
Change of the semantic of function declarations in Firefox when included in
block (spoiler: hoisting issue).
(Not standard ES for sure, but definitely JS.)
Enjoy: http://statichtml.com/2011/spidermonkey-function-hoisting.html
—Clau
Jorge Chamorro wrote:
On 31/12/2012, at 15:55, Juan Ignacio Dopazo wrote:
I'm surprised not to see Automatic Semicolon Insertion in the list.
Yes I would ditch ASI altogether if only to force the javascrhipsters to put
back each and every semicolon where it belongs: they are *delimiters*.
I don't think ASI _per se_ is the problem. Rather, the restricted
productions bite people:
function foo() {
return
very + long + expression() + goes + here;
}
and of course, the expectation of ASI where there's no error to correct:
a = b
(function () {
... // lots of line
Le 31 déc. 2012 à 18:58, Axel Rauschmayer a écrit :
>> Personally, I have issues with from- and to-String conversions when working
>> with HTML form field values and data-* attributes. More precisely, I am
>> careful to make these conversions manually, and I regret that JS doesn't
>> warn me
> Personally, I have issues with from- and to-String conversions when working
> with HTML form field values and data-* attributes. More precisely, I am
> careful to make these conversions manually, and I regret that JS doesn't warn
> me if I forget to do them. Indeed the following cases are prob
On 31/12/2012, at 15:55, Juan Ignacio Dopazo wrote:
> I'm surprised not to see Automatic Semicolon Insertion in the list.
Yes I would ditch ASI altogether if only to force the javascrhipsters to put
back each and every semicolon where it belongs: they are *delimiters*.
No ASI would force them t
Le 31 déc. 2012 à 10:17, Axel Rauschmayer a écrit :
>>> I’d be interested in other examples of implicit conversions stumping people.
>>
>> What stumped who, when? Any bugs/github issues/blog posts to cite?
>
> No, I think I agree with your assessment that implicit conversion to boolean
> (the
I'm surprised not to see Automatic Semicolon Insertion in the list.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>> I’d be interested in other examples of implicit conversions stumping people.
>
> What stumped who, when? Any bugs/github issues/blog posts to cite?
No, I think I agree with your assessment that implicit conversion to boolean
(the most prevalent implicit conversion) is manageable, possibly eve
Axel Rauschmayer wrote:
JS is functional first, not OOP first. APIs that want methods to be
extractable as bound to the object from which they were extracted
must do extra work, which can be self-hosted via getters for specific
methods, or a general proxy.
Again, not sure if that’s feasible,
Axel Rauschmayer wrote:
- Implicit conversions are messy (and a superset of pitfall #2), but
seem to surprise people much less than the above items.
I think you have it backwards.
My experience, so far. I’d be interested in other examples of implicit
conversions stumping people.
What stump
> You don't mean for-of, you mean for (let i...) in any form. We want all
> for-let forms to make fresh let bindings per iteration. That's what your
> resolution for (7) should say, and ES6 does indeed aim to do this.
Yes, thanks. I thought only for-of did this.
>>> We can work around it by cha
>> - Implicit conversions are messy (and a superset of pitfall #2), but seem to
>> surprise people much less than the above items.
>
> I think you have it backwards.
My experience, so far. I’d be interested in other examples of implicit
conversions stumping people.
>> - Modules close another i
Axel Rauschmayer wrote:
You did not include variants of
var i, a=[];
for (i=0; i < 10; i++) {
a.push(print(i));
}
print(a[3]); /* output is 9 */
in your list. I see related bugs on a regular basis.
That would be (7). The above should work. The problem only exists with
functions (or rathe
Yes, tripped me up a few times. Then I remember to use a regular expression
with a /g flag as the first argument. I wouldn’t consider it a major pitfall,
but it is definitely a pitfall.
On Dec 30, 2012, at 23:06 , gaz Heyes wrote:
> I'd say String.replace needs to be there:
> http://blog.minde
seems that strict equals is usually faster.
> On 30 December 2012 16:22, Axel Rauschmayer wrote:
> [Starting a new thread, just in case.]
>
>>> I made a list of the 10 biggest JS pitfalls and most of them will be gone
>>> under ES6. Much less to worry about, much easi
Axel Rauschmayer wrote:
1. Both undefined and null [not too much of a problem, easily learned]
2. Truthy and falsy values [not pretty, but I’ve grown used to them
and the convenient but sloppy “has a value” checks via `if`]
These are usually winning. Dart makes you be explicit in testing and
On Sun, Dec 30, 2012 at 10:22 PM, Axel Rauschmayer wrote:
> 5. Array-like objects [not completely fixed (DOM...), but `arguments`
Specifics welcome, though probably better posted to www-...@w3.org.
We've made some effort towards changing some of this, but legacy
content is against us. :/
--
ht
that == is faster than
=== in at least one implementation, because that's what sunspider tests.
On 30 December 2012 16:22, Axel Rauschmayer wrote:
> [Starting a new thread, just in case.]
>
> I made a list of the 10 biggest JS pitfalls and most of them will be gone
> under ES6. Mu
I'd say String.replace needs to be there:
http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html
http://www.thespanner.co.uk/2010/09/27/string-replace-javascript-bad-design/
Also the fact that no built in html encode/decode exists.
__
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
> On Behalf Of Axel Rauschmayer
> Sent: Sunday, December 30, 2012 16:22
> 9c) using methods as callback functions
The single biggest feature on my ES7 wishlist is the bind operator strawman:
http://wiki.ecmascript
[Starting a new thread, just in case.]
>> I made a list of the 10 biggest JS pitfalls and most of them will be gone
>> under ES6. Much less to worry about, much easier to learn.
>
> Could you share your 10-biggest list?
1. Both undefined and null [not too much of a problem,
33 matches
Mail list logo
