> I do understand the technical difference very well - I have a PhD in implementing programming languages like JavaScript. I am happy for your PhD and that it is for implementing programming languages like JavaScript. My assertion is the advantage of having function scoping is apparent to those who understand function scoping. Block scoping-style programming in JavaScript was always, in my experienced, shoe-horned in…
> My assertion is the advantage of having function scoping is apparent to those who understand function scoping. I assert that if you can't say what the advantage is then you don't understand it yourself. "You'd see the advantages if you understood this, and since you don't you must not understand it" is not a reasonable thing to say to people.
I'm surprised by the state of const/let nowadays. The well-known good practice: use const by default; use let when it's needed. At the release of ES6, it was the way to go. But everyday I notice libraries—and some really famous— that use let everywhere in their docs, or some really influent developers from Google or Facebook who share samples of code on Twitter using let when it's not needed [1]. I don't know why. Se…
How do you feel about `const` for variables that are not reassigned but are still mutated? const array = [1, 2, 3]; array.push(100); // unexpected? I prefer to use let for bindings to objects that get mutated, even if the variable is not re-bound.
Yeah, I wrestled with that briefly.
For anyone not in the know, declaring `const` on an object only makes it where you can't re-assign the object, but you can still mutate its 'members'.
Personally, I use `let` just to symbolize that it isn't a constant and does change even though I could declare it a `const`.
"best practices": "use class instead of manipulating prototype directly"
Who comes up with these "rules"? This is not a hard and fast rule. Manipulating the prototype of an object is not "dangerous".
I'm sick and tired of some loud mouth saying something is dangerous without explaining why. WHY? Why it it dangerous? Don't talk at me. Provide me a sound reason and case to justify what you say. Talk is cheap.
It makes me not trust anything else in this article when someone is flippant.
> I do understand the technical difference very well - I have a PhD in implementing programming languages like JavaScript. I am happy for your PhD and that it is for implementing programming languages like JavaScript. My assertion is the advantage of having function scoping is apparent to those who understand function scoping. Block scoping-style programming in JavaScript was always, in my experienced, shoe-horned in…
But I do understand function scoping. I understand what it is, what its semantics are, and how to implement and use it. And the advantage over block scoping isn't apparent to me. But even if it should be apparent to me, why can't you explain the reason to me? What is this - some kind of argument that is impossible to comprehend unless you already agree with it? I can understand your argument that block scoping was sh…
I understand your question now was more about function scoping versus block scoping from a language design perspective, and not about specific to JavaScript. It wasn't clear from your comment you were heading in that direction. Having var enable you to make use of function scoping is useful to JavaScript developers who have, up until this point in history, have always had function scoping. As parent mentioned, using var allows you define the variables where you are. It makes the code more readable. As far as function scoping versus block scoping I don't have much of a say, as I am not sure there are any meaningful advantages, merely minor ones, but none that would impact productivity if you were experienced in one or the other. Maybe you could convince me otherwise?
It's both amazing, and 600MB worth of dependencies. We use it for server-side code. It's high quality, and we only have a few issues with it, but I can't wait to be able to ditch is (pretty much when async/await lands in a stable node).
Doing du -ch ./babel* from my `node_modules` directory yields 3.2M total so I'm gonna need a citation on that 600MB claim.
Admittedly, if you're using a flat structure like NPM3 does, then everything else is at the same level :)
const vs let is an "immutable by default" vs "mutable by default" type of difference. it's not just a style difference, it can help you write stateless code if you assume immutability. but yeah.
Native objects in JavaScript are already immutable as in you can not change them, only create new objects. Const will not make your object immutable! Try this: const foo = {bar: 1} foo.bar = 2; It will only avoid having the pointer re-pointed to another object. It's better to just try avoiding global variables, and use a naming convention like uppercase and/or underscore for constants and global variables. Const is p…
All true. But what I said was,
> it can help you write stateless code if you assume immutability
const vs let is an "immutable by default" vs "mutable by default" type of difference. it's not just a style difference, it can help you write stateless code if you assume immutability. but yeah.
Native objects in JavaScript are already immutable as in you can not change them, only create new objects. Const will not make your object immutable! Try this: const foo = {bar: 1} foo.bar = 2; It will only avoid having the pointer re-pointed to another object. It's better to just try avoiding global variables, and use a naming convention like uppercase and/or underscore for constants and global variables. Const is p…
const vs let is an "immutable by default" vs "mutable by default" type of difference. it's not just a style difference, it can help you write stateless code if you assume immutability. but yeah.
> const vs let is an "immutable by default" vs "mutable by default" type of difference Sorta. I mean you're right but at the same time if you're using const for an object or array then it doesn't really matter without `object.freeze()` because it's not immutable only the reference is and I don't think most JavaScript developers understand that (at least not most of the ones I've run into).
Note that Object.freeze only works for shallow objects
Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? While I agree that const/let is a useful convention for communicating mutability, it isn't nearly a big enough deal to warrant the attention it receives from the community. It's not just const/let; I rarely make a front end PR that isn't bike-shedded to death over subjective styling choices, sin…
> Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars? - Tabs vs spaces. - Vi vs Emacs - Weak vs strong typing - where to place {} in block statements - where to put commas No, programming in general is susceptible to these trivial holy wars.
Vi vs Emancs? Weak vs strong typing?? tabs vs spaces??? where did you get those??