10 ms·

I've never understood JScripters' insistence on anonymous functions instead of named ones. As someone just delving into Node from another platform what're "pro

by ameen 11y ago

I've never understood JScripters' insistence on anonymous functions instead of named ones. As someone just delving into Node from another platform what're "proper best practices"-based JS patterns?

aus_ 11y ago
http://callbackhell.com http://callbackhell.com is a good starting point.
- riebschlager 11y ago
  I was on board with that website until I couldn't find a single semicolon. Then my eyeballs started twitching.
  - Killswitch 11y ago
    Love me some non-semicolon JavaScript.
aswanson 11y ago
Yeah, I've always been suspicious of anon functions in any language, but jscripters take it beyond absurdity.
aaronem 11y ago
Best (professional) practice is to use named functions, with lambdas reserved for one-offs which are so genuinely trivial that promoting them to named functions would do more to clutter your code than to streamline it. It's telling that, while you do often see Javascript (not JScript, which is a Microsoft product and quite obsolete) developers pull some crazy nonsense with deeply nested lambdas, you almost never see Javascript developers do that in an environment that requires peer code review.
- ameen 11y ago
  I used JScripters as a short-hand. I'm well aware of the stigma surrounding JScript :P I've come across many JavaScript devs casually using and advising interns, etc to use anon functions to avoid cluttering code. It was almost preached as a design pattern. I was taken aback (as a back-end dev), but given the crazy stuff most JS devs did I just shrugged it is one of the platforms' quirks.
  - deleted 11y ago
    [deleted]
  - aaronem 11y ago
    JScript isn't a shorthand for Javascript. It's a name for an ill-favored heterodox implementation of ECMAscript. Using it in the fashion you have here will therefore cause knowledgeable engineers to assume you must not know what you're talking about. Of course, you're welcome to continue doing so nonetheless. Using lambdas in the fashion you describe is a dangerously poor practice that, over the long run, produces code that's much harder to maintain than it should be. That's why you don't see it in environments where changes have to pass peer review by experienced Javascript engineers before being accepted into the codebase. Unfortunately, such environments are far from prevalent and the JS dev world lacks rigor even by comparison with web development as a whole, so you see a lot of people abusing lambdas and encouraging others to do likewise. That doesn't make it any less a bad idea.
    - ameen 11y ago
      I totally agree, and my use of JScript(er) has been the first in the last few years, the last was when I was teaching a bunch of school kids about Web technologies. I don't intend to use it again and only arose out of laziness than ignorance. Are there any other such bad practices in the JS dev world? I've only just considered moving onto Node as I've grown disillusioned with Rails and the concept of using a single language across the entire app & mobile (React Native, etc) sounds enticing.
      - 11y ago
mgr86 11y ago
this is my problem with Reactjs right now. I like it but debugging it is often difficult as hell. Thankfully my problems right now are small. With Hot module reloading I am constantly watching for signs of trouble. And can spot many quickly as they are introduced. But the stack trace is damn near foreign to me right now.
- novaleaf 11y ago
  if you switch to es6 classes, it helps. https://facebook.github.io/react/docs/reusable-components.html#es6-classes https://facebook.github.io/react/docs/reusable-components.ht...
  - mgr86 11y ago
    I am using those.
    - novaleaf 11y ago
      i use that + sourcemaps, and it seems pretty easy to debug. using Chrome + React Dev Extensions setting up sourcemaps to work properly is quite a pain though, most the browserify tooling via gulp or grunt does a pretty poor job of it.
      - cozuya 11y ago
        Actually gulp has many great ways to work with sourcemaps, browserify, and babel. Google it and you should find a gist. I'm using through2.
        novaleaf 11y ago
        I'm using typescript, which may impact my success, but really I don't get proper sourcemappings if I use uglify/browserify, or even the sourcemaps plugin. I only get proper sourcemaps if I use the tsify plugin + setting browserify debug=true. adding anything else causes sourcemaps to go out-of sync. That's OK though, as I get good sourcemaps in development and can live without it when in production.
maxerickson 11y ago
Perhaps they aren't clearly reasoning about first class functions and think that is the way it needs to be written. Some complaints I see about Python's weak lambda have a similar undercurrent.
nawitus 11y ago
Lambdas make code really easy to read compared to making the reader skip around the code. In addition, it reduces boilerplate code and requires less time to be spent on naming functions. Of course, it all depends on situation. Simple logic which is not beneficial elsewhere can be implemented as an anonymous function in my opinion. For example: if(objects.find(object => object.id === id)) {}
- tragic 11y ago
  Also: anonymous function, file x, line y tends to be enough for me.
- coldtea 11y ago
  >Lambdas make code really easy to read compared to making the reader skip around the code. You can have lambdas that are also named, e.g: if(objects.find(function idCheck(object){ return object.id === id}) Not sure if it's possible with the new ES6 syntax [Edit: apparently it's not, although arrow functions will automatically be assigned a name in some common scenarios].
  - Killswitch 11y ago
    That defeats the whole purpose of fat arrow functions.
    - coldtea 11y ago
      I'm not sure what purpose you have in mind. The main purposes of fat arrow functions is the auto-binding of this and succinctness. A named fat-arrow function would still retain both, and in fact the feature was considered for ES6 back in 2013, but didn't made it. Syntax would have been like: if(objects.find(functionName(object) => object.id === id)) {}
  - vkjv 11y ago
    It's also important to note that these are not quite the same thing. If you name a function, it will be hoisted to the top of the scope where a possible naming conflict could occur.

