| > I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript? Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to you? The more different languages you play with, the broader your mental modelling toolset becomes. It
is painfully obvious to me that someone worried about interfaces in JS is not very familiar with more dynamically typed or/and functional languages. JS is a VERY FLEXIBLE language which can be coded in any style, which is why I've suggest playing with something more opinionated to get the gist. Languages like XSLT, Erlang, LISP, Haskell etc. > You are called to edit a function that takes 2 arguments: > function handle_req(request, options): > What is request in this context and what is options? The fact that you can edit handle_req means it is application code. So how you figure that out comes down to the structure and patterns you and your team use (if any) and the available documentation (if any). You'd be surprised how far Eslint and JSDoc will take you. TypeScript accomplishes the same, and I've no problem using it within a team that needs it but personally, it feels like an overkill I don't really need to. > A whole lot of the time, especially in JavaScript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen? The decision to use TypeScript or any other tooling should really be made at the BEGINING of a project, so why are we talking about projects that already missed the boat, and even worse lack documentation and tests? This just proves my point, what you really need is discipline (documentation, tests, best praise etc) and a good linter, not a whole new language or programming paradgim. |