4 ms·

I don't like using them everywhere, but they're very handy for inline anonymous functions. But it really pains me when I see export const foo = () => {} inst

I don't like using them everywhere, but they're very handy for inline anonymous functions. But it really pains me when I see export const foo = () => {} instead of export function foo() {}

creesch 2y ago
Thank you, that's something I also never have understood myself. For inline anonymous functions like callbacks they make perfect sense. As long as you don't need `this`. But everywhere else they reduce readability of the code with no tangible benefit I am aware of.
berkes 2y ago
I wish javascript had a built-in or at least (defacto) default linter. Like go-fmt or rust fmt. Or clippy even. One that could enforce these styles. Because not only is the export const foo = () {} painful on itself, it will quite certainly get intermixed with the function foo() {} and then in the next library a const foo = function() {} and so on. I'd rather have a consistently irritating style, than this willy-nilly yolo style that the JS community seems to embrace.
- throwitaway1123 2y ago
  ESLint and Prettier are the de facto default linter/formatter combo in JS. There are rules you can enable to enforce your preferred style of function [1][2]. [1] https://eslint.org/docs/latest/rules/func-style https://eslint.org/docs/latest/rules/func-style [2] https://eslint.org/docs/latest/rules/prefer-arrow-callback https://eslint.org/docs/latest/rules/prefer-arrow-callback
  - berkes 2y ago
    They are miles away from `gofmt` or `rust fmt` or `cargo clippy` and so on. It's not opinionated, but requiring you to form your own opinion or at least choose from a palette of opinions. It requires effort to opt-in rather than effort to opt-out. The community doesn't frown on code that's not adhering to the common standard or code that doesn't pass the "out of the box" linter. So, if I have a typescript project with a tree of some 20 dependencies (which is, unfortunately, a tiny project), I'll have at least five styles of code when it browse through it. Some JS, some TS, some strictly linted with "no-bikeshedding", some linted with configs that are bigger than the codebase itself. Some linted with outdated. Many not linted at all. It's really a mess. Even if each of the 20 dependencies themselves are clean, beauties, the whole is an inconsistent mess.
    - throwitaway1123 2y ago
      I personally believe that Prettier strikes a decent balance between being configurable vs being opinionated. I've used formatters that are much less opinionated than Prettier (e.g. the last time I used XCode it only handled indentation by default). ESLint also teeters on the edge between configuration vs convention quite well in my opinion, especially given the fact that browser JS and server side JS have vastly different linting requirements. I also love the extensibility of ESLint. Being able to write your own linting rules is a boon on productivity. Having access to custom framework specific linting rules is quite nice (I couldn't use React without the react-hooks/rules-of-hooks third party ESLint rules). > Some JS, some TS I think the JS community has done remarkably well amongst dynamically typed languages in settling on one form of gradual typing and adopting it fervently (Flow no longer has any market share at all). Whereas the last time I checked Python still had the Mypy/Pywright divide, and Ruby had the Sorbet/RBS dichotomy. Ultimately though, most of your critique boils down to the fact that JS (unlike Rust and Go) isn't maintained by a single monolithic entity, and therefore there's no one to dictate the standards you're looking for. If Deno were the sole caretaker of JS for example, we'd have a standard linter and formatter devoid of complex configuration, but Deno doesn't control JS. This is a consequence of JS being a collaborative product of the various browser vendors, TC39, and the server side JS runtimes that have adapted JS to run on servers. The advantage of this of course though is that JS can run natively in the browser. I think that's a decent tradeoff to make in exchange for having to wade through dependencies with different ideas about when it's appropriate to use arrow functions.
jappgar 2y ago
These aren't equivalent as function foo will be hoisted but const foo will not be.
- cxr 2y ago
  Sure the food that this restaurant serves is pricey, but you have to remember that it also tastes terrible.
- crabmusket 2y ago
  Yep, and that usually doesn't matter at the top level.
NohatCoder 2y ago
But do they make much of a difference? You have always been able to write: myArray.sort(function(a,b){return a-b}) People for some reason treat this syntactic sugar like it gives them some new fundamental ability.
- marcosdumay 2y ago
  Oh Javascript would be much better if it could only be syntactic sugar... `function(a,b){return a-b;}` is different from `(a,b) => a - b` And `function diff(a,b) {return a-b;}` is different from `const diff(a,b) => a - b;`.

