Node.js adds experimental support for TypeScript • Hacker News Board

Re: Node.js adds experimental support for TypeScript

#321

Post by crabmusket » Thu, Jul 25, 2024, 2:28 PM UTC

tpm wrote: post #283

yen223 wrote: post #160

Earlier quoted context omitted.

Java and Typescript have fundamentally different type systems, that lead to drastically different ways to approach types. Utility types, like Partial , are basically impossible to represent in Java except with almost-duplicated classes.

> drastically different ways to approach types Exactly. > Partial Looking at that it's just what a default POJO (with nullable properties) already is, so I'd see no need to represent that in Java. Looks cool though and I like Typescript; my issue with it is that it needs transpiling to run. If it was a first-class citizen in an environment I would use it for my pet projects.

> it's just what a default POJO (with nullable properties) already is

I think you missed the point. Partial is an example of a "mapped type", see the handbook for more explanation: https://www.typescriptlang.org/docs/handbook/2/mapped-types....

Re: Node.js adds experimental support for TypeScript

#322

Post by hajile » Thu, Jul 25, 2024, 2:30 PM UTC

BiteCode_dev wrote: post #212

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 bad parts of the language like type coercion. It should disallow things that hurt performance like changing object shape/value type or making arrays of random collections of stuff. Incoming data from untyped modules would either coerce or throw errors if coercion can't be done at which point the compiler can deeply-optimize the typed code because it would have far stronger type guarantees and wouldn't have a risk of bailing out.

Re: Node.js adds experimental support for TypeScript

#323

Post by hajile » Thu, Jul 25, 2024, 2:34 PM UTC

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…

TS is an intentionally unsound type system that tries to allow you to type your code no matter if it will run like garbage, is unreadably complex, and uses terrible parts of the language.

What TC39 needs is a type system that limits what you can do to things that are sound, performant, and good practice. TS is the exact opposite of this.

Re: Node.js adds experimental support for TypeScript

#324

Post by xigoi » Thu, Jul 25, 2024, 2:35 PM UTC

zarzavat wrote: post #298

klodolph wrote: post #292

Earlier quoted context omitted.

I’ll flip this around… reusing comparison as angle brackets is the mistake. C++ ran into some issues too. I think Rust made the really smart move of putting :: before any type parameters for functions. Go made the good move of using square brackets for type parameters.

The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square b…

I think the D syntax would work: f!T(x)

Re: Node.js adds experimental support for TypeScript

#325

Post by draw_down » Thu, Jul 25, 2024, 2:38 PM UTC

hajile wrote: post #317

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.

Flow tries to be sound and that makes it infinitely better than TS where the creators openly threw the idea of soundness out the window from the very beginning.

Maybe FB should have tried putting more than like 4 people on the project then. (Yes I met them all once.)

Re: Node.js adds experimental support for TypeScript

#326

Post by hajile » Thu, Jul 25, 2024, 2:41 PM UTC

garbagepatch wrote: post #103

commercialnix wrote: post #50

https://rescript-lang.org/

Looks very similar to Reason ML, another language that compiles to Js: https://reasonml.github.io/docs/en/getting-started

ReScript was an outgrowth of ReasonML and basically split the community killing both of them.

Re: Node.js adds experimental support for TypeScript

#327

Post by kevincox » Thu, Jul 25, 2024, 2:45 PM UTC

miki123211 wrote: post #89

mattnewton wrote: post #55

Earlier quoted context omitted.

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[f…

> it could minify the properties declared as private, while leaving the public ones intact.

I don't think it ever actually did this. It renamed all properties (you could use the index syntax to avoid this) and just used a global mapping to ensure that every source property name was consistently renamed (no matter what type it was on). I don't think type information was ever actually used in minification.

So if you had two independent types that had a `getName` function the compiler would always give them the same minified name even though in theory their names could be different because they were fully independent types. The mapping was always bijective. This is suboptimal because short names like `a` could only be used for a single source name, leading to higher entropy names overall. Additionally names from the JS runtime were globally excluded from renaming. So any `.length` property would never be renamed in case it was `[].length`.

Re: Node.js adds experimental support for TypeScript

#328

Post by behnamoh » Thu, Jul 25, 2024, 2:45 PM UTC

zarzavat wrote: post #298

klodolph wrote: post #292

Earlier quoted context omitted.

I’ll flip this around… reusing comparison as angle brackets is the mistake. C++ ran into some issues too. I think Rust made the really smart move of putting :: before any type parameters for functions. Go made the good move of using square brackets for type parameters.

The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square b…

Everytime a standardization happens, part of human creativity gets suppressed. Before ASCII, people were inventing all sorts of symbols and even the alphabet was flexible to changes. After ASCII, we got stuck with a certain set of letters and symbols. Heck, even our keyboards haven't changed that much since then. I really think we need more symbols than just &@$#%^*}{][()/\_~|

Re: Node.js adds experimental support for TypeScript

#329

Post by wiseowise » Thu, Jul 25, 2024, 2:47 PM UTC

meiraleal wrote: post #302

wiseowise wrote: post #166

Earlier quoted context omitted.

I misread the proposal. Thought it was for JSDoc.

Misread no, you didn't read.

Yeah. I saw JSDoc and closed it, lol.

Re: Node.js adds experimental support for TypeScript

#330

Post by satanacchio » Thu, Jul 25, 2024, 2:47 PM UTC

Shacklz wrote: post #314

satanacchio wrote: post #208

Hi I'm the author of the PR, AMA

Great work, many thanks! Out of curiosity, what do you see as next steps, and what possible futures do you see for typescript in the node- and overall JS-ecosystem?

this is the roadmap https://github.com/nodejs/loaders/issues/217. We talked with the typescript team and we will give each other continous feedback on the progression. We made sure to take some precautions in order to avoid breaking the ecosystem. I still think in production, js is the way to go, so users should always transpile their ts files.