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