loading...

re: The Trouble with TypeScript VIEW POST

FULL DISCUSSION
 

🤨 I will have to agree if a project doesn’t start with TypeScript, migrating to TS can be problematic, we are all engineers and by definition that means we should be finding technological solutions to problems. Being an engineer doesn’t necessarily mean “I do what I want”.

I have run into instances where I had to refactor code to make it conform to TS compiler, but never found a use case where the refactor made the code less performant.

Perhaps instead of calling out all the issues you found with TypeScript, be more proactive and help fix those issues. That is what open source is all about, collaboration.

There is no controversy here. No “trouble”.

 

I try to be heavily involved in Open Source and I have reported and joined discussions on issues. Refactoring for TS is unacceptable for Solid at this point as it is in contention for being the fastest Client UI rendering library period. So very sensitive to even smallest code changes. But that's a library.

I figured refactoring would be hard so that's why at the startup we have only started TypeScript on greenfield projects and that is the additional experience I am speaking to.

 

I would like to see some concrete examples of how adopting TS would slow down rendering in Solid. Without performance metrics this is just hyperbole.

Solid is all TypeScript and it works well so I feel I worded that wrong. I meant that I was unwilling to change the runtime output to better support types. Especially around JSX there have been some questionable suggestions. Most of the friction has been around declarative path based API which is there to enforce better patterns as reactivity can get out of control. Internally TypeScript still lets me use object factories where they are faster than classes. And define class interfaces without using class properties which babel can handle less than ideally. And I have benchmarks for those sort of things. Coming from the perspective of someone who benchmarks excessively it wasn't about TypeScript being slow. It's about finding the optimal JS code and then in a few places forcing TS to behave. It takes considerable effort when changes are made in certain places to test these things. So I didn't like TS changing output. But making it work without on the performance side wasn't too bad. API is a whole other thing.

If you are concerned about performance then you should take a look at Closure Compiler which will change output, but is tried and true solution for optimizing JS better than any other tool.

Thanks. A few of the other top tier competitors use it or used it at one point. I admittedly haven't tried it with Solid yet but it's probably worth a shot.

code of conduct - report abuse