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