Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

451–460 of 570 posts

Re: Node.js adds experimental support for TypeScript

#451
post #322

Eventually, node might allow JS to introspect those types. That would be a huge win. Right now in Python, great tools like pydantic exist because Python can introspect said types, and generate checks out of them. This mean you can define simple types, and get: - type checking - run time data check - api generation - api document generation Out of a single, standard notation. Right now in JS, things like zod have to d…

If JS ever adds type checking, I hope it doesn't choose Typescript. We need a type system that is actually sound and TS is intentionally unsound. We need a type system that doesn't allow bad coding practices like TS does. We need a type system that enforces program design that allows programs to be fast. We need a Hindley Milner type system. If you want a module to be typed, add a `"use type"`. This should disallow b…

Rescript?

Re: Node.js adds experimental support for TypeScript

#452

One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…

If only typescript could avoid changing syntax every 2 weeks.

Re: Node.js adds experimental support for TypeScript

#453
post #369

Earlier quoted context omitted.

Can you explain what you mean when you say "to be sound"?

Here's an example of TypeScript failing to be sound - it should give a type error but it doesn't. I believe Flow does indeed give a type error in this situation: https://news.ycombinator.com/item?id=41069695

You don't have to go even that far to find unsoundness in flow.

    const arr = ["abcd"];
    const str = arr[1];
    const num = str.length; // this throws
    console.log(num);
For me, typescript is a pretty good balance.

Re: Node.js adds experimental support for TypeScript

#454
post #435

Earlier quoted context omitted.

It's good for things that don't involve ripping through terabytes of data, which is actually a lot of things. And idk if I'd use Java for that either.

I'm actually in this exact position right now. The vast majority of the time I write in TS but I have a need to process a whole lot of data so I went for Rust instead. Java is too much of a headache for me, personally

Yeah, Rust is fast, or you can go the other extreme with Python if you can put the heavy lifting on native modules.

Re: Node.js adds experimental support for TypeScript

#455
post #361

Earlier quoted context omitted.

Facebook never gave Flow enough resources, whereas Microsoft has had 10+ devs on TypeScript for a long time.

Because Flow is an actual developer tool, not a rent-seeking landgrab with a marketing budget.

If you're paying rent for typescript, you're doing it wrong.

Re: Node.js adds experimental support for TypeScript

#456
post #104

Earlier quoted context omitted.

Fortunately, code is generally bundled for browsers to reduce the number of network requests and total size of downloads. And node has access to the filesystem, so it can do path searches just fine if it wants to support existing code.

You probably don't need a bundler in the browser anymore. We're not yet to the point that is a popular "mainstream" opinion, but between massive improvements in browser connection handling (HTTP 1.1 connection sharing actually works in more places, HTTP/2+) and very good ESM support in browser's well optimized preloaders and caching engines (which can sometimes reduce download size much better than all-or-none bundle…

Meh. Even with h3 I still see more gains from reducing network requests than most other attempts I try. (One day s3 will support multiple ranges per request, if I wish hard enough).

Re: Node.js adds experimental support for TypeScript

#457
post #178

Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit,…

Bun is pretty awesome. However, the node:crypto module still doesn't work 100%. So, I can't use it yet.

The parallel implementation they do uncovers a number of unexpected behaviors in the node implementation.

Re: Node.js adds experimental support for TypeScript

#458
post #219

Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit,…

Isn't Bun too raw? It's built with Zig, which hasn't even hit 1.0.

You still get segmentation faults. My biggest complain with bun is not having enough safety.

If you use frameworks written for node memory usage is very high and performance is meh.

If you use frameworks written for bun they smoke anything on node.

I'd definitely move over, just to get rid of the whole TypeScript / cjs / esm crap, but:

1. frontend support is poor (next.js / solid.js - I can't run anything fully on bun)

3. I still need to rewrite my backend app from a node.js framework to a bun one

4. for backend development the javascript ecosystem is losing the crown: if I wanted something safe I'd just write it in Rust (TS allows any random developer to write crap with any in it and it validates), if I'm doing something AI related I'd probably need python anyway and fastapi is not half bad

Re: Node.js adds experimental support for TypeScript

#459
post #442

If this feature ever becomes the default (ie not behind a flag) - how will the NPM ecosystem respond? Will contributors still bother to build CJS end EJS versions when publishing a NPM module, or just slap an 'engine: nodejs >= 25' on the package.json and stop bothering with the build step before pushing to NPM ? I personally would very much prefer if NPM modules that have their original code in TS and are currently…

The legendary Ryan dahl is actually working on solving the exact problem you described by creating a new package registry called JSR. Essentially what it does is allow you to upload your typescript code without a build step so when other devs install it they can see the source code of the module in it's original typescript instead of transpiled JavaScript.

That's really cool. One of the benefits of the JS ecosystem is the ability to step through code and crack open your dependencies. Not sure if this would directly make this possible when running your projects/tests, but it at least sounds like a step in that direction.

Re: Node.js adds experimental support for TypeScript

#460

Earlier quoted context omitted.

> and in that case there's nothing unsound about ts since it won't allow you to do so Consider this example ( https://www.typescriptlang.org/play/?ssl=10&ssc=1&pln=1&pc=1... ): function messUpTheArray(arr: Array ): void { arr.push(3); } const strings: Array = ['foo', 'bar']; messUpTheArray(strings); const s: string = strings[2]; console.log(s.toLowerCase()) Could you explain how this isn't the type system accepting t…

That's a good example, albeit quite of a far-fetched one. In Haskell land, where the type system is considered sound you have `head` functions of type `List a -> a` that are unsound too, because the list might be empty.

> In Haskell land, where the type system is considered sound you have `head` functions of type `List a -> a` that are unsound too, because the list might be empty.

Haskell's `head` not is not an example of the type system being unsound (I stress this point because we've been talking about type system soundness, not something-else-soundness).

From the view of the type system, `head` is perfectly sound: if the list is empty, the resulting value is ⊥ ("bottom"). And ⊥ is an inhabitant of every type. Therefore, `head` returning ⊥ when given an empty list is perfectly fine. When you force ⊥ (i.e. use it any way whatsoever), an exception is thrown. See https://wiki.haskell.org/Bottom

This is very much not the same thing (or remotely analogous) to what we have in my TypeScript example. There, the code fails at runtime when I attempt to call `toLowerCase`, yes; what's worse is the slightly different scenario where we succeed in calling something we shouldn't:

  class Person {
    name: string;
   
    constructor(name: string) {
      this.name = name;
    }
   
    kill() {
      console.log("Killing: " + this.name);
    }
  }
  
  class Murderer extends Person { }
  
  class Innocent extends Person { }
  
  function populatePeopleFromDatabase(people: Array): void {
      // imagine this came from a real SQL query
      people.push(new Innocent("Bob"));
  }
  
  
  function populateMurderersFromDatabase(people: Array): void {
      // TODO(Aleck): come back and replace this with a query that only selects murderers.
      //              i wanted to get the rest of the code in place, and this type checks,
      //              so I'll punt on this for now and come back later when I wrap my head
      //              around the proper SQL.
      //              we're not actually using this anywhere just yet, so no biggie ¯\_(ツ)_/¯
      populatePeopleFromDatabase(people);
  }
  
  // ... some time later, Bob comes along and implements the murderer execution logic:
  const murderers: Array = [];
  populateMurderersFromDatabase(murderers);
  // Bob is about to have a really shitty day:
  murderer.forEach((murderer) => murderer.kill());
It is not possible to write an analogous example in Haskell using `head`.
Post reply on HN