| I feel exactly the opposite. I'm continually amazed that Java devs have still not acclimated themselves to Javascript after all this time. If you notice that the style you're used to coding in is causing a lot of problems and that people coding in other styles have few-to-none of these problems, maybe it's worth questioning your approach. I maintain a medium-sized (50k lines) codebase with frequent requirement changes that uses a functional style, and the closest we've come to ever needing a type-check is null checks. Type errors are maybe 2% of total errors when developing, and because our code doesn't have too many layers of indirection, they've all been trivial to fix way before production. I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours writing type files and code in a dialect of Javascript that doesn't provide 100% coverage. If you embrace functional programming with mostly immutable data structures and avoid mutation, side-effects, and gross mixins/polymorphism, you reduce the size of your codebase significantly, which makes it much easier to keep documentation terse and up-to-date. On the other hand, if your team is so undisciplined and untrustworthy that you need to throw errors on compilation because you don't trust them to update comments and docs or name variables descriptively and your entire team knows Java but not Javascript, I could see the huge amount of boilerplate involved in Typescript being well worth it. As someone who's primarily a Javascript developer who does Clojure on the side, I feel that the Java approach is fundamentally impoverished. I've never met anyone who chose to develop in Typescript whose background wasn't enterprise Java, just like I've never met anyone using Ramda (before lodash replicated it) whose background wasn't in FP. |
I'll take "unrealistic estimates" for $500, Alex.