Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea.

CanadaHonk has gotten further than the rest of us. It’s surprising and impressive.

You’re only replying to the quickjs issue I raised, but it’s not the only issue. Their approach to numbers is broken. Their approach to measurement is broken. The quickjs thing raises another red flag: it suggests to me that they are using reference counting, not GC. That’s guaranteed to make them too slow to be useful. (If they weren’t using RC, then they’d have a hard time on the boundary to quickjs.)

As to the `any` issue, let me explain it in a way you’ll appreciate. I asked Claude how likely it is that TS code uses any, and it found:

- 79.5% of TS repos use any explicitly. So, about 4/5 chance that newly written dep-free TS code will use it.

- the explicit any type is about as common as Boolean and void.

- a third of inferred types are any. That’s huge.

So, if you don’t believe me, then at least believe Claude: any is a super common type, so they will be falling off into quickjs a lot.

Oh, and in case it isn’t clear, quickjs-ng is no better than quickjs. They’re the same thing for the purpose of perf

▲ simonw 12 hours ago | parent | next [-]

The QuickJS thing doesn't seem like a big deal to me, provided the documentation makes it clear that code will run slower if you use Any.

If I was using this project for something I'd expect to write custom TypeScript for it.

The floats rather than integers thing does look bad though. I tried compiling their fibonacci example to C (--backend c) and got this:

  static double sc_f_fib(double sc_l_n_0) { /* /private/tmp/fib.ts:1 */
    double sc_t0 = sc_l_n_0;
    double sc_t1 = 2.0;
    bool sc_t2 = sc_t0 < sc_t1;
    double sc_t3;
    if (sc_t2) {
      double sc_t4 = sc_l_n_0;
      sc_t3 = sc_t4;
    } else {
      double sc_t5 = sc_l_n_0;
      double sc_t6 = 1.0;
      double sc_t7 = sc_t5 - sc_t6;
      double sc_t8 = sc_f_fib(sc_t7);
      double sc_t9 = sc_l_n_0;
      double sc_t10 = 2.0;
      double sc_t11 = sc_t9 - sc_t10;
      double sc_t12 = sc_f_fib(sc_t11);
      double sc_t13 = sc_t8 + sc_t12;
      sc_t3 = sc_t13;
    }
    return sc_t3; /* /private/tmp/fib.ts:2 */
  }

▲

slopinthebag 12 hours ago | parent [-]

If you’re writing Typescript with zero dependencies and trying to target native I feel like it makes more sense to write it in a different language like Rust or Go. The main reason for this I think is getting cheap perf wins by running existing code natively.

▲

timcobb 10 hours ago | parent [-]

For some new custom small thing you'd be better off using not this though, right?

	▲	queenkjuul 7 hours ago \| parent [-]
		Personally i can kind of see a use case here. I've shipped some simple server side packages as a "compiled" Node single executable written in TS, but you're stuck with the big overhead of Node. I've just been teaching myself Go, also a single binary but without the overhead. But in Go i miss the expressiveness of the TS type system sometimes.

▲ skeledrew 12 hours ago | parent | prev | next [-]

> if you don’t believe me, then at least believe Claude

I had to do a triple take on this.

▲ sroussey 11 hours ago | parent | prev | next [-]

There is always AssemblyScript

▲ slopinthebag 12 hours ago | parent | prev [-]

I think more human effort is going into defending this project then what was put into the project itself haha.