return to table of content

Node.js adds experimental support for TypeScript

pansa2
79 replies
13h58m

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a type checker. This would be similar to the situation in Python, where type checkers check types and leave them intact, and the Python interpreter just ignores them.

It's interesting, though, that this approach in Python has led to several (4?) different popular type checkers, which AFAIK all use the same type hint syntax but apply different semantics. However for JavaScript, TypeScript seems to have become the one-and-only popular type checker.

In Python, I've even heard of people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments. Support for ignoring types in Node.js would make that approach possible in JavaScript as well.

winter_blue
32 replies
13h56m

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.

mattnewton
21 replies
13h17m

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).

miki123211
13 replies
12h38m

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.

mananaysiempre
8 replies
6h41m

A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses.

Given TypeScript’s type system is unsound, neither could it even if it tried, right? I guess Flow could, but well, here we are.

epolanski
6 replies
5h46m

What do you mean by unsound exactly.

I'm asking because there's no accepted definition of what an unsound type system is.

What I often see is that the word unsound is used to mean that a type system can accept types different to what has been declared, and in that case there's nothing unsound about ts since it won't allow you to do so.

cstrahan
2 replies
3h39m

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<string | number>): void {
      arr.push(3);
  }
  
  const strings: Array<string> = ['foo', 'bar'];
  messUpTheArray(strings);
  
  const s: string = strings[2];
  console.log(s.toLowerCase())
  
Could you explain how this isn't the type system accepting types "different to what has been declared"? Kinda looks like TypeScript is happy to type check this, despite `s` being a `number` at runtime.

epolanski
1 replies
1h57m

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.

crdrost
0 replies
24m

That option also exists, you can just leave out the `messUpTheArray` lines and you get an error about how `undefined` also doesn't have a `.toLowerCase()` method.

However this problem as stated is slightly different and has to do with a failure of OOP/subtyping to actually intermingle with our expectations of covariance.

So to just use classic "animal metaphor" OOP, if you have an Animal class with Dog and Cat subclasses, and you create an IORef<Cat>, a cell that can contain a cat, you would like to provide that to an IORef<Animal> function because you want to think of the type as covariant: Cat is a subtype of Animal, F<Cat> should be a subtype of F<Animal>. The problem is that this function now has the blessing of the type system to store a Dog in the cell, which can be observed by the parts that still consider this an IORef<Cat>.

Put slightly differently, in OOP, the methods of IORef<Cat> all accept an implicit IORef<Cat> called `this`, if those methods are part of what define an IORef<x> then an IORef<x> is necessarily invariant, not covariant, in <x>. And then you can't assume subtyping. So to be sound a subtype system would presumably have to actually mark contra/covariance around everything, and TypeScript very intentionally documents that they don't do this and are just trying to make a "best effort" pass because JavaScript has 0 types, and crappy types are better than no types, and we can't wait for perfect types to replace the crappy types.

sharlos201068
1 replies
3h42m

That’s not correct, there’s several ways the actual type of a value differs from what typescript thinks it is. But soundness isn’t a goal of typescript.

WorldMaker
0 replies
3h11m

It's maybe useful to note in this discussion for some that "soundness" of a type system is a bit of technical/theoretical jargon that in some cases has specific mathematical definitions and so "unsound" often sounds harsher (connotatively) than it means. The vast majority of type systems are "unsound" for very pragmatic reasons. Developers don't often care to work in a "sound" type systems. Some of the "most sound" type systems we've collectively managed to build are in things like theorem provers and type assertion systems that some of us don't always even consider useful for "real" software development.

Typescript is a bit more unsound than most because of the escape hatch `any` and because of the (intentional) disconnect between compiler and runtime environment. Even though "unsound" sounds like a bad thing to be, it's a big part of why Typescript is so successful.

mananaysiempre
0 replies
1h54m

there's no accepted definition of what an unsound type system is

Huh?

The cheeky answer would be that the definition here is the one the TypeScript documentation itself uses[1].

The useful answer is that there’s only one general definition that I’ve ever encountered: a type system is sound if no well-typed program encounters type errors during its execution. Importantly, that’s not a statement about the (static) type system in isolation: it’s tied to the language’s dynamic semantics.

The tricky part, of course, is defining “type error”. In theoretical contexts, it’s common to just not define any evaluation rules at all for outwardly ill-typed things (negating a list, say), thus the common phrasing that no well-typed program must get stuck (unable to evaluate further). In practical statically-typed languages, there are on occasion cases that are defined not to be type errors essentially by fiat, such as null pointer accesses in Java, or escape hatches, such as unsafeCoerce in practical implementations of Haskell.

Of course, ECMAScript just defines behaviour for everything (except violating invariants in proxy handlers, in which case, lol, good luck), so arguably every static type system for it is sound, even one that allows var foo: string = 42. Obviously that’s not a helpful point of view. I think it’s reasonable to say that whatever we count as erroneous situations must at the very least include all occurrences of ReferenceError and TypeError.

TypeScript prevents most of them, which is good enough for its linting use case, when the worst possible result is that a buggy program crashes. It would definitely not be good enough for Closure Compiler’s minification use case, when the worst possible result is that a correct program gets silently miscompiled (misminified?).

[1] https://www.typescriptlang.org/docs/handbook/type-compatibil...

afavour
0 replies
6h34m

Theoretically TS could… until it encounters an ‘any’ type in that code path, then it would have to give up.

But there are TSconfig options to ensure no use of any so with the right level of strictness it could happen.

wiktor-k
1 replies
11h55m

Something like `foo.bar[function]()` is perfectly valid JS,

A minor thing but `function` is a keyword in JS so technically it's not a "perfectly valid JS".

mkesper
0 replies
11h19m

Oh boy, just think functionName and it fits.

