Hi everyone,
I was being curious about what’s under the hood. And I checked the implementation of elm/virtual-dom and I was wondering why would var be used instead of const ?
Is it for compatibility reasons ?
1 Like
Very old browsers don’t recognise const.
I think it must be for compatibility reasons, I wonder how elms browser support looks like, never read anything about it…
Here’s discussion about old IE support from February 2018. At least back then IE 9-10 should be possible to get working.
Now according to Can I Use, IE 9-10 don’t support const at all, and even IE 11 doesn’t support it fully.
Yup backwards compatibility. And there’s just no reason to use fancy new things when the code isn’t intended to be read/edited by people. Also heard that var is marginally faster.
1 Like
Also it’s two characters shorter - which probably doesn’t mean much if gzipped, but if there are no downsides, why not save a bit?
1 Like
Yeah that is what i was thinking. Thank’s for your answers.
I think "const everything" is an ugly anti-pattern in modern JS. Read this and you will understand why:
So much brain power is being wasted on this bad habit these days.
const is useless most of the time (as you can still mutate object) and const is semantically wrong (it’s not what you expect a constant to be in 99% of other programming languages out there). Being able to reassign a variable is never a problem in Python, Ruby and almost every scripting languages. Why would this be one in JS? (Remember we can’t use const on functions parameter, did it ever cause a bug in your code ?).
1 Like
That doesn’t mention var even once.
var is kind of deprecated in modern JS because of its weird behavior:
https://hackernoon.com/why-you-shouldnt-use-var-anymore-f109a58b9b70
Basically, we should use let instead (and occasionally const when it makes sense, for example for primitive constant values like const PHI = 1.618).
(Elm compiling to var is not a problem IMO, the code will work as expected and it has the benefit of being backward compatible with old browsers.)
1 Like
Well, the idea of fixing the pointer to something (but you can still interact with the object) is not new. Java, C#, C++ etc have this idea. C# has readonly for example which has the same effect.
Also when you pass an object to a function, guess what the function cannot change what the caller is referring to at all, but you can mutate the object. So that concept is already in OO programming languages.
So while it is not as perfect as ML languages where if someone passes you an object you cannot mutate it to the suprise of the caller, const does provide some value in documenting that something wont change.
Figuring out what to use is easy. If you are in a loop, use let. Otherwise use const. 99% of the time that is what you want. You rarely want to mutate references or values of local variables. Otherwise you have come up with a name for something and then changed it, so how do you name it? Based on the “first” meaning or the later meaning?.
Example
// Here, score means zero
let score = 0;
// … typical business code here … imagine lots of lines of other stuff …
// Here, score means goals, but not penalties
score = score + goals;
// … typical business code here … imagine lots of lines of other stuff …
// Here, score means score
score = score + penalties;
// … typical business code here … imagine lots of lines of other stuff …
You can not move lines around in this business logic without checking what score means at that point.
vs.
const score = goals + penalties;
// … typical business code here … imagine lots of lines of other stuff …
So I’m a fan of const, although more of a fan of referential transparency!
I think a major point that’s easy to miss is that Elm is treating JavaScript as a compile target as a first priority. The hand written parts are secondary.
For compiled JS the const/let/var debate doesn’t really matter because the Elm compiler is providing the guarantees, not the JS style.
Most of the points people make about let and const are focused on the pros and cons for hand written JavaScript. But for generated code, if you already have better guarantees than anything in native JS, then you might as well just pick whatever has the broadest compatibility. (Especially at the time when the decision was made several years ago.)
The hand written kernel code just follows the overall style of the compiled code, so it uses var as well. No point reducing compatibility for that because kernel code is only a secondary priority.
So I think for Elm this question has a very different set of constraints than “normal” JavaScript application code, and that changes the priorities a lot. I would never write JS application code this way at work, but I think it makes sense for a compile target.
7 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.