What is stopping this from getting close to stage 4?

[backspaces]

Could someone enumerate the core issues preventing this from moving forward? Or if there already such a list, could you post it here? Thanks .. it's stopping some of our new projects just going to typescript or some other alternative. I.e. If this really is going forward, we'd far prefer it!

[theScottyJam]

The proposal is in the "explore the problem space" stage right now. They have one example concrete solution outlined in the README, but they're still trying to look at different options and collaborate with others to decide which paths are good and which aren't.

As for an actual list of core issues - the answer to that will depend on who you ask, and what they feel to be the biggest issues. But a couple of example issues I've seen delegates raise is:

• There's too much grammar for this use case
• This proposal is too closely tied to TypeScript syntax, and it should be type system agnostic
• There's better ways to solve the issue of "removing a build step" than "adding type syntax to JavaScript"
• Token soup concerns - in some cases, you might accidentally comment out more code than you intended with this new types-as-comments syntax, leading to potentially difficult-to-find bugs.
• grammar concerns - there were a handful of "bugs" in their tentative grammar
• There's probably others I'm not thinking of off of the top of my head.

Issues like these may be major ones that will force the proposal to change what it's doing. Or, maybe after some discussion, the delegate(s) raising those issues could be convinced that their issue isn't a major problem, and they'd be fine living with it, or maybe some other compromise could be made, or maybe things will just stall because there's no good way to fix it.

Anyways, I personally wouldn't hold up on switching to TypeScript on account of this proposal. Larger proposals have a tendency of taking many years to get through, and this is one of the largest proposals I've seen. There's also the fact that many proposals don't seem to get past stage 1 - there's a possibility that this proposal just won't make it, or if it does, it may be in a radically different form than what's currently envisioned. When this proposal does finally come out, there's two possible ways it could take shape - 1. It'll be backwards compatible with TypeScript, in which case you can just use a code mod to make the switch, or 2. It won't be backwards compatible with TypeScript, in which case you'll probably have to wait many more years for the community to really adopt it (and when you do finally switch, having existing type definitions will make the switch easier vs starting from scratch). Think about all of the libraries out there that currently have type definitions for TypeScript - the community would have to go through and additionally provide type definitions for the new JavaScript type system for these libraries, and that won't be a quick process. It kind of reminds me of common JS vs ESM - after this many years, we're still trying to move to ESM, and it's not easy, because the moment you switch to ESM, you'll be locked out from using any NPM libraries that are still in commonJS (at least, that's how it is with Node, I understand that competitors do things a little differently).

[backspaces]

Thanks, lots to consider. Good luck!

[egasimus]

after this many years, we're still trying to move to ESM, and it's not easy, because the moment you switch to ESM, you'll be locked out from using any NPM libraries that are still in commonJS (at least, that's how it is with Node, I understand that competitors do things a little differently).

...which originated as a completely artificial limitation (that you could defeat by catching a certain exception, if I recall correctly) -- and no, I can't help but think that it was introduced to nudge people to just write the damn TS. Instead of pairing a .d.ts with a .js, and being able to stay respectfully off the bandwagon, and being able to maintain backwards compatibility - you would now have to maintain .d.ts alongside two nearly-identical .mjs and .cjs... or just write the damn TS.

Don't get me started on how TS also provided the nudge to move to ESM at about the same time (Node 16, April 2022, never forget) - even though it didn't even support it correctly. Things will get real messy real quick if I don't stop myself from talking about that right... now.

:shrug:

I feel that the discussions here might have fizzled out because the participants (myself included) decided that putting up with the new normal (write ze TS) was doable, and finding common ground on the basis of which to propose an alternative, was not doable. A programming language is first and foremost a tool for communicating ideas - and when the functioning of such a tool is itself disrupted, how does one communicate ideas about how to fix it? Well, unsuccessfully.

🫠

