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

Node.js adds experimental support for TypeScript

github.com

Post reply on HN
Print view View original

541–550 of 570 posts

Re: Node.js adds experimental support for TypeScript

#541

Post by joseferben »

WorldMaker wrote: post #535
joseferben wrote: post #502

Earlier quoted context omitted.

i wish it was that easy. i keep trying to default to esm on node projects but the ecosystem is not there yet, at least in the context of server side nodejs stuff.

It's one reason to consider a switch to Deno or Bun, but at least to maybe at least check JSR before NPM these days. The ecosystem for server-side ESM exists and is growing at a rapid pace, but it's sometimes hard to separate the active maintained npm packages from the legacy ones in the server-side ecosystem. (Browser ecosystem is definitely more ESM hungry.) That said with "type": "module" in my own package.json fi…

the issue i ran into recently was around react/jsx where i wanted .tsx files server side.

might have to look into it again but there was an issue where some react/jsx/fragment bit had to be ported to esm first.

Re: Node.js adds experimental support for TypeScript

#543

Post by LordKeren »

pansa2 wrote: post #540
LordKeren wrote: post #524

Earlier quoted context omitted.

While it’s not common (from the source code I’ve reviewed over the years), some people make a new type with a name and use that in the definition: ``` from typing import NewType # Create a new type for some_prime SomePrime = NewType('SomePrime', int) def process_prime(value: SomePrime) -> int: return value ``` However, this isn’t nearly as common as simply using a more descriptive argument name like “prime_number : i…

> One of the big advantages to type hinting in Python is that it feeds the IDE a lot of information to increase auto-complete functionality Yeah, until this discussion I thought the main benefit of type hints was earlier detection of bugs via static checking. Now though, I'm getting the impression that the bigger benefit is enabling IDE features such as autocomplete. That helps me understand better why I haven't foun…

There’s a fair argument to make that better IDE autocomplete does prevent many type-related issues even before a static type checker is run

Re: Node.js adds experimental support for TypeScript

#544

Post by hajile »

dwb wrote: post #536
hajile wrote: post #532

Earlier quoted context omitted.

I think the real answer is adding actually sound types to JS itself. One of the biggest revolutions in JS JITS was the inline cache (IC). It allows fast lookup and specialized functions (which would be too expensive otherwise). These in turn allow all the optimizations of the higher-tier JITs. The biggest problem of Flow and TS is encouraging you to make slow code. The second you add a generic to your function, you a…

Maybe! I see where you're coming from. That sounds like a long and painful road, still, though, from what is still a very dynamic language. Do you have a rough idea of how much more time/space-efficient a typical JavaScript program could be through this?

It's an interesting question.

JS uses a JIT while Ocaml is AOT which is generally an advantage for Ocaml.

Ocaml only compiles once while JS compiles every time it runs. This means that JS is a lot more selective about its compilation, but the hot code could be every bit as fast as Ocaml. On the flip side, Ocaml is fast because it compiles method-at-a-time and a SML compiler like MLton which does a slow whole-program pass can generate significantly faster code (despite being a part-time hobby project for a few academics).

The big difference is money. Ocaml has some funding, but nothing compared to JS. It's hard to believe, but handling strings in JS is probably faster than what most devs could do themselves in C/C++. It's not because JS is inherently faster. It's because those bits are native and have had countless man-years poured into making them fast. That said, even the JIT itself is top-tier and raw integer code is only 20-50% slower than C (excluding any SIMD optimizations).

I think the upper limit for a typed JS could be about as fast and maybe a little faster than Ocaml on the JIT and maybe even a little faster with a more restrictive subset compiling to WASM.

Re: Node.js adds experimental support for TypeScript

#545

Post by zarzavat »

bazoom42 wrote: post #522
zarzavat wrote: post #482

Earlier quoted context omitted.

It can’t strip what’s after the as keyword without an up-to-date TS grammar, because `as` is an expression. The parser needs to know how to parse type expressions in order to know when the RHS of the `as` expression ends. Let’s say that typescript adds a new type operator “wobble T”. What does this desugar to? x as wobble T Without knowing about the new wobble syntax this would be parsed as `x as wobble; T` and desug…

The “as” expression is not valid JavaScript anyway, so the default rule for implicit semicolon does not apply. A grammer for type expressions could define if and how semicolons should be inserted.

TypeScript already has such type operators though. For example:

    type T = keyof
    {
      a: null,
      b: null
    }
Here T is “a”|”b”, no automatic semicolon is inserted after `keyof`. While I don’t personally write code like this, I’m sure that someone does. It’s perfectly within the rules, after all.

While it’s true that TS doesn’t have to follow JS rules for semicolon insertion in type expressions, it always has done, and probably always should do.

Re: Node.js adds experimental support for TypeScript

#546

Post by nequo »

hajile wrote: post #529
joseferben wrote: post #525

Earlier quoted context omitted.

