Please can this proposal not die, Python achieved adding types

[mangelozzi]

Python managed to bring in a very useful typing system. Maybe we can learn from them. We don't have to go the whole hog and try to do what TypeScript did. Year on year in the state of Javascript survey has the number one feature that Dev's want is typing. So to the TypeScript fans, please don't try to squash this proposal. I am glad Typescript works for you. I use TypeScript half of the week and it's okay, the other half of the week I write native web components and would love some simple basic typing, dont want typescript in my build. I don't even use NPM for these projects, and they have very advanced UI's (file explorers, graphing report data etc).

And to the people who don't like this proposal of adding typing to native JS, then don't use it, don't ruin the number one requested JavaScript feature just because you personally feel you can live without it. It's opt in, you can continue living your best life with TypeScript, or Vanilla Javascript (without using types).

To be able to put a breakpoint and step your actual javascript code is always the biggest benefit over anything else in my opinion, and that is why I never choose Typescript. Yes I can step Angular code in most situations due to source maps, but not always, on some difficult bugs it falls apart, and you are left dead in the water.

This proposal in the README is brilliant, yet I feel is being halted by some sort of TypeScript agenda push back, or choose your own conspiracy theory.

[temeddix]

Totally agreed, vanilla JS needs typing system like Python

[mangelozzi]

Totally agreed, vanilla JS needs typing system like Python

I feel Python pulled it off very succesfully, they have a great typing system, in a scenario where they never had one before. People can choose to sprinkle in typing more and more if they desire to, providing huge benefits to some people.

[mangelozzi]

I think a comment from a developer at Svelta gives a very reasonable balanced point of view, and highlights the benefits of this proposal, that if implemented, I suspect they would have gone with this proposal's native types:

https://news.ycombinator.com/item?id=35892250

Lordy, I did not expect an internal refactoring PR to end up #1 on Hacker News. Let me provide some context, since a lot of people make a lot of assumptions whenever this stuff comes up! If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you. If you're rabidly pro-TypeScript and think we're a bunch of luddite numpties, I'm about to disappoint you as well.

Firstly: we are not abandoning type safety or anything daft like that — we're just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won't affect your ability to use TypeScript with Svelte at all — functions exported from Svelte will still have all the same benefits of TypeScript that you're used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever (for an example of this, see https://svelte.dev/blog/zero-config-type-safety).

I would say that this will result in no changes that are observable to users of the framework, but that's not quite true — it will result in smaller packages (no need to ship giant sourcemaps etc), and you'll be able to e.g. debug the framework by cmd-clicking on functions you import from svelte and its subpackages (instead of taking you to an unhelpful type declaration, it will take you to the actual source, which you'll be able to edit right inside node_modules to see changes happen). I expect this to lower the bar to contributing to the framework quite substantially, since you'll no longer need to a) figure out how to link the repo, b) run our build process in watch mode, and c) understand the mapping between source and dist code in order to see changes.

So this will ultimately benefit our users and contributors. But it will also benefit us, since we're often testing changes to the source code against sandbox projects, and this workflow is drastically nicer than dealing with build steps. We also eliminate an entire class of annoying papercuts that will be familiar to anyone who has worked with the uneven landscape of TypeScript tooling. The downside is that writing types in JSDoc isn't quite as nice as writing in TypeScript. It's a relatively small price to pay (though opinions on this do differ among the team - this is a regular source of lively debate).

We're doing this for practical reasons, not ideological ones — we've been building SvelteKit (as opposed to Svelte) this way for a long time and it's been miraculous for productivity.

[mangelozzi]

PS I see the one person who downvoted this issue contributes to https://github.com/microsoft/TypeScript and is part of the Microsoft organisation. Make up your own conclusions of why the people who work for microsoft/typescript feel about this proposal, despite the obvious benefit for the JS community as a whole.

[orta]

To counter-balance this thread, I was on the TypeScript team when we were thinking about this proposal, and I'm a big supporter of it. IMO the biggest evidence against the idea that the TS team is slowing it is that one of the leads for this proposal is the product manager of TypeScript itself.

That the proposal has slowed down to my knowledge is not that the TS team is stopping it but because there is a lot of cultural work done to make sure the trade-offs are reasonable, this is a substantial change to the language and it affects all contributors involved at TC39.

This repo has generally discussed almost everything that could be discussed, and is mostly new issues from folks who have not read all the background discussion or are presenting ideas / "you should not do this" style feedback

I gave a talk on a lot of this at the TypeScript Congress last year, if you're interested in learning more: https://portal.gitnation.org/contents/what-is-tc39-type-annotations-aka-the-types-as-comments-proposal

