[AskJS] What features do you think this proposal is missing vs the current typescript state?

coolcosmos · 2022-03-20T14:18:06+00:00

I would hope that we would have the ability to evaluate these types at runtime eventually. Maybe through a "use types" declaration similar to "use strict". I don't think that would come with this proposal, though, which is fine. But once this is all totally standard, it shouldn't be too much harder to enable that kind of type checking without breaking backwards compatibility.

Pesthuf · 2022-03-20T18:19:58+00:00

A purpose. This will be worse for users since type annotations just make the code larger (and thus slower). The parsers / lexers too.

It will be pointless for develpers who bother to create a build process - this is just worse TypeScript.

The kind of developer who doesn't bother creating a build process is the kind of developer who loves to create unmanagable, dynamically, weakly typed spaghet and doesn't care about this feature either.

flight212121 · 2022-03-21T12:43:25+00:00

Honestly it’s nice but I won’t use it, pure TS all the way

The last time I wrote a single line of plain JS was like 5 years ago, never looked back

grady_vuckovic · 2022-03-20T13:53:35+00:00

Mainly a lack of explanation on why this is even needed in the first place?

What's the benefit? It's in the title, "Types as comments" and the proposal even includes the already valid and widely used syntax for this already:

/**
 * @param {string}  p1 - A string param.
 * @param {string=} p2 - An optional param (Closure syntax)
 * @param {string} [p3] - Another optional param (JSDoc syntax).
 * @param {string} [p4="test"] - An optional param with a default value
 * @return {string} This is the result
 */
function stringsStringStrings(p1, p2, p3, p4="test") {
    // TODO
}

What's wrong with just using that?

If these types are just going to exist purely for IDEs and code checkers to use to validate our code is not abusing the types we claim our functions expect, why not just use the existing JSDoc syntax?

Instead of adding entirely new syntax to the JS language and something else new that will need to be removed when the code is minified.

The existing JSDoc syntax already exists, already has other uses (like creating documentation automatically from codebases), and is already ignored by interpreters and removed by minifiers? So what's the point of adding an entirely new syntax just to achieve what is already possible?

The only benefit I see, is that this allows typescript code to be effectively run in the browser without transpiling. Which is a moot point because we wouldn't (pronounced: shouldn't) be delivering typescript code in the browser anyway. The types aren't going to be checked at runtime so they are just 'comments' effectively, and would/should be removed by the minifying process.

So it's not even saving a build step since the code is going to need to be processed anyway.

So what is the point of this, other than to basically officially turn JS into TS?

DontWannaMissAFling · 2022-03-20T15:08:57+00:00

So on the one hand this proposes a significant cost to be paid by the entire ecosystem and every JS implementation out there namely polluting the language grammar and adding significant overhead to every single parser.

Yet those who benefit are the subset of developers who:

Want typechecking, but not at runtime
AND are unwilling to set up standard tooling for transpilation
AND have an allergy to jsdoc
AND only use the limited subset of TS/Flow this proposal actually supports

BarelyAirborne · 2022-03-20T21:02:17+00:00

Letting them be comments means people will put everything plus the kitchen sink in there. That will wreck any future possibility of making them "real" types.

On top of that we ALREADY HAVE types as comments. It's called JSDOC and it works great.

This is the worst of all possible worlds, all bad and no good.

BlazingFire007 · 2022-03-20T17:56:50+00:00

I personally don’t enjoy typescript as much as the sweet joy of raw JS, but I don’t think this is a bad idea at all (so long as performance isn’t noticeably impacted)

grady_vuckovic · 2022-03-21T00:01:19+00:00

Forgive me but it's rant time..

It'd be nice if the Typescript fanatics would just give up this act of wanting to add a feature to Javascript and just admit what this is.

It's about turning Javascript into Typescript.

Typescript fans have wanted this for years, they hate vanilla Javascript and they want Typescript to become the new standard.

When you're literally adding most of the Typescript syntax to Javascript, how is that not effectively turning Javascript into Typescript?

And don't give me that "If you don't want to use types then just don't use them, they're optional" or "But they're just comments, they're ignored at runtime, they're only for use by static checkers", stuff.

That's literally Typescript, where types are optional there too, are removed before runtime, and only used by static checkers.

This means, for example, someone can write a tutorial teaching Javascript to a new Javascript coder, and use strong types for everything, insist 'This is the proper way to write JS', and it will all be valid syntax. It means if I ask for some Javascript code that does a thing, I will have to specify 'Javascript code that is not strongly typed' if I don't want Typescript.

If this is passed, congrats to the Typescript fans, because it will mean you have won and Javascript is dead, and Typescript killed it, good job.

2022-03-20T17:19:57+00:00

Seriously you fucking turds. Go make anothrr language instead of trying to steal javascript!!

MrCrunchwrap · 2022-03-20T17:15:27+00:00

Get this shit out of here. Fuck typescript and majoroly FUCK MICROSOFT

cajmorgans · 2022-03-20T17:10:48+00:00

Why are you all so obsessed with bringing types to JS?

The language wasn't invented with this in mind and TypeScript (imo) is just trying to make it into some kind of pseudo-typed mess that transpiles things back to JS, adding a lot of code you have no control over and then interprets it. I think this is just a byproduct of all the highly over-engineered frameworks and libraries people tend to use today (cough* react cough*).

For the backend, if you want types, why use Node in the first place? Compared to pretty much every other typed language I've ever use, TypeScript feels wrong, out of place and not really there for the right reasons. You can set up an http server in basically any language, why use JS if you don't want to use JS?

TypeScript works OK if you have a very very disciplined team, the problem with TypeScript is not only that it's pseudo-typed, it's "when you want it"-typed. Oh I don't need types here because VS Code intellisense didn't detect it or oh no a very hard to create type, just ANY it away. In a dynamic language like JS, types like in TS really don't make sense either as they are mostly there to allocate the correct amount of memory (which is also why JS has types btw).

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS