Let vs Const vs Var in ES6

In my mind, one of the best additions to EcmaScript 6 over previous versions is the inclusion of Let and Const keywords to use when defining variables, as opposed to the old Var keyword. The Var keyword still exists in ES6, which has led to a debate about which is better, or when to use each keyword. For any readers not familiar with the difference between these three, I’ll outline them here.


The Var keyword, as you’d expect defines a variable. This variable is given “function scope.” When I first started studying JavaScript, before ES6 was released, this gave me headaches to no end. Out of the 16 different programming languages I know, JavaScript is the only one I’ve encountered that uses this “function scope.”


The Let keyword, new to ES6, is very similar to Var, with one key difference. Variables defined with Let are given “block scope.” Block scope, being very common among programming languages, makes it much easier for experienced developers to use.


Rather self-explanatory for experienced developers, the Const keyword defines a constant. Don’t ask me why the core JavaScript team waited this long to add constants to their language, or how the devs dealt with that.

The Debate

Now that I’ve outlined the difference between the two, we get to the debate. Should you still use Var? Should Const be restricted to proper constants, or should it be your default?

For starters, I looked at a blog by Mathias Bynens. He suggests that Var should be forgotten about when writing ES6. Personally, I’m inclined to agree. As I noted above, the function scope that Var gives is very unusual in the programming world, and caused me a great deal of headaches.

Now, Mathias also says that your default should be Const, and that you should only use Let when you know that you’ll change the value. He also refers to the idea that “Const is for constants” is a misunderstanding.

This is where I disagree. It should be fairly obvious that Const is short for constant, and thus, it should be treated as such. In my research, I came across a website that compares runtime performance of code when using Var, Let or Const. Running these tests numerous times, I have not seen any performance advantage in using one over the others. So I see no particular reason to default to using constants for everything.

What I suggest is this. Unless you are absolutely certain that the variable you’re declaring will not change values, I suggest using Let. That way, if you find a point that you need to change the value, you won’t have to go hunting for that declaration. After all, they’re called “variables” for a reason.


Working with command line arguments in Crystal

Being a compiled language, Crystal is great for creating command line tools. But what’s a command line tool without options? Well, that’s where command line arguments come in.

In line with the goals of the Crystal language, working with command line arguments in Crystal is very similar to doing so in Ruby. The constant even has the same name.

In this tutorial, we’ll be building a simple command line tool that shows the current time, complete with a usage guide.

Let’s start by creating a file that we’ll name cl-tutorial.cr. Since command line tools always have a help page or usage guide, we’ll create one of those first.

A simple way to create a multi-line string in Crystal is with a heredoc. From Crystal’s documentation:

A “heredoc” starts with <<-IDENT, where IDENT is an identifier: a sequence of letters and numbers that must start with a letter. The “heredoc” finishes with a line that starts with IDENT, ignoring leading whitespace, and is either followed by a newline or by a non-alphanumeric character.

In this case, we’ll use STRING as our identifier, and assign it to a variable named usage. Enter this at the beginning of your cl-tutorial.cr file:

usage = <<-STRING
Usage: cl-tutorial [option]

    time, --time, -t show the current time
    help, --help, -h show this help
    version, --version, -v show version


As I said earlier, Crystal handles arguments pretty much the same as Ruby, with an array with the name ARGV. In this example, we only have one argument, so we’ll be accessing it as ARGV[0].

Since there are 3 different options, we’ll use a case-switch structure to check the argument:

case ARGV[0]
when "time", "--time", "-t"
  puts "The current time is #{Time.now}"
when "help", "--help", "-h"
  puts usage
when "version", "--version", "-v"
  puts "CLI Tutorial v0.1.0"
  puts "Unrecognized option"
  puts usage


Now, running a program with arguments using the Crystal compiler requires a little extra work. You have to add to hyphens (–) between the file name and the arguments themselves. Keep in mind that you only need those hyphens if you’re compiling and running in one step, not when you’re running an executable. So you can either run this with the help option this way:

$ crystal cl-tutorial.cr -- -h

or this way:

$ crystal build cl-tutorial.cr
$ ./cl-tutorial -h

and you should see the help menu output.

The app mostly functions now, but it has one critical error. If you were to run this program without any arguments, you’d get an error, due to ARGV being an empty array. In Ruby, this would trigger the else clause of the case-switch statement, so it’d be ok. However, because Crystal is statically typed, ARGV[0] on an empty array triggers an out of bounds error.

This is easy enough to fix however. We’ll create an if-else statement, and place our current case-switch inside the else of said if-else statement. Add these three lines prior to the case:

if ARGV.size == 0
   puts usage

and then add another end after the case. Now, your case statement will only be evaluated if the ARGV array is confirmed to be non-empty. If you’d like, you can confirm this by going back to your command line, and entering:

$ crystal cl-tutorial.cr

without any arguments. The output will be identical to what you saw earlier when you added — -h to the end of the line.

Now our simple program is complete. You can even test out the time function by running:

$ crystal cl-tutorial.cr -- -t

If you’re having any issues, you can compare your program to the original on my github page. Otherwise, feel free to let me know in the comments section.

Why I Love React (Even Though I Don’t Like JavaScript)

I’ve been learning Reactjs for about a year now, using it for my first freelance gig and my personal website. The more I use it, the more convinced I am that React represents the future of the internet.

What brought me to this conclusion is actually something that web developers don’t think about, and that’s the Internet of Things. Whereas the internet was originally built for people to access, now we have to share it with automated devices. So what does that mean for the future of web development?

What this means, is that as the IoT grows, so will the importance of web APIs. While it’s possible for a machine to read and parse HTML, it’s just not practical. It’s far more practical and efficient for a device to receive the data directly in JSON or GraphQL format. People on the other hand want their information presented in a visually pleasing way.

This is where frameworks and libraries like React come in. The back end, instead of serving up HTML as well as JSON, can be focused on providing just JSON. Then, the front end can be created separately, and serve its responsibility as an intermediary between the data, and the human who wants to read it.

I will not be surprised if future trends have a greater separation between back-end frameworks that focus on serving up raw data, and front end frameworks that focus on providing a human interface for that data. That seems like the best way for people and devices to use the same internet.

My New Blog

Hello everyone,

I’m a software developer in Mississauga, Ontario. After creating my own blog software, and hosting that for a year, I’ve decided to move to the more established WordPress platform. I’ll be using this blog to share my knowledge of Ruby on Rails, ReactJS, the new Crystal programming language, Raspberry Pi and occasional thoughts on the state of the technology industry.