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

551–560 of 570 posts

Re: Node.js adds experimental support for TypeScript

#551

Post by sgammon »

wiseowise wrote: post #508
sgammon wrote: post #171

Earlier quoted context omitted.

Sure, but Kotlin is to Java as TypeScript is to JavaScript, which is the point I am making.

That’s not even remotely true. TypeScript is a direct superset of JavaScript. Any valid JS is a valid TypeScript. If Kotlin is what TS to JS, then so is Groovy, Scala, Clojure and other JVM languages.

> TypeScript is a direct superset of JavaScript. Any valid JS is a valid TypeScript.

Kotlin on JVM is a direct superset of Java on JVM. Any valid Java is also valid Kotlin at the bytecode layer.

> If Kotlin is what TS to JS, then so is Groovy, Scala, Clojure and other JVM languages.

Correct

Re: Node.js adds experimental support for TypeScript

#553

Post by hajile »

nequo wrote: post #546
hajile wrote: post #529

Earlier quoted context omitted.

Ocaml messed up with their operators. StandardML had a better approach and I hope a future version adds module typeclasses (to help limit the type soup we see in Haskell). As I wrote elsewhere in this thread, TS makes it incredibly easy to unintentionally make megamorphic functions that don’t have any inline cache and don’t get optimized at all. You think you’re writing efficient, DRY code, but it’s really just dog s…

> Ocaml messed up with their operators. ... I hope a future version adds module typeclasses Do you mean modular implicits?[1] The original paper was published in 2014. There's an internship report from 2023 that summarizes the design and implementation issues: https://modular-implicits.github.io/report.pdf [1] https://arxiv.org/abs/1512.01895

https://www.cs.cmu.edu/%7Erwh/papers/mtc/short.pdf

I believe modular implicits and modular typeclasses are similar and aim to solve the same issues, but they are not quite the same.

Re: Node.js adds experimental support for TypeScript

#554

Post by recursive »

hajile wrote: post #520
recursive wrote: post #474

Earlier quoted context omitted.

Yes it throws in typescript. Typescript isn't the the language chasing soundness at any cost. This just illustrates the futility of chasing soundness. Soundness is good as long as the type-checking benefit is worth the cost of the constraints in the language. If the poster child for soundness isn't able to account for this very simple and common scenario, then nothing will actually be able to deliever full soundness.…

