re: The Trouble with TypeScript VIEW POST

re: 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 t...

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