Validate if a rewrite in TS has any performance penalty

[StarpTech]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Maintaining types is hard and error-prone. I opened this issue to make an experiment if a rewrite of this module in TS has any performance penalty. If this experiment succeeds, we can simplify contributions and don't have to maintain TS types separately.

• Rewrite in TS without breaking changes
• Validate the performance of JS and TS versions.

@kibertoad

[Eomm]

we can simplify contributions and don't have to maintain TS types separately.

is this the truth?

I'm not a blocker here, but I want to say that I'm out of all the packages written in TS

[Uzlopak]

There is a use case for everything. I dont see typescript here as having any benefit. Its like a project on purpose uses hand crafted assembler to ensure high performance and somebody suggests C++ because it is more modern.

I am personally a big fan of typescript and use it in projects regularly. But I am openly against using typescript in any of our packages. And tbh. I am not convinced, that the overhead of controlling if the output of our code is what we wanted in the first place is worth it. Also after an update of typescript, we would need to check again if the code changed in a significant way.

And I am not convinced that rewriting fastify-plugin will solve the original issue in #217 . You have still the same issue because you have to do the same work.

[StarpTech]

Let's allow the experiment to take place before labeling it as a failure. No long-term decision was made here. @kibertoad wants to give it a shot.

[Uzlopak]

I asked kibertoad regarding your assignment of this task to him and your claim that he wanted to "give it a shot". Actually i asked him, if there is maybe a misunderstanding, because he just wrote that he would test and benchmark if there is a solution in typescript.

I will remove the assignment of kibertoad to this task, because i think it is a misunderstanding. Also i want to avoid the impression, that if he doesnt supply a PR or a fork with the desired typescript implementation that you think we kind of block this feature request from being assessed.

You are free to assign this issue to yourself and implement a typescript rewrite so that kibertoad and others can review it.

Also kibertoad is of course free to pick this task if he wants to do the heavy lifting.

[kibertoad]

I am happy to write benchmark for this task, but not sure when I'll find time for it

[StarpTech]

I believe it may not be worthwhile to pursue further investigation if the majority is opposed to it. My rationale for assigning @kibertoad to this issue was based on their comment in #217 (comment). However, it is possible that I misunderstood their perspective. My motivation has waned, and I will close this issue.

[kibertoad]

I am generally curious where this might go and especially curious to see perf implications of this change. let's not close it just yet.
I'll contribute what I can

[Eomm]

I believe it may not be worthwhile to pursue further investigation if the majority is opposed to it.

I must say that a fastify-plugin-ts could make everyone happy:

• the experimentation will take place
• the data and users' feedback will show if it works better

This package is quite feature-complete, so it does not change so often (the last feature is almost 1 year old)

[Uzlopak]

I on the other hand expect alot of ts-ignore.... :D

[andersonjoseph]

For the sake of the experiment I would like to give it a shot to this with a fastify-plugin-ts