Is there any movement in the node world for the runtime to be able to ascertain types? Obviously nodejs doesn't do this, but does Bun or Deno or are there plans for any of this in the future?

▲

nosianu 5 days ago | parent | next [-]

This has nothing to do with the "node world". Such an enormous feature would have to go into ECMAScript. Which is very, very unlikely to ever happen, they may as well design a new language. All those runtimes implement that spec. Expecting them to write an extremely complex new feature that is easily more complicated than everything already implemented (especially with backwards compatibility, and given that the language was not designed for this) would be a bit much.

TypeScript is for compile time checking of a language that was not designed to have them. Runtime types have very different requirements! It has to be in the language from the early design phase, otherwise it will just be a hack with many conditions, restrictions and holes.

TS Types are only partially a description of the underlying types in the code, a very big part instead is that it provides guard rails that prevent you from using a lot of perfectly fine and valid JS code that would however be incompatible with type guarantees. You pay the price of using only a part of the large space of JS code possibilities for guarantees. If you were to put that into the runtime you would end up with two different versions of the language. If you still want to support the full JS you would end with two runtimes in one (or one that has so many branches and conditions that maintaining that runtime is a real beast).

▲

hungryhobbit 4 days ago | parent | next [-]

ECMAScript community is actually dipping their toes in the water of adding typing to the spec, and it's at Stage 1: https://github.com/tc39/proposal-type-annotations.

Now of course, this would only add type syntax to the language, not true processing: there's nothing in the spec about actually handling them. Still, it's a step in that direction, so I wouldn't say "very unlikely to ever happen" ... "still a long ways off (if ever)" would be more accurate.

▲

ninetyninenine 5 days ago | parent | prev [-]

Can't be too hard imo. Primitives can contain an extra metadata field for the types defined in the code. This doesn't really interfere with the runtime and will be backwards compatible. The runtime of course still doesn't actually have to do any type checking, it's just forwarding the type information on a new metadata field so it's not in any way interrupting the core flow of the runtime logic. As a result you can still have the wrong type tagged onto a primitive just like TS has it currently.

Only downside I see is that It can slow down the code as the runtime now has to evaluate type level functions in order to know what to place in the metadata.

But you're right in the sense that it has to go into the core ECMA specification rather then being a node project.

	▲	pinoy420 5 days ago \| parent [-]
		[dead]

▲

ruined 5 days ago | parent | prev | next [-]

i don’t think you’ll see this at the typescript level, and you won’t see anything like this that compiles to javascript. specifically, compiling typescript to javascript with runtime checks would not actually be very useful.

typescript is pretty ambiguous about a lot of the things that would need explicit definition for runtime safety, and anyways we already have tools for that - it’s called zod.

and comprehensive checks would incur a significant runtime penalty, unless they were restricted to external interfaces, which is what you’re really concerned about. we already have tools for that - protobuf, swagger, etc.

anything else is sharing a runtime with you. so either it’s in your ide, and you just don’t write shitty code; or you’re trapped in some kind of demonic javascript prisoner’s dilemma, and you are mutable.

so typescript is basically ‘good enough’ for developers.

thinking forward anyway, and assuming you’re really willing to share a runtime with a stranger…

node doesn’t really operate in that kind of context, but maybe browser code does. i could imagine a framework based on web components, workers, and maybe iframes, taking advantage of message boundaries to enhance analysis and conceal code generation. it’s not that much better than typescript.

but if you want efficient runtime checks, and you want to leverage static analysis and strong module boundaries to scope the type-checking codegen, and you probably need additional syntax, you might as well target wasm.

	▲	CharlieDigital 5 days ago \| parent \| next [-]
		Yeah, but Zod and all of the runtime schema libraries all kind of add verbosity to the type system compared to say something like Typia[0] which AOT compiles the type checks (and ends up being way more elegant). Caveat is that there are some restrictions with the compiler and some possible footguns (duplicated declarations bloating code). [0] https://typia.io/
	▲	marcjschmidt 4 days ago \| parent \| prev [-]
		> you won’t see anything like this that compiles to javascript https://github.com/microsoft/TypeScript/issues/47658

▲

ireadmevs 5 days ago | parent | prev [-]

I believe it would be too hard to keep up with pace of TypeScript development. We should probably at some point formally define the system and allow for alternative implementations outside of the control of Microsoft.