The Unreasonable Effectiveness of Dynamic Typing for Practical Programs
(working full-time on JavaScript code for last 4 years)<p>TL;DR good dynamic codebase is possible, but not when you throw <i>too many devs</i> at it (particularly <i>junior devs</i>) and only when you set the very high quality bars. Otherwise, in finite time the codebase will converge to a big pile of mess.<p>IMO the big dynamic-language codebase with multiple people working on it can only survive with extensive test suite, lots of mock data available, automated quality tooling (jshint etc) and proper code review in place. All of those are well-known best practices, but they require good developers and certain discipline.<p>In particular, when the app retrieves lots of data from a server, it&#x27;s easy to get lost when the frontend app doesn&#x27;t even know what data it operates on, it just knows it gets &quot;some JSON&quot;. In old-school java world you&#x27;d have this mapped into a bean and you&#x27;d at least know what you work on.<p>Previous project I worked on was an inherited poor JS codebase with lots of unrefactorable magic happening inside, multiple event buses and what not. Since JS is a very dynamic and very permissive language, someone can abuse some language constructs to make it very hard to reason about the code.<p>In a pathological extreme you may get &quot;everything is an object&quot; codebase but no idea what keys each object has. 
Bonus points if the code is passing some JSON around and adding some keys to that object in an ad-hoc manner, scattered along many functions.
No tests and no mocks meant that to learn that, you&#x27;d have to run the app and put breakpoints. But, the same variable might have had totally different type of data inside depending on how some if-elses executed.
Most of our bugs were due to some objects not having some keys (sometimes) for some reason etc.