He still uses the 'function' keyword in his ECMAScript in 2019

>he uses ECMAscript in 1k+1019

Attached: 1545903263715.jpg (700x994, 76K)

kys samefag

yes, that.

I don't, because I can make sites working and interactive without javascript functions. The only thing I need is literally document queryselector() and classlst.toggle().

*blocks your path*
"Your application must work on all browsers huh? Nothing personal, kiddo."

Attached: Internet_Explorer_9_icon.svg.png (1024x1024, 217K)

>I don't need Javascript the only thing I need is Javascript

the only *javascript* I need, boyo.

On that note, does anyone have a shim so "() => nigger" doesn't return syntax error in IE11?

in 800 years or so humanity will have starships capable of FTL and has effectively achieved immortality - yet everything will still need to be IE compatible, because there will always be some faggot using windows xp, until the end of time

bump for this.
I don't even know what that ECMAScript notation is called. Function casting?

compile it bruv

It's already compiled.

arrow notation

>He still uses the 'function' keyword in his ECMAScript in 2019
>He thinks there's an alternative when you need to use a generator function
Also, there is a difference between a function expression vs. a function declaration, so there are still use cases for using 'function' explicitly.

It's impossible to polyfill if that's what you mean, because it constitutes as a syntax error.

You need to configure Babel correctly senpai. Look up the docs for babel-preset-env.

I'm not talking about Babel code.

What do you mean by '''compiled''' then? I can only assume some kind of transpilation (as you can't compile JS), and even if you don't happen to use Babel for that but something else I'm sure you can target ES5, because what's the purpose of transpilation if not?

it's called Babel, it recompiles your ES6+ code to ES5 compilant

>it recompiles your ES6+ code to ES5 compilant

man technology fucking rules. web programming fucking rules lmao

>What do you mean by '''compiled''' then?

It's production code that cannot be updated.

Try implementing a true throttle/debounce without it.

Well if you can't touch the code, you cannot do anything, see

Why would that not be feasible without it

You would lose context. There's no equivalent for:

function debounce(t, f) {
let instance;
return function() {
clearTimeout(instance);
instance = setInterval(() => f.apply(this, arguments), t);
};
}

>2019
>not knowing the difference between functions, and closures

it's like not knowing the difference between var and let.

It's much more important. Who gives a shit about var/let

It would be trivial. Arrow funcs still have a bind prototype as well so it's not like they can't be made to mimic functions created using function keyword.

???
const debounce = (time, func) => {
let instance

return (...args) => {
clearTimeout(instance)
instance = setInterval(() => func(...args), time);
}
}

Unless I'm missing something...

What's wrong with function keyword and what's the alternative?

const debounce = (fun, timeout) => {
//debounce setup//
return (...args)=>{
//debounce logic//
return fun(...args)
}
}

unsure why you'd use debounce anyways instead of just request animation frame.

>hello user, it says here you know javascript
>what's the difference between var and let?

Using the Function constructor, duh noob. Or arrow functions I guess if you like shoe horning them everywhere and then being mindful to call bind proto on them when appropriate.

Nope, neither work without trashing `this` in some contexts. Try using these for a class method.

It's honestly so minor. This is something only beginners would care about/get tripped up on.

desu. Context in javascript is one of the worst ideas that mankind has ever came up with. I keep having to do something like this just to bypass it
function wrapped(someObject) {
return () => {
// now I can use someObject and not have it be overwritten for stupid
// reasons
}
}

But fair enough. I suppose you deserve to win this argument

I would love to see the code bases where this is an issue. I'm assuming your coworkers are on the slower side lmao.

Is .bind used heavily in your code bases?

Personally I love context in JavaScript (slash closures). I know it's bad and a hurdle for many but it can be powerful sometimes. Gives me a schemesh feel

In all honesty, relying on the this binding of function keyword defined functions is really strange and seemingly only useful for prototypes. Almost everywhere else is the behavior strange and bug laden. And sometimes bind is appropriate, but it's more likely you'd be using call or apply directly instead of binding a function to a this.

Hard agree

Only exception I guess would be shitty automagical libraries (((vue))), still not a good idea.

>Nope, neither work without trashing `this` in some contexts. Try using these for a class method.

forget this. use let self = this; in the context you want to keep, and use self instead.

Mainly it's an issue with class methods. Consider this
class foo {
constructor() {
this.barWrapper = () => this.bar();
}

bar() {
console.log(this)
}
}

const bar = new foo()

document.addEventListener('click', foo.bar)
document.addEventListener('click', foo.barWrapper)

In the bar function, "this" is undefined. while the wrapped version is what should be the proper value of "this". And so this is just one example. I'm sure this is just a performance optimization, but it's a bit stupid having to work around

Ya no shit. I'm not asking for an answer lmao. The easiest way to not care about this is to:

debounce(t, ()=>classInstanceMethodOrSomeOtherShitWhoCares())

Last time I seen self in some JS code was 2014

I'm assuming you meant bar.bar

this probably isn't ever going to get fixed. just gotta learn to live with it. or abuse it.

I mean might be useful in some instances

i use function keyword, its beautiful

Attached: ZlJo0gg.png (880x294, 22K)

>not
main();

async function main(): Promise {
...
}

> this

what's the point doing this?