
StandardJS just turned 10.0.0 - feross
https://standardjs.com/changelog.html#1000---2017-04-04
======
RyanCavanaugh
So what's the goal of this project? From the announcement it says

    
    
      there are lots of new rules in 10.0.0 designed to help catch bugs and make programmer intent more explicit.
    

Then in the FAQ it says

    
    
      Can I use a JavaScript language variant, like Flow?
    
      Before using a custom JS language variant, consider whether the added complexity (and effort required to get new contributors up-to-speed) is worth it.
    

The goal of variants like Flow is to catch bugs and make intent more explicit!
We have to consider if it's worth training up new contributors on this, but we
don't have to consider the contributor cost to learn all of feross's personal
JS style preferences and API opinions?

I get the goal of having a uniform style - that's important and valuable, even
though StandardJS's decisions don't match the style predominant in the JS
community. But it seems like there's been a lot of scope creep here where now
there are specific rules for specific APIs and other stuff that is well
outside the domain of "Let's all format our code the same".

~~~
peterjmag
_even though StandardJS 's decisions don't match the style predominant in the
JS community_

I find it particularly ironic that there's a reasonably popular fork called
semistandard. [1]

In all seriousness though, I'd really love to see the JS community move
towards tools like prettier[2] instead of continuously trying to establish
"one eslint config to rule them all". I just want each repo I work with to
configure my editor for me and reformat stuff automatically (a la gofmt) so I
can forget about it. Even if some of the particular style decisions are ones
that I personally don't agree with, it doesn't matter — the value of having
those decisions abstracted away from me in the first place is significant
enough that any minor quibbles fade away pretty quickly. Then I can focus on
writing and reading code, not on arguing about whether we should enforce or
disallow dangling commas in our lint config.

