Found it difficult to integrate with existing JS, such as THREE.js. Also found it difficult to create libraries (I make a RAD workflow for VR apps) that could be used in arbitrary JS projects; I want people to be able to drop my concatenated script into their page with a script tag and not have to worry sbout anything else. Also, early on I ran into quality issues with the 3rd party type mappings for popular libraries, and eventually decided it wasn&#x27;t worth the hassle.<p>Generally speaking, gradual typing doesn&#x27;t get me excited.  I don&#x27;t think there is a payoff to having some of your code statically typed and others not. The mismatch between the two causes problems. So TypeScript, et al are an all-or-nothing proposition, and there were big chunks in my workflow that prevented it from being &quot;all&quot;.<p>If you choose to embrace dynamic code, you can write less of it and minimize your surface area to bugs. I&#x27;d prefer static checking and more code because of stricter typing, but dynamic can be done well in its own right if you approach it at a much higher, metaprogramming level. Don&#x27;t half-ass two programming styles. Whole-ass one.<p>I also missed the fast-reload workflow of native JS. I sometimes live-edit code in the browser, and being able to go back and forth between the two with no hiccups is nice.<p>So while a lib layout e.g. THREE.js is &quot;old&quot;, it at least works without major machinations on the most systems for the most implementing developers.<p>I might start using more ES6 features, as I could use native browser support in my browser of choice for development and a transpiler to pack up packages for deployment. But I won&#x27;t be going to a language that gets between me and the browser.<p>Contemporary webdev workflow is designed for either A) automated setup and execution of scripts in remote, headless environments or B) getting beginners gluing libraries together quickly. These are frequently not the same thing as a great developer experience.