[annoyingconst92]

Except `const` ruins interactive rapid prototyping using the browser DevTools console. If `width` was declared `const width = 800` you can't interactively experiment by setting `width=1024` because you get `..TypeError: Assignment to constant....`

[johnfn]

I mean, it's literally a constant. Of course you can't redefine it. You said it was a constant! :P That's like saying that declaring a variable as "8" instead of 8 ruins rapid prototyping because now you can't multiply it.

[Dylan16807]

More like replacing declarations with magic number literals. And that does hurt interactive prototyping if it happens a lot!

[annoyingconst92]

> Of course you can't redefine it.

Well, you can redefine it by editing its source code file on disk. (Unless the file is read-only.) But it's a lot faster to be able to redefine it interactively inside the DevTools console and I wish there was a "dev" setting that allowed this. Also, you said "you declared it" but usually it wasn't me who declared it constant. Rather, some other programmer thought `width=800` or `numColumns=80` should be declared constant. "Variables aren't; constants won't be." No coder is an island: one programmer's bad `const` can't make life harder for other coders. Related: One reason I use Chromium browsers instead of Firefox is because in Firefox DevTools console once you declare `class A {}` you can't interactively change it to, say, add a constructor like `class A { constructor (foo) { this.foo = foo } }` During learning and experimentation this is lousy; you can't interactively iterate at the console prompt like a proper dynamic language. You must instead put your code in an external file and set up a "save file and re-run everything" system just like static languages like C++ require.

[ficklepickle]

I'm also a big fan of hacking away in the browser console. Can't you use the `let foo = class {}` syntax for iterating on classes?

[annoyingconst92]

If you are the one writing entirely new code then you can choose to do that. But if you must build upon the work of a different programmer who is not you and that programmer chose `class Foo{}` instead of `Foo=class{}` then the codebase is now rigid and inflexible for purposes of prototyping and experimentation. You are going to have to save the JavaScript to a disk file and edit it there to get rid of the non-redefinable `class Foo{}` or `const numColumns=80`.

[eccenux]

class A defines a let variable. It's how the standard define it.

You can replace A with: A = class {...}

This works with any browser.

BTW. In Firefox there is a multi line editor. With code completion. I actually find more convenient to test large code fragments in fox because of that.

[annoyingconst92]

Good tip, thanks, but it means that code written like

  class A {}

has a huge difference from code written like

  A = class {}

In classical JavaScript consider how small the difference is between

  function foo () {}

and

  foo = function () {}

Function hoisting only works for the "function foo(){}" form so there's a difference but they intuitively work essentially the same and either form works well when experimenting in the console. If enough rules like "class A {} is very different from A = class {}" are piled onto JavaScript it's going to become like C++, a language so complex that people would rather learn a simpler language so they can focus on the complexities of their actual problem space rather than the complexities of their language. A new language called Zig is now trending upward because a growing number of programmers would rather have a language they can 100% understand after a reasonable time investment rather than a language like C++ where even after a 20 year career with it and implementing portions of a compiler for it you still get painfully surprised by some obscure rule interaction you never dreamed to imagine possible.