kevincox
0 replies
3h45m

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`.

AprilArcus
0 replies
3h14m

of course this created an interoperability nightmare with third party libraries, which irrevocably forked Google's whole JS ecosystem from the community's 20 years ago and turned their codebases into a miserable backwater.

LoganDark
3 replies
13h12m

Oh, Closure Compiler is such a throwback. I still remember staring at the project page on Google Code. Isn't it like two decades old or even older by this point? Is it still alive?

rty32
0 replies
7h30m

This can give you some hints of the current status of closure compiler:

https://github.com/google/closure-compiler/issues/2731

I happen to know this because we have some old projects that depend on this and are working hard to get rid of the dependency.

I wish Google either updates it or just mark the whole thing deprecated -- the world has already moved on anyway. Relating this to Google's recent cost cutting, and seeing some other Google's open source projects more or less getting abandoned, I have to say that today's Google is definitely not the same company from two decades ago.

mdhb
0 replies
12h56m

The compiler itself lives on but it works with TypeScript now rather than the JSDoc comments style approach which is officially EOL AFAIK.

flohofwoe
0 replies
11h51m

Closure is still used in Emscripten to optimize the generated Javascript shim file.

rty32
1 replies
7h35m

Closure is almost a forgotten child of Google now. Does not even fully support ES2022 as of today. We are working hard to get rid of it completely. Surprise, lots of important projects still rely on it today.

jazzypants
0 replies
2h48m

This is true. For instance, React still uses Closure compiler in their build process.

btown
0 replies
12h13m

Google’s Closure Library is fascinating too. It’s being retired, but if you want to build a rich text interface for email authoring that truly feels like Gmail, warts and all, you can just use a pre-compiled version of the library and follow https://github.com/google/closure-library/blob/master/closur... within a more modern codebase!

hajile
5 replies
4h14m

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.

idlephysicist
1 replies
2h45m

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

pansa2
0 replies
2h34m

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

machiaweliczny
0 replies
4h4m

But in practice is was crap

dwb
0 replies
2h7m

This is a point in Flow's favour. However! Seven years ago or so, when TypeScript was quite young and seemed inferior to Flow in almost all respects, I chose Flow for a large project. Since then, I spent inordinate amounts of time updating our code for the latest breaking Flow version, until one came along that would have taken too long to update for, so we just stayed on that one. We migrated to TypeScript a little while back and the practical effect has been much more and effective type checking through more coverage and support. TypeScript may be unsound, but it works better over all. We turn on the vast majority of the safety features to mitigate the unsoundness. And it's developed by a team that are beholden to a large and vibrant user base, so any changes are generally well-managed. There's no contest, really.

ahuth
0 replies
3h30m

TS made the choice to be “just JS” + types, and lean into JS-isms.

Both choices are reasonable ones to make. Flow has some really cool stuff, and works great for a lot of people.

There’s no denying, though, that there’s TS has done something right (even if you personally dislike it)

simplify
1 replies
6h7m

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

sesm
0 replies
2h46m

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

sesm
1 replies
2h50m

There was no real competition, Flow was a practical internal tool with 0 marketing budget. Typescript is typical MS 3E strategy with a huge budget. Needless to say, Flow is much more practical and less intrusive, but marketing budget captured all the newbie devs.

pphysch
17 replies
13h51m

In Python, I've even heard of people writing types in source code but never checking them

This is my main approach. Type hints are wonderful for keeping code legible/sane without going into full static type enforcement which can become cumbersome for rapid development.

josephg
13 replies
13h32m

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.

pansa2
9 replies
12h56m

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 hints much of a problem in practice?

kcrwfrd_
6 replies
12h24m

Is this “unsound”-ness that you’re referring to because it uses structural typing and not nominal typing?

Fwiw I’ve been working with TypeScript for 8+ years now and I’m pretty sure wrong type hints has never been a problem. TS is a God-send for working with a codebase.

nyssos
4 replies
4h54m

There's not much connection. Typescript's record types aren't sound, but that's far from its only source of unsoundness, and sound structural typing is perfectly possible.

lolinder
3 replies
4h45m

Soundness is also a highly theoretical issue that I've never once heard a professional TypeScript developer express concern about and have never once heard a single anecdote of it being an issue in real-world code that wasn't specifically designed to show the unsoundness. It usually only comes up among PL people (who I count myself among) who are extremely into the theory but not regularly coding in the language.

Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application? Or an anecdote you can link to from someone else?

kcrwfrd_
1 replies
2h15m

Ah someone else posted a link and I understand the unsoundness now.

The only time an issue ever came up for me was in dealing with arrays

  let foo: number[] = [0, 1, 2]

  // typed as number but it’s really undefined
  let bar = foo[3]
But once you’re aware of the caveat it’s something you can deal with, and it certainly doesn’t negate the many massive benefits that TS confers over vanilla JS.

lolinder
0 replies
1h43m

Yeah, that example is unsound in the same way that Java's type system is unsound, it's a compromise nearly all languages make to avoid forcing you to add checks when you know what you're doing. That's not the kind of problem that people usually are referring to when they single out TypeScript.

nyssos
0 replies
53m

Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application?

Sure. The usual Java-style variance nonsense is probably the most common source, but I see you're not bothered by that, so the next worst thing is likely object spreading. Here's an anonymized version of something that cropped up in code review earlier this week:

    const incomingValue: { name: string, updatedAt: number } = { name: "foo", updatedAt: 0 }

    const intermediateValueWithPoorlyChosenSignature: { name: string } = incomingValue

    const outgoingValue: { name: string, updatedAt: string } = { updatedAt: new Date().toISOString() , ...intermediateValueWithPoorlyChosenSignature }

cstrahan
0 replies
3h12m

No, TypeScript is not unsound because it uses structural typing.

A language has a sound type system if every well-typed program behaves as defined by the language's semantics during execution.

Go is structurally typed, and yet it is sound: code that successfully type checks is guaranteed to abide the semantics of the language.

TypeScript is unsound because code that type checks does not necessarily abide the semantics of the language:

  function messUpTheArray(arr: Array<string | number>): void {
      arr.push(3);
  }
  
  const strings: Array<string> = ['foo', 'bar'];
  messUpTheArray(strings);
  
  const s: string = strings[2];
  console.log(s.toLowerCase())
`strings` is declared as a `Array<string>`, but TypeScript is happy to insert a `number` into it. This is a contradiction, and an example of unsoundness.

`s` is declared as `string`, but TypeScript is happy to assign a `number` to it. This is a contradiction, and an example of unsoundness.

This code eventually fails at runtime when we try to call `s.toLowerCase()`, as `number` has no such function.

What we're seeing here is that TypeScript will readily accept programs which violate its own rules. Any language that does this, whether nominally typed or structurally typed, is unsound.

lolinder
0 replies
12h40m

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.

jaggederest
1 replies
13h23m

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.

crabmusket
0 replies
12h38m

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.

black3r
0 replies
9h39m

Or you can configure the TS compiler to allow JS imports, then everything also compiles and works, but you can slowly convert your codebase from JS to TS file by file and be sure that all TS files are properly typed and all JS files are untyped instead of having everything as TS files where some are typed and some are not.

pansa2
0 replies
13h5m

With this approach, do you still use Python's standard syntax for type hints?

    def mersenne(p: int): return 2**p - 1
Or, given there's no need for the type hints to be checker-friendly, do you make them more human-friendly, e.g:

    def mersenne(p: 'prime number'): return 2**p - 1

edflsafoiewq
0 replies
6h18m

IME if you aren't checking them, they're eventually going to be out of date.

Humphrey
0 replies
12h59m

Exactly. And if you use a library that does lots of meta programming (like Django) then it's impossible to pass all type errors. Hopefully one day the type system will be powerful enough to write a Django project with passing tests.

dobladov
15 replies
10h28m

You can have this now adding types with JSDoc and validating them with typescript without compiling, you get faster builds and code that works everywhere without magic or need to strip anything else than comments.

The biggest pain point of using JSDoc at least for me was the import syntax, this has changed since Typescript 5.5, and it's now not an issue anymore.

murmansk
10 replies
10h16m

For god's sake, please stop shilling JSDoc as a TS replacement. It is not. If you encounter anything more complicated than `A extends B`, JSDoc is a pain in the ass of huge intensity to write and maintain.

dobladov
2 replies
9h52m

You should write complex types in interfaces files where they belong, and there's full typescript support.

I use this approach professionally in teams with many developers, and it works better for us than native TS. Honestly give it a try, I was skeptical at first.

rty32
1 replies
7h38m

In general JSDoc is just much more verbose and has more friction, even outside complex types. I recently finished a small (20 files/3000 lines), strictly typed JS project using full JSDoc, and I really miss the experience of using the real TypeScript syntax. Pain points: annotating function parameter types (especially anonymous function), intermediate variable type and automatic type-only import, these are the ones that I can remember. Yes you can get 99% there with JSDoc and .d.ts files, but that's painful.

dobladov
0 replies
4h51m

I use snippets to write those, yes it's more verbose there's not denying that.

For me the advantages of just having JS files and not worrying about more complex source-maps, build files, etc definitely makes it worth it.

tracker1
1 replies
3h23m

JSDoc is also helpful in dealing with multiple argument option types for a function or constructor, which won't show in TS alone.

adhamsalama
1 replies
10h9m

You can write TypeScript types in JSDoc.

sureIy
0 replies
7h39m

You can’t write complex TypeScript types in JSDoc, which is what GP said.

The moment you need to declare or extend a type you’re done, you have to do so in a separate .ts file. It would be possible to do so and import it in JSDoc, but as mentioned before it’s a huge PITA on top of the PITA that writing types can already be (e.g. function/callbacks/generics)

Waterluvian
1 replies
5h53m

Jsdoc is honestly fine for simple and smaller projects. But yeah, it’s definitely not nearly as expensive while being anywhere as succinct.

yard2010
0 replies
2h11m

JSDoc is for docs, TypeScript is a static type checker. How can these tools be used interchangeably?

afavour
0 replies
6h36m

I’ve had a lot of success combining JSDoc JS with .d.ts files. It’s kind of a Frankenstein philosophically (one half using TS and one half not) but the actual experience is great: still a very robust type system but no transpiling required.

In a world where ES modules are natively supported everywhere it’s a joy to have a project “just work” with zero build steps. It’s not worth it in a large project where you’re already using five other plugins in your build script anyway but for small projects it’s a breath of fresh air.

itsmeste
1 replies
8h36m

I strongly agree, but JSDoc isn't "the cool thing". So it's left to be used by us, who care (and read their docs).

llimllib
0 replies
4h59m

The auto-export of declared types was what killed it for me

epolanski
1 replies
5h49m

JSDoc absolutely does not scale and allows for very limited type programming.

It's fine on toy projects, and somewhat I would say, for 99% of users that don't even know what a mapped or intersection type is.

mablopoule
0 replies
4h50m

JSDoc does not scale, but some projects are just better when they aren't scaled.

JSDoc is indeed fine on toy project, or in fact any project (even prod-ready ones) that doesn't warrant the trouble of adding NPM packages and transpilation steps.

Although they are rare, those type of small, feature-complete codebases do exists.

wiseowise
7 replies
11h45m

Beyond ugly. They should just make TS official and be done with it.

E: I thought it was JSDoc proposal. Ignore the comment.

blovescoffee
3 replies
11h17m

I did only briefly look at the proposal. What did you find so ugly?

wiseowise
2 replies
10h56m

I misread the proposal. Thought it was for JSDoc.

meiraleal
1 replies
4h51m

Misread no, you didn't read.

wiseowise
0 replies
3h42m

Yeah. I saw JSDoc and closed it, lol.

IshKebab
1 replies
11h20m

What do you mean ugly? This basically is making Typescript official.

They just can't have browsers doing the actual type checking because there isn't a specification for how to do that, and writing one would be extremely complicated, and I'm not sure what the point would be anyway.

wiseowise
0 replies
10h55m

I misread the proposal, tho it it was for JSDoc.

padavanchik
0 replies
11h19m

There is no language spec for TS. No alternative implementations. All we have is checker.ts. It's ugly and slow.

black3r
1 replies
9h49m

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript

Node.JS isn't the only JS runtime. You'll still have to compile TS to JS for browsers until all the browsers can run TS directly. Although some bundlers already do that by using a non-official compiler, like SWC (the one Node's trying out for this feature).

In Python, I've even heard of people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments.

It's not just comments. It's also, like the name "type hint" suggests, a hint for your IDE to display better autocomplete options.

pansa2
0 replies
9h5m

It's not just comments. It's also a hint for your IDE to display better autocomplete options.

Ah yes, autocomplete is another benefit of machine-readable type hints. OTOH there's an argument that another IDE feature, informational pop-ups, would be better if they paid more attention to comments and less to type hints:

https://discuss.python.org/t/a-more-useful-and-less-divisive...

Doxin
0 replies
12h8m

In Python, I've even heard of people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments.

Note that there's IDEs that'll use type hints to improve autocomplete and the like too, so even when not checking types it can make sense to add them in some places.

harshitaneja
58 replies
12h40m

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.

zx8080
22 replies
12h22m

we all just wanted java with JIT, more feature rich type system

Java has JIT. How is TypeSript type system feature-richer than the Java one?

VMG
9 replies
12h13m

1. *Type Inference*: TypeScript can automatically infer types from context, reducing the need for explicit type declarations. 2. *Union and Intersection Types*: Allows combining multiple types, offering more flexibility in defining data structures. 3. *Literal Types*: TypeScript supports exact values as types (e.g., specific strings or numbers), which can be useful for more precise type-checking. 4. *Type Aliases*: You can create custom, reusable types, enhancing code clarity and maintainability. 5. *Interfaces and Structural Typing*: Interfaces allow for flexible contracts, and TypeScript uses structural typing, where the type compatibility is based on the shape of the data rather than explicit type declarations. 6. *Mapped and Conditional Types*: These allow for dynamic type creation and manipulation, making the type system more powerful and expressive. 7. *Optional Properties and Strict Null Checks*: These provide better handling of undefined and null values.

tpm
8 replies
11h55m

That's just an copy-paste of some features, not a comparison with Java which does most of that too.

VMG
5 replies
5h34m

most of that? name one

tpm
4 replies
5h18m

Java has type inference. Also if a type alias is just a new name for a existing type, then you can always do something like

  class MyNewClass extends OldClass {};
(of course it's not just a new name, it's also a new class, but it's also still a OldClass, and you are out of luck if OldClass is final or sealed)

Java also has interfaces, of course. And optional properties (using Optional) and strict null checks, when you want that, you can use it.

VMG
2 replies
4h38m

type inference

very limited, for instance you must declare the type of a public method

alias

as you point out it's not

Java also has interfaces, of course

but you have to implement them explicitly

strict null checks, when you want that, you can use it

if we start accepting static analysis tools then C has null checks as well I guess

tpm
1 replies
3h30m

as you point out it's not

so what's the difference except the name?

if we start accepting static analysis tools

I'm not talking about static analysis. In today's Java you can write code that does not accept nulls, if you want to.

svieira
0 replies
2h7m

You cannot write code that will fail to compile `theEntryMethod(null)` unless you only use primitive types. (You can, of course, make that method fail at runtime, but that's not what's being talked about here).

guipsp
0 replies
4h39m

Using optional still has the secret third thing problem

afiori
1 replies
11h46m

Union types, structural typing, and conditional types are like a big chunck of what makes typescript typescript.

It is how TS is able to "type" a completely untyped language.

Just the support for union types is something that not even Haskell or Ocaml have.

nequo
0 replies
33m

I am not familiar with TypeScript. Is there something that you can achieve with union types that you can’t with sum types or type classes in Haskell?

yen223
5 replies
11h5m

Java and Typescript have fundamentally different type systems, that lead to drastically different ways to approach types.

Utility types, like Partial<T>, are basically impossible to represent in Java except with almost-duplicated classes.

tpm
4 replies
5h32m

drastically different ways to approach types

Exactly.

Partial<T>

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.

tpm
1 replies
3h28m

I understand that much, just thinking aloud what problem would that solve in Java.

scotty79
0 replies
2h50m

I think it's for when you need type that expresses partial data update for an object that has some fields required.

svieira
0 replies
1h54m

Yep - all non-primitive types in Java are `TheType | null` - TypeScript actually allows you to strip out the `| null`, which then means that sometimes you want to add it back in. So Java doesn't have a need for `Partial<T>`, it has a need for `NonNull<T>` and it can't express that at the type system level very easily right now (you can do it with type tagging and runtime checks inserted explicitly, but it's not very ergonomic right now)

https://gist.github.com/svieira/9f8beeafb7bf4aa55d40c638532f...

DarkNova6
2 replies
10h22m

alone puts TS over anything that Java has.

Virtual Threads alone challenge this assumption.

Syntax bloat is not a feature.

Byamarro
0 replies
8h12m

It's not really a syntax bloat, the linked docs mention how to define strict string types and elaborate on type-level programming, something that is a very rare and powerful type-level capability. As far as I understand Virtual Threads aren't type oriented feature, which is basically the context for this thread.

3836293648
0 replies
5h19m

Virtual Threads are not a type system feature?

dagenix
9 replies
12h31m

Java does jit

harshitaneja
8 replies
12h20m

Yes, 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.

sgammon
7 replies
11h53m

Native Java via GraalVM starts up in milliseconds.

wiseowise
6 replies
11h48m

And it has to go through slow compilation step. With Node you can have a cake and eat it too.

ZhongXina
2 replies
10h50m

You're saying it like it's an absolutely good thing. Some (many?) users would rather pay the cost upfront in compilation time (doesn't really matter if it's AOT or JIT) than pay the same cost many times over through a significantly slower runtime. JVM also scales up to supercomputers (and everything in between) if you want it to, so depending on your requirements a single-threaded alternative might not even be an option.

wiseowise
1 replies
10h40m

I’ll use C++ or Rust for such use cases.

sgammon
0 replies
10h4m

Okay!

DarkNova6
1 replies
10h16m

You can't be serious about comparing the technological capabilities of the JVM and Node and objectively declare the latter as the winner.

Compilation times are also an absolute non-issue.

You don't compile for development. You do it for production (in the rare circumstances that you need it).

harshitaneja
0 replies
6h53m

That's not what I am trying to convey here. JVM is amazing and it is a feat that java is as fast as it is and javascript and v8 are order of magnitude slower.

Also even though I also found java too verbose, I kept believing that we need it to be so to write good software. I still enjoy java but it doesn't compare to the ergonomics of typescript for me. And nimbleness of the experience according to me plays a decent role.

Currently for me, either I really care about performance and I default to rust for those applications or I need solutions where the product will evolve quickly over time and I need great DX over performance and I default to typescript for those.

Java definitely has a role to play but its role in my work has certainly diminished.

sgammon
0 replies
9h50m

It does not "have" to go through such a step, by the way, because you can simply run such code on the JVM.

bufferoverflow
9 replies
12h27m

Typescript is way better than Java, in my experience. It's a lot less verbose. A lot more flexible.

sgammon
4 replies
11h54m

They are not comparable. If anything, Kotlin is the equivalent in the JVM universe.

quonn
3 replies
11h7m

Kotlin is much closer to Java than to TypeScript even in terms of flexibility.

DarkNova6
1 replies
11h0m

To me "Flexibility" sounds a lot like "The programmer always knows what he does".

scotty79
0 replies
3h3m

Flexibility means for me more something more like, I think I know what I want to do but I also know that I'm probably wrong about that, so for now let's skip all the baroque protocol and let me make it work first. Once I'm sure I wrote what I actually wanted I'll add types if only to get rid of some bugs, consider edge cases and earn nice code completions and auto-generated docs.

sgammon
0 replies
10h45m

Sure, but Kotlin is to Java as TypeScript is to JavaScript, which is the point I am making.

ZhongXina
3 replies
11h0m

Better for what? Quickly churning out short-lived code to get the next round of funding, definitely. Writing (and _supporting_) "serious" projects over the long term, which also require high performance and/or high scalability, and can rip through terabytes of data if needed, definitely not. (All IMHO from lots of personal experience.)

viridian
1 replies
5h16m

Depends on your architecture. For scaling out rather than up, node and python are both far more performant because the footprint of minimum viable environment is much smaller. When you need to serve anywhere from 10-200,000 requests a minute on the same system quickly, and efficiently, lambda/azure functions/google app engine backed by node or python is pretty ideal.

As an example, when my org needs to contact folks about potential mass shooter events, our SLA is 90 seconds. If we did it in cloud with java or .net, it'd be too slow to spin up. If we did it on prem, we'd be charged insane amounts just for the ability to instantly respond to low frequency black swan events, or it'd be too slow. This is a real story of how a Java dev team transitioned to using node for scale in the first place.

neonsunset
0 replies
4h40m

Unlike Spring, JIT-based ASP.NET Core deployments spin up very fast (<2-5s for even large-ish applications, the main bottleneck is how fast it can open connections to dependencies, load configuration, etc.). For AOT variant, the startup time is usually below 200ms if we don't count the slowness of surrounding infra which applies to any language.

Of course CPU and RAM per request when compared to Node.js are not even close as Node is easily slower by a factor of 2-10.

hot_gril
0 replies
2h36m

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.

tomjen3
2 replies
10h57m

The typesystem of Java was so laughably unpowerful that it severely constrained what you could write.

In Typescript you have far more freedom, and all the benefits of strong types.

yen223
0 replies
5h43m

The fact that Java forced you to write types, and then made everything implicitly nullable so that you still get NullPointerExceptions at runtime after writing out all those types, was probably a big reason why dynamically-typed languages became popular.

DarkNova6
0 replies
10h15m

Strong types without strong typing that is.

qalmakka
2 replies
12h17m

we all just wanted java with JIT

Java was literally the thing that made the term "JIT" popular, so I really don't know what you were going for here.

Also I just can't see how Typescript is in any way "closer" to Java - it's incredibly different IMHO. The only thing they have in common is probably the "Javascript" misnomer and the fact both support imperative programming, but that's it.

seanmcdirmid
1 replies
12h2m

Typescript’s optional and unsound type system also does nothing for a JIT beyond what it could already do for JavaScript, you can’t do optimization if your types are unreliable. However, I really really like how Typescript’s type system super charges developer productivity (type errors via the compiler and feedback via the IDE), and don’t mind this part of the design at all.

teaearlgraycold
0 replies
11h27m

You can use typescript types to compile functions. You just might need to deoptimize when you actually hit the function.

38
1 replies
12h16m

gradual typing

AKA dynamic typing. Unless it's 100% static, it's dynamic

debugnik
0 replies
7h24m

Gradual typing could still keep some static guarantees if the static part were sound, e.g. you couldn't assign a dynamic-typed integer to a string-typed variable without checking the type at runtime first; which TypeScript isn't.

Elixir's new type system does much better here, as it determines whether a function actually guards for the right type at runtime ("strong arrows") and propagates the guarantees, or lack thereof, accordingly.

wiseowise
0 replies
11h49m

Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem.

God I wish they’d just integrate something lightweight like npm into JDK.

It is beyond me why you have to install third-party heavy weight tool just to manage dependencies.

scotty79
0 replies
3h10m

Gradual typing is the key. The problem with Java is that types are in your face way before you actually need them.

With TS you can prototype with JS and only after you know what you are looking for you can start to add types to find bugs and edge cases and want to get nice code completions for your stuff.

ninepoints
0 replies
12h22m

Not having an opaque tech stack encumbered by a patent minefield is another plus.

lmm
0 replies
10h11m

Java's type system was just very limited, gradual typing is a poor tradeoff most of the time. I used to think there were advantages to something like Python, but once I found Scala I never went back.

jddj
0 replies
11h34m

I'm somewhere here as well. Personally I think what I want is the stdlib (without the current legacy/ all but deprecated bits) and ecosystem of c# but with the ease and power of structural algebraic types. AoT is fine, with option for single binary. Ideally runtimeless with clever trimming. If it also ran jitted in the browser all the better.

I also want compiler/type checker niceties like exhaustive pattern matching.

hot_gril
0 replies
2h34m

The type system is a big part of what made Java cumbersome. It's loosened up a little over the years. TS itself may allow partial typing, but when team/company policies are involved, you'll often end up being forced to type everything.

bubblyworld
0 replies
12h25m

I'm very glad to use typescript over java, personally - the ergonomics are so much better! Especially if you stray away from the somewhat incomplete classes thing (type support for decorator arguments isn't great, for instance) and just focus on interfaces and functions.

One thing I miss that java has is runtime reflection of types though. Typescript's ecosystem has a million different ways to get around that and they're all a bit ugly imo.

spankalee
45 replies
14h24m

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 TypeScript because it'll have to stay backwards compatible, but it's grown to that point now, imo.

spankalee
14 replies
14h7m

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

dgellow
13 replies
13h59m

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

spankalee
9 replies
13h47m

This proposal aims to enable developers to add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript. At runtime, a JavaScript engine ignores them, treating the types as comments.
dgellow
8 replies
13h42m

Yes, that’s explaining what type erasure is. “type as comments” is what Flow supports, literal comments for type annotations.

I think we disagree on the terminology but agree on the goal of the proposal

pcthrowaway
3 replies
13h35m

Types as comments is what jsdoc supports. Flow is compiled like typescript.

tsc does also support jsdoc though, so technically I think tsc is closer to supporting types as comments, though it's possible Flow has this also.

pcthrowaway
0 replies
19m

Thanks, I've never used flow and didn't know this. I've only seen it used in the non-comment form.

spankalee
0 replies
17m

Types _in_ comments is different from types _as_ comments. "Types as comments" refers to how type expressions are parsed.

eyelidlessness
2 replies
13h30m

The proposal would explicitly treat supported type annotation syntax as comments in the grammar. It is definitely types as comments, even if it is also type erasure.

And it would apply to Flow’s type annotation syntax which is also not presently treated as comments, at least for the very large subset of that syntax which overlaps with the proposal.

eyelidlessness
0 replies
3h21m

I know what you meant.

spankalee
0 replies
13h27m

"types as comments" is the term that the champions and reviewers of this proposal have been using.

It refers to how the types are parsed: aside from some kind of standard start and end delimiters, the parser does not try to parse the expression-level type syntax. Type expressions are just strings of characters. This way you can have basically any syntax at all for types.

madeofpalk
0 replies
7h44m

It explicitly is, from the link

At runtime, a JavaScript engine ignores them, treating the types as comments.

The phrasing here is that the types are meaningless. They are just "comments" to the JS engine.

jraph
0 replies
12h43m

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

crabmusket
0 replies
12h46m

That has no bearing on the comment you're replying to.

The point is that the types could be TypeScript, Flow, Hegel, or something else. The browser won't perform type checking, it will just ignore the types.

So, it is not standardising TypeScript.

vivzkestrel
10 replies
14h16m

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

jjk7
4 replies
14h10m

There are a few optimizations that types can use but 99% of applications wouldn't benefit from them anyways.

Shacklz
2 replies
13h45m

Taking one link out of the toolchain (tsc) would already be a huge blessing.

And naive me hopes for a future where in my web-app I can set a policy that any non-ts, type-incompliant code is not allowed to run.

The amount of exceptions I get in the console from terrible garbage-code outside of my control but that I have to include because enterprise is staggering. Would love to have a meta-setting which would just kill them if they can't be arsed to even have a modicum of code-hygiene (sorry for the rant)

_flux
1 replies
9h28m

Why is taking out the part that actually checks the types at the developer's side a huge blessing?

Or if you are hoping to get the benefit of type checking in the browser itself (taking the same sweet time as tsc, but this time on every browser instead of once in the CI), then how long would you want to wait to be able to actually use the new typing functionality described in e.g. the latest TS annoucement? https://devblogs.microsoft.com/typescript/announcing-typescr... .

Because it would take a while until that would then become the standard and then become available in every browser. And you still need to provide the JS versions, because not every browser is going to support TS.

In the meanwhile you could just keep using tsc just as before and get access to new functionality immediately.

(I imagine you could run tsc in the browser right now if you really wanted to.)

Shacklz
0 replies
4h44m

Why is taking out the part that actually checks the types at the developer's side a huge blessing?

Oh, no, certainly we want to keep type-checking in the pipeline, somewhere.

However, if the browser "understood" typescript, your codebase could have immediate hot-reload, without any transpilation in-between. The type-checking could then be (and already is when using something like esbuild/swc) an entirely separate process that happens independently.

Webpack's HMR is pretty good, but not having to modify the code at all to have it work in the browser, that'd be much much better :)

... the browser being able to typecheck (and reject violating code) itself is certainly something I'd love to see eventually, but fully agreed, this is not happening anytime soon.

flohofwoe
0 replies
11h32m

One advantage of Typescript in context of performance should be that it nudges one to not change the 'shape' of runtime objects too much, this should allow less runtime overhead in JS engines because code doesn't need to be re-jitted as often.

This doesn't require the type annotations at runtime though, it's just a side effect of code being written against a static type system.

crabmusket
2 replies
12h44m

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.

dtech
1 replies
9h36m

That's a pretty obtuse interpretation of the comment. Browsers natively being able to run Typescript code / .ts files instead of requiring transpiling to plain Javascript would be a large boon to the TS ecosystem by making basically everything easier. Even if it's just stripping the TS and running the plain JS it would already be helpful, but it running the typechecking beforehand would be wonderful.

crabmusket
0 replies
5h26m

Maybe I was reading too much into the comment I replied to, but to me "a typescript engine" implied more than "ignoring the types" (which is the current TC39 proposal).

And I was replying based on what I've seen other people saying whenever the subject comes up; apologies if I misread.

Browsers doing type checking is a pretty fraught idea IMO, at least with Typescript and not some other statically typed language entirely.

rty32
0 replies
6h45m

My take as an outsider: Google has absolutely no interest in this, especially with their recent cost-cutting measures. Google cares about things that make the "web" better for the end users so that they can sell more ads, not developer tools. TypeScript or JavaScript doesn't matter that much to Google, and actually Google probably doesn't want to see TypeScript files distributed over network (which doesn't make much sense in the first place). In all honesty, Microsoft understands development experience much better than Google and most other companies. They literally own Visual Studio, Visual Studio Code and GitHub and sell products/services for money.

mcintyre1994
0 replies
12h15m

A lot of apps would (or at least should) still want to strip types for bundle size reasons though.

To take one extreme example, a library I work on includes an API for calling a JSON RPC server. Instead of manually implementing each call, we use a proxy object that converts any method call on it to a JSON RPC call. Then layer on types so given an RPC object you know every method on it and have typed input params and output. This means you can have any number of methods without increasing your bundle size, because all the types disappear at runtime. It also means you can add your own methods if you’re talking to a server that implements custom ones by just defining types. If you shipped this to the browser with the types then it’d be a much bigger bundle than without them.

tylerchilds
5 replies
14h4m

i’m not sure i buy the “company floods the industry with broken tooling and deserves to be standardized” narrative.

yeah, the ecosystem sucks, but rewarding the system incentivized to co-opt the system will actually make things worse in the long run, not better.

for example, internet explorer failed why?

dgellow
4 replies
13h52m

What broken tooling are you talking about? tsc is broken?

IE failed because it was a horrible browser that didn’t evolve for years and was incompatible with major web standard developments. Nothing to do with typescript, an open source, best in class type system and type checker.

tylerchilds
2 replies
12h14m

“During the transpilation process, no type checking is performed, and types are discarded.”

this node feature is primarily around disregarding typescript in favor of the underlying javascript it represents.

that reminds me of this fun article: https://www.richard-towers.com/2023/03/11/typescripting-the-...

dgellow
1 replies
10h44m

Yes, the feature is about being able to run typescript scripts. It’s not a type checker, it is similar to ts-node, deno, bun, etc. Typescript has been designed for that specific purpose.

tylerchilds
0 replies
5h21m

seen and heard, my original point was that typescript is not poised to be a tc39 standard.

this is still a “runs some typescript” and “not runs every typescript file”

“ At least initially in this PR no trasformation is performed, meaning that using Enum, namespaces etc... will not be possible.”

this type of nuance is the core of why typescript is a headache for any organization with more than a single codebase— javascript is portable, typescript is in theory, but not in observed practice.

tylerchilds
0 replies
13h23m

IE failed because they tried to define the standard as themselves. i argue we’re witnessing that again from the same company that only gave up that strategy once they had typescript, github, npm locked in.

i’m not bullish on political strategies being technical solutions, which is the premise.

typescript has nothing to do with internet explorer, true, but is it really not obvious that it is the same tactic as a different brand? become the standard, steer the committee.

and broken in that copying code between systems requires compatibility between configurations, which should be a red flag for any language.

dgellow
4 replies
13h56m

I would rather let Typescript evolve a few more years before freezing its development via standardization

suby
2 replies
13h3m

I'm interested to know what are some things that you (or anyone reading this) feels that Typescript is missing / should change?

rty32
0 replies
6h52m

One example:

https://github.com/microsoft/TypeScript/issues/30551

Which goes to https://github.com/microsoft/TypeScript/issues/9998 which captures a lot of such scenarios

And just a few releases ago there were some big problems with handling recursive types. I think most are fixed but there may still be a few around.

These are things that you run into on a daily basis if you write enough TypeScript.

I doubt we should standardize TypeScript before we have definitive solutions to all these. And I 100% agree with the parent's comment.

_flux
0 replies
9h37m

I don't have a list and I don't even write TS (or do much web dev in general), but I do follow their announcements and it seems every one of them brings new big type things.

Nevertheless, I don't see TS support in e.g. browsers being anything useful, as in practice all JS code deployed is already packaged somehow, so the stage to convert TS to JS (and then also checking the types..) fits that just fine. It's useful for hobbyists, but I don't that is a reason enough to come up with a standard.

pas
0 replies
7h25m

C++ and Java are quite good at churning out standard docs and new versions every few years. (Even Python is aiming to offer GIL-lessness!)

paulddraper
2 replies
14h13m

TypeScript used to have a standard.

Years and years ago. Now it's whatever the compiler does.

Which to be fair, is evolving quite rapidly.

spankalee
1 replies
14h5m

Yeah, that was from 2016 or so. But a TypeScript spec is different than folding TypeScript into the ECMAScript standard. Some parts of TypeScript would have to be dropped or changed for that to work.

paulddraper
0 replies
13h31m

Right, having a spec is easier (and effectively prerequisite) to your suggestion.

But they don't have it.

silverwind
1 replies
9h1m

Imho standardizing the syntax is enough and this is what https://github.com/tc39/proposal-type-annotations does.

The type checker is immensely complex and should be left out so that other type checkers can be developed, e.g. similar to how it's for Python today.

spankalee
0 replies
15m

That doesn't standardize the syntax, only types-as-comments. It would have to standardize some delimiters for type expressions, but that's it.

I do think that the semantics should be standardized too, otherwise you have non-interoperable types. The goal should be that you can use two libraries together without having to make sure they use the same type-checker.

pier25
0 replies
4h47m

Another reason is probably performance. Executing TS would require a lot of extra CPU and even more energy than JS.

A lot of effort and money has been invested into JS engines. I wonder if making a TS native engine (which nobody has made yet) from scratch might make more sense than adapting JS engines to run TS.

hajile
0 replies
3h56m

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.

zarzavat
36 replies
11h54m

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 < bar & baz > ( x )`. In TypeScript 1.5 this parsed as (foo<bar) & (baz > (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo<(bar & baz)>(x) which desugared to foo(x). I realise I’m going back in time here but it’s a nice simple example.

If you want to continue to use new TypeScript features you are going to need to keep compiling to JS, or else keep your node version up to date. For people who like to stick on node LTS releases this may be an unacceptable compromise.

nialv7
10 replies
5h25m

Using inequality signs as angled brackets really is a mistake isn't it...

klodolph
6 replies
5h16m

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.

zarzavat
4 replies
4h58m

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 brackets wouldn't work for parametric functions because f[T](x) already means get the element at index T and call it.

parasense
1 replies
1h14m

Paired characters...

That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes... no idea what new sets would look like.

pshc
0 replies
4m

So many different pairs are available. I like Asian corner brackets 「」and French guillemets « ». The angle brackets 〈〉 are popular in CS/math papers I think, though they might be confused with <>.

xigoi
0 replies
3h54m

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

behnamoh
0 replies
3h44m

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 &@$#%^*}{][<>()/\_~|

lolinder
0 replies
4h34m

I don't think you're flipping it around, I think that's exactly what OP was saying, just clearer.

SomeCallMeTim
1 replies
1h56m

It's not a TypeScript mistake.

You could argue that it was a C++ mistake. It makes parsing harder, but otherwise seems to work as expected, so I don't consider it a mistake, but you could at least argue that way.

But regardless if it was a mistake in C++, it's now a complete standard, used in C++, Java, C#, and other languages to denote type parameters.

I would argue that it would have been a mistake to break that standard. What would you have used, and in what way would that have been enough better to compensate for the increased difficulty in understanding TypeScript generics for users of almost every other popular language?

vips7L
0 replies
1h31m

It's definitely the right choice for Typescript. You could have gone the Scala route and used [] for generics, but that is so heavily used in ts/js as arrays it would not have made any sense.

jmull
0 replies
4h34m

Mistake isn't the right word. It's just a tradeoff.

There was no perfect solution available, so a tradeoff was necessary. You can disagree with this particular tradeoff, but had they gone another way some people would disagree with that as well. To be a mistake there would have had to have been an option available that was clearly better at the time.

Anyway, the idea that TS 5 should be backwards compatible with TS 1 is probably a bad one. Personally, I think packages with wide usage break backwards compatibility far too easily -- it puts everyone who uses it on an upgrade treadmill, so it should be done very judiciously. But even I wouldn't argue that TS 1 should have been its final form.

the_gipsy
8 replies
11h10m

You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But that's probably not an issue.

zarzavat
6 replies
10h17m

It’s an issue because node has a system of LTS releases, whereas TypeScript has quarterly updates, so the release cadence is different.

Updating node is much more fraught than updating TypeScript. For example, it may break any native code modules. That’s why users are directed to use the LTS and not the most recent release, so that there’s enough time for libraries to add support for the new version.

On the other hand, I usually adopt a new TypeScript version as soon as it comes out.

mort96
2 replies
9h9m

TypeScript feels "boring" enough at this point that being a few years behind isn't gonna be an issue in most cases. For teams who want to stay on the absolute latest release of TypeScript but want to be more conservative with their Node version, external compilation will remain necessary; but for someone like me, where TypeScript has been "good enough" for many years that I'm not excited by new TypeScript releases, this feature will be really nice.

("Boring" in this context is a compliment, by the way)

EDIT: Though reading other comments, it seems like you can update the typescript stripper independent of node? That makes this moot anyway

mu53
1 replies
7h59m

typescript is still evolving in dramatic ways. The 5.0 release has some really good improvements

mort96
0 replies
5h34m

But at the same time, it's good enough and has been good enough for many years. It's like how I'm sure EcmaScript 2024 contains cool new stuff, but if node only supported ES6, I would have no trouble writing ES6.

another-dave
1 replies
10h8m

Though I'd primarily see this as a feature for the REPL or manual scripts where I'm not going to mind doing a `nvm use X`.

For production use, I'd still put my TS files through a build pipeline as normal

chrisweekly
0 replies
5h52m

tangential protip: if you're using nvm to manage node versions, take a look at fnm as a superior replacement. (It can read the same .nvmrc file to switch on cd into a given dir, but it's faster and "cleaner" wrt impact on your shell.)

satanacchio
0 replies
9h11m

I made it sure to decouple the transpiler from node itself, the transpiler is in a npm package called amaro, that is bundled in node. The goal is to allow user to upgrade amaro indipendently so we dont have to lock a ts version for the whole lifespan of a release

klodolph
0 replies
5h9m

Not necessarily.

With a couple exceptions (like enums), you can strip the types out of TypeScript and end up with valid JS. What you could do is stabilize the grammar, and release new versions of TypeScript using the same grammar. Maybe you need a flag to use LTS grammar in your tsconfig.json file.

spoiler
3 replies
11h11m

It's possible that internal SWC version will be versioned alongside Node, meaning TS syntax support won't drift. Or am I missing something?

thecopy
1 replies
10h18m

TypeScript evolves independent of Node, and the syntax you can use depends on your `typescript` version in the `package.json`

re-thc
0 replies
8h44m

Not if SWC or your tooling doesn't support it.

satanacchio
0 replies
1h59m

yes but can also be upgraded separately as npm package

WorldMaker
3 replies
3h22m

The syntax from the perspective of type stripping has been relatively stable for more versions of Typescript than it was unstable. You had to reach all the way back to 1.5 in part because it's been very stable since about 2.x. The last major shift in syntax was probably Conditional Types in 2.8 adding the ternary if operator in type positions. (The type model if you were to try to typecheck rather than just type-strip has changed a lot since 2.x, but syntax has been generally stable. That's where most of Typescript's innovation has been in the type model/type inferencing rather than in syntax.)

It's still just (early in the process) Stage 1, but the majority of Typescript's type syntax, for the purposes of type stripping (not type checking), is attempting to be somewhat standardized: https://github.com/tc39/proposal-type-annotations

teaearlgraycold
2 replies
2h25m

They did just add a new keyword, satisfies, in 5.4. That would be a breaking change if you can’t upgrade the type stripper separately.

panzi
0 replies
1h15m

But at least its a loud failure and not a silent different interpretation of the source as the example was. Still.

felixfbecker
0 replies
1h9m

This is true, but in other cases they added keywords in ways that could work with type stripping. For example, the `as` keyword for casts has existed for a long time, and type stripping could strip everything after the `as` keyword with a minimal grammar.

When TypeScript added const declarations, they added it as `as const` so a type stripping could have still worked depending on how loosely it is implemented.

I think there is a world where type stripping exists (which the TS team has been in favor of) and the TS team might consider how it affects type stripping in future language design. For example, the `satisfies` keyword could have also been added by piggy-backing on the `as` keyword, like:

    const foo = { bar: 1 } as subtype of Foo
(I think not using `as` is a better fit semantically but this could be a trade-off to make for better type stripping backwards compatibility)

madeofpalk
2 replies
7h53m

It looks like the team has already considered this in one regard

There is already a precedent for something that Node.js support, that can be upgraded seperately, its NPM. Node bundles a version of npm that can upgraded separately, we could do the same with our TypeScript transpiler.

We could create a package that we bundle but that can also be downloaded from NPM, keep a stable version in core, but if TypeScript releases new features that we don't support or breaking changes, or users want to use the new shiny experimental feature, they can upgrade it separately. This ensures that users are not locked, but also provides support for a TypeScript version for the whole 3 years of the lifetime of Node.js release.

https://github.com/nodejs/loaders/issues/217

SomeCallMeTim
1 replies
2h2m

As long as Node understands to use the project-specific version of TypeScript (i.e., the one in node_modules or the PNP equivalent), that should be fine.

But it would be a step backward to need to globally upgrade TypeScript (as you do with npm), since some older projects will not be compatible with newer versions of TypeScript.

Ask me how I know. ;)

