Hacker News new | ask | show | jobs
by brundolf 1268 days ago
I say this as a huge proponent of TypeScript and static types in general: I'm fairly bearish on this proposal

1) TypeScript supports a huge set of syntax for describing types, and I would be surprised if the standard ever supports all or even most of that, which would mean you can't skip the build step for most real-world TS projects

2) Most front-end projects will continue to have a build step anyway because of things like JSX, minification, and bundling. And if you've got a build step already, stripping out types is one of the easier things to do as a part of it (and you would want to do it even with this proposal, as a part of minification)

3) On the back-end Deno and Bun run TypeScript natively without a build step. Node doesn't, and it won't be displaced overnight, and it may end up the biggest beneficiary of such a proposal. But even there, build tools like esbuild are fast and easy enough to use that you don't gain much by being able to avoid them (and if you're benefitting from static checking, you're setting up at least one tool already!)

I won't go so far as to say it's a bad thing, but I think it'll end up one of those standards that nobody really uses

3 comments

I'd also add that Typescript would be a very bad language choice anyway. If we're going to have a backward-incompatible change, we should do things the right way (after all, we're stuck with it forever).

Don't make a type system work around the really bad parts of JS. Instead, don't allow them in typed modules. Don't settle for an intentionally unsound (aka broken ) type system. Add an actually sound (probably hindley-milner based) type system that provides usable type info to the JIT so we can guarantee fast, safe code.

> If we're going to have a backward-incompatible change, we should do things the right way

It makes much more sense to use a good language (Kotlin, Rust, Java) and transpile to JavaScript. There's already great tooling for it.

JavaScript seems an unlikely compiler target, forced on us out of the odd historical success of JS on the browser. I'd think that a better target would be to make a VM like WASM.
If WASM were a viable target today, I'd agree, but it isn't yet.

Transpiling to JS is ready for production and widely compatible with all browsers already.

Welcome to Nim.
Even if they don't get further than the basic types and user-defined types, that would be enough to make my life dramatically easier. I honestly avoid making stuff in typescript, not because I don't love it, but because setting it up is such a pain in the ass.

If I could avoid that step and still have type annotations and tooling support, I would be a happier person.

Regarding point 2. Also, there's no way to run a build/compile step for running 'javascript' to catch these type errors before runtime. Would we bring Node into the CI just to catch those errors?

So you may be right, it seems typescript will still be around for enterprise at least.

> there's no way to run a build/compile step for running 'javascript' to catch these type errors before runtime

I don't think I follow what you mean here, can you clarify?

Currently we run "tsc" to "compile" the code and tell us about type errors. "This method passes as string to something that expects a number" etc.

In a world where JS has type notation, we'd need a similar command that could analyze the code without running it.

tsc does that, but yes, you'd still have to run tsc which was part of my original point