1. 8
  1.  

  2. 7

    Personally, I use let instead of const mainly just because let is shorter. I don’t care that it’s two characters shorter, but I find that let foo = 10, reads much nicer and flows smoother in my head than const foo = 10, when I’m reading the code.

    Also, const isn’t very useful in JavaScript IMO. When I’m writing C or C++, the biggest benefit of const is being able to use const int *foo to say “Never change the value pointed to by foo”. I don’t really care about accidentally reassigning a variable, as I’ve never ever had a difficult bug caused by accidentally reassigning a variable, but communicating that you don’t want some other code to change the values it’s given a reference to is useful. JavaScript’s const lacks that.

    1. 2

      Same. I don’t feel const has ever provided me any value but I do value better looking code.

    2. 3

      Fun fact, you can use const inside a loop as long as you dont try to modify it:

      const a1 = [10, 20];
      for (const n1 of a1) {
         console.log(n1);
      }
      
      1. 1

        Note that let won’t work in about 95% of browsers, never mind that the IE11 behaviour is broken enough that it most likely will cause bugs.

        A lot of devs consider these kind of numbers insignificant, and sneer at users for not using a “modern” browser. I don’t necessarily disagree that it’s annoying that people keep using really old browsers, but at the end of the day it’s a reality we’ll have to deal with. To me it seems somewhat akin to rejecting 5% of your customer base because you don’t like their backwards wearing baseball caps.

        1. 4

          Based on what I’m seeing on that site, (using the Usage Relative graphs), it does work in 95% of browsers. Granted, I suspect that most people using “let” are using it along with Babel, or they are explicitly targeting webapps that require a “modern” browser. Anymore, modern Line of Business webapps should have a pretty good feel for what their users are using.

          Personally, though, I try to write code that is at least compatible with Edge/IE11. That makes it eaiser to do things like host a website in a C# WebBrowser control.

          1. 2

            It all depends on what you’re making, of course, and “never use let” is clearly simplistic and wrong advice. But I almost never see this listed as a consideration at all, including on this otherwise resonable article.

            I always feel that “it does work for 95% of users” is the wrong way to look at it, and “it doesn’t work for 5%” is much more useful. I’ve been intending to make a version of caniuse.com which lists the browsers in which a feature won’t work, instead of the browsers in which it does work (edit: I actually went ahead and created this: https://github.com/arp242/cantuse)

            There are a number of other features which won’t work for (IMHO often significant) number of people, like arrow functions (~7%).

            Babel is nice, but also a complex build step, which has quite a few downsides. Especially for sites/apps with a limited amount of JS (which are most sites/apps), I don’t find the minor convenience that some of these newer JS features offer to be worth adding complex build steps.

            1. 1

              Well, realize that there are other developers that do check caniuse and co, and definitely try to consider less than mainstream browsers.

              I’ve definitely asked for consideration of less-than-mainstream browser in the past. It’s not something that I do all the time, however.

          2. 3

            The obvious solution (which you’ve already stated you don’t like) is to use Babel to transform to whatever browsers you want to support. Many people already do this.

            But quite frankly, the last 5% isn’t important unless it’s a business-critical segment, which seems increasingly unlikely. Edge was introduced nearly 5 years ago now. With its upcoming switch to blink, there’s even less incentive to cater to these old browsers.

            I think many of us operate on the 80/20 rule, and I’m extremely confident in saying the last 5% of users are an edge case that would only hurt productivity, developer happiness, and feature progress.

            If you want to cater to 100%, you probably shouldn’t use any JavaScript.

            1. 2

              I find those some bold statements: who says those users aren’t important for your business? Businesses reguarly make some fairly significant investments in e.g. advertising, rebrands, etc. to get 5% increase in their user base.

              I don’t think that there would be a massive loss in “productivity, developer happiness, and feature progress” by simply using var. Is let a bit better? Sure. Does it make a large difference? Not really.

              If you want to cater to 100%, you probably shouldn’t use any JavaScript.

              Surely 99.5% is better than 90% or 95%.

              1. 2

                who says those users aren’t important for your business?

                […] the last 5% isn’t important unless it’s a business-critical segment

                I think the person you’re replying to covered that concern? 🙂

                I have that 5%-but-critical-users case at my job: one customer, with only a handful of users, but they pay us a lot, so our app still works with IE11. I suspect, with knowing the details, that one of the reasons they pay us well is that we do continue to support them.

                1. 1

                  About 10% of the users at $work are using IE11, representing over half our paying users.

                  Medical sector :/

                2. 2

                  I’ve spent a number of years working in the health-care space, and that’s a world that’s notorious for horrid outdated tech – think ancient versions of Windows, IE6, the whole nine yards. Which means it’s not even a question of modern JavaScript being available, it’s a question of basic modern HTML/CSS.

                  And as strange as it may sound, I’ve seen multiple companies in that space adopt a strategy of “tell us your mailing address, we’ll send you a Chromebook”. Often that works out to be cheaper than figuring out some doctor’s office’s ancient operating system + browser and trying to cater to it.

                  1. 1

                    The difference between getting from 50% to 55% is vastly different than going from 90% to 95%, or even worse (in this case) 95%-100%.

                    It’s not a matter of “simply using var.” There is a lot of stuff in modern javascript that makes life miles better than it used to be.

                    1. 1

                      Yeah, but you can use all that stuff and still compile to es3 quite easily.

                      1. 1

                        They were talking about NOT wanting to compile things. If you’re adding a compile step, it really doesn’t matter at all obviously. You can target whatever you want.

                3. 2

                  That link says the exact opposite of what you just said.

                  1. 1

                    You can use a transpiler to sort that out. No need to manually use var.