silverwind
0 replies
51m

As long as Node understands to use the project-specific version of TypeScript

It won't, but in such a scenario, typescript would only be a type checker, wich is a entirely different endeavor than running typescript.

Tade0
1 replies
10h0m

I'm not worried about that too much to be honest.

To me beyond v4.4 or so, when it started being possible to create crazy recursive dependent types (the syntax was there since ~4.1 - it's just that the compiler complained), there weren't a lot of groundbreaking new features being added, so unless an external library requires a specific TS version to parse its type declarations, it doesn't change much.

3np
0 replies
8h0m

crazy recursive dependent types

Some edge-cases involving those have bugfixes and ergonomy improvents I've run into on 5.x.

noname120
0 replies
9h40m

It's already the case for ECMAScript and I don't see why TypeScript should be treated differently when Node.js has to transpile it to JavaScript and among other things ensure that there are no regressions that would break existing code.

Unlike Python typing it's not only type erasure: enums, namespaces, decorators, access modifiers, helper functions and so on need to be transformed into their JavaScript equivalent.

getcrunk
0 replies
7h27m

Do you really need to update all the time? Are the new features always that immediately important?

felixfbecker
0 replies
1h6m

I think the kind of teams that always stay on top of the latest TypeScript version and use the latest language features are also more likely to always stay on top of the latest Node versions. In my experience TypeScript upgrades actually more often need migrations/fixes for new errors than Node upgrades. Teams that don't care about latest V8 and Node features and always stay on LTS probably also care less about the latest and greatest TypeScript features.

rockwotj
21 replies
14h32m

My favorite deno feature is coming to node directly. Awesome!

Maybe this means I don't always have to install esbuild to strip types - very excited how this will make writing scripts in TypeScript that much easier to use. I lately have been prefering Python for one off scripts, but I do think personally TypeScript > Python wrt types. And larger scripts really benefit from types especially when looking at them again after a few months.

yamumsahoe
10 replies
14h20m

btw if anyone is looking to run ts on node, there is tsx. there is also ts-node but i prefer tsx.

https://github.com/privatenumber/tsx

iansinnott
4 replies
12h52m

Seconded again. While tsx usually just works ts-node almost never just works. tsx is perhaps unfortunately named though so it may confuse people at first since it has nothing to do with jsx syntax.

jimvdv
2 replies
12h30m

Thank you for bringing this up, I almost ignored this project since I assumed it had something to do with TypeScript + JSX.

The JS ecosystem sure struggles with naming things.

tommica
1 replies
12h11m

The _programming_ ecosystem sure struggles with naming things.

jimvdv
0 replies
4h55m

Fair enough

tills13
0 replies
1h39m

It's named as such to mirror `npx`

herpdyderp
1 replies
6h33m

Does swc-node work with code coverage calculation libraries? For a long time tsx didn’t (and it’s still pretty finicky) so that kept me from using it.

silverwind
0 replies
4h4m

Not sure what features those need, but at least the stack traces are correct in swc-node, so maybe worth a try.

wruza
0 replies
8h17m

Tsx’s only reset-in-console mode is <Enter>, which makes it impossible to develop cli apps in watch mode.

You cannot run tsx from a non-project cwd if you’re using tsconfig/paths.

And personally I find its maintainers relatively unpleasant to message with. Leaves “you’re plebs” aftertaste most of the times.

jessym
0 replies
13h34m

I second this. The tsx library is zero config and always "just works" in my experience, which puts it miles ahead of ts-node, imo.

yamumsahoe
7 replies
14h25m

correction: the only deno future that i want

sholladay
5 replies
13h11m

Deno has so many other great features. Most web standard APIs are available in Deno, for example. It can do URL imports. It has a built in linter, formatter, and test framework. Built in documentation generator. A much better built in web server.

Node is copying many of these features to varying degrees of success. But Deno is evolving, too.

johnny22
3 replies
12h35m

the url imports is one the things I don't want.

sholladay
1 replies
3h8m

You want to be forced to use a centralized registry? I don’t know. URL imports also enable fully isomorphic modules. I think you would enjoy the freedom of URL imports if the ergonomics were better. For example, it should just default to https:// so you don’t have to type that. Import maps also help a lot with this, definitely use them. But they could be even better by having first-class support for templating the module version into the URL so that the version can be stored separately, alongside the module name. Popular hosts with well-known URL structures could have their URLs automatically templated so you only have to specify the host and not the rest of the URL.

In other words, the tooling could be better, but the fundamentals of URL imports are sound, IMO.

zzo38computer
0 replies
1h38m

I disagree. It should not default to "https://" (I think defaulting to local files would be better).

Furthermore, I think that it should be made so that the "hashed:" scheme that I had invented (in the Scorpion protocol/file-format specification document, although this scheme can be used independently of that) can also be usable.

And, popular hosts with well-known URL structures automatically templating also I would disagree, although it might do to allow any expressions in place of the string literals and then add functions for abbreviations of some of those URLs, if that would help (although I still think it is unnecessary).

niklasmtj
0 replies
12h17m

There are also the `npm:`, `node:` and `jsr:` specifiers now. So you don't have to use the URL imports if you don't feel them.

throwitaway1123
0 replies
12h16m

Node supports URL imports via the --experimental-network-imports command line option. There's also a built in test runner now.

WuxiFingerHold
0 replies
7h27m

... and obviously the only one you know.

Kidding aside: You should really take an hour and check out the manual and std lib (https://jsr.io/@std). I was surprised how far Deno has come. A lot of pretty useful stuff you would otherwise need tons of NPM modules for.

tnzk
0 replies
8h6m

This seems very interesting approach to scripting. Does it basically provides with an alias to child_process.exec as $ and besides that I can write in the same way I'd do in Node?

Node.js standard library requires additional hassle before using

I read the hassle as having to setup Node runtime in advance, but zx requires npm to install so I'm not sure.

samtheprogram
18 replies
14h28m

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, I can’t imagine the user experience (or performance) to match Bun’s when it reaches stable.

spankalee
6 replies
14h3m

Extensions should be required. It's not possible to do path searches over the network like you can on local disk, and network-attached VMs, like browsers, are a very, very important runtime for JavaScript.

pfg_
1 replies
12h18m

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.

WorldMaker
0 replies
2h43m

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 bundles can, sure the trade-off is network requests but we are in a good place to take that trade-off), we're at an exciting point where there is almost never a need to bundle in development environments, and it is increasingly an option to not bundle in production either. It is worth benchmarking today (I can't tell you what your profiler tools will tell you) if you are really gaining as much from production bundles as you think you are. Not enough people are running those benchmarks, but some of them may already be surprised.