A quick Google search doesn't give me any good data about how many people in the world write JavaScript professionally today (instead offering percentages of unspecified sample sizes). But let's say somewhere between 50k and 500k humans have skin in this game. How many turned up here? Tens? More than I expected, for sure.

The handful of us that realized that we can come to this repo and bikeshed are no match for a competent, well-funded, and well-organized corporate team - even if that team's efforts are ultimately in the service of enshittification and a boot stamping on a human face for ever.

:cricket: :cricket: :cricket:

For the "herd of cats" approach to work, we would need to bikeshed. even. harder. But then feelings are gonna get felt - and, inevitably, hurt. The norms of debate on this platform being what they are, we're all better off with the disavowal, and so... ze TS it is.

Besides, I've gotten kinda good at tricking TS into letting me do my job. It brings me almost the same intellectual satisfaction as the "actually accomplishing anything" part - and I get paid the same for either. So, what have we to lose but our sanity?

[backspaces]

My main concern is that it divides the JavaScript community. I use vanilla JS and find it off-putting to have to wade thru TS when vanilla JS would be fine or even better.

Example: I'm taking a Udemy AI for JS developers course. The teacher chose to use TS and kept running into awkwardnesses, and had to compile the TS to JS anyway. Converting to vanilla JS immensely simplified the AI code.

The approach being considered for JS types is great: it's treated as comments for use by IDEs or others to use to improve the code. And it had the potential to remove the Great Divide between us JSers and TSers. Sigh.

[egasimus]

You might be interested in the following affordances. Right now, you can[^0]:

• write types-as-comments, by annotating JS with JSDoc comments, and running tsc on that (I think this "discovery" also contributed significantly to people chilling out about the whole "native type annotations" thing);
• write a single .d.ts that covers the public API of your entire library (who will check that your package's exports match what the .d.ts says, remains a mystery to me to this day).

I only learned about these from previous discussions here. I haven't really seen anyone use these in the wild, and even though they are documented, they sure as hell aren't being advertised.[^1]

I did actually try these, and I wasn't really able to find the correct tsconfig.json incantations (or is it now jsconfig.json?) to get these two features to work properly. Yet, there they are. Maybe you will have better luck. Please report back if you try.

[^0]: (sort of)

[^1]: Hmm, don't good-faith open source projects normally advertise their compatibility with all sorts of adjacent things?

[backspaces]

Interesting! .. and thoughtful. What are your thoughts on the division of the JS community? And being forced to use TS in certain situations like a tutorial/class using it?

[egasimus]

the division of the JS community?

Royalty is one continuous cutting motion.

being forced to use TS in certain situations like a tutorial/class using it?

Basically a crime against humanity.

[ptomato]

Good heavens. A programming language you don't like is not a crime against humanity. Please refrain from comparisons like these.

[egasimus]

Because tech conglomerates do not have a track record of facilitating actual genocides?[^x]

Because subjecting the livelihoods of knowledge workers to forced obsolescence is somehow doing us a favor?[^0]

Because teaching corporate surrogates in place of the digital commons somehow cultivates individual agency and personal autonomy?[^1]

Or because feelings were felt? It's okay to have those about the way you make a living in this world. I'll stop myself before I advocate violence against anyone who claims otherwise, but please at least remember the person who made you internalize such knee-jerk language-policing reactions, and try to let go of their likeness.[^y]

[^x]: Meta 2017-, IBM 1933-, I wonder where our very own gracious hosts have left their mark?

[^0]: Privileged as we supposedly may be... JavaScript was what kept me off the streets, while my first encounter with TypeScript was decidedly nonconsensual

[^1]: I realize most people either take these things for granted or don't give a damn about them in the first place. But I've had to struggle for mine, probably more than most people who grew up this side of November '89. That's why I treasure them.

[^y]: It might take a few tries before you start noticing the difference.

[ctcpip]

conversation is locked because this is a closed issue and comments were veering off-topic. please be reminded of our Code of Conduct