Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

Post reply on HN
Print view View original

251–260 of 570 posts

Re: Node.js adds experimental support for TypeScript

#251

Post by WuxiFingerHold »

yamumsahoe wrote: post #10
rockwotj wrote: post #4

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 a…

correction: the only deno future that i want

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

Re: Node.js adds experimental support for TypeScript

#252

Post by pas »

dgellow wrote: post #36
spankalee wrote: post #11

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

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

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

Re: Node.js adds experimental support for TypeScript

#253

Post by debugnik »

38 wrote: post #107
harshitaneja wrote: post #88

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 surprising…

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

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.

Re: Node.js adds experimental support for TypeScript

#254

Post by WuxiFingerHold »

yamumsahoe wrote: post #12
vithalreddy wrote: post #3

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

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

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

Re: Node.js adds experimental support for TypeScript

#255

Post by [deleted] »

skybrian wrote: post #169
flohofwoe wrote: post #132

Earlier quoted context omitted.

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…

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.

[deleted]

Re: Node.js adds experimental support for TypeScript

#256

Post by Dylan16807 »

bythreads wrote: post #230
BiteCode_dev wrote: post #212

Eventually, node might allow JS to introspect those types. That would be a huge win. Right now in Python, great tools like pydantic exist because Python can introspect said types, and generate checks out of them. This mean you can define simple types, and get: - type checking - run time data check - api generation - api document generation Out of a single, standard notation. Right now in JS, things like zod have to d…

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 e…

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

Re: Node.js adds experimental support for TypeScript

#257

Post by harshitaneja »

DarkNova6 wrote: post #186
wiseowise wrote: post #128

Earlier quoted context omitted.

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

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

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.

Re: Node.js adds experimental support for TypeScript

#258

Post by rty32 »

suby wrote: post #63
dgellow wrote: post #36

Earlier quoted context omitted.

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

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

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.

Re: Node.js adds experimental support for TypeScript

#259

Post by rty32 »

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

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

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

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.

Re: Node.js adds experimental support for TypeScript

#260

Post by mananaysiempre »

miki123211 wrote: post #89
mattnewton wrote: post #55

Earlier quoted context omitted.

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

Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[f…

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

Post reply on HN