4 ms·

I don’t find the arrow function version of (1) cleaner than the anonymous function version. Is it cleaner because you can fit it on one line? I don’t find the

I don’t find the arrow function version of (1) cleaner than the anonymous function version. Is it cleaner because you can fit it on one line? I don’t find the import version of (2) cleaner than the require() version. Having a boring old function that’s consistent with the rest of the language actually seems better than dedicated syntax, especially when that dedicated syntax is unnecessarily verbose. Copying Python’s might have been okay: // I have to repeat “fs” =( var fs = require('fs'); // Wait, I still have to repeat “fs” *and* it’s longer // *and* it looks more confusing? There’s no precedent // for this use of * in JavaScript. import * as fs from 'fs'; // Nice. import fs; I don’t find the `export default` version of (3) cleaner or more streamlined than the one that assigns to `module.exports`. It just seems like another waste of dedicated syntax.

tracker1 11y ago
how about... return myArray.map(item => `I am ${item}, yo!`); vs return myArray.map(function(item){ return 'I am ' + item + ', yo!'; }); There are a lot of one liners that are much more composable in the fat-arrow syntax. The default returns takes a lot of it out, and makes it simpler the simpler it starts. Beyond this, the above also uses templates, which you can even create custom processors for templates... var result = await sql` SELECT * FROM a WHERE a.foo = ${bar} ` You can create an sql processor that turns that query as a template into a parameterized query for the database, that returns a promise, which inside an async function can be awaited directly... I wrote a few libraries that did just that to make using sql, bigtable (azure tables), queues and other pieces really easy to use... With that I was able to write data migration scripts with ease... it was really awesome to see. Your second example is only if there's no default export... the local name doesn't have to match the name of the module, also modules can be `foo.bar` or `foo_bar` or `foo-bar` which can't be a single value within the script... so it creates a disconnect there, requiring the localized in-script name.
- minitech 11y ago
  > There are a lot of one liners that are much more composable in the fat-arrow syntax. The default returns takes a lot of it out, and makes it simpler the simpler it starts. They’re not more composable… they’re slightly shorter, and anything non-trivial doesn’t fit on one line. Template literals are nice, sure. > the local name doesn't have to match the name of the module, But when it does, everything is a lot more obvious. It works fine for all the Python modules, too.
  - tracker1 11y ago
    Try the following without fat-arrow syntax off of an object { foo: (a,b) => doFoo(this, a, b, 'fixed-value') } I find the fat-arrow syntax allows for much more dynamic flows that are easy to understand, more so than bind, and like the above, where bind wouldn't work. There's a lot of oneliner possibilities when you get rid of 12+ characters `function(){ return ` ... Also, I find the fat-arrow syntax looks better in a lot of cases, where you might use bind.

tracker1 11y ago

how about... return myArray.map(item => `I am ${item}, yo!`); vs return myArray.map(function(item){ return 'I am ' + item + ', yo!'; }); There are a lot of one liners that are much more composable in the fat-arrow syntax. The default returns takes a lot of it out, and makes it simpler the simpler it starts. Beyond this, the above also uses templates, which you can even create custom processors for templates... var result = await sql` SELECT * FROM a WHERE a.foo = ${bar} ` You can create an sql processor that turns that query as a template into a parameterized query for the database, that returns a promise, which inside an async function can be awaited directly... I wrote a few libraries that did just that to make using sql, bigtable (azure tables), queues and other pieces really easy to use... With that I was able to write data migration scripts with ease... it was really awesome to see. Your second example is only if there's no default export... the local name doesn't have to match the name of the module, also modules can be `foo.bar` or `foo_bar` or `foo-bar` which can't be a single value within the script... so it creates a disconnect there, requiring the localized in-script name.

minitech 11y ago
> There are a lot of one liners that are much more composable in the fat-arrow syntax. The default returns takes a lot of it out, and makes it simpler the simpler it starts. They’re not more composable… they’re slightly shorter, and anything non-trivial doesn’t fit on one line. Template literals are nice, sure. > the local name doesn't have to match the name of the module, But when it does, everything is a lot more obvious. It works fine for all the Python modules, too.
- tracker1 11y ago
  Try the following without fat-arrow syntax off of an object { foo: (a,b) => doFoo(this, a, b, 'fixed-value') } I find the fat-arrow syntax allows for much more dynamic flows that are easy to understand, more so than bind, and like the above, where bind wouldn't work. There's a lot of oneliner possibilities when you get rid of 12+ characters `function(){ return ` ... Also, I find the fat-arrow syntax looks better in a lot of cases, where you might use bind.