Repository navigation
This proposal regarding TypeScript version #213
Description
I've just now tried TypeScript to startup the following technology combination:
- Node.js + Prisma ORM + ExpressJS
Surprise? I've tried to integrate the cors NPM package and got a TypeScript version conflict as the cors package was requiring a specific TypeScript version range (an old version: 3.x to 4.0). I gave up on TypeScript and ended up with JSDoc.
I think this proposal would be very useful!
(Or I'm not sure... Maybe I used a problematic TypeScript template that contained a problematic dependency.)
Activity
oelmekki commentedon Mar 6, 2024
I support this proposal for a similar reason: I'm tired of wasting my life managing dependencies (upgrading them on all my projects, refactoring for breaking changes, dealing with things going unmaintained, etc), so I go all-in vanilla-js, nowadays. Having types backed in ecmascript would be a game changer, for me. I'm using JSDoc, right now, but it still forces me to use Typescript to perform static analysis (at least, I don't depend on it, as my code runs unmodified in the browser).
So yeah, thank you for the proposal, maintainers. :)
lillallol commentedon Mar 6, 2024
If JSDoc (coupled with TS) works, then why do we need the context proposal (given also the drawbacks that it brings)?
oelmekki commentedon Mar 6, 2024
@lillallol Please read my comment, your answer is in it.
lillallol commentedon Mar 6, 2024
This proposal is about reserving syntax space in EcmaScript in which any kind of type system that conforms to that syntax can exist. You will not get TypeScript into that syntax space. You have to introduce breaking changes into TypeScript for it to live into that syntax space. Static analysis will not be performed by EcmaScript or browsers. You will still need third parties for that. This proposal is about future proofing the TypeScript syntax by just breaking in it one last time, i.e. making sure that future EcmaScript proposal will not introduce breaking changes into TypeScript.
As you people already said
.js+ JSDoc + TS works. Projects like Deno, Svelte, Preact, Webpack, remark, eslint, etc, work like that. There is no need to reserve syntax for something that already works.oelmekki commentedon Mar 6, 2024
Give it a few more years and you'll understand why this way of thinking is bogus - when you'll see all your tools "software rot" to death, or become impossibly bloated before everybody give up on them. There's a reason we have standards, you'll understand them after a decade or two of programming. And this is what this proposal is about. If you don't like nor understand standards, maybe your input on a discussion about standards is not as useful as you think.
And by the way, yes, you can very much expect that browsers' devtools will implement static analysis when they will start supporting this. They already do it in many ways, they even implement full blown debuggers, this is exactly their turf.
lillallol commentedon Mar 6, 2024
These are all my tools:
tsc --noEmitHow are these going to "software rot" to death or become impossibly bloated before everybody give up on them?
Have you actually taken a look at the tc39 meeting notes for the context proposal?
Why do we need to reserve extra syntax space for that when it can already happen without reserving the extra space?
Oh and by the way I forgot to mention that a working syntax has not yet been proposed, and that the JS parser will become slower.
azder commentedon Mar 19, 2024
They already are, just not the way you like it, so you dismiss them? There are no types in JS because they aren't up to the "let's write code for the static compiler and type checker" crowd standard?
You can have simpler compilers to build and maintain if you have languages that require you specify types ahead of time, sure. But then we end up writing code for the compilers, not the people.
The other solution is to just write code that is easy for people to read and write. Compilers can get more sophisticated with time. AI can become better with time and it will be faster at generating loads of static or dynamic code more than us in any way.
So, just adding syntax into ES that is already supported in languages that transpile to ES... I can see some short term benefit, maybe more emotional than practical for everyone raised to see and express the world through static typing, but long term just syntax bloat that once introduced into ES can't be taken out.
Unlike other languages ES can't quite support adding stuff now just to see if it will work out and maybe releasing a breaking change later that removes it.
hydroper commentedon Mar 23, 2024
The case is lost then. The web standards for existing JavaScript have gone through an entirely different path from ECMAScript 4; otherwise explicit typing in the form of runtime types would be ideal for ECMAScript.
TypeScript versus ECMAScript 4:
Either way, build steps are almost always needed due to XML user interface frameworks. For example, the Flex compiler for ActionScript 3 processed special files called MXML files, similiar to .NET Razor.
hydroper commentedon Mar 23, 2024
You may also check my prespecification of a language called Jet that is based on ECMAScript 4: https://hydroper-jet.github.io/lang/spec/1.0/live/
No, I'm not planning to work on it definitely anymore, but it points to an ideal type system; read the Language Overview section.
markcellus commentedon Mar 23, 2024
Hmm I'm not entirely sure what the issue is here. Is there any question or something we can help understand? FWIW, there are a ton of other issues open that discuss the pros and cons of this proposal. Based on the OP, it sounds like you're having compatibility issues with TS versions, which I don't think this proposal is focused on.
hydroper commentedon Mar 23, 2024
@markcellus Surely, the TypeScript varying version behavior might not be of interest when it comes within the IDE.
This proposal will, still with type erasure, be useful to avoid setting up TypeScript projects 👍