[azder]

@orta I think you're presenting a narative that sidesteps the issue, diverts from it. All one needs to do is see the top of the README document to this proposal. Here it is:

This document has not been updated regularly. See TC39 meeting notes from 2022 (March 29, March 31) and 2023 (March 22) for the most up-to-date information.

In short, champions that work on TypeScript make a proposal to the ES commitee, the commitee has some questions and needs the champions to re-examine their proposal, things that may lead to other ways to add types to JS, not just make JS be TS, the champions don't even update their claims with the feedback...

(NOTE: JS already has types, we're talking about static type checking and adding a notation for that meta-code)

If that's not an indication that the champions will settle with nothing less than making JavaScript be Typescript in all but name, then what's that counter-balance saying? Cultural work? What's that? The TypeScript evangelists and the community in general gets to 99% use of TS so that no one remains to ask for a different type of type system?

This proposal, if it doesn't change, it should be killed. There are a few ides in the discussions that would make for a better proposal, provided there are people willing and able to pick them up. Proposals that might allow types to be added to JS or besides JS, yet still not make JS become TS.

That's the issue I see here, especially if one reads the commettee feedback: this proposal isn't about adding types to JS, but making TS syntax part of JS. Two different goals.

[lemanschik]

whats going on here why does no one close and lock this mangelozzi and all others here i agree with the creator of Python that python it self is dead it will not give a 4.0 ECMAScript will replace it simple calm down and stop spam tc39

[mangelozzi]

whats going on here why does no one close and lock this mangelozzi and all others here i agree with the creator of Python that python it self is dead it will not give a 4.0 ECMAScript will replace it simple calm down and stop spam tc39

It does not seem like the creator of Python, Guido van Rossum, has died. And Python is not dead, so this comment does not seem authentic it it's contribution.

[lemanschik]

https://answerpython.com/why-python-4-may-never-arrive/

[mangelozzi]

https://answerpython.com/why-python-4-may-never-arrive/

Guido van Rossum is not dead, and have you read the article. Python 3 was not backwards compatible with Python 2. Due to migration pains people had, they don't want to repeat that. In fact most languages actually are actually backwards compatible with each major revision. The only implication is that python names it's release 3.10, then 3.11, then 3.12, instead oy say 3, then 4 then 5, to indicate backwards compatability. Inferring that it is dead due to it's release naming conventions is misguided.

[lemanschik]

do what ever you like you got informed the future is anyway the llm-compilers that spit out directly adjusted ASM

[mangelozzi]

do what ever you like you got informed the future is anyway the llm-compilers that spit out directly adjusted ASM

I hope you will be able to set breakpoints, e.g. step into an event handler due to some source map in your none compiled code. My experience with source maps is they are not reliable for debugging. But I hope it works out well for you using assembled code.

[conartist6]

I could not agree less, because Python added a type system. Python's type system checks your types, so you are strongly incentivized to ship types that have meaning according to Python's type system. (Edit: I may have been wrong that Python's system works like this -- it seems it also does not define checking rules)

Adding a system of comments creates no such incentive. Imagine where Python's system is a canvas on which people do the artwork of type-safety, adding delicate solutions to a system of mathematical equations checked by the runtime. This solution is more like establishing a latrine, where the meaningless random byproducts of unseen and unknowable systems of typing rules would be pissed into the JS ecosystem without the courtesy of calling it rain. You would not know whether you were reading JS or Flow type rules. You would not know if the information you were reading was an outright lie. In fact the only sane thing to do when trying to read a file containing these type comments would be to completely synactically erase them so that there would be no possibility at all that they might lie or mislead you.

Now advance 5 years to when TS, Flow, and all the other type systems have been pooping their excrement into these comments and suddenly JS users are saying "Hey, in Python this type data means something -- in Python the types help the tools understand the structure of the code. We want the JS types to work like that!"

Unfortunately using the type syntax as virtual landfill is the only way to be 100% sure that it will never be possible to use it for anything more valuable in the future. Once the opportunity presented by the availability of this syntax is squandered for no benefit, the opportunity to do something better (like what Python actually does) is gone forever.

[shaedrich]

Once the opportunity presented by the availability of this syntax is squandered for no benefit, the opportunity to do something better (like what Python actually does) is gone forever.

That is actually an important point 👍🏻

[quantuminformation]

I no longer use Typescript for small client projects and use my own vanillajs non-framework framework. It means no complexity debugging and maintenance burden having to track the tsc compiler.

JS Types would be useful though in this case. I will defo be using them if they come out.