<p>The differences you mention are pretty negligible, so whichever style students want to use should be fine. It's unfortunate that there are multiple styles, but it's normal for mainstream languages, and most of the critical differences (mostly binding <code>this</code>) won't matter to students at first.</p>
<hr />
<p>Here are responses to your specific concerns:</p>
<blockquote>
<p>hoisting</p>
</blockquote>
<p>I don't think hoisting (or lack thereof) is a big issue. Generally speaking, it's sensible to expect things to be defined before they're used, so if anything, this is a point in favor of <code>const</code> over <code>function</code>. Hoisting is only a pitfall if you're used to it, and then it's not there all of a sudden.</p>
<p>If students are arriving with some exposure to an OO language like Java or C#, they may be used to &quot;hoisting&quot;, but functions are always methods in classes and order doesn't matter. That's its own thing and the behavior is no different in JS classes.</p>
<blockquote>
<p>omitting the keyword <code>function</code> makes it less transferable to teaching learning other languages</p>
</blockquote>
<p>Actually, most languages don't use the word <code>function</code> in their definitions of functions: Java, C#, C++ and C are a stylistic family that use something like <code>int foo() {}</code> to declare a function. Ruby and Python use <code>def</code> (as in <a href="https://en.wikipedia.org/wiki/Def_Jam_Recordings" rel="nofollow noreferrer">Def Jam</a>). Perl uses <code>sub</code>. Rust uses <code>fn</code>, Kotlin uses <code>fun</code> and Swift and Go use <code>func</code>, close but not quite. Bash has an optional <code>function</code> keyword (but it's optional, and Bash!). Only R, Lua and PHP come to mind as explicitly using <code>function</code>. PHP's arrow equivalent uses <code>fn</code> because it's really annoying to write <code>function</code> in every <code>array_map</code> call, like JS.</p>
<blockquote>
<p>[<code>function</code>] has the clear advantage of looking more like other imperative and oop languages</p>
</blockquote>
<p>I'll grant that the lack of <code>=&gt;</code> and required braces makes a <code>function</code> definition <em>feel</em> less &quot;functional&quot; and closer to imperative Java/C++/C#-family languages. JS isn't special in having anonymous/lambda/arrow-style functions, only somewhat special in that they're typically used for top-level assignments.</p>
<blockquote>
<p>As I tend to use the module and encapsulation traits in JavaScript...</p>
</blockquote>
<p>Using modules to group functions doesn't imply classes, necessarily. By the time classes are introduced to students (usually too early in most curricula, in my opinion, given that I don't use them all that often in day to day JS coding--closures and modules without classes are usually plenty of encapsulation), students will be able to navigate the unfortunate fact that the syntax differs between standalone functions and class methods.</p>
<p>Actually, object literals are probably the worst offender here, since:</p>
<pre class="lang-js prettyprint-override"><code>const o = {
  foo() {},
  bar: () =&gt; {},
  baz: function () {},
}
</code></pre>
<p>The top style is preferred, but the choice mainly boils down to how you want to bind <code>this</code>, which is generally out of scope for most first semester students.</p>
<blockquote>
<p>[fat arrow] is immutable</p>
</blockquote>
<p>I think you mean &quot;reassignable&quot;, since you can technically add properties and mutate the arrow function, even if <code>const</code>. <code>const</code> saves a rare function redefinition name clash, but that's about it--not enough to force a decision either way. Also, if students don't use <code>const</code>, it's reassignable as well as mutable.</p>
<blockquote>
<p>[fat arrow] is used for anonymous or lambda</p>
</blockquote>
<p>Yeah, this is common, although <code>function</code> can be used for any anonymous or &quot;lambda&quot; (not actually a thing in JS; I'd avoid the term) cases. They'll definitely be seeing <code>[&quot;a&quot;, &quot;b&quot;, &quot;c&quot;].forEach(e =&gt; console.log(e))</code> rather than <code>[&quot;a&quot;, &quot;b&quot;, &quot;c&quot;].forEach(function (e) {console.log(e);})</code> before long, which is why you can't get away with ignoring arrow syntax, even if it's not actually necessary.</p>
<p>I'd be remiss to mention one significant pitfall with arrow functions, which is the implicit return value. Students will probably be bitten by mistakes like <code>[1, 2, 3].map(e =&gt; { e * e })</code> and <code>[1, 2, 3].map(e =&gt; return e * e)</code> at some point and wonder why they're getting weird results and syntax errors. You can cover these cases when the time is right, and start out with always using braces and <code>return</code>.</p>
<p>Ditto for arrow argument parentheses--I'm used to omitting them on single-argument parameters, but for beginners it's probably better to always use them (although, yet again, they'll inevitably encounter them in the wild).</p>
<p>On a similar topic, should students use the <code>var</code> keyword since it's closer to &quot;variable&quot; than <code>let</code> or <code>const</code>, which probably make little sense initially? I'd suggest not, since <code>var</code> is worse in every regard than <code>let</code> and <code>const</code>. As with the <code>function</code> versus arrow debate, I'll mention that <code>var</code> exists in case they see it in the wild, but tell students to avoid using it in their own programs unless they're trying to write code that'll run in old IE versions without transpilation.</p>
<hr />
<p>If you've read through this post and you're still on the fence, then I'd recommend using arrow functions and <code>const</code> for everything. It's common to see these days, will unavoidably be seen in callbacks, and has more predictable <code>this</code> behavior. You'll still need to mention that students may encounter the <code>function</code> version from time to time, and that it's occasionally used to allow special <code>this</code> binding in callbacks. You can skip the second half of that explanation if they're not to objects and <code>this</code> yet.</p>
<p>On the other hand, if you feel <code>function</code> is clearer for beginners, that's an acceptable position. Go for it. But as above, you'll still have to introduce arrow functions more or less as soon as you get to callbacks. A rule like &quot;use <code>function</code> for all standalone function definitions and use arrow functions for all callbacks&quot; is a sensible approach to take, although I'd leave the decision ultimately up to students and wouldn't deduct points (I'd issue a warning for mixing styles arbitrarily).</p>

CC BY-SA 4.0
2024-01-27T21:22:39.377Z
2024-02-01T07:33:15.117Z
2024-02-01T07:33:15.117Z
ggorlen
<p>I'm teaching a a high-school classes on front-end JavaSript development. What is overwhelming in specifically JavaScript is the large number of seemingly disparate ways of doing the same thing. Like functions. I've identified three ways of declaring functions:</p>
<ol>
<li>Classic: <code>function &lt;name&gt; ( &lt;param&gt; ) { &lt;body }</code></li>
<li>(fat) Arrow: <code>const &lt;name&gt; = ( &lt;param-list&gt; ) =&gt; { &lt;body }</code></li>
<li>Class member: <code>class &lt;class-name&gt; { &lt;name&gt; ( &lt;param-list&gt; ) { &lt;body&gt; }</code></li>
</ol>
<p>As I tend to use and push the module and encapsulation traits in JavaScript I also want to go with the latter but omitting the keyword <code>function</code> makes it less transferable to learn other languages. Number 2. has it benefits (immutable and used for anonymous or lambda) and pitfalls (no hoisting) and 1. has the clear advantage of looking more like other imperative and oop languages and makes it <strong>clear</strong> that it is a <em>function</em> by saying so.</p>
<p>What should I be starting with?</p>

<secondary-education><javascript>
teaching javascript functions
# teaching javascript functions

(Asked by: username_0 on 2024-01-27)

I'm teaching a a high-school classes on front-end JavaSript development. What is overwhelming in specifically JavaScript is the large number of seemingly disparate ways of doing the same thing. Like functions. I've identified three ways of declaring functions:

1. Classic: `function  (  ) {`
2. (fat) Arrow: `const  = (  ) => {`
3. Class member: `class  {  (  ) {  }`

As I tend to use and push the module and encapsulation traits in JavaScript I also want to go with the latter but omitting the keyword `function` makes it less transferable to learn other languages. Number 2. has it benefits (immutable and used for anonymous or lambda) and pitfalls (no hoisting) and 1. has the clear advantage of looking more like other imperative and oop languages and makes it **clear** that it is a *function* by saying so.

What should I be starting with?

**Tags:** secondary-education, javascript


---

## 1 answers

### Answer by username_1 on 2024-01-27. Score: 3 | Accepted answer

The differences you mention are pretty negligible, so whichever style students want to use should be fine. It's unfortunate that there are multiple styles, but it's normal for mainstream languages, and most of the critical differences (mostly binding this) won't matter to students at first.

Here are responses to your specific concerns:

hoisting

I don't think hoisting (or lack thereof) is a big issue. Generally speaking, it's sensible to expect things to be defined before they're used, so if anything, this is a point in favor of const over function. Hoisting is only a pitfall if you're used to it, and then it's not there all of a sudden.
If students are arriving with some exposure to an OO language like Java or C#, they may be used to "hoisting", but functions are always methods in classes and order doesn't matter. That's its own thing and the behavior is no different in JS classes.

omitting the keyword function makes it less transferable to teaching learning other languages

Actually, most languages don't use the word function in their definitions of functions: Java, C#, C++ and C are a stylistic family that use something like int foo() {} to declare a function. Ruby and Python use def (as in Def Jam). Perl uses sub. Rust uses fn, Kotlin uses fun and Swift and Go use func, close but not quite. Bash has an optional function keyword (but it's optional, and Bash!). Only R, Lua and PHP come to mind as explicitly using function. PHP's arrow equivalent uses fn because it's really annoying to write function in every array_map call, like JS.

[function] has the clear advantage of looking more like other imperative and oop languages

I'll grant that the lack of => and required braces makes a function definition feel less "functional" and closer to imperative Java/C++/C#-family languages. JS isn't special in having anonymous/lambda/arrow-style functions, only somewhat special in that they're typically used for top-level assignments.

As I tend to use the module and encapsulation traits in JavaScript...

Using modules to group functions doesn't imply classes, necessarily. By the time classes are introduced to students (usually too early in most curricula, in my opinion, given that I don't use them all that often in day to day JS coding--closures and modules without classes are usually plenty of encapsulation), students will be able to navigate the unfortunate fact that the syntax differs between standalone functions and class methods.
Actually, object literals are probably the worst offender here, since:
const o = {
  foo() {},
  bar: () => {},
  baz: function () {},
}

The top style is preferred, but the choice mainly boils down to how you want to bind this, which is generally out of scope for most first semester students.

[fat arrow] is immutable

I think you mean "reassignable", since you can technically add properties and mutate the arrow function, even if const. const saves a rare function redefinition name clash, but that's about it--not enough to force a decision either way. Also, if students don't use const, it's reassignable as well as mutable.

[fat arrow] is used for anonymous or lambda

Yeah, this is common, although function can be used for any anonymous or "lambda" (not actually a thing in JS; I'd avoid the term) cases. They'll definitely be seeing ["a", "b", "c"].forEach(e => console.log(e)) rather than ["a", "b", "c"].forEach(function (e) {console.log(e);}) before long, which is why you can't get away with ignoring arrow syntax, even if it's not actually necessary.
I'd be remiss to mention one significant pitfall with arrow functions, which is the implicit return value. Students will probably be bitten by mistakes like [1, 2, 3].map(e => { e * e }) and [1, 2, 3].map(e => return e * e) at some point and wonder why they're getting weird results and syntax errors. You can cover these cases when the time is right, and start out with always using braces and return.
Ditto for arrow argument parentheses--I'm used to omitting them on single-argument parameters, but for beginners it's probably better to always use them (although, yet again, they'll inevitably encounter them in the wild).
On a similar topic, should students use the var keyword since it's closer to "variable" than let or const, which probably make little sense initially? I'd suggest not, since var is worse in every regard than let and const. As with the function versus arrow debate, I'll mention that var exists in case they see it in the wild, but tell students to avoid using it in their own programs unless they're trying to write code that'll run in old IE versions without transpilation.

If you've read through this post and you're still on the fence, then I'd recommend using arrow functions and const for everything. It's common to see these days, will unavoidably be seen in callbacks, and has more predictable this behavior. You'll still need to mention that students may encounter the function version from time to time, and that it's occasionally used to allow special this binding in callbacks. You can skip the second half of that explanation if they're not to objects and this yet.
On the other hand, if you feel function is clearer for beginners, that's an acceptable position. Go for it. But as above, you'll still have to introduce arrow functions more or less as soon as you get to callbacks. A rule like "use function for all standalone function definitions and use arrow functions for all callbacks" is a sensible approach to take, although I'd leave the decision ultimately up to students and wouldn't deduct points (I'd issue a warning for mixing styles arbitrarily).


---

