Why Omit Semicolons?
This is a highly controversial topic to say the least, but let's give credit where credit is due. While some may passionately insist that there is only one correct way to write your code, both sides offer some compelling arguments. Well, perhaps it's easy to understand why you would stick with the familiar syntax, but why would you ever want to change it? There are mainly two arguments.
It looks cleaner.
Although defenders of the semicolon have been known to criticize the legibility of this, especially in the case of multiline expressions like ternaries, the objective truth of the matter is there's less text on the screen. Some say it's confusing when they're missing, but perhaps it's the designer in me that can sympathize with even a mild case of information overload. Sometimes, white space makes it easier to focus on the important stuff.
It's an easier transition if you're used to languages like Python or Go
Python and Go, among a handful of others, do not use semicolons in their native syntax. When developers become accustomed to one environment for so long, and then switch over suddenly, sometimes it's better to minimize the likelihood of making a mistake by keeping the syntax similar wherever possible. Furthermore, computer languages are ultimately human, as humans are expected to read and write them. Being a human experience, it could be stated that we should respect the humans behind it, and make the overall development process a more pleasant one.
What are the Risks?
As anyone who has any experience in projects without semicolons may tell you, there are some cases known as ASI (automatic semicolon insertion) hazards , which can cause problems in your code. For many, that alone is enough reason to oppose the semicolonless approach. For example:
const greeting= 'hello'
(() => console.log(greeting))()RESULT: Uncaught TypeError: "hello" is not a function
If you're confused by that result, let's simplify it to a shorter version of what just happened.
'hello'()RESULT: Uncaught TypeError: "hello" is not a function
This is actually how the JavaScript parser interpreted the first block, because there was nothing to indicate a line ending above it. This is a limitation of JavaScript ASI. Even though you leave your semicolons off, the parser will come in and add them for you just before running the scripts, but in some cases like the one above, it gets a little confused. You can remedy this by adding a semicolon at the beginning of the line in just those cases, but a much cleaner method may be avoiding the IIFE altogether. Just explicitly define your function and then run it.
const greeting = 'hello'
// this is okay
;(() => console.log(greeting))()
// this is better
const sayHello = () => console.log(greeting)
sayHello()This issue is not limited to IIFEs, however, they just may be one of the most common cases. It's for a number of different characters, notably ( , [ , ` , and / .
Regardless, there is a way to always prevent this kind of issue, even in a team environment. Thanks to modern editors, we can just adopt the no-unexpected-multiline rule for ESLint to enforce it project-wide.
Who Decides the Best Practice?
Usually, they are industry leaders, like Jacob Thornton (co-creator of Bootstrap) and Douglas Crockford (creator of tools like JSMin, JSLint, popularized the JSON format.) But even these two titans can't agree in a famous exchange on a GitHub issue thread. In response to Thornton suggesting there was a bug in JSMin when it wouldn't build due to a missing semicolon, Crockford stung back, "Learn to use semicolons properly." Thornton wasn't shaken by this comment, however, retaliating with "I have learned to use them, that's why there isn't one present."
Then along came StandardJS, a popular effort to create a universal style guide, and they actually encourage the omission of semicolons .
In another twist of events, along comes TC39, who writes the actual language spec, recently discouraging their omission . This stirred up plenty of controversy in the comments, with some even referencing the aforementioned StandardJS.
At the end of the day, there is no objectively correct answer. The most correct thing you can do is follow your team's style guide, whatever that may be. Be wary of bikeshedding , but do whatever you want to do in your own personal projects! I personally prefer the whitespace over the excess visual noise, but my preference isn't a law by any stretch.