The Developer Experience of unbundled ESM is great. Of course you do need to do things like always use file extensions. But those aren't hard changes to make, worth it for the better Developer Experience, and if it can help us start to wean off of mega-bundler tools as required production compile time steps.

leipert
1 replies
12h53m

Also performance.

foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx.

So 12 times the stat checking for each import.

simlevesque
0 replies
43m

foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups.

Only in the worst case. If it's foo.js there's only one lookup.

Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import.

Again, you're only taking into account the worst case.

silverwind
0 replies
9h6m

Yeah, besides that, leaving out the extension also creates ambiguity when the same filename exists with multiple file extensions.

samtheprogram
0 replies
12h58m

That makes sense. I guess since using .js for the relevant imports just works in TypeScript I should be happy then…

oblio
2 replies
9h4m

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

laxis96
1 replies
8h2m

Probably had to stay in the oven a bit longer...

Jokes apart, Zig is moving forward a lot which is why it's not 1.0 yet, but it doesn't mean you can't write safe and performant applications right now.

Zig is also a rather simple and straightforward language (like C) and has powerful compile-time code generation (like C macros, but without the awful preprocessor).

oblio
0 replies
5h26m

I'm more worried about compilation or stdlib bugs. In theory you can do lots of things with lots of things, but in practice there are all sorts of hidden limitations and bugs that tend to be noticed once a software product is past 1.0 and has been out in the wild for half a decade or more.