I don't like using them everywhere, but they're very handy for inline anonymous functions. But it really pains me when I see export const foo = () => {} instead of export function foo() {}

creesch 2y ago

Thank you, that's something I also never have understood myself. For inline anonymous functions like callbacks they make perfect sense. As long as you don't need `this`. But everywhere else they reduce readability of the code with no tangible benefit I am aware of.

berkes 2y ago

I wish javascript had a built-in or at least (defacto) default linter. Like go-fmt or rust fmt. Or clippy even. One that could enforce these styles. Because not only is the export const foo = () {} painful on itself, it will quite certainly get intermixed with the function foo() {} and then in the next library a const foo = function() {} and so on. I'd rather have a consistently irritating style, than this willy-nilly yolo style that the JS community seems to embrace.

throwitaway1123 2y ago
ESLint and Prettier are the de facto default linter/formatter combo in JS. There are rules you can enable to enforce your preferred style of function [1][2]. [1] https://eslint.org/docs/latest/rules/func-style https://eslint.org/docs/latest/rules/func-style [2] https://eslint.org/docs/latest/rules/prefer-arrow-callback https://eslint.org/docs/latest/rules/prefer-arrow-callback
- berkes 2y ago
  They are miles away from `gofmt` or `rust fmt` or `cargo clippy` and so on. It's not opinionated, but requiring you to form your own opinion or at least choose from a palette of opinions. It requires effort to opt-in rather than effort to opt-out. The community doesn't frown on code that's not adhering to the common standard or code that doesn't pass the "out of the box" linter. So, if I have a typescript project with a tree of some 20 dependencies (which is, unfortunately, a tiny project), I'll have at least five styles of code when it browse through it. Some JS, some TS, some strictly linted with "no-bikeshedding", some linted with configs that are bigger than the codebase itself. Some linted with outdated. Many not linted at all. It's really a mess. Even if each of the 20 dependencies themselves are clean, beauties, the whole is an inconsistent mess.
  - throwitaway1123 2y ago
    I personally believe that Prettier strikes a decent balance between being configurable vs being opinionated. I've used formatters that are much less opinionated than Prettier (e.g. the last time I used XCode it only handled indentation by default). ESLint also teeters on the edge between configuration vs convention quite well in my opinion, especially given the fact that browser JS and server side JS have vastly different linting requirements. I also love the extensibility of ESLint. Being able to write your own linting rules is a boon on productivity. Having access to custom framework specific linting rules is quite nice (I couldn't use React without the react-hooks/rules-of-hooks third party ESLint rules). > Some JS, some TS I think the JS community has done remarkably well amongst dynamically typed languages in settling on one form of gradual typing and adopting it fervently (Flow no longer has any market share at all). Whereas the last time I checked Python still had the Mypy/Pywright divide, and Ruby had the Sorbet/RBS dichotomy. Ultimately though, most of your critique boils down to the fact that JS (unlike Rust and Go) isn't maintained by a single monolithic entity, and therefore there's no one to dictate the standards you're looking for. If Deno were the sole caretaker of JS for example, we'd have a standard linter and formatter devoid of complex configuration, but Deno doesn't control JS. This is a consequence of JS being a collaborative product of the various browser vendors, TC39, and the server side JS runtimes that have adapted JS to run on servers. The advantage of this of course though is that JS can run natively in the browser. I think that's a decent tradeoff to make in exchange for having to wade through dependencies with different ideas about when it's appropriate to use arrow functions.

jappgar 2y ago

These aren't equivalent as function foo will be hoisted but const foo will not be.

cxr 2y ago
Sure the food that this restaurant serves is pricey, but you have to remember that it also tastes terrible.
crabmusket 2y ago
Yep, and that usually doesn't matter at the top level.

NohatCoder 2y ago

But do they make much of a difference? You have always been able to write: myArray.sort(function(a,b){return a-b}) People for some reason treat this syntactic sugar like it gives them some new fundamental ability.

marcosdumay 2y ago
Oh Javascript would be much better if it could only be syntactic sugar... `function(a,b){return a-b;}` is different from `(a,b) => a - b` And `function diff(a,b) {return a-b;}` is different from `const diff(a,b) => a - b;`.