11–20 of 250 posts
On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions. (without counting people using the default browser on pre-Lollipop Android)
On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions. (without counting people using the default browser on pre-Lollipop Android)
On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions. (without counting people using the default browser on pre-Lollipop Android)
Indeed. Are there any 'good' strategies for this (loading ES6 for supported browsers)? I imagine you'd have to do UA sniffing on the server side, and I suppose it's kind of a moot point if you're using React/JSX.
destructing is very useful and encourage good coding styles Is it? Personally I'd say that was bad code. What so wrong with using the original objects? Putting aside the need to variable swap once a year or so, all the other examples look really confusing to me and unclear what they're doing. The `Deep Matching` especially.
var lst = [[1,2], [3,4], [5,6]];
for (var [a,b] of lst) { console.log(a + b); }
Using const and `splice` breaks the rules: const info = [1,2,3,4] const newInfo = info.splice(2); 'info' has changed
Common misconception, const only disallows reassignment. For instance, const number = 1337; number = 10; // fails But objects/arrays are not immutable in js, so you can do this: const person = { name: 'Dude' }; person.name = 'Dudette'; Which is perfectly valid. If you want full immutability, i recommend you check out https://facebook.github.io/immutable-js/ , been running it in production, a real pleasure to work wit…
> Because even though the if-block is not executed, the line 4 still redefines var x as undefined. This is because of hoisting. Not quite right as described.
destructing is very useful and encourage good coding styles Is it? Personally I'd say that was bad code. What so wrong with using the original objects? Putting aside the need to variable swap once a year or so, all the other examples look really confusing to me and unclear what they're doing. The `Deep Matching` especially.
Yes, but not in the silly example showed.
Consider something like :
zip(fooArray, barArray, bazArray).map(([foo, bar, baz]) => foo + bar + baz)
zip(fooArray, barArray, bazArray).map((arr) => arr[0] + arr[1] + arr[2]);The point of constructor functions is not having to write new. So classes does nothing besides syntactic sugars over the prototype system, witch actually makes it more complicated and the code harder to maintain.
Async programming is hard, but not because of callbacks. Promises is just a wrap around callbacks, witch just adds complexity and more boilerplate. It will get better with async/await but I will still prefer simple callbacks.
Arrow functions are very nice for one liners, but will ruin your code if you use them everywhere instead of named functions. You should always name your closures, then it's easier to debug and lift them out.