Hacker News Reader

Comment by acdha | Hacker News Reader

The idea is that leaving out a semicolon saves an almost imperceptible amount of time but requires you to be deeply familiar with the rules of every JavaScript engine, any minifiers/transpilers/etc. which will ever see that code, etc. and also commits you to rigourously applying that logic to every future change.

That's where I'd expect this to come up most frequently – someone writes code, tests it, it works and they move on but later someone makes a change and doesn't notice that the original author left a trap for them. It's easy to avoid that in the “ASI is cool” examples but real programs evolve over time and you never want to make maintenance programming harder.

View on HN

If you're writing idiomatic modern javascript you're using modules -- we no longer have the issue of two JS files being concatenated together in a shared lexical scope. The only rules you need to be familiar with are the 2 I mentioned. In my work, I've never thought about it as "imperceptible" time savings: I worked on a codebase without semi-colons, and then didn't want to go back. It was easier code to work with and write, and the feared downsides never materialized.

I still use them to conform with existing code bases or linters that require them, of course, but given the preference..

> It was easier code to work with and write

This is the part I'm still having trouble with – hitting ";" at the end of a statement is harder than having to look at the next line and reason about it? I mean, we're talking about a single character on the home row of most keyboards – just how fast are you cranking out code?

EDIT: just to be clear, I don't see this as a huge factor either way – a formatter can easily add or remove to your preference – so I surprised by the way ASI proponents talk about it as a big deal. To me it seems like a minor aesthetic preference on the level of “2 spaces or 4?” which doesn't meaningfully change the way you're writing code and is significantly outshone by something like switching to ES6, etc.

If you're using an editor to automatically pair your parens/brackets/braces/quotes, you now have to find and navigate to the end of the expression, which could be lines away if you're creating objects and arrays, or calling functions with complex arguments.

When coding, my cursor is rarely just "at the end of a statement" on its own. The only way it typically gets there is by me intentionally placing it there.

Refactoring is a bigger hassle as well. You may want to use the return of your statement as an argument to some new function. Now the semi has to be removed and added elsewhere.

It's not the end of the world, but it's a hassle.

I never have to "look at the next line and reason about it" -- you simply do not find yourself in a position very often of starting a line with an open brace. I'm not going to list all of the little reasons why I found it more enjoyable and easier to omit the semicolons. If you're interested, try it on a project yourself. Suffice to say, I found several cases where my life was just easier. Here's just one, from the very top of a file. It's easier to add another import to this list:

  let states    = require('../data/states.json')
    , cloneDeep = require('lodash/cloneDeep')

Again, I have tried this and fail to see any more benefit than, say, changing the indent size in my editor. Personally, I prefer

  let states    = require('../data/states.json'),
      cloneDeep = require('lodash/cloneDeep');

  let states    = require('../data/states.json')
    , cloneDeep = require('lodash/cloneDeep')

but that's an unimportant aesthetic preference. The structure of the code is the same and my experience working with it is fundamentally unchanged. In either case we're talking about a fraction of a percentage of the time it takes to understand what the application is or should be doing.

Now compare that to something which actually matters: arrow functions, classes, modules and imports, the newer data structures, generators, etc. In that case, the time spent adopting a new style actually changes the structure of the code you're writing and, hopefully, makes it easier to clearly convey your intention to the next person who works on it.

You have strong opinions about this. That's cool, and if you believe one way is more correct that's also cool. My advice to everybody is the same advice I gave you: try it. Try project without them and see. The only risk is that you might find out you're wrong. If you want to add them later there are tools for that.

> You have strong opinions about this.

It's odd that you appear to have ready my comments but missed the point where I repeatedly said that I do not have a strong opinion about this and was expressing my surprise that some people do.

Reply on news.ycombinator.com