Hacker News Reader

Comment by cloakandswagger | Hacker News Reader

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, single quotes vs double quotes, etc. It often feels like conforming to flavor-of-the-week, subjective decrees from frontend trendsetters is more important than the substantive work that your code is doing.

View on HN

The fact that a const can't be changed is great but in my mind the bigger thing is what the code communicates. Using const vs let tells future devs who work on the code that the value was meant to remain unchanged. If they need to change it, that's a signal that maybe there's more to it than they currently understand.

I agree that pull requests that mass change from let to const are largely a waste of time, but usage of const vs let is a legitimate discussion within your team.

> 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.

Weak vs strong typing is hardly "trivial"... it's the very foundation of a language.

Not trying to derail the convo or take sides, but one of these is not like the others ;)

Hardly anyone argues weak vs. strong types, the battle is primarily between dynamic vs static typing.

Vi vs Emancs? Weak vs strong typing?? tabs vs spaces??? where did you get those??

The ONLY holy war in JS is the semi-colon one

That's what OP is saying: programming has plenty of holy wars that predate JavaScript.

You are right, I misread his comment

Clearly you have never encountered the strange "comma first" brigade.

Au contraire, for a while I was one of them. But I think we were seen as too weird to even bother with a holy war

Though I don't see why this is a holy war in the first place. Clearly, no-semicolon is the only way to go.

:^)

[loads machine gun...]

We have a little more than vi and emacs these days as competition not two sided wars.

Sublime vs Atom if you prefer.

The point still stands

Atom is clearly better until you want to open a file larger than 64 bytes.

Presumably each project/organization/etc. has its own style guidelines (or at least unwritten conventions). If you're not following them, then it's not a surprise people are calling you on it. If, on the other hand, they don't exist then it would be weirder.

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

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 probably only meant for constants like the name suggests.

I think something like this is pretty safe from reassigning:

  {
    let foo = 1
    ...
  }
  ...

If you want more control over your properties, you can use the ES5 feature "defineproperty" where you can set writeable: false

    const foo = {bar: 1}

The only thing const about it is the reference `foo` cannot be reassigned:

    foo = something_else; // error

Unlike `const` in C++, `const` in javascript in not very useful in my opinion. `let` is shorter and more readable.

All true. But what I said was,

> it can help you write stateless code if you assume immutability

Even that is only true for shallow objects

You can call `Object.freeze()` if you want immutable properties.

> Is it just me, or is Javascript (and more generally, all front end technology) more susceptible to these trivial holy wars?

What constitutes holy wars are often the most accessible[1]

[1] https://en.wikipedia.org/wiki/Law_of_triviality

The arguments are so bitter because the stakes are so low.

Reply on news.ycombinator.com