Hacker News Reader

Comment by jongjong | Hacker News Reader

It's great that we now have 3 major JS server environments: Node.js, Deno and Bun. The competition keeps them all in check.

Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs. But I like that Deno is an option which users of my open source projects can use.

That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version. None of that nonsense.

View on HN

TypeScript is, objectively, the superior option—especially in the presence of LLMs, because the type safety is incredibly useful as a first-line eval to ensure that what the LLM spits out is sound in terms of data inputs and outputs. Strong static typing is an absolute must for building anything bigger than trivial systems.

> Strong static typing is an absolute must for building anything bigger than trivial systems

I was under the impression that TypeScript is only statically typed, not strongly typed, too. Am I mistaken?

In casual convo, I often hear strong typing conflated with static typing. Its generally fine unless im being pedantic for sport. Typescript has a stronger typing system than javascript, but depending on your audience, some might not consider typescript a strongly typed language because of things like `any`, type assertions, and lack of runtime guarantees to name a few

Structural typing versus nominal typing is another one that often upsets "strong type" fans, because structural typing looks weak (but is still stronger than "no typing").

I don't know what kind of LLMs you're using but mine (Claude) has never once in 6 months got the type incorrect; neither with JavaScript nor TypeScript. So what's the point of type safety if it never gets the type wrong?

All the LLM issues I face are related to incorrect priorities, choosing the wrong tradeoffs, UX and UI flaws or incorrect assumption about requirements.

Why would I want to fill up my context window with useless type annotations and waste tokens generating them? Just like I don't want to be distracted thinking about types when I code, I don't want my LLM to be distracted by them either. Also, I don't want to waste time waiting for the transpiler to build. I don't use bundling nowadays - Not necessary if I use plain JS; instead I preload all my frontend libraries and distribute them individually; better for caching and they still download in parallel. I don't have to invalidate the entire bundle cache just because I updated one script.

Also, I don't want my LLM to generate over-engineered enterprise code. My priority is to get stuff done, not achieve job security.

Some of us have the job "get stuff done correctly" though.

Reply on news.ycombinator.com