hackandthink
2 replies
12h1m

"nor have tsc configured to automatically add .js extensions to its compiled output"

It seems to be the default now:

  $echo 'console.log("test")' > t.ts
  $ tsc t.ts
  $ ls
  t.js  t.ts
  $ node t.js
  test

WorldMaker
0 replies
2h40m

Given the context of Node here will allow experimental type-stripping and will not be doing things like import rewriting, Typescript's decision here to focus on "users write .js in imports because that's how the type-stripped file should look" seems like the right call to me. Less work for a type-stripper because Typescript can already check if there is a .ts or .d.ts file for you if you use .js imports everywhere.

IshKebab
1 replies
11h19m

unprecedented

Well except for Deno...

pas
0 replies
7h31m

Bun started with compatibility with NodeJS as a primary goal, whereas for Deno it took a while to be able to import npm stuff. (Of course there are fun WTF[0] errors with Bun, and I only tried Deno before the npm import feature landed.)

[0] https://github.com/oven-sh/bun/issues/11420

k__
0 replies
10h32m

Bun is pretty awesome.

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

WuxiFingerHold
0 replies
7h33m

I like Bun a lot, but Deno is (still) the more mature, stable, capable (e.g. stable workers, http2) and depending on the use-case more performant option (V8 > JSC). DX and tooling is top-notch. Deno can perform typchecking, btw. They bundle the TSC IIRC. Bun is the hype, but Deno is currently clearly the better option for serious endevours. Still, the vision and execution of Bun is impressive. Good for us devs.

