It’s arguably more complex to adopt a style that uses semis, since it’s not obvious when you should put them in or leave them out. An example in this post: https://feross.org/never-use-semicolons/ … An argument that omitting is easier for beginners to JS: https://m.youtube.com/watch?v=gsfbh17Ax9I …
-
-
The rules to omit semis will get more complex with class properties, won’t they? And it’ll be harder to explain than current rules. I get that it’s not always obvious where semis can be omitted but putting them in more spaces than necessary won’t break anything; omitting can.
1 reply 0 retweets 2 likes -
The rules will only get more complicated if TC39 members intentionally disregard the needs an entire group of JS users for expediency’s sake (handling ASI properly is more work) or because they want to kill a style they personally don’t like (probably true of a few members)
5 replies 0 retweets 2 likes -
I mix between both styles, so I am not trying to make a judgement here. But I think it is imperative of leaders in our industry to check themslves when they word things as strongly as this. It strongly implies ill intent by the tc39 members. Which I highly doubt there is.
1 reply 0 retweets 0 likes -
The public comments of the tc39 proceedings show that certain members have open disdain toward the semi-less coding style. I think it's probably based on misunderstanding the real-world risk of the style (thinking it's a much worse idea than it is) and not on ill-will.
3 replies 1 retweet 5 likes -
Replying to @feross @wesleytodd and
For example, see this exchange: "KCL: A quick run through GitHub's codebase, which uses standardjs and omits semicolons, found only four places that required semicolons, related to Array destructuring assignment. YK: Are you sure the rest of the code is correct?"
2 replies 0 retweets 0 likes -
Replying to @feross @wesleytodd and
In practice there are very few ASI edge cases in real-world code – even in huge codebases like GitHub's. But YK's impression is that there *must* be hidden errors, even though he knows that
@StandardJS (ESLint) catches and warns about unexpected ASI, so there can't be ASI errors.2 replies 0 retweets 2 likes -
-
How do you feel about making semis mandatory for class fields? That was the other option (the recommendation was a compromise) but it seemed more heavy handed than the recommendation.
1 reply 0 retweets 0 likes -
I personally think consistency is important in a code base, so required ;s in classes in a no; codebase would not be my first choice. Reading the GH issue makes it clear TC39 thinks the ASI hazards will increase, so the warning seems like a good thing IMO.
2 replies 0 retweets 0 likes
Right, this is where we landed. We don't want to impose semis on no-semi users. Serious no-semi users won't listen to us anyway and have linters. Casual no-semi users (memorizers) might become aware of the new hazards through the recommendation. Might switch to linters.
-
-
As I was trying to point out in my original tweet, there is clearly no ill intent or motives here. It is just everyone trying to improve the language and learning experience for devs.
1 reply 0 retweets 1 like -
Replying to @wesleytodd @feross and
Ironically, the recommendation came from a strong desire by TC39 members (including a
@github representative strongly supporting no-semi style) to avoid making semis mandatory for fields and force no-semi users to use 'em.0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.