what kind of problem is this fat arrow feature trying to solve ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Oct 2 10:55:25 PDT 2013

fat arrow does not add any capabilities but create the need to be sure
about the context.

In use strict fat arrow will bring a lovely `undefined` wich is undesired
so nothing is solved in there.
You need to be sure that the function/closure that is defining the fat
arrow is doing it in a `this` context you expect and I wonder how many
developers will fall into a `this` hell instead  of "_callback hell_"
forced to define fat arrows inside functions such:


this.method = () => alert(123);


The good part is that I've already written about so many pattern able to
solve many common mistakes fat arrow will introduce so at least for me this
will be a good reference to solve those mistakes/problems later on in the

Not much to add if not please read again your first answer to my question,
something not just me found not just rude.

I've asked a question, a honest one, trying to understand. I wasn't
trolling and I write real code so your "virtually nobody use that" approach
is my daily basis code which is "virtually a better architecture for my
needs" that I strongly hope W3C won't ever decide to get rid of because it
avoids massive, expensive, pointless usage of extra objects, GC operations,
and amount of RAM.

Google is usually very keen to these problems, handleEvent solve an
infinity of them at once, developers should just learn how convenient this
approach could be for mostly all their DOM based tasks and why not, even

Best Regards

On Wed, Oct 2, 2013 at 10:46 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Tue, Oct 1, 2013 at 7:35 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > setTimeout accept extra arguments ... I write JavaScript that uses this
> > feature.
> >
> > `setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);`
> >
> > so fat arrow does not solve much here, I can use self as first argument
> and
> > I am good.
> >
> > `forEach` and all other arrays accept a second argument
> >
> > `array.forEach(doStuff, boundContextObject);`
> >
> > so fat arrow does not solve a thing in mostly all Array extras.
> Having the capability to set 'this' (or pass the current this as a
> plain argument) doesn't make it any more convenient.  'this' still
> isn't captured by the closure like every other variable is, which is
> confusing.  As David said, being forced to pollute the signature of
> every standard callback-taking function with this argument is just
> silly.  As Claude and others have said, the silly 'this'-rebinding
> kludges we have to adopt *everywhere* just to work around this feature
> of JS are ridiculous and fragile.  Automatic 'this' binding is very
> convenient in some places.  In others, it's very inconvenient.  Arrow
> functions give us something better suited for those latter cases.
> > for **DOM** I use handlers as specified by **W3C** so that `{handleEvent:
> > function () {this}}` works better than any mess I could create with
> > callbacks that I won't be unable to remove later on (as I've said) ...
> Virtually nobody does this, and newer interfaces specified with the
> WebIDL 'callback' type don't accept it at all.
> > so I
> > can use `removeEventListener(this)` in every method handled by that
> object.
> I didn't mention event listeners, actually.  There are lots of other
> things that take callbacks besides event listeners.
> > So I actually wonder what kind of JavaScript **you** write because this
> was
> > a honest question but probably ... people not familiar with JS are the
> > answer: since developers ignore part of JS specs available since every
> then
> > we need a fat arrow to break old syntax to make the creation of self
> bound
> > function easier.
> >
> > This would be already an answer so thanks for participating.
> Wow, that's pretty rude.
> ~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131002/36e32313/attachment.html>

More information about the es-discuss mailing list