storafrid
12 replies
13h5m

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 to evolve more before actually marrying and having kids with it. But at the same time, I like the direction Node.js is taking.

coffeemug
5 replies
12h56m

What's an example of a ceiling? Out of all the mass-market programming languages, TS arguably has the most advanced type system in the world. It's a modern marvel that they got it working on top of Javascript.

mdhb
1 replies
12h49m

I don’t know what you mean here by advanced? If you mean the sheer amount of fuckery they have to do in order to make it work with JS perhaps you have a point.

If you mean expressiveness or consistent or soundness then no, it’s actually very bad compared to almost anything else and I think the longer it goes on the more it starts to feel like a house of cards.

The upside I guess is that whenever Safari decides to get their shit together Web Assembly is well placed to get us out of the scenario where we are forced to use JS and as an extension Typescript at all for most things and actually good language choices with reliable type systems like Dart, Kotlin and C# all become viable options.

There is no way I’d choose JavaScript over those other options in the majority of scenarios unless I was forced to.

wiseowise
0 replies
11h34m

The upside I guess is that whenever Safari decides to get their shit together Web Assembly is well placed to get us out of the scenario where we are forced to use JS and as an extension Typescript at all for most things and actually good language choices with reliable type systems like Dart, Kotlin and C# all become viable options.

Out of those three only Dart has nice DX story compared to JS world.

bottlepalm
1 replies
12h48m

I think it took the seemingly impossible challenge of bringing typing to a dynamic language that made typescript so powerful in the first place.

All other static languages start bottom up, simple to more complex, but end up getting boxed in by their own design. TypeScript started top down, trying to map itself on to a fully dynamic language. Never getting boxed in, just trying to 'fill' the box that is all the possibilities of JavaScript. 10 years on and TypeScript is still exciting, making significant updates and improvements.

randomdata
0 replies
11h35m

Typescript isn't particularly powerful compared to other non-mainstream languages, though, which is why the parent comment was careful to add that caveat. Which is to say that I'm not sure the idea that "all other static languages" start simple and get boxed in stands up.

You may have a point that Typescript would have been relegated to obscurity with all the others had it tried to start "top down" as a brand new language. There may be some truth that it is a necessity of a language to start simple in order to become accepted in the mainstream and that Typescript only made it because it rode on the coattails of a language that also started simple: Javascript.

storafrid
0 replies
11h53m

Certainly advanced, but not mature in my experience. Using e.g. classes and inferred generic function arguments, quickly reveals a lot of features that are missing. Often some similar feature is present but it lacks depth/completeness. Lots of good discussions to read in TS repo on GitHub if you're interested: Optional generic type inference, extends oneof, generic values, keyof a subset, conditional types, etc.

I want to emphasize that the reason we keep running into "ceilings" is probably because of its advanced type system. Libraries and frameworks are using those type features and when we can't keep building on the type - we end up casting to unknown and reconstructing it. Which feels worse than not being able to construct that complex type at all.

SebastianKra
4 replies
12h43m

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.

fire_lake
2 replies
11h37m

C# has record (product) types now.

crabmusket
1 replies
10h46m

I'm not sure about the terminology here, but the & in TS is much more than a record. You can use it to smush types together e.g.

{name: string} & {birthday: Date}

becomes a single type with both properties.

fire_lake
0 replies
5h9m

Product types are tuple types.

Record types are tuple types with names instead of indexes.

The TypeScript “&” is another thing.

storafrid
0 replies
11h42m

Sorry I probably used the wrong term, not a native English speaker. I didn't mean lack of complexity or lack of "features" but rather the lack of carefully thought-through feature "depth". Like, we can infer generic arguments which is nice, but then we try doing that with some keyof complex type and it doesn't work. And later we find an issue on GitHub saying that it's not implemented. Which is fine, I love TS anyway and it's evolving.

Zamicol
0 replies
12h58m

Well said. Bearing that in mind, we've found that JSDoc is a reasonable substitution for some TypeScript applications; however, JSDoc has limitations that we've ran into frequently as well.

Shacklz
12 replies
14h5m

I'm honestly giddy. This could be the (slow) beginning of a new era, where "JS with types" is finally a native thing.

I'm even willing to forgive all the mess that CJS vs. ESM is if they manage to pull this off.

I hope this sees widespread adoption/usage, which might finally cause some movement to integrate TS into ecmascript after all. Some dynamically-typed language fanatics (which are, in my opinion, completely detached from the reality that static types are what the vast majority of devs want) still have an iron grip on TC39, this might be the start of their end. And good riddance.

yashap
7 replies
13h33m

Yeah, my personal experience is that easily 95% of devs I work with/have met in person, if not closer to 99%, prefer statically typed languages. Maybe that’s a biased sample, but I do think the overall preference among devs is very strong. I also see JS slowly, more-or-less becoming TypeScript over time.

tstrimple
4 replies
13h14m

My days of being a real software developer are long behind me. So I'm totally willing to accept that I'm wrong here. But when I build a POC in particular, there's a LOT of power and flexibility granted by not giving a fuck about types. Suddenly I can accept non well defined data types (depending on my implementation) and can persist data that otherwise would have taken code changes and approval processes to accept. I do believe there is a place for types, but to type all the things is folly. There are capabilities within JavaScript to handle both.

miunau
1 replies
10h59m

Just use `any` or `unknown` when prototyping, then apply types once your happy paths start working for the first time to start catching the unhappy ones.

djeastm
0 replies
5h44m

then apply types once your happy paths start working for the first time to start catching the unhappy ones.

I.e. the "I'll go back and add safety later" strategy. Somehow I never seem to get around to doing it.

iamsaitam
0 replies
12h32m

The malicious beauty of typescript is that at any point you can just declare something "any" and voilá, the guard rails are off.

iainmerrick
0 replies
5h15m

when I build a POC in particular, there's a LOT of power and flexibility granted by not giving a fuck about types

I find the same thing, but only for very small throwaway scripts and the like. For anything beyond like 20 lines of code, I rapidly hit confusing cases like “is this parameter just a map, or a map or maps?” Then I add types and it makes sense again.

spaceheater
1 replies
12h9m

Let's make it 94 then. I think typescript is an abomination forced by java developers that don't want to learn javascript.

wiseowise
0 replies
11h38m

Guard rails on a bridge are an abomination forced onto us by government because people don’t want to learn how to fly.

jampekka
3 replies
11h47m

the reality that static types are what the vast majority of devs want

[citation needed]

dgb23
0 replies
2h55m

This is not what GP asked for. That's the most requested feature from the state of JS survey.

I bet the percentage of web developers who want this are a tiny minority. There are just too many issues with this.

Static typing without the benefits of better runtime performance, soundness, strong typing etc. is basically just documentation/comments with extra steps.

Also TS is a complex, moving target. Most devs don't want to learn new fancy features every couple of months, but prefer stability guarantees. Several notable projects have moved away from TS. Even Ryan Dahl admitted that integrating Deno with TS was probably a mistake.

Meanwhile you have WASM slowly and steadily getting crucial features on a sound foundation.

I'm extremely cautious about TS and wary of the hype surrounding it.

wokwokwok
0 replies
11h12m

The reaction emoji on the merged PR are not particularly ambiguous.

BiteCode_dev
12 replies
9h10m

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 do:

    const mySchema = z.string();
Which is basically reinventing what typescript is already doing.

hajile
4 replies
3h59m

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.

ahuth
3 replies
3h28m

What bad coding practices does TS allow, and why are they bad?

hajile
1 replies
2h45m

If there's a bad way to write JS, TS has something available to make sure it's typed.

Does TS help you keep your functions monomorphic so they'll get optimized by the JIT? nope

Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never optimize beyond the basic bytecode (making it one or two orders of magnitude more slow than it could otherwise be).

TS doesn't do anything to prevent or even discourage these kinds of bad decisions. They "type soup" many projects fall into is another symptom of this. The big reason the types become such a mess is because the underlying design is a mess. Instead of telling programmers "fix your mess", TS just releases even more features so you can type the terrible code without fixing it.

tln
0 replies
1h23m

Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never optimize beyond the basic bytecode (making it one or two orders of magnitude more slow than it could otherwise be).

Can you elaborate or point to some of the tools? So I know what tools I may need to avoid

DexesTTP
0 replies
1h28m

TS allows you to pass a read-only object to a method taking a read-write value:

    type A = { value: number; }
    function test(a: A) { a.value = 3; }
    function main() {
      const a: Readonly<A> = { value: 1 };
      // a.value = 2; <= this errors out
      test(a); // this doesn't error out
      console.log(a); // shows 3
    }

bythreads
2 replies
8h35m

That's not entirely true. `z.string()` in Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing.

For those unfamiliar:

`z.string()` effectively converts `mySchema` into a functional schema capable of parsing and validation.

For example:

`mySchema.parse("some data")` returns successfully.

`mySchema.parse(321)` throws an exception.

I've used it in places where you need runtime validation and in process verification - it works pretty well for that and you can extract the types from it via :

const A = z.string(); type A = z.infer<typeof A>; // string

Meaning if you define your types in zod first, and infer their types from that you get compile and runtime type checking.

---

It a bit of an overkill for nimble and fast code bases though - but works wonders for situations where in process proofing needs to be done, and in all honesty it isn't that big of a task to do this.

