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

81–90 of 570 posts

Re: Node.js adds experimental support for TypeScript

#81

Post by crabmusket »

vivzkestrel wrote: post #18
spankalee wrote: post #11

It's about time for TC39 and Microsoft to standardize TypeScript as part of JavaScript. Not "types as comments" either, but actually TypeScript, minus the non-standard runtime semantics and modulo whatever changes are necessary to integrate the grammar. So many runtimes and tools are integrating TypeScript now, and with multiple implementations, that a real standard is necessary. It'll be much harder to evolve TypeSc…

its about time google chrome started making a typescript engine maybe? and get rid of JS in phases?

This is a persistent meme that has no basis in reality. A TypeScript engine is a JavaScript engine, since everything that can be done in JS can be done in TS. It's plausible, maybe, that there could be some additional optimisations on TS code where the engine is sufficiently happy with all types in a subset of the program. But that would be on top of all existing JS engine features, unless you want your engine's performance to suddenly degrade if you stray outside the fully-statically-verifiabe-TS happy path.

Re: Node.js adds experimental support for TypeScript

#82

Post by jraph »

dgellow wrote: post #32
spankalee wrote: post #25

Earlier quoted context omitted.

That is "types as comments", not standardizing TypeScript.

It is explicitly not type as comments, it is type erasure

I believe you and several of your child comments might be confusing "types as comments" with "types in comments".

Re: Node.js adds experimental support for TypeScript

#83

Post by SebastianKra »

storafrid wrote: post #60

I have mixed feelings about this. While I do use TS with Node.js today and absolutely like the concept, its type system is still far from something mature and stable like C#. We keep running into ceilings (EDIT: lack of completeness/depth, not lack of complexity) all the time, and TypeScript questions on Stack Overflow is basically a library of workarounds. Mostly bad ones. So if I worked on Node.js I would prefer it…

This is the first time I'm hearing such a claim.

In C# you can't work with optional generics because an optional reference type is different from an optional value type.

C#s poor type-inference often requires you to type out types thrice. You can't declare constants or class members with type-inferrence.

The only way to define sum-types (A | B | C) is through intefaces and I'm pretty sure they can't be sealed. Defining product-types (A & B & C) is impossible.

Re: Node.js adds experimental support for TypeScript

#84

Post by SwiftyBug »

crabmusket wrote: post #74
throwitaway1123 wrote: post #24

It's been a really eventful month for Node. First they added node:sqlite in v22.5.0, and now TypeScript support is landing. I love the direction Node is heading in.

The recently-added test runner is very cool too!

YES. It was such a joy to be able to ditch Jest completely and run tests natively.

Re: Node.js adds experimental support for TypeScript

#85

Post by crabmusket »

ibash wrote: post #13
Klaster_1 wrote: post #7

Earlier quoted context omitted.

This reminds me of io.js situation, where in the end major fork changes were incorporated into Node. This is why I am comfortable staying with Node and npm for my projects - the features will eventually trickle down anyway.

But in the meantime you suffer for it. How many days have you spent on webpack config? Or the package.json type property? Or yarn/pnpm/etc particulars? I have spent too many. Bun is quite nice.

Is Bun's bundler on par with webpack for features? You can't escape webpack* if you're targeting frontend.

*Or vite, or whatever equivalent.

Re: Node.js adds experimental support for TypeScript

#86

Post by zoul »

pansa2 wrote: post #69
josephg wrote: post #47

Earlier quoted context omitted.

You can configure typescript to make typing optional. With that option set, you can literally rename .js files to .ts and everything "compiles" and just works. Adding this feature to nodejs means you don't even have to set up tsc if you don't want to. But if I were putting in type hints like this, I'd still definitely want them to be statically checked. Its better to have no types at all than wrong types.

> Its better to have no types at all than wrong types. I agree - but the type systems of both Python and TypeScript are unsound, so all type hints can potentially be wrong. That's one reason why I still mostly use untyped Python - I don't think it's worth the effort of writing type annotations if they're just going to sit there and tell lies. Or maybe the unsoundness is just a theoretical issue - are incorrect type h…

In my experience unsoundness is almost never a problem in practice, see here for details:

https://effectivetypescript.com/2021/05/06/unsoundness/

Re: Node.js adds experimental support for TypeScript

#87

Post by lolinder »

pansa2 wrote: post #69
josephg wrote: post #47

Earlier quoted context omitted.

You can configure typescript to make typing optional. With that option set, you can literally rename .js files to .ts and everything "compiles" and just works. Adding this feature to nodejs means you don't even have to set up tsc if you don't want to. But if I were putting in type hints like this, I'd still definitely want them to be statically checked. Its better to have no types at all than wrong types.

> Its better to have no types at all than wrong types. I agree - but the type systems of both Python and TypeScript are unsound, so all type hints can potentially be wrong. That's one reason why I still mostly use untyped Python - I don't think it's worth the effort of writing type annotations if they're just going to sit there and tell lies. Or maybe the unsoundness is just a theoretical issue - are incorrect type h…

I've been using TypeScript professionally for 6+ years and have only ever run into issues at the border between TypeScript and other systems (usually network, sometimes libraries that don't come with types). There are a few edge cases that I'm aware of, but they don't really come up in practice.

Re: Node.js adds experimental support for TypeScript

#88

Post by harshitaneja »

I really enjoy typescript and have been yearning for a typescript runtime but I can't help but laugh that I left java all those years ago to finally seek something a lot closer to java.

I guess we all just wanted java with JIT, more feature rich type system and gradual typing. Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem.

And surprisingly even though rust is on a different end of the language spectrum but yet it offers a similar feel.

Edit: JIT was not the right terminology to use. I lazily wrote JIT. Apologies. What I meant to convey was the difference in startup times and run time between running something in JVM and V8. Java feels heavy but in javascript ecosystem it feels so nimble.

Re: Node.js adds experimental support for TypeScript

#89

Post by miki123211 »

mattnewton wrote: post #55
winter_blue wrote: post #35

Earlier quoted context omitted.

Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.

Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code)…

Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful.

With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[function]()` is perfectly valid JS, where the value of `function` might come from the user.

A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Because Closure was a type checker and a minifier at the same time, it could minify the properties declared as private, while leaving the public ones intact.

Re: Node.js adds experimental support for TypeScript

#90

Post by crabmusket »

jaggederest wrote: post #53
josephg wrote: post #47

Earlier quoted context omitted.

You can configure typescript to make typing optional. With that option set, you can literally rename .js files to .ts and everything "compiles" and just works. Adding this feature to nodejs means you don't even have to set up tsc if you don't want to. But if I were putting in type hints like this, I'd still definitely want them to be statically checked. Its better to have no types at all than wrong types.

Yeah I start projects by explicitly typing `any` all over the place and gradually refining things, so every type that's specified is explicit and checked, I'm really enjoying that style.

Combine this with an eslint config that nudges you about explicit any, and the typescript compiler option to disallow implicit any, and you're well taken care of.
Post reply on HN