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

561–570 of 570 posts

Re: Node.js adds experimental support for TypeScript

#561

Post by bazoom42 »

Timon3 wrote: post #556
bazoom42 wrote: post #516

Earlier quoted context omitted.

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…

How about:

    TypeAssertion ::= Expression “as” TypeStuff
    TypeStuff ::= TypeStuffItem+
    TypeStuffItem ::= Block | any     token except , ; ) } ]
    Block ::= ParenBlock | CurlyBracketsBlock | SquareBracketsBlock | AngleBracketsBlock
    ParenBlock ::= ( ParenBlockItem* )
    ParenBlockItem ::= Block | any token except ( )
etc.

Re: Node.js adds experimental support for TypeScript

#562

Post by yashap »

tstrimple wrote: post #56
yashap wrote: 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…

For sure, if I’m writing a short script, no more than ~200 LOC, Python (without type hints) is my favourite language. But for a sizeable codebase, worked on by multiple devs or even just me over time, I’ve got an extremely strong preference for static types.

Also, FWIW, TypeScript is the most “lightweight” statically typed language I’ve ever used, in terms of extra ceremony/lines of code over a dynamic language. Once you get used to its type system, and embrace the structural typing ideas, I feel the overhead is super minimal. It might slow me down by ~5% on a short script over JavaScript, while dramatically improving maintainability as a codebase grows.

Re: Node.js adds experimental support for TypeScript

#563

Post by throw156754228 »

zarzavat wrote: post #101
throw156754228 wrote: post #95

I see it just strips the typings. So if I attach the debugger I'm still going to see javascript right?

Presumably it would also generate a source map to allow debuggers to work properly, like tsc does.

What is 'it' here in your sentence above?

Re: Node.js adds experimental support for TypeScript

#564

Post by miunau »

djeastm wrote: post #277
miunau wrote: post #164

Earlier quoted context omitted.

Just use `any` or `unknown` when prototyping, then apply types once your happy paths start working for the first time to start catching the unhappy ones.

>then apply types once your happy paths start working for the first time to start catching the unhappy ones. I.e. the "I'll go back and add safety later" strategy. Somehow I never seem to get around to doing it.

Like documentation, you should do this while it's fresh in your head, but I get it.

Re: Node.js adds experimental support for TypeScript

#565

Post by nilsbunger »

satanacchio wrote: post #560
nilsbunger wrote: post #539

Earlier quoted context omitted.

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…

That all makes sense, it sounds like you haven’t ruled out supporting TS directly in production, but it’s complex and you have to move carefully and you’re not sure if you’ll get all the way there. Is that right ?

Re: Node.js adds experimental support for TypeScript

#566

Post by bazoom42 »

zarzavat wrote: post #545
bazoom42 wrote: post #522

Earlier quoted context omitted.

The “as” expression is not valid JavaScript anyway, so the default rule for implicit semicolon does not apply. A grammer for type expressions could define if and how semicolons should be inserted.

TypeScript already has such type operators though. For example: type T = keyof { a: null, b: null } Here T is “a”|”b”, no automatic semicolon is inserted after `keyof`. While I don’t personally write code like this, I’m sure that someone does. It’s perfectly within the rules, after all. While it’s true that TS doesn’t have to follow JS rules for semicolon insertion in type expressions, it always has done, and probabl…

This is just the default. Automatic semicolon insertion only happen in specific well-defined cases, for example after the “return” keyword or when an invalid expression can be made valid by semicolon insertion. Neither applies here.

Re: Node.js adds experimental support for TypeScript

#567

Post by AfterAnimator »

kcrwfrd_ wrote: post #379
lolinder wrote: post #306

Earlier quoted context omitted.

Soundness is also a highly theoretical issue that I've never once heard a professional TypeScript developer express concern about and have never once heard a single anecdote of it being an issue in real-world code that wasn't specifically designed to show the unsoundness. It usually only comes up among PL people (who I count myself among) who are extremely into the theory but not regularly coding in the language. Do…

Ah someone else posted a link and I understand the unsoundness now. The only time an issue ever came up for me was in dealing with arrays let foo: number[] = [0, 1, 2] // typed as number but it’s really undefined let bar = foo[3] But once you’re aware of the caveat it’s something you can deal with, and it certainly doesn’t negate the many massive benefits that TS confers over vanilla JS.

For this case, I've switched to using `foo.at(3)` now instead, as it returns `T | undefined`, so you have to handle the undefined case.

Re: Node.js adds experimental support for TypeScript

#568

Post by meowtimemania »

Omerd6 wrote: post #469
meowtimemania wrote: post #465

Earlier quoted context omitted.

it must install compiled and uncompiled versions? Otherwise node (without the above flag) would throw errors when it encounters types in node_modules

I just checked and you are correct, in node it only installs the compiled version. Apparently you can only view the uncompiled source code in deno since it natively supports typescript. My bad

No worries! I was curious how it worked on node. Thanks!

Re: Node.js adds experimental support for TypeScript

#569

Post by johnny22 »

sholladay wrote: post #349
johnny22 wrote: post #91

Earlier quoted context omitted.

the url imports is one the things I don't want.

You want to be forced to use a centralized registry? I don’t know. URL imports also enable fully isomorphic modules. I think you would enjoy the freedom of URL imports if the ergonomics were better. For example, it should just default to https:// so you don’t have to type that. Import maps also help a lot with this, definitely use them. But they could be even better by having first-class support for templating the mo…

yes, I would prefer to use a centralized registry indeed. However, that's not actually what i'm talking about here. Even just decoupling the import from the package is enough. You can already do this by by pointing a package in package.json to a remote tarball or git repo.

Re: Node.js adds experimental support for TypeScript

#570

Post by __alias »

fulafel wrote: post #214
__alias wrote: post #210

Earlier quoted context omitted.

I mean the obvious answer is language familiarity, If your projects frontend code is in javascript/typescript ( which it is ), then using node is an easy choice. Shared libraries, shared types, etc etc

Lots of people do of course use other languages for the frontend. (Or go for thin frontends, ala HTMX )

1. that's a lie, and "lots" of people don't use HTMX (unless I've been living under a rock and there is a non-unsubstantial number of people using it :D ) 2. HTMX IS javascript, and you can still use the same familiar packages across front end and backend e.g. lodash
Post reply on HN