tommy_axle
0 replies
5h38m

There's also typescript-to-zod that makes it possible to generate the zod schemas from your types.

Dylan16807
0 replies
7h1m

Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing.

Well of course it offers more, or you wouldn't be installing a library.

The problem is that even when you're expressing normal Typescript types, you have to use entirely different syntax. It's good that you can usually avoid double-definition, but it's still a big barrier that shouldn't be necessary.

aitchnyu
2 replies
8h57m

Does this mean Node can know if an exception is subclass of ValueError or an object is instance of SomeClass? I'm a TS newb, I thought types outside of array, object, number, string arent present in JS and Zod and typeguard functions return plain objects with "trust me bro".

gampleman
0 replies
8h35m

In JS, classes do retain runtime information. So the `instanceof` is a real runtime operator that works by checking the prototype chain of an object. So checking subclasses can be done at runtime.

However, in TS other type information is erased at compile time. So if you write

    type Foo = "a" | "b";
the runtime code will see that just as a plain string.

LelouBil
0 replies
8h37m

You are right, they aren't. In the JavaScript languages which is what gets actually executed, there are no typescript types.

The parent commenter was talking about a way for nodejs to provide, via an API, the content of type annotations on fields/functions/variables like in python.

However, in python the type annotations are a property of the object at run time, whereas they are completely stripped before execution for typescript.

So I'm not sure how it would work except by changing the typescript philosophy of "not changing runtime execution"

MrBazlow
0 replies
7h54m

A lot of the focus by the TypeScript team is focused on alignment with the JavaScript language these days and novel new features such as run time types have all but been dismissed or at the very least pushed behind the TC39 JavaScript types proposal. Much like using decorators on variables outside of class structures was.

Having said that, TypeScript allows plugins, these are very rarely used as they augment the language by introducing other features that are transformed into the resulting JavaScript files. One plugin that relates to your suggestion of run time types is called Typia, it permits you to use your TypeScript type signatures at runtime with guards like `assert<MyType>(myValue)` where it intercepts the function call to construct an exhaustive if statement in the transpiled JavaScript checking the nature of the passed variable.

So while I don't see it being a part of the language in the next four to six years, there are at least libraries out there already that allow you to do it today.

throwitaway1123
10 replies
14h9m

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.

crabmusket
6 replies
12h50m

The recently-added test runner is very cool too!

SwiftyBug
3 replies
12h43m

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

joseferben
2 replies
11h11m

i tried that but had to revert to vitest, the native test runner feels incomplete atm.

crabmusket
1 replies
10h59m

What is missing for your use case or workflow?

sureIy
0 replies
16m

Probably a bunch of assertion types and general DX. Node:test is just a feature, Vitest is a whole product. The former might be enough for small packages but nowhere near useful for anything non-trivial.

herpdyderp
0 replies
2h52m

I just started using it the other day and it’s a dream. I look forward to the eventual stability of their snapshot testing.

conaclos
0 replies
9h47m

I tested it a few months ago. However, the output isn't very human friendly.

eknkc
2 replies
10h0m

It is Bun influence / competition I guess. Good for everyone.

mark_and_sweep
1 replies
6h36m

I believe the competition started with Deno. But yes, Bun is part of the competition now, too.

eknkc
0 replies
6h29m

Deno was doing its own thing though.

Bun came out swinging with strong Node.JS compatibility promises. I have simply replaced node with bun for most of my own work without much effort. The mental effort required is to use `bun` instead of `node` in command line for most of the trivial things.

me_vinayakakv
10 replies
14h35m

Nice to see Node.js getting parity on this with Deno and Bun

Klaster_1
5 replies
14h31m

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.

ibash
3 replies
14h22m

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.

crabmusket
1 replies
12h43m

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.

iainmerrick
0 replies
5h33m

Using vite is escaping webpack!

Klaster_1
0 replies
13h46m

Very true, rising popularity of deno and bun clearly indicate that new runtimes solve real issues people have. That's why I mentioned "my projects", your experience may vary.

devjab
0 replies
10h42m

This is the “enterprise” approach and it’s a solid one in my book. I do think drop-ins like Bun and PNPM are always great, however, and we’ve adopted both where it has made sense. I don’t think Bun will make sense very often as it’s only when you really need the performance the added maintenance becomes worth it. Especially right now where it’s not exactly stable for a lot of things. PNPM however is often very great compared to NPM and doesn’t add much maintenance as the tooling essentially gives your developers a very similar experience.

I’m also not sure the features will eventually “tickle down”. I’m not sure NPM wants to adopt the advantages PNPM gives you as an example, and it’s probably a good thing too considering the basis of NPM is just a really solid system to build on top of which it wouldn’t be if it was very opinionated. One of the big issues Node has today is that it was very opinionated with CommonJS, which made sense at the time, but is a ginormous pain in the butt in the modern world. Though the blame is obviously not with Node alone.

theflyinghorse
3 replies
14h29m

On the topic of typescript - yes. However Bun has a lot more tools baked in than Node does at (bun test for instance). Would be real nice to see Node start adopting more ideas from Bun and others.

joshmanders
1 replies
10h35m

I find it interesting that everyone looks at Bun and shames Node saying they need to catch up to Bun and implement stuff Bun has but Node doesn't, yet nobody is like Bun should catch up with feature parity of Node. Node isn't trying to replace Bun, Bun is trying to replace Node so it should be the one who needs to match parity.

pfg_
0 replies
10h19m

Bun is doing that - every update usually has node compat fixes or improvements and the list of supported modules has gone up significantly since it was released

iecheruo
0 replies
14h21m

Give node a closer look, it's been quietly accruing those features.

node has a built in test runner now

https://nodejs.org/api/test.html

gaptoothclan
8 replies
9h25m

A long time ago I started converted to using node js for backend work, seemed to offer many benefits over writing code in PHP without bringing many problems of Java. I found node to be somewhat clunky and a language where you had to bolt it together to get the language you wanted. Eventually started writing golang and it felt much easier to write, sometimes way more verbose but the type safety just made coding simpler.

Typescript seemed like a good option but was just another bolt on, I am not sure what value you gain by using Typescript over Golang, you have nice defined types which is great but it does not solve other issues with the language that are resolved in golang (also solved in deno).

One large benefit of using node over golang is the speed of prototyping something which I think having to use type script largely negates, so I can not really decide if this is a good step forwards or is making node loose some qualities that made it a good choice in other ways.

bezier-curve
2 replies
9h3m

Typescript is safer JS. You're still using JS with TS. The "bolted on" phrasing makes me think your issue may be more the absence of more opinionated frameworks like Django, that manage everything out of the box. I love using Django, but it's a little harder to go off the beaten path with it.

hot_gril
0 replies
2h30m

"Bolted on" is how I'd describe it too. Using TS means messing a lot more with random config files. And standard tools like the NodeJS profiler don't work with TS, which hopefully will change soon.

I've never used Django. Express seems a lot nicer.

gaptoothclan
0 replies
8h57m

My phrasing there was a direct comparison of developer experience between golang and nodejs. Golang has a very complete core library, I try to avoid frameworks as much as possible. For me I rarely have to think about the language or ecosystem, everything I want or need is already part of the language, testing, linting are some great examples

__alias
2 replies
9h15m

I mean the obvious answer is language familiarity, If your projects frontend code is in javascript/typescript ( which it is ), then using node is an easy choice. Shared libraries, shared types, etc etc

gaptoothclan
0 replies
9h1m

I was in the paradigm, there was very little code reuse from front to backend, some time performing validation I would like to have that option, but I would not have that as a killer feature that determined the language I use.

fulafel
0 replies
9h9m

Lots of people do of course use other languages for the frontend. (Or go for thin frontends, ala HTMX )

_joel
1 replies
9h18m

I guess if you already know Javascript, or have inhouse experience vs. learning Go. We use it with cdktf as previous fe experience, seemed logical vs. Go

gaptoothclan
0 replies
9h5m

sorry was going to add that there are probably more javascript developers in the jobs market, although there is a limit to the usefulness of these developers.

In the company I worked at we were fairly small and did not have huge applications running on node, so it made that journey easier

just-tom
7 replies
14h7m

Nice, but without support for Enums, for me it's mostly useless.

Shacklz
3 replies
13h58m

In our codebase we started to disallow enums in favour of string literal types, and once folks get over the ingrained "this needs to be an enum" (coming mostly from other languages like Java), it's not much missed.

Enums are one of the very few things in typescript that seem to not have turned out that well, but it's relatively easy to work without them with string-literable types and such, derived from some const in case they're also needed at runtime.

bythreads
1 replies
8h27m

agree enums in typescript are the devil

revskill
0 replies
4h40m

Could u explain why ?

shepherdjerred
0 replies
13h28m

100% agree. Coming from Java I really wanted an Enum type, but string literals/discriminated unions fill that niche just fine.

azangru
2 replies
10h6m

There are union types for strings; and there are plain javascript objects (typed as const) if "namespace.name" syntax is desired. With these available, what is the point of enums?

azangru
0 replies
5h44m

Yes. Both namespaces and enums (and probably the "private" keyword on class methods) are an early addition to the language, which would have never been added if typescript from the very start aligned closely with Ecmascript.

unilynx
6 replies
2h34m

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 transpiling would stop shipping dist/.cjs so I unambiguously know where to put my debugger/console.log statements. And it would probably be very tempting to NPM contributors to not have to bother with a build step anymore.

But won't this start a ripple effect through NPM where everyone will start to assume very quickly 'everyone accepts TS files' - it only takes one of your dependencies for this effect to ripple through? It seems to me that nodejs can't move this outside an opt-in-experimental-flag without the whole community implicitly expecting all consumers to accept TS files before you know it. And if they do, it will be just months before Firefox and Safari will be force to accept it too, so all JS compilers will have to discard TS type annotations

Which I would personally be happy with - we're building transcompiling steps into NPM modules that convert the ts code into js and d.ts just to support some hypothetical JS user even though we're using TS on the including side. But if node accepts

.ts files we could just remove those transpiling steps without ever noticing it... so what's stopping NPM publishers from publishing js/d.ts files without noticing they broke anything?

nfriedly
4 replies
2h15m

For the old libraries I maintain that are typescript and transpiled into .cjs and .mjs for npm, I'll probably just start shipping all three versions.

For a new thing I was writing from scratch, yeah, I might just ship typescript and not bother transpiling.

[edit: Apparently not. TS is only for top-level things, not libraries in node_modules according to the sibling comment from satanacchio who I believe is the author of the PR that added TS support and a member of the Node.js Technical Steering Committee]

WorldMaker
3 replies
1h53m

Why are you still transpiling to .cjs in 2024? ESM is supported in every LTS version of Node now. We can kill CJS, we have the power.

nfriedly
2 replies
43m

Because I don't like breaking things unnecessarily. Some of my libraries are 10 years old and depended upon by similarly old projects that are not using ESM and probably never will.

Besides, it's already going through one transpilation step to go from TS to ESM, so adding a second one for CJS really isn't that much hassle.

I think if node.js had made require() work with ESM, I could probably drop CJS. But since that's probably never going to happen, I'm just going to continue shipping both versions for old projects and not worry about it.

sureIy
1 replies
18m

adding a second one for CJS

Nobody is arguing for that. Once you ship ESM, you can continue shipping ESM.