for my use case (web dev) ts is fast enough. but i do miss the ocaml compile times! it's mainly the lack of ad-hoc polymorphism that makes ocaml feel a bit clunky to me at times. but structural typing sure would be nice. i used to avoid typescript because of similar soundness issues. but in the context of web dev this weird type system that evolved from adding types to javascript turned out to be so nice to use. it's…

Ocaml messed up with their operators. StandardML had a better approach and I hope a future version adds module typeclasses (to help limit the type soup we see in Haskell). As I wrote elsewhere in this thread, TS makes it incredibly easy to unintentionally make megamorphic functions that don’t have any inline cache and don’t get optimized at all. You think you’re writing efficient, DRY code, but it’s really just dog s…

> Ocaml messed up with their operators. ... I hope a future version adds module typeclasses

Do you mean modular implicits?[1] The original paper was published in 2014. There's an internship report from 2023 that summarizes the design and implementation issues:

https://modular-implicits.github.io/report.pdf

[1] https://arxiv.org/abs/1512.01895

Re: Node.js adds experimental support for TypeScript

#547

Post by WorldMaker »

joseferben wrote: post #541
WorldMaker wrote: post #535

Earlier quoted context omitted.

It's one reason to consider a switch to Deno or Bun, but at least to maybe at least check JSR before NPM these days. The ecosystem for server-side ESM exists and is growing at a rapid pace, but it's sometimes hard to separate the active maintained npm packages from the legacy ones in the server-side ecosystem. (Browser ecosystem is definitely more ESM hungry.) That said with "type": "module" in my own package.json fi…

the issue i ran into recently was around react/jsx where i wanted .tsx files server side. might have to look into it again but there was an issue where some react/jsx/fragment bit had to be ported to esm first.

Interesting. Every example that I've seen of React SSR is all natively in ESM, but I've mostly only glanced at the big ones (Astro/Next/Nuxt). I'm sure that there are a lot of paths that aren't as well paved given how diverse the React SSR space currently is (there are way too many competing options), and how simple you want to try to keep your SSR (a lot of those options are just so complex today, which presumably is why there are so many competing options, everyone has a different idea of how complex to make the whole thing).

(My own .tsx based view library doesn't yet have official SSR support, but I do all my testing in ESM in the built-in Node test runner `node --test` so I don't see any complications in doing .tsx on the "server-side", because that is how I'm testing everything already, I just haven't entirely figured out my "hydration" or "islands" or "stamps" approach so I don't officially support SSR yet. It's on the roadmap and I've made small bits of progress towards it, just need to solve it and haven't had the time/priority.)

Re: Node.js adds experimental support for TypeScript

#548

Post by sprkv5 »

hajile wrote: post #532
dwb wrote: post #527

Earlier quoted context omitted.

I know, but it just doesn't matter enough. Believe me, I'm signed up to the idea of theoretical rigour, the argument for soundness is part of what originally won me over (along with previous good experiences with Flow on a smaller project, and the support for gradual adoption). I will continue to be drawn to languages and tools that have a strong theoretical foundation. But in this particular case, today, when compar…

I think the real answer is adding actually sound types to JS itself. One of the biggest revolutions in JS JITS was the inline cache (IC). It allows fast lookup and specialized functions (which would be too expensive otherwise). These in turn allow all the optimizations of the higher-tier JITs. The biggest problem of Flow and TS is encouraging you to make slow code. The second you add a generic to your function, you a…

> I use TS because of its ubiquity, but I think there's the possibility for a future where a system a little more like Flow gets baked into the language.

Have you looked into ReScript? It is basically a sound type system + JavaScript-like syntax. It inherits the type system from OCaml. You might like it. They recently released version 11.

Re: Node.js adds experimental support for TypeScript

#549

Post by sprkv5 »

iimblack wrote: post #451
hajile wrote: post #322

Earlier quoted context omitted.

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?

Absolutely. People are sleeping on it.

If only projects like Bun/Deno/Node added runtime support for ReScript instead of TypeScript, collectively as the web-tooling industry, we'd be in a better place. But you can't win against the MS's marketing budget.

Also in hindsight, ReScript diverged away from OCaml, but the ReScript development team could have gone further by creating a runtime for ReScript. Then again I don't blame them - they are polishing the dev experience of ReScript and React.

This is the decade of writing shiny new runtimes - I hope somebody writes a ReScript runtime. Imageine ReScript, Core, rescript-webapi, typechecker, re-analyze, plus a bundler minifier etc baked into the runtime like Bun. Sounds like an interesting value proposition. Fingers crossed.

Re: Node.js adds experimental support for TypeScript

#550

Post by silverwind »

dimgl wrote: post #464
silverwind wrote: post #220

Earlier quoted context omitted.

tsx has very slow startup performance, I prefer https://github.com/swc-project/swc-node which is around twice as fast.

We have not seen this whatsoever. How big is your project? `tsx` is almost instantaneous in a server-side project of ours.

A hello world here takes 400ms on tsx and 250ms on swc-node for me.

Basically it boils down to swc being faster than esbuild, see their benchmarks:

https://swc.rs/docs/benchmarks

Post reply on HN