[1]
[https://github.com/Flet/semistandard](https://github.com/Flet/semistandard)

[2]
[https://github.com/prettier/prettier](https://github.com/prettier/prettier)

~~~
Nadya
_> Even if some of the particular style decisions are ones that I personally
don't agree with, it doesn't matter — the value of having those decisions
abstracted away from me in the first place is significant enough that those
quibbles fade away pretty quickly._

So... Standard?

I use Prettier and pipe the output my own eslint file. Could do the same but
Prettier | Standard. Or Semistandard. Or whatever.

The issue is the community largely values their personal styles (ignoring
choice of semicolon omission) too much to standardize on "one style to rule
them all". Because everyone (including myself) "I like this except these _two
little things_ " and everyone's two little things are different so you end up
with 200 different lint configs each mostly similar but with their own little
tweaks.

~~~
peterjmag
I guess what I was trying to say is that I wish the JS world had had its own
gofmt/refmt from the get-go. But since it didn't, the community's still pretty
undecided more than 20 years after the language came into being, and I don't
see that changing significantly any time soon. I don't know, maybe it's "too
late"?

Not that I think golang got it exactly right either, but because the style
guide was essentially built into the language from the start, the change
process is necessarily slower and more intentional, and I think that's a good
thing.

------
imcotton
Call me old faction or what, but semicolons and 4 spaces indentation, I'm off
the grid, so long for so called "Standard" JS.

~~~
andrewmcwatters
I agree. Furthermore, it is really deceitful to use the name "Standard" when
it's far from it. For years this was not the standard way of writing
JavaScript. I get that standards change. However, this isn't even the way most
companies write JavaScript.

The way I interpret this: some group of developers thought it would be a good
idea to hijack the word "standard," and wedge this particular new style into
the concept. It just isn't standard. It's as absurd as having a company called
"Blue Shine" and selling only green colored cleaning products.

At least be honest about it. Call it something else, like "Colonless," since
that's the most obvious thing that sticks out when using this style.

~~~
TAForObvReasons
> it is really deceitful to use the name "Standard" when it's far from it.

reminds me of the debacle around "Standard Markdown", now called "CommonMark"

------
ronilan
Feross (of YouTube Instant and Webtorrent fame) did a great branding job on
this. However, from my own limited experience, this is an unneeded layer on
top of the fantastically good ESLint.

~~~
fiatjaf
I used Standard for a while, because it matched my personal preferences almost
100%. Some day, however, I decided to do a small modification. Now I'm alone
with my own eslintrc and my own dotfiles management.

~~~
timdorr
You can just extend the eslint config and disable or tune any rules you don't
like: [https://github.com/feross/eslint-config-
standard](https://github.com/feross/eslint-config-standard)

------
codedokode
This is an awful project. Someone took his own preferences for code style and
tries to make it look like some "standard".

The parts that I don't like the most are 2 spaces for indentation (why so
small? who else is using such small indentation?) and "no semicolons" rule.

It would be better to adopt some style guide from Java, because JS has similar
syntax and because Java has been in use in large projects for a long time.

------
tzaman
I've been always meaning to try this out but always just keep reusing the
ESLint config, which is probably a bit out of date now. So the question is,
could someone explain to me (and everyone who has these same thoughts) why is
StandardJS worth a try?

~~~
Lazare
If you want a prebuilt eslint config, and you don't like the really popular
ones (eg, airbnb[0]) because they default to requiring semicolons, then this
is definitely the most popular of the ones that require you to omit
semicolons.

Beyond that, there are no advantages. It's just a decent eslint config that
requires you to omit semicolons wherever possible. If that's important to you,
use it. If it's not important, or you'd rather not omit semicolons, or if you
_do_ want to omit semicolons but you're happy making a one line change to the
airbnb preset, then there's nothing to set this apart from more, if you'll
pardon the expression, "standard" options. :)

[0]:
[https://github.com/airbnb/javascript](https://github.com/airbnb/javascript)

~~~
ikurei
You can just disable that rule and use the rest of the airbnb preset, which is
what I'd recommend. I hate semicolons, and I do a couple of things that I like
but airbnb apparently doesn't, so I override those settings on my .eslintrc
and use the rest as a great foundation.

~~~
Lazare
Exactly.

I think airbnb is a really good base for a project.

------
vram22
I thought for a moment that this was a joke, like the one about the vanilla JS
tool, long ago, here. That was a good one.

------
k__
How does it compare to Prettier?

~~~
timdorr
Prettier is a formatter. It doesn't check for errors, it merely parses JS and
enforces a style. It actively corrects any style problems that are found.

Standard is a linter (ESLint) configuration and frontend. It doesn't correct
errors, just checks for them. It goes beyond style to actually check for
logical errors (usage of deprecated APIs, invalid regexps, etc).

In theory, you can run the two together. Ideally, you'd use plain ESLint with
a config geared around catching programming errors, and leave Prettier for
just styling concerns.

------
partycoder
StandardJS is like TornadoGuard from xkcd.

[https://xkcd.com/937/](https://xkcd.com/937/)

Very good reviews, but it doesn't achieve the grandiose things it claims to
achieve.

While consistent indentation is important, a coding standard is much more than
that. I consider this to be an actual standard:

[https://google.github.io/styleguide/jsguide.html](https://google.github.io/styleguide/jsguide.html)

For example Python enforces consistent indentation, but you know that there is
still a lot of room to create a mess even with those restrictions.

StandardJS was designed to maximize adoption, not to ensure actual quality:

\- Want a 1,000 characters long line of code? StandardJS badge of approval.

\- Want a 10,000 lines of code function? StandardJS badge of approval.

\- Want a function with a cyclomatic complexity of 10,000? StandardJS badge of
approval.

Those are very basic measures of code quality and StandardJS does not have an
actual position about them.

Then... StandardJS actually goes against good practices. Omitting semicolons
actually has an effect in JavaScript, and there are many examples of that. The
Google JavaScript coding standard advises specifically against it for good
reasons. Remember that Google created v8, and has a lot more authority in this
matter than whoever created StandardJS.

ESLint can enforce a cyclomatic complexity limit, number of statements per
function, lines per file, etc.

~~~
wolfgang42
There's a lot of FUD around Automatic Semicolon Insertion for some reason.
Basically, the parser inserts a semicolon anywhere where the program is
otherwise unparseable but a semicolon would make it syntactically valid.
Importantly, this will occur _even if you are otherwise using semicolons,_ so
simply saying that you need to manually put the semicolons in doesn't help the
situation since the parser may add them for you in places you didn't expect
anyway. Leaving them out forces you to know the rules, but you should have
known them anyway since otherwise they will bite you at some point.

ESLint provides--and StandardJS uses--the `no-unexpected-multiline` rule,
which will insist that you insert semicolons in places where the meaning would
otherwise be unexpected. In practice, with `semi` set to never and `no-
unexpected-multiline` enabled, I find that I have _never_ had a problem with
semicolons that was not caught by the linter. By contrast, when I was afraid
of ASI (since "omitting semicolons actually has an effect", eek!) I would find
that I'd occasionally have mysterious issues where arrays were interpreted as
indexes and so on. (I switched to semicolonless-style at the same time as I
started using a linter, so I can't compare the two independently.)

~~~
partycoder
There's a lot of FUD around not using a seat belt. Basically, if you are
careful to not crash your car, your seat belt should not be necessary. You can
die even if using a seat belt.

My standard of car safety relies on that each time you crash your car, a red
light will flash telling you that you have crashed your car. It is very
effective detecting car crashes, therefore, very safe.

~~~
randallsquared
Hm. In the case where the ASI inserts a semicolon where you wouldn't have
expected one, how do the semicolons you already added where you _would_ expect
them help? Using semicolons in JS to avoid problems is like making sure the
seatbelt is securely fastened across the seat before you sit down: there's a
satisfying click and the worrying light on the dash goes off, but it won't
actually protect you in an accident.

------
draw_down
I used to be on a team that wrote JS this way and I really enjoyed it. Now I'm
in a Flow/React/semicolons-and-classses-everywhere type place. I find this
style so much more pleasant.

~~~
0xCMP
It's almost like it doesn't matter unless it's consistent ;)

~~~
draw_down
Well, I agree with that and all. But why type (and more importantly, look at)
a bunch of semicolons if you don't have to, ya know?

~~~
RyanCavanaugh
Its a good question readers of the English language can also infer punctuation
where needed it's not considered good style to make readers infer this there
can be some oddness if you are not used to putting punctuation where it
belongs naturally garden path sentences can result and some tools can detect
ambiguity automatically but why learn some custom rules for that when its
straightforward to consistently put periods at the end of sentences

~~~
robertbenjamin
Damn, this is clever!

Except that 'punctuation' in JavaScript comes in the form of a line break, and
adding a semicolon is like adding two periods to the end of every sentence
just in case someone missed the first one.