In Node 22 you can even require() ES modules (with an experimental flag, at the moment)

nfriedly
0 replies
2m

> adding a second one for CJS

Nobody is arguing for that. Once you ship ESM, you can continue shipping ESM.

I'm not sure I follow you there. I did continue shipping ESM.

In Node 22 you can even require() ES modules (with an experimental flag, at the moment)

Oh, I didn't know about that, cool! Once it becomes un-flagged I might consider dropping CJS.

satanacchio
0 replies
2h1m

We dont support running .ts files in node_modules, this is one of the main constraints to avoid breaking the ecosystem

umvi
4 replies
4h2m

Side note, but IMO Typescript is too complicated. They should have stuck to a reasonably simple type system but now I see projects with incomprehensible and frankly unmaintainable typescript consisting of extremely complex generics, type conditionals, and type constraints. Basically if you aren't careful you'll find your project metaprogramming in typescript's turing complete meta language...

andrewmcwatters
2 replies
2h27m

TypeScript in its current usage reminds me of Hello, World! or FizzBuzz Enterprise Edition. There's almost more code dedicated to typing than the actual running software itself in some codebases I've seen.

The authors trick you with reasonable examples on https://www.typescriptlang.org, but in the wild, you have these ridiculous codebases that couldn't control themselves and they have this insane ratio of multiple declaration files to actual source files and you have to ask yourself, "Are you writing software to get something actually done, or do you just like write type definitions?"

Even people who write in C++ don't go to the lengths that TypeScript users do. It's super weird and cult-like.

umvi
0 replies
1h41m

To be clear, I do like the type-checking benefits of TypeScript, but it requires some discipline to keep it simple. Get one unchecked TS astronaut on the team and the TypeScript can get complex and esoteric very quickly.

sureIy
0 replies
4m

I also get lost in types sometimes, but the point of types is that they help you. Typescript lets you just use `as any` and `as unknown` as you please, but you want complex constraints you will need complex types.

There are some type libraries that parse GraphQL queries and CSS selectors. They’re crazy to look at but they’re hugely helpful.

ChicagoBoy11
0 replies
3h14m

This is something I've struggled with as a mostly solo dev. I've most often just stuck with vanilla javascript because of course that's good enough, but definitely there have been times where I hoped I had some typing helping me out. Alas, I haven't quite finagled the art of finding a way to use it "just a little bit."

65n56nm5665m56
4 replies
3h30m

I beg of thee, do not do this. I get that people love typescript but I am already running into a problem where javascript resources are written in typescript by default with nothing for regular javascript. This is the same problem that happened when JQuery hit its peak popularity and an overwhelming amount of resources and guides amounted to "Oh just do this in JQuery"

pansa2
1 replies
2h37m

javascript resources are written in typescript by default with nothing for regular javascript. This is the same problem that happened when JQuery hit its peak popularity

That's definitely a potential issue - JavaScript is the fundamental standard, not JQuery and not TypeScript. Certainly there are situations where maximum forward-compatibility is important (learning resources are a good example) and for those, vanilla JavaScript is the best choice.

All of the old resources that relied on JQuery are now hopelessly outdated, whereas the contemporary ones that used plain JavaScript are as valid now as when they were written. I'm sure the same will be true of TypeScript vs JavaScript when the next big thing comes along.

silverwind
0 replies
36m

the contemporary ones that used plain JavaScript are as valid now as when they were written.

True, but on the other hand, almost any JS code snippet written 20 years ago has better and more elegant alternatives today. APIs evolve all the time.

lolrsten349
1 replies
2h53m

Tell me you're out of touch without telling me that you're out of touch.

jQuery was so popular because writing anymore than a few lines of vanilla JavaScript was an *awful* experience due to all differences in browsers.

When things eventually standardized-ish and jQuery became unnecessary, other libraries/ecosystems popped up (e.g. React/JSX) to make writing webapps easier because writing anymore than a few lines of vanilla JavaScript was still an *awful* experience.

When webapps grew in size and scope, other "transpiled" languages popped up (e.g. TypeScript) because writing anymore than a few lines of vanilla JavaScript is *still an awful* experience.

We're stuck with JavaScript due to past decisions, but let's not pretend it's actually a good tool. If it were we wouldn't need 50,000 tools/frameworks/transpiled languages to hide how terrible it is.

sureIy
0 replies
9m

JavaScript is not terrible and I don’t understand where you got that from. Since ES2015 came out, it’s actually rather pleasant.

vithalreddy
3 replies
14h34m

Simply amazing!

I wonder bun and deno support for typescript played a big role here :)

yamumsahoe
1 replies
14h24m

i do wish nodejs adopts uwebsockets (totally what makes bun fast)

WuxiFingerHold
0 replies
7h20m

Yes, many aren't aware of that. If nodes webserver performance is not enough, you could always use uwebsocktsjs or hyperexpress with node.

matrixhelix
0 replies
14h2m

This is why competition is important

satanacchio
3 replies
9h20m

Hi I'm the author of the PR, AMA

Shacklz
1 replies
4h37m

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?

satanacchio
0 replies
3h42m

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.

mostafah
0 replies
6h27m

Thank you a lot. Great work. I know it’s still experimental, but over time it will have a big impact on developer experience and will simplify the development workflow for a lot of projects.

deanc
3 replies
14h31m

So how does this work in practice? Does it strip types and yolo trying to run or will it spit out type errors?

bentruyman
0 replies
14h16m

If you read the third sentence of the PR, it says:

During the transpilation process, no type checking is performed, and types are discarded
TheRealPomax
0 replies
14h20m

Why would you describe that "yolo"? If you're writing TS, you already have a TS linter that checks whether code has typing problems or not (at least, I certainly hope you do?). It's not really Node's job to do that linting, its job is to execute the JS that's hiding in the TS. It'd be "handy" if it did, but it'd also be a bit weird when there are already TS linting tools. It'd just hold up landing any sort of TS support that much longer.

Shacklz
0 replies
14h13m

If I understood correctly they use a wrapper around swc to strip types, without any type-check being performed.

Which makes perfect sense to start out with; as typechecking with tsc is rather slow and can easily be delegated to the consumer.

hajile
1 replies
3h49m

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

mardifoufs
0 replies
3h27m

What was the reason behind the split?

torginus
2 replies
3h0m

I might be ignorant but wasn't there a plan to add Typescript support to the browser itself?

In which case wouldn't V8 support TS directly without needing to transpile?

jokoon
0 replies
2h48m

all browsers would have to agree, the language would have to be very well defined and well supported across all those browsers.

that would be a lot of work

I would rather see new WASM features instead

skybrian
2 replies
12h54m

It would be nice for debugging if at least simple npms could just bundle their .ts files without any processing, so we could see the comments and types as they existed in the git repo. Apps can always minify them later.

(I use Deno, but also use some npms.)

flohofwoe
1 replies
11h44m

You can simply create npm packages which contain only the 'unprocessed' TS source files (or really any type of files - for instance I experimented with using npm as package for C/C++ projects in the past, it works just fine). Pre-bundling or compiling from TS to JS is just a convention. And in case of bundling not a good one IMHO, because bundling should only be a final step in the top-level project. One good reason to compile the package content to .js/.d.js/.map files is that the resulting package is usable both in JS and TS projects.

skybrian
0 replies
10h49m

The nice thing about this change to Node.js (when it’s no longer experimental) is that you could just distribute .ts files and JS projects could use them.

ofirg
2 replies
14h31m

support for typescript as long as you are only using it for type checking, not if you are also using features that are not supported in the javascript version you are targeting.

paulddraper
0 replies
14h20m

That is what people use TypeScript for generally.

If you need JS syntax features that Node.js doesn't support you can use tsc, babel, etc.

Because obviously unsupported features are unsupported, whether JS or TS.

flohofwoe
0 replies
11h37m

not if you are also using features that are not supported in the javascript version you are targeting. reply

This is only 'half-assed' anyway, TS will only emulate new language features on older JS target version, but not any Javascript runtime features (like new Object methods). For the latter you will still need a separate polyfill solution.

zaphod420
1 replies
5h32m

I would rather raw dog JavaScript than write Typescript. Typescript is an abomination.

halfmatthalfcat
0 replies
5h20m

Thank god you’re in the minority with that opinion

throw156754228
1 replies
12h29m

I see it just strips the typings. So if I attach the debugger I'm still going to see javascript right?

zarzavat
0 replies
12h21m

Presumably it would also generate a source map to allow debuggers to work properly, like tsc does.

jvanveen
1 replies
9h10m

I just switched to Bun for typescript support, a free bundler and better performance. Iojs flashback all over :)

XCSme
0 replies
6h23m

Does Bun always work for you? For me, none of my projects worked to run "bun install" on.

jdeaton
1 replies
3h36m

Isn't the whole idea of TS that you just convert to JS to run it

WorldMaker
0 replies
1h56m

Yes. The question is where you do the conversion and how much of a conversion to do. This allows a key conversion (type stripping) directly at load time by Node rather than needing an extra step (an external type stripper such as Typescript or esbuild) sometime before passing the file to node for loading.

CodeCompost
1 replies
13h2m

Ok that's cool, but how about adding native support to browsers?

zelphirkalt
0 replies
4h44m

If this means, that one day I don't need to use a bundler any longer to make a website using TypeScript, I am all for it.

winrid
0 replies
2h29m

anyone know, for example where this is already done with Bun, how this impacts startup times with large applications?

tracker1
0 replies
3h23m

Nice to see this, and important to stay closer to parity with Deno and Bun.

sgammon
0 replies
11h54m

Really glad to see this

rglover
0 replies
13h4m

Didn't expect types to come to JavaScript like this (native or without a separate compiler), but I love the idea.

olalonde
0 replies
5m

It just took 3 weeks to merge this? Seems really fast by Node.js standards. I assume it was discussed before the PR was opened?

nthngy
0 replies
4h44m

IMAO writing (hard-coding) TypeScript is deprecated and a waste of time. With all tech available nowadays it is possible to do the entire type check automatically in the IDE, even more so now with the help of AI. It's just a matter of time when we stop hard-coding type info. Better invest time and money in getting the IDE's work better for us.

cryptica
0 replies
7h55m

It's interesting how TypeScript beat Flow in terms of popularity, and yet everyone is now calling for TypeScript to be more like Flow (to focus on plain type checking instead of transpilation; just strip out the type annotations)... And most of those people don't even know about the existence of Flow.

The sad thing about the tech sector is that you can be right about something and yet still lose the hype-wagon popularity contest. Then your competitor copies your original idea... The exact same idea which they had previously claimed was inferior.

It seems that the idea was inferior purely on the basis that it wasn't their idea. As soon as they've appropriated the idea, suddenly it's the best idea in the world.

brundolf
0 replies
2h25m

I feel like Deno and Bun have lit a fire under the Node team to finally modernize things people have been desperately wanting for years. Great to see!

alabhyajindal
0 replies
11h21m

What next? Renaming Node.js to Node.ts?

I understand that built in TS support is very nice as provided by Bun. But I feel doing this in Node is going to take a long time.

RadixDLT
0 replies
46m

Oh, great, people love JavaScript. What a shock.

DrMiaow
0 replies
8h29m

Without some kind of transformation on `enum` isn't this mostly useless? `enum` is heavily used in many TypeScript code-bases.