Comment by Slackwise | Hacker News Reader

Comment by Slackwise | Hacker News Reader

The most important thing I'd like to see is ASI ("Automatic Semicolon Insertion") removed/disabled in a stricter mode. Too many weird edges cases in the language exist, and it's now getting in the way of extending ECMAScript[1]. The only people who seem to disagree focus on the aesthetics of code over the clarity of explicitly telling the reader your intentions to terminate a statement.

Without ASI, the following would work as you'd assume, instead of returning `undefined`:

    return
    {
      answer: 42
    };

Just one of many ridiculous edge cases that would go away if ASI didn't insert a secret "helpful" semicolon at the end of the return line.

Rather than making me remember all the edge cases and rules [2] that keep growing with each new syntactical feature added to the language, we should just be making your code more explicit. The rules of reading the code are simply much more complicated than they should be with ASI, and many proponents don't even understand these issues, or suggest preposterous solutions to some of these edge cases such as inserting leading semicolons[3]!

Maybe put simply: Semicolons are sometimes required. Let's just make them always required.

[1]: https://www.theregister.com/2018/01/12/javascript_technical_...

[2]: https://tc39.es/ecma262/multipage/ecmascript-language-lexica...

[3]: https://standardjs.com/rules.html#semicolons

> The only people who seem to disagree focus on the aesthetics of code over the clarity of explicitly telling the reader your intentions to terminate a statement.

Okay, I'll bite. I don't think "aesthetics" and "clarity" are disconnected. Clear code looks nice, and nice looking code is clear.

I still adhere to a "no-semicolons-needed" approach. The edge cases are few, and I can't recall the last time I ran in to trouble because there was no semi-colon.

People not including that trailing comma out of IE-era habits is something that bites me far more often (although you do get an error, but Firefox at least will also issue an "unreachable code" error in your example).

There's often real tradeoffs between explicitness and readability, but yeah, I don't think semicolons are one of them. By definition they're completely out of the way (at the end of statements).

I have the same problem with JS devs removing file extensions on imports. You're just removing useful information from the code, that's sitting in the most out of the way place in the file (right at the top before anything is even happening), for absolutely no good reason. And replacing it with build time magic in some 3rd party tool. That's such a terrible tradeoff it's almost unfathomable to me that an experienced programmer would willingly make it, let alone double down and argue for it if the topic is brought up.

You even get the same ridiculous post-hoc justifications for it too. "Oh but what if I want to change a JS file to a JSON file? I'd have to change the extension!".

Unfortunately file extension removals gets into another weird space, where Typescript (well, `tsc`) won't rewrite your extensions, so if you add them you have to write "foo.js" even though the source file is "foo.ts" (at least in ES modules).

This gets solved by using some sort of packager, but it's another sort of bit of ugliness that doesn't feel like it's going to get resolved anytime soon.

GLSL requires a semicolon or it won't work if you miss one accidentally.

For me, personally, I find it easier to remember putting a semicolon in special cases than to remember putting one after each statement.

Ah, are we revisiting the great JavaScript semicolon wars of 2012? The logical conclusion that was reached was a language consisting entirely of semicolons:

https://pksunkara.com/semicolon/

The comments on HN:

https://news.ycombinator.com/item?id=3854130

Further context:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Reply on news.ycombinator.com