Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

vincentrolfs.dev

Post reply on HN
Print view View original

51–60 of 64 posts

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#51

Post by lukan »

sjrd wrote: post #28

Indeed, `let`s and `const`s incur a significant performance penalty. This is also why the Scala.js compiler emits `var`s by default, even when targeting very recent versions of ECMAScript. The good news is that we can still write our Scala `val`s and `var`s (`const` and `let`) in the source code, enjoying good scoping and good performance.

And here I was thinking I should finally embrace using const and let for performance reasons .. shouldn't in theory the compiler has more room for optimization if it knows the variable won't be changed? Or is apperently all the scope checking more expensive?

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#52

Post by ngruhn »

sfink wrote: post #11
taejavu wrote: post #2

The first example is not “terrible”, that’s just how lexical scope works. I don’t really see the point of complaining about language features like this - either learn how it works or ignore at your peril.

That's not how lexical scope works anywhere but in JavaScript. Or rather, it's the interaction between "normal" lexical scope and hoisting. In a "normal" lexically scoped language, if you tried: function f() { return x; // Syntax parsing fails here. } let x = 4; return f(); you would get the equivalent of a ReferenceError for x when f() tried to use it (well, refer to it) at the commented line. But in JavaScript, thi…

Would mutual recursion still work with this solution? E.g.

   function f() {
     return g()
   }
   function g() {
     return f()
   }

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#53

Post by pwdisswordfishy »

I wish they had made lexical scope work like Lua, where the binding simply does not exist before the declaration – including in the initialization expression:

    local x = 42
    do
      print(x) -- 42
      local x = x * 2
      print(x) -- 84
    end
    print(x) -- 42
Look, ma! No dead zones!

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#54

Post by prmph »

sfink wrote: post #11
taejavu wrote: post #2

The first example is not “terrible”, that’s just how lexical scope works. I don’t really see the point of complaining about language features like this - either learn how it works or ignore at your peril.

That's not how lexical scope works anywhere but in JavaScript. Or rather, it's the interaction between "normal" lexical scope and hoisting. In a "normal" lexically scoped language, if you tried: function f() { return x; // Syntax parsing fails here. } let x = 4; return f(); you would get the equivalent of a ReferenceError for x when f() tried to use it (well, refer to it) at the commented line. But in JavaScript, thi…

One thing about scope hoisting in JS is that it allows to simulate some aspects of functional programming, where the the order of execution does not necessarily math the order of declaration. I use this all the time to order code elements in a file in order of decreasing importance.

I wish there was explicit support for this though, maybe with a construct like where , etc, like what Haskell has, instead of having to hack it using functions and var

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#55

Post by mjmas »

ngruhn wrote: post #52
sfink wrote: post #11

Earlier quoted context omitted.

That's not how lexical scope works anywhere but in JavaScript. Or rather, it's the interaction between "normal" lexical scope and hoisting. In a "normal" lexically scoped language, if you tried: function f() { return x; // Syntax parsing fails here. } let x = 4; return f(); you would get the equivalent of a ReferenceError for x when f() tried to use it (well, refer to it) at the commented line. But in JavaScript, thi…

Would mutual recursion still work with this solution? E.g. function f() { return g() } function g() { return f() }

It would work just like Lua then and require manually hoisting one of the declarations:

  local b
  local function a()
    return b()
  end
  b = function()
    return a()
  end
(Lua's named function statements are just syntatic sugar. For example `local function a()` is equivalent to `local a; a = function()`.)

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#56

Post by mjmas »

Aurornis wrote: post #7
throw-the-towel wrote: post #5

Earlier quoted context omitted.

I second that, I actually don't understand why do people believe every pair of curly braces has to be its own separate scope. An explicit construct for scoping would have been so much clearer to me.

> I actually don't understand why do people believe every pair of curly braces has to be its own separate scope. It’s much easier to reason about when your variables aren’t going to escape past the end of the block. In non-GC languages going out of scope can also be a trigger to free the contents of the variable. This is useful for situations like locking where you can put the minimal span of code that requires the l…

GCed languages often also have a mechanism for running code on scope exit. For example Lua's attribute, which runs a metamethod when it goes out of scope rather than having to wait for GC:

  function readfile(name)
    local f  = assert(io.open(name))
    return assert(f:read"a")
  end

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#57

Post by dwattttt »

wonnage wrote: post #18
craftkiller wrote: post #15

Earlier quoted context omitted.

By crux you mean the 1 paragraph at the end where it mentions performance? That's basically a footnote to an article that spends the other 99% describing javascript variable hoisting. They cite an 8% performance boost but they don't analyze it, instead just claiming it is a lot of work for the interpreter and linking to a github issue. They've run no benchmarks. They have shown no interpreter internals. They just rep…

Yes it turns out the article’s conclusion is in fact contained in the conclusion paragraph

To be fair, with JS's initialisation rules it does feel like it could have been anywhere.

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#59

Post by strken »

conartist6 wrote: post #38

Why wouldn't `let` be exactly what you want? It's block scoped but doesn't need fancy TDZ checks because like `var` it just starts out as undefined.

The article is slightly wrong. The TDZ is the zone before the variable is declared, not after. Referencing variables before they're declared isn't valid for `let` and hence it needs a TDZ check.

Consider

    console.log(foo)
    let foo
vs

    console.log(foo)
    var foo
I think the article confuses "in scope" with "declared", and "declared and initialised" with "initialised".

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#60

Post by coldtea »

sjrd wrote: post #48
csto12 wrote: post #40

Earlier quoted context omitted.

I wonder how many companies are still using Scala.js. Scala was fun to work with, wish it was more popular these days.

Usage of Scala.js is steadily growing. Several indicators suggest that 1 in 5 Scala developers use Scala.js at this point. It's regularly brought up as one of the strongest suits of Scala. Usage of Scala itself is less shiny if you look at market share. But I believe it's still growing in absolute numbers, only quite slowly.

>Usage of Scala.js is steadily growing. Several indicators suggest that 1 in 5 Scala developers use Scala.js at this point.

Wow! 4 out of 20 total ain't bad!

Jocking aside the starting set (Scala developers) is already small, so it's not like either it or even less Scala.js is going to be a major player anytime soon.

Post reply on HN