Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

291–300 of 570 posts

Re: Node.js adds experimental support for TypeScript

#291
post #280
post #119

Earlier quoted context omitted.

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

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 want that, you can use it.

Re: Node.js adds experimental support for TypeScript

#292
post #287

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

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.

Re: Node.js adds experimental support for TypeScript

#293

Earlier quoted context omitted.

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

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

Re: Node.js adds experimental support for TypeScript

#294
post #46

Earlier quoted context omitted.

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.

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…

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.

Re: Node.js adds experimental support for TypeScript

#295

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…

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.

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.

Re: Node.js adds experimental support for TypeScript

#296

Earlier quoted context omitted.

C# has record (product) types now.

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.

Product types are tuple types.

Record types are tuple types with names instead of indexes.

The TypeScript “&” is another thing.

Re: Node.js adds experimental support for TypeScript

#297

Earlier quoted context omitted.

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.

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

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

Re: Node.js adds experimental support for TypeScript

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

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.

Re: Node.js adds experimental support for TypeScript

#299

Earlier quoted context omitted.

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.

[flagged]

[flagged]

Re: Node.js adds experimental support for TypeScript

#300
post #94

Earlier quoted context omitted.

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.

The _programming_ ecosystem sure struggles with naming things.

Fair enough
Post reply on HN