Top
Best
New

Posted by culi 3 days ago

JSDoc is TypeScript(culi.bearblog.dev)
206 points | 266 commentspage 3
Brysonbw 3 days ago|
I'm a big advocate for explicit type annotations in code. Likewise, either or is good with me. However, these days I lean towards using JSDoc only because I prefer not to add typescript lib and an additional build step just to get type safety in a project.

Also, you can use both (if that's what you prefer).

hilarycheng 2 days ago||
JSDoc is great. But remember, JSDoc is used for well trained developer. For those junior programmer, they will totally ignore it and write lots of shxt code. At least TypeScript can force them to use correct type like forcing them not to use "any" type.
Hrun0 2 days ago||
I’m surprised TypeScript is controversial to some people. Having worked on a large vanilla JavaScript framework, the benefits were pretty clear.
embedding-shape 2 days ago||
Many of us don't encounter the sort of problems Typescript offers to solve. As most programming languages, most of the bugs I create when using JS is logic bugs, and those are solves by unit testing, not "more types". It was a long time ago I managed to push broken frontend code because of assuming the wrong types, so personally I don't find TS that valuable. But obviously others seem severely impacted by those types of issues, otherwise TS wouldn't be so popular in the first place. People be different :shrug:
culi 2 days ago||
Myself and this post are also pro-TypeScript!
columk 2 days ago||
To address point 2 you can enable the VSCode setting: "TypeScript: Prefer Go To Source Definition".

If it's your own library you can add declarationMap: true to your tsconfig.

I almost always want to see the source when I cmd+click.

Merad 2 days ago||
Can you perform type checking with JSDoc? As in, run type checks in CI/CD, commit hooks, etc?
matt_kantor 2 days ago|
Yes. As described in the article, the TypeScript compiler understands type annotations that are written in JSDoc syntax. So you can use `tsc`, just like you would to check `.ts` files.
notpushkin 2 days ago||
What I would really like to see is a TS compiler that emits .js libraries with typing information compiled as JSDoc comments.
mohsen1 3 days ago||
Webpack is typed using JSDoc and type-checked via TypeScript -- I started this migration a while ago. It works pretty well
culi 3 days ago|
Wow I had no idea! Have you written anywhere about your experiences?
neallindsay 3 days ago||
Some TypeScript features are only available through JSDoc. The one I encounter most often is `@deprecated`.
pyrolistical 3 days ago|
What do you mean? Jsdoc has it

https://jsdoc.app/tags-deprecated

christophilus 3 days ago||
I think he’s saying that only JSDoc has it. Vanilla TS doesn’t.
gaigalas 3 days ago|
The sooner we get https://github.com/tc39/proposal-type-annotations, the better.

Once we get it, there is still a solid decade before runtimes support it, and optimistically, still more 10 years minimum having to deal with an interpreted language that has acquired an unecessary build step.

I absolutely hated when PHP switched from a phpDoc culture with static analysis (and IDE inconsistencies that would click-take you to stubs as well) to actual types. Not because I hate types, but because of the transition period. Once it's gone, it's such a relief to get rid of unecessary docblocks.

conartist6 3 days ago||
That proposal is a nonstarter. It cannot and will not ever be accepted
gaigalas 3 days ago|||
Something needs to change. I don't care about one specific proposal.

It's miserable having a de-facto build step for an interpreted language. Worst of both worlds.

Maybe just TS is fast, but it encourages developers to put more and more stuff into that build step (and they do, they do that a lot). Culturally, that trend is not going to change unless the main reason for having said build step is removed.

The whole babel/transpiling thing was meant to be temporary. It became temporarily permanent / permanently temporary.

conartist6 3 days ago||
I'm the person who is developing a permanent solution.
prmph 3 days ago||
Which is?
conartist6 3 days ago||
A standard environment in which to run code that extends the builtin parser.
indolering 3 days ago||||
Please elaborate!
conartist6 3 days ago||
The proposal is to introduce a whole slew of syntax to JS that according to the proposal will have no meaning. This is a paradox. You have only created a language if you can use it to convey meaning
gaigalas 3 days ago||
That's not entirely true. Ideally, there would be a follow up with a reflection API.

Also, comments are syntax and they're mostly meaningless. By your reasoning, programming languages should have no comments.

So, it's not really a qualitative issue (presence of meaningless syntax) but a quantitative one (presence of lots of parsing complexity).

conartist6 3 days ago||
If you say that whatever data is put there doesn't matter at all, the one thing you definitely cannot ever do later is give it meaning.
gaigalas 3 days ago||
Unless I say it's meaning is to be optionally reflected upon during runtime!

Look, I understand the purism and mostly, I agree. But this is not a clean slate language, it will never be perfect and it's going to become more and more idiosyncratic as times go by.

conartist6 3 days ago||
I don't see how it's optional.

Comments are a kind of freedom in code. You're completely free to use them precisely because (in a plain execution environment) they cannot influence the result of evaluation

If comments /can/ change the result of evaluation then you simply are not (completely) free to use them. (And yes I know that this is a simplification in JS where you can already get the source code of a function with toString... Ugh)

gaigalas 3 days ago||
Makes sense. I'm excited for your solution, despite not having seen it. If you can solve that, it would be awesome.
botten 3 days ago|||
Why?
conartist6 3 days ago||
In short, we can do much better. I'm building a full syntax extension/macro evaluation mechanism for JS.
herpdyderp 3 days ago||
Where is it? What is it called?
conartist6 3 days ago||
It's called BABLR as it takes concepts from Babel (transpiling) and ANTLR (parsing arbitrary syntax). https://github.com/bablr-lang/

I'm currently in the process of trying to pull together our first big release.

g947o 2 days ago||
The proposal likely won't go anywhere. The first sentence in README says enough about it.
More comments...