home.social

#hoisting — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #hoisting, aggregated by home.social.

  1. Přestaňte hádat a začněte vědět. Praktický rozbor toho, jak JS engine spravuje proměnné, proč funkce je objekt a jak díky pochopení vnitřních mechanismů psát čistší kód bez zbytečných chyb.

    https://zdrojak.cz/clanky/lexikalni-prostredi-rozsah-a-uzaver-v-javascriptu-vysvetleno/
  2. Přestaňte hádat a začněte vědět. Praktický rozbor toho, jak JS engine spravuje proměnné, proč funkce je objekt a jak díky pochopení vnitřních mechanismů psát čistší kód bez zbytečných chyb.

    https://zdrojak.cz/clanky/lexikalni-prostredi-rozsah-a-uzaver-v-javascriptu-vysvetleno/
  3. New post: codito.in/frontend-refactoring

    We talk about some lessons for a beginner developer like dependencies, hoisting, shipping source or bundle, using linters to guide a clean architecture and so on.

    #frontend #npm #hoisting #dependencies #architecture #eslint #cleancode #software #refactoring

  4. New post: codito.in/frontend-refactoring

    We talk about some lessons for a beginner developer like dependencies, hoisting, shipping source or bundle, using linters to guide a clean architecture and so on.

    #frontend #npm #hoisting #dependencies #architecture #eslint #cleancode #software #refactoring

  5. New post: codito.in/frontend-refactoring

    We talk about some lessons for a beginner developer like dependencies, hoisting, shipping source or bundle, using linters to guide a clean architecture and so on.

    #frontend #npm #hoisting #dependencies #architecture #eslint #cleancode #software #refactoring

  6. New post: codito.in/frontend-refactoring

    We talk about some lessons for a beginner developer like dependencies, hoisting, shipping source or bundle, using linters to guide a clean architecture and so on.

    #frontend #npm #hoisting #dependencies #architecture #eslint #cleancode #software #refactoring

  7. I've always preferred `function`-style over lambda style (`() => {}`) for named functions in #JavaScript because I think it's less confusing for newcomers and you can take advantage of #hoisting which can be a useful feature.

    However, thinking about it again, hoisting can also lead to a lot of confusion as it leads to temporal dead zone which can be super confusing, even to experienced developers.

    ```
    doSomething();
    let value = 1;
    function doSomething(): void {
    // ERR: Cannot access 'value' before initialization
    console.log(value);
    }
    ```

    Based on that, I wonder if lambda style might actually be less confusing for new JS devs just because it avoids that entire class of footgun.

    In practice I find this kind of issue to be relatively rare, but maybe new devs encounter it more frequently than I think.

    I guess the question here is: Is JS function hoisting a useful feature or an antipattern to avoid?

  8. I've always preferred `function`-style over lambda style (`() => {}`) for named functions in #JavaScript because I think it's less confusing for newcomers and you can take advantage of #hoisting which can be a useful feature.

    However, thinking about it again, hoisting can also lead to a lot of confusion as it leads to temporal dead zone which can be super confusing, even to experienced developers.

    ```
    doSomething();
    let value = 1;
    function doSomething(): void {
    // ERR: Cannot access 'value' before initialization
    console.log(value);
    }
    ```

    Based on that, I wonder if lambda style might actually be less confusing for new JS devs just because it avoids that entire class of footgun.

    In practice I find this kind of issue to be relatively rare, but maybe new devs encounter it more frequently than I think.

    I guess the question here is: Is JS function hoisting a useful feature or an antipattern to avoid?

  9. I've always preferred `function`-style over lambda style (`() => {}`) for named functions in #JavaScript because I think it's less confusing for newcomers and you can take advantage of #hoisting which can be a useful feature.

    However, thinking about it again, hoisting can also lead to a lot of confusion as it leads to temporal dead zone which can be super confusing, even to experienced developers.

    ```
    doSomething();
    let value = 1;
    function doSomething(): void {
    // ERR: Cannot access 'value' before initialization
    console.log(value);
    }
    ```

    Based on that, I wonder if lambda style might actually be less confusing for new JS devs just because it avoids that entire class of footgun.

    In practice I find this kind of issue to be relatively rare, but maybe new devs encounter it more frequently than I think.

    I guess the question here is: Is JS function hoisting a useful feature or an antipattern to avoid?

  10. I've always preferred `function`-style over lambda style (`() => {}`) for named functions in #JavaScript because I think it's less confusing for newcomers and you can take advantage of #hoisting which can be a useful feature.

    However, thinking about it again, hoisting can also lead to a lot of confusion as it leads to temporal dead zone which can be super confusing, even to experienced developers.

    ```
    doSomething();
    let value = 1;
    function doSomething(): void {
    // ERR: Cannot access 'value' before initialization
    console.log(value);
    }
    ```

    Based on that, I wonder if lambda style might actually be less confusing for new JS devs just because it avoids that entire class of footgun.

    In practice I find this kind of issue to be relatively rare, but maybe new devs encounter it more frequently than I think.

    I guess the question here is: Is JS function hoisting a useful feature or an antipattern to avoid?

  11. I've always preferred `function`-style over lambda style (`() => {}`) for named functions in because I think it's less confusing for newcomers and you can take advantage of which can be a useful feature.

    However, thinking about it again, hoisting can also lead to a lot of confusion as it leads to temporal dead zone which can be super confusing, even to experienced developers.

    ```
    doSomething();
    let value = 1;
    function doSomething(): void {
    // ERR: Cannot access 'value' before initialization
    console.log(value);
    }
    ```

    Based on that, I wonder if lambda style might actually be less confusing for new JS devs just because it avoids that entire class of footgun.

    In practice I find this kind of issue to be relatively rare, but maybe new devs encounter it more frequently than I think.

    I guess the question here is: Is JS function hoisting a useful feature or an antipattern to avoid?