Earlier quoted context omitted.
How does debugging in the browser console work when you use that approach?
Normally you have mapping files which tell your browser which bits correlate to the outputted "compiled" code. Thus in your browser you see the code you write, you put in breakpoints as desired, and everything generally works. I don't have much depth as to how it all works behind the scenes though, I'd love to know more.
Making the Most of the JavaScript Language (2016)
11–20 of 47 posts
Re: Making the Most of the JavaScript Language (2016)
#12Re: Making the Most of the JavaScript Language (2016)
#13While I use `const` for a lot of my variables that I don't want to change it feels super-super wrong.
Re: Making the Most of the JavaScript Language (2016)
#14Re: Making the Most of the JavaScript Language (2016)
#15Re: Making the Most of the JavaScript Language (2016)
#16While I use `const` for a lot of my variables that I don't want to change it feels super-super wrong.
Re: Making the Most of the JavaScript Language (2016)
#17Earlier quoted context omitted.
What feels wrong about it?
It's an incredibly verbose way to do what you'd prefer to be the default. val or con would have been better.
I know some/most people don't care. I can't be one of them.
Maybe we'll get `val` in ES9.
Re: Making the Most of the JavaScript Language (2016)
#18Earlier quoted context omitted.
What feels wrong about it?
It's an incredibly verbose way to do what you'd prefer to be the default. val or con would have been better.
Re: Making the Most of the JavaScript Language (2016)
#19Very true on both counts, but unfortunately the article perpetuates some of this misunderstanding.
> Where it gets interesting is when you return a function from an outer function...
Abbreviated example from the article:
var outer = function () {
var a = 1;
return function inner() {
return a;
};
};
...and that's the only example. No mention of where closures are actually most useful, and not a peep that you don't need a function that returns a function to get one. Any function call can get you a closure.I deal with this frequently on Stack Overflow. Someone asks a question where a closure is a great solution, and then someone answers with a complicated example involving a function that returns a function.
It seems to come up a lot in Google Maps API code:
var places = [
{ name:"Test", lat:10, lng:10 },
...
];
function initMap()
var map = new google.maps.Map(...);
for( var i = 0; i
It doesn't have to be done that way! You'll get a closure that works just as well if you simply call a function in the loop: function initMap()
var map = new google.maps.Map(...);
for( var i = 0; i
There are other ways to do this in modern JavaScript (such as using let inside the loop). I'm using old-school JavaScript here just to show that it could be done this simply even in the oldest browsers.Of course, the same thing can be done with forEach():
function initMap()
var map = new google.maps.Map(...);
places.forEach( addMarker );
function addMarker( place ) {
var marker = new google.maps.Marker(...);
marker.addListener( 'click', function() {
// We have a closure here too:
infowindow.open( map, marker );
});
}
}
Or with the forEach callback inline: function initMap()
var map = new google.maps.Map(...);
places.forEach( function( place ) {
var marker = new google.maps.Marker(...);
marker.addListener( 'click', function() {
// We have a closure here too:
infowindow.open( map, marker );
});
});
}
The point in each of these cases is that you don't need a function that returns a function to get a closure, but people who answer SO questions perpetuate this myth day after day.Re: Making the Most of the JavaScript Language (2016)
#20As someone who works with this every day, I'd say this is pretty solid advice. The "use a more functional approach" and "take advantage of ES6" are by far the biggest for me. ES6 added so much good stuff, I wouldn't consider it optional. It's better than incremental upgrades, feels almost like a different language to me. Every language has its quirks, and while I'll keep on hating Javascript's, I'll never lose sight…
Writing [1,2,3].map(function(x) { return x+10 }) really doesn't bother me. I don't see what the benefit is of an arrow function. Are there other things that you like?
As the OP mentions, the inheritance stuff is just likely to cause architecture headaches. I like JavaScript's concurrency model (single threaded with callbacks) so I don't see any benefit to the async stuff.
It just seems like people added a ton of complexity to give up a few keystrokes. Transpiling and shimming and adding more control structures make your application more complicated, so there is a real cost. And keystrokes are not generally a big problem when I'm programming. I'm not in a race.