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

311–320 of 570 posts

Re: Node.js adds experimental support for TypeScript

#311

Post by neonsunset »

viridian wrote: post #293
ZhongXina wrote: post #161

Earlier quoted context omitted.

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

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…

Unlike Spring, JIT-based ASP.NET Core deployments spin up very fast (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.

Re: Node.js adds experimental support for TypeScript

#312

Post by guipsp »

tpm wrote: post #291
VMG wrote: post #280

Earlier quoted context omitted.

most of that? name one

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…

Using optional still has the secret third thing problem

Re: Node.js adds experimental support for TypeScript

#313

Post by VMG »

tpm wrote: post #291
VMG wrote: post #280

Earlier quoted context omitted.

most of that? name one

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…

> 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

Re: Node.js adds experimental support for TypeScript

#315

Post by jmull »

nialv7 wrote: post #287
zarzavat wrote: post #120

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 ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…

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

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.

Re: Node.js adds experimental support for TypeScript

#316

Post by lolinder »

klodolph wrote: post #292
nialv7 wrote: post #287

Earlier quoted context omitted.

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

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.

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

Re: Node.js adds experimental support for TypeScript

#317

Post by hajile »

winter_blue wrote: post #35
pansa2 wrote: post #34

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…

Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.

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

Re: Node.js adds experimental support for TypeScript

#318

Post by machiaweliczny »

hajile wrote: post #317
winter_blue wrote: post #35

Earlier quoted context omitted.

Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.

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

But in practice is was crap

Re: Node.js adds experimental support for TypeScript

#319

Post by silverwind »

herpdyderp wrote: post #264
silverwind wrote: post #220

Earlier quoted context omitted.

tsx has very slow startup performance, I prefer https://github.com/swc-project/swc-node which is around twice as fast.

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.

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

Re: Node.js adds experimental support for TypeScript

#320

Post by umvi »

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...
Post reply on HN