My balance point is StandardML. SML and TS both have structural typing (I believe this is why people find TS to be more ergonomic). SML has an actually sound type system (I believe there is an unsoundness related to assigning a function to a ref, but I've never even seen someone attempt to do that), but allows mutation, isn't lazy, and allows side effects. Put another way, SML is all the best parts of TS, but with mo…

Personally, I think javascript kind of sucks, but it's approximately* the only choice for targeting browsers. If it wasn't for this face, I probably never would have touched TS. SML sounds pretty good.

Re: Node.js adds experimental support for TypeScript

#555

Post by leshenka »

iamsaitam wrote: post #92
tstrimple wrote: post #56

Earlier quoted context omitted.

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…

The malicious beauty of typescript is that at any point you can just declare something "any" and voilá, the guard rails are off.

It’s fine to have an escape hatch when you can’t figure/don't care about types (yes sometimes you should use unknown but that’s another topic)

But at least TS forces (if enabled by strict flag) you to explicitly mark all those places. You can always revisit them later.

Case in point: I’ve written A LOT of redux-saga code and figuring out types for that was exceptionally difficult for me. Sprinkled all that with a ton of anys. Had a few bugs but not anything serious.

Finally rewriting all that slop with async-await and am really happy about it

Re: Node.js adds experimental support for TypeScript

#556

Post by Timon3 »

bazoom42 wrote: post #516
Timon3 wrote: post #425

Earlier quoted context omitted.

I don't know a lot about parser theory, and would love to learn more about ways to make parsing resilient in cases like this one. Simple cases like "ignore rest of line" make sense to me, but I'm unsure about "adversarial" examples (in the sense that they are meant to beat simple heuristics). Would you mind explaining how e.g. your `as` stripping could work for one specific adversarial example? function foo () { retu…

CSS syntax have specific rules for how to handle unexpected tokens. E.g if an unexpected character is encountered in a declaration the parser ignores characters until next ; or }. But CSS does not have arbitrary nesting, so this makes it easier. Comments as in your example is typically stripped in the tokenization stage so would not affect parsing. The TpeScript type syntax has its own grammar, but it uses the same l…

I understand that you can define a restricted grammar that will stay parseable, as the embedded language would have to adapt to those rules. But that doesn't solve the question, as Typescript already has existing rules which overlap with JS syntax. The GP comment was:

> For example, the `as` keyword for casts has existed for a long time, and type stripping could strip everything after the `as` keyword with a minimal grammar.

My question is: what would a grammar like this look like in this specific case?

Re: Node.js adds experimental support for TypeScript

#557

Post by RyanCavanaugh »

price wrote: post #496
RyanCavanaugh wrote: post #447

Earlier quoted context omitted.

Flow's type system isn't sound either FWIW

Yeah, Flow had the ambition to be sound but has never accomplished it. If you read the Flow codebase and its Git history, you can see that it's not for lack of trying, either — every couple of years there's an ambitious new engineer with a new plan for how to make it happen. But it's a real tough migration problem — it only works if they can provide a credible, appealing migration path to the other engineers across F…

Flow doesn't even check that array access is in-bounds, contrast to TypeScript with noUncheckedIndexedAccess on. They're clearly equally willing to make a few trade-offs for developer convenience (a position I entirely agree with FWIW)

Re: Node.js adds experimental support for TypeScript

#558

Post by price »

RyanCavanaugh wrote: post #557
price wrote: post #496

Earlier quoted context omitted.

Yeah, Flow had the ambition to be sound but has never accomplished it. If you read the Flow codebase and its Git history, you can see that it's not for lack of trying, either — every couple of years there's an ambitious new engineer with a new plan for how to make it happen. But it's a real tough migration problem — it only works if they can provide a credible, appealing migration path to the other engineers across F…

Flow doesn't even check that array access is in-bounds, contrast to TypeScript with noUncheckedIndexedAccess on. They're clearly equally willing to make a few trade-offs for developer convenience (a position I entirely agree with FWIW)

Neat example, thanks! I hadn't known TS had that option. Array access was actually exactly the example that came to mind for me in a related discussion: https://news.ycombinator.com/item?id=41076755

I wonder how widely used that option is. As I said in that other comment, it feels to me like the sort of thing that would produce errors all over the place, and would therefore be a real pain to migrate to. (It'd be just fine if the language semantics were that out-of-bounds array access throws, but that's not the semantics JS has.) I don't have a real empirical sense of that, though.

Re: Node.js adds experimental support for TypeScript

#559

Post by alxndr »

sureIy wrote: post #417
lolrsten349 wrote: post #355

Earlier quoted context omitted.

Tell me you're out of touch without telling me that you're out of touch. jQuery was so popular because writing anymore than a few lines of vanilla JavaScript was an *awful* experience due to all differences in browsers. When things eventually standardized-ish and jQuery became unnecessary, other libraries/ecosystems popped up (e.g. React/JSX) to make writing webapps easier because writing anymore than a few lines of…

JavaScript is not terrible and I don’t understand where you got that from. Since ES2015 came out, it’s actually rather pleasant.

In the first decade of this millennium, writing JS was a pretty frustrating, and JQuery papered over a lot of the nastiness.

Re: Node.js adds experimental support for TypeScript

#560

Post by satanacchio »

nilsbunger wrote: post #539
satanacchio wrote: post #330

Earlier quoted context omitted.

this is the roadmap https://github.com/nodejs/loaders/issues/217 . We talked with the typescript team and we will give each other continous feedback on the progression. We made sure to take some precautions in order to avoid breaking the ecosystem. I still think in production, js is the way to go, so users should always transpile their ts files.

Could you expand on why transpiling is the right long-term strategy for production? I get that right now you don't support some TS-specific features like enums. Is that the concern? Those seem like a few legacy exceptions, new TS capabilities will be "just javascript". Not transpiling would be great to reduce toolchain complexity and eliminate the need for sourcemaps just to understand exceptions and debug.

The first reason is because if we supported ts features that require transformation (such as enume) we would also need to support sourcemaps, so in the first iteration I decided not to, to avoid being overwhelmed. Right now we replace inline types with whitespace, so locations are preserved. We plan to add those features, probably behind a flag at the beginning. We need to move in small steps and think very carefully, every decision could make a huge impact on the ecosystem so I decided to start with the smalled subset possible.
Post reply on HN