by ameen 11y ago

I've never understood JScripters' insistence on anonymous functions instead of named ones. As someone just delving into Node from another platform what're "proper best practices"-based JS patterns?

aus_ 11y ago

http://callbackhell.com http://callbackhell.com is a good starting point.

riebschlager 11y ago
I was on board with that website until I couldn't find a single semicolon. Then my eyeballs started twitching.
- Killswitch 11y ago
  Love me some non-semicolon JavaScript.

aswanson 11y ago

Yeah, I've always been suspicious of anon functions in any language, but jscripters take it beyond absurdity.

aaronem 11y ago

Best (professional) practice is to use named functions, with lambdas reserved for one-offs which are so genuinely trivial that promoting them to named functions would do more to clutter your code than to streamline it. It's telling that, while you do often see Javascript (not JScript, which is a Microsoft product and quite obsolete) developers pull some crazy nonsense with deeply nested lambdas, you almost never see Javascript developers do that in an environment that requires peer code review.

ameen 11y ago
I used JScripters as a short-hand. I'm well aware of the stigma surrounding JScript :P I've come across many JavaScript devs casually using and advising interns, etc to use anon functions to avoid cluttering code. It was almost preached as a design pattern. I was taken aback (as a back-end dev), but given the crazy stuff most JS devs did I just shrugged it is one of the platforms' quirks.
- deleted 11y ago
  [deleted]
- aaronem 11y ago
  JScript isn't a shorthand for Javascript. It's a name for an ill-favored heterodox implementation of ECMAscript. Using it in the fashion you have here will therefore cause knowledgeable engineers to assume you must not know what you're talking about. Of course, you're welcome to continue doing so nonetheless. Using lambdas in the fashion you describe is a dangerously poor practice that, over the long run, produces code that's much harder to maintain than it should be. That's why you don't see it in environments where changes have to pass peer review by experienced Javascript engineers before being accepted into the codebase. Unfortunately, such environments are far from prevalent and the JS dev world lacks rigor even by comparison with web development as a whole, so you see a lot of people abusing lambdas and encouraging others to do likewise. That doesn't make it any less a bad idea.
  - ameen 11y ago
    I totally agree, and my use of JScript(er) has been the first in the last few years, the last was when I was teaching a bunch of school kids about Web technologies. I don't intend to use it again and only arose out of laziness than ignorance. Are there any other such bad practices in the JS dev world? I've only just considered moving onto Node as I've grown disillusioned with Rails and the concept of using a single language across the entire app & mobile (React Native, etc) sounds enticing.
    - 11y ago

mgr86 11y ago

this is my problem with Reactjs right now. I like it but debugging it is often difficult as hell. Thankfully my problems right now are small. With Hot module reloading I am constantly watching for signs of trouble. And can spot many quickly as they are introduced. But the stack trace is damn near foreign to me right now.

novaleaf 11y ago
if you switch to es6 classes, it helps. https://facebook.github.io/react/docs/reusable-components.html#es6-classes https://facebook.github.io/react/docs/reusable-components.ht...
- mgr86 11y ago
  I am using those.
  - novaleaf 11y ago
    i use that + sourcemaps, and it seems pretty easy to debug. using Chrome + React Dev Extensions setting up sourcemaps to work properly is quite a pain though, most the browserify tooling via gulp or grunt does a pretty poor job of it.
    - cozuya 11y ago
      Actually gulp has many great ways to work with sourcemaps, browserify, and babel. Google it and you should find a gist. I'm using through2.
      - novaleaf 11y ago
        I'm using typescript, which may impact my success, but really I don't get proper sourcemappings if I use uglify/browserify, or even the sourcemaps plugin. I only get proper sourcemaps if I use the tsify plugin + setting browserify debug=true. adding anything else causes sourcemaps to go out-of sync. That's OK though, as I get good sourcemaps in development and can live without it when in production.

maxerickson 11y ago

Perhaps they aren't clearly reasoning about first class functions and think that is the way it needs to be written. Some complaints I see about Python's weak lambda have a similar undercurrent.

nawitus 11y ago

Lambdas make code really easy to read compared to making the reader skip around the code. In addition, it reduces boilerplate code and requires less time to be spent on naming functions. Of course, it all depends on situation. Simple logic which is not beneficial elsewhere can be implemented as an anonymous function in my opinion. For example: if(objects.find(object => object.id === id)) {}

tragic 11y ago
Also: anonymous function, file x, line y tends to be enough for me.
coldtea 11y ago
>Lambdas make code really easy to read compared to making the reader skip around the code. You can have lambdas that are also named, e.g: if(objects.find(function idCheck(object){ return object.id === id}) Not sure if it's possible with the new ES6 syntax [Edit: apparently it's not, although arrow functions will automatically be assigned a name in some common scenarios].
- Killswitch 11y ago
  That defeats the whole purpose of fat arrow functions.
  - coldtea 11y ago
    I'm not sure what purpose you have in mind. The main purposes of fat arrow functions is the auto-binding of this and succinctness. A named fat-arrow function would still retain both, and in fact the feature was considered for ES6 back in 2013, but didn't made it. Syntax would have been like: if(objects.find(functionName(object) => object.id === id)) {}
- vkjv 11y ago
  It's also important to note that these are not quite the same thing. If you name a function, it will be hoisted to the top of the scope where a possible naming conflict could occur.