4 ms·
> personally I don't see why you'd want to use anything other than Typescript right now A desire to not have IP coupled to Microsoft and a desire to put the bu
by rglover 5y ago
> personally I don't see why you'd want to use anything other than Typescript right now
A desire to not have IP coupled to Microsoft and a desire to put the burden/discipline on the self to ensure clean API design versus using TypeScript as a crutch to do it for you. In my experience, writing JavaScript code that's conscious of types/inputs/etc. is far easier (and more productive) than maintaining a TS codebase and all the trimmings that come with it (i.e., dependency on build tools, frameworks, etc). A lot of hidden costs.
- jolux 5y agoHow is TypeScript a crutch for API design?
- rglover 5y agoAPI meaning data API/structure, not a public/restful API.
- manigandham 5y agoHow are you conscious of types without any tooling? And if you use tooling, then what's the difference?
- rglover 5y agoWhen you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it. For example, JavaScript default args are really helpful for avoiding type errors: const nameString = (name = {}) => { return `${name.first} ${name.last}`; }; Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).
- imbnwa 5y agoNot to mention the Typescript parser can be configured to parse JSDoc comments for compiling an index.d.ts file for external users if need be
- jmondi 5y agobasically you just described dynamic languages here. We know why and how to program in a dynamic language. We don’t want that though. People that are using TypeScript are using it for the static typing.
- deleted 5y ago[deleted]
- rglover 5y agoYes? And I understand why you want to use it, I'm just saying that it's not always necessary (i.e., some of the dogma around it is unwarranted).
- yuretz 5y ago> I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.
- rglover 5y agoIMO, same thing. If I see that, I'm going to know what to fix. Still not a sell that I need to add in TypeScript. I get the why, but it's often overkill.
- mattlondon 5y ago...or just use typescript and get red squiggles in your IDE (...or when compiling if not using and IDE) and you don't have to go manually check your UI or write a unit test to make sure you provided the right type. Your approach sounds totally unscalable beyond a small project to me - you can't go manually eye ball your entire UI on every change. Just let the computer handle this trivia and concentrate your efforts on adding value I say. Sure it takes an hour or two to set up the tooling, but once you are up and running there is no overhead (unless you consider defining types an overhead). Compiles take a fraction of a second and the browser has usually already reloaded itself before you've even physically moved your eyes over to the other monitor