3 ms·

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 inten

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".

fiatjaf 10y ago
Flow doesn't run on my home computer nor in my personal VPS I use for development. It also doesn't run in my Linux girlfriend's computer which I use sometimes, or the computer I sometimes use at work.
peterjmag 10y ago
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 10y ago
  >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 10y ago
    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.

fiatjaf 10y ago

Flow doesn't run on my home computer nor in my personal VPS I use for development. It also doesn't run in my Linux girlfriend's computer which I use sometimes, or the computer I sometimes use at work.

peterjmag 10y ago

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 10y ago
>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 10y ago
  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.