Hacker News Reader

Comment by corecoder | Hacker News Reader

Before Babel, I often used to ask about code organization/modularization, mostly to filter out candidates who haven't been on a big project and have only copied and pasted jQuery snippets together; today I'd ask if you use Babel modules and why/why not. As other people have said, closures will surely come out. A favorite of mine is array functions: map, forEach, filter. Also, promises, callbacks, workers. Finally, xhr throttling.

View on HN

Why would Babel change drastically the way you organize your code? Isn't it a just compiler?

I really meant ES6 modules, I said babel because it's what made ES6 features actually usable in production.

Can you clarify what you mean by xhr throttling? Implementing something like _.throttle to wrap requests?

Hopefully not! Surely _.debounce would be more appropriate to avoid locking out your UI - or worse, returning out of date responses - but even then you would potentially want to handle the responses more robustly.

Not to mention needing to handle .fetch()s lack of abort if you're not using xhr.

How can a throttled vs debounced xhr request "lock out the UI"?

Do you mean ES6 modules?

Yes, ES6 modules. Before that I've used browserify, AMD/RequireJS and half assed in-house solutions.

are JS closures already fixed ?

var a = 10; var fn = function (x) { return x + a}; fn(10); ==> 20 var a = 1; fn(10) ==> 11 //WAT ??

Is the above fixed with ES2015 ? Closures need to enclose values and not references.

I don't think javascript will ever be "fixed": it is as it is, if you change how hoisting works, you break everything. But:

1. You can solve that already in ES6, by returning fn from a function, also avoiding the global variable;

2. Your ES3 linter should warn you about the redefined variable.

Reply on news.ycombinator.com