8 ms·

Using TypeScript with React

225 points by skn0tt 7y ago

wintorez 7y ago
“TypeScript solves problems that I don’t have, in a way that I don’t like.”
- JoeyJoJoJr 7y ago
  What are the problems that Typescript solves that you don’t have?
hki99 7y ago
During my internship we've built a large prototype using React+Typescript, and here are some of my key take aways from it: - Quite often when using unreleased APIs, you turn to using "any" all over the place. - Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features). - Lots of frustration when a package doesn't have types (although most major ones do have them). Otherwise it has been a joy writing the application, and it does "document" your components significantly better.
- latchkey 7y ago
  Development time isn't slower when you factor in all the bugs it saves you from dealing with down the road when you're either wonder what is the type of an object or why something isn't working during runtime that a compiler could have caught.
  - a_wild_dandan 7y ago
    Also, if you're working with an untyped APIs, define the types you're using. It doesn't have to be complete or perfect. But having that formal contract will save you time and make explicit your assumptions. In the best case, you can contribute those types to the API to everyone's benefit.
- altschuler 7y ago
  Beyond a certain size and complexity (which is not that much), I find that the argument of typescript (and other typed languages) being less productive than untyped dynamic ones, is not true when you look at it as a whole. It might feel slower, especially to begin with, but once you get used to the language and semantics you save a vast amount of time, by the bugs you _don't_ debug and by not having to jump through the code all the time to find out what that function or module was called or what parameters it accepted. This of course is less true if you're using a lot of untyped packages, but as you said, most do have types either natively or in the DefinitelyTyped project. For most modules it's also feasible to declare the module typings manually, even doing it gradually for the parts that you happen to need at a given time.
- ghego1 7y ago
  IMHO TypeScript saves a lot of time as soon as any project grows over few thousands lines of code. I'm working on a large project in which both backend and frontend are in JavaScript (node+PWA) and without TS it would have been close to impossible to proceed at the speed we did. Thanks to TS we easily know what types must be passed between client and server, and we can easily refactor or edit code without worrying that some mis-type somewhere will brake things. We don't use any anywhere (literally), it's not trivial, but as soon as you get to know TS well enough it's absolutely feasible, at least since TS 3.x.
- andyhmltn 7y ago
  >- Quite often when using unreleased APIs, you turn to using "any" all over the place. What unreleased APIs are you needing to warrant this? We've used any a couple times, but usually just as a placeholder until the data model is locked down. >- Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features). Again, I can't say I've had this experience. Development time is _initially_ a tiny bit slower, but once you've setup types, the time saved from fixing type related issues adds up very very fast. Also, autocomplete / autoimporting has actually sped up my development time hugely. Not having to worry about figuring out relative paths or imports and just being able to type a component to import it is magic. >- Lots of frustration when a package doesn't have types (although most major ones do have them). This is true, but I've found that 95% of the packages we use do have types. The few that don't, tend to be very small indie packages that don't do a lot, so the lack of types isn't a huge issue.
- aquadrop 7y ago
  I think the threshold of when Typescript starts being helpful is reached very quickly. Because there's always some schema in code, yes you can assign any value in JS, but then you have to remember it and account it in other code etc. There's always some schema, you just have to keep it in your head. And with TS I can offload it to the code/IDE to help me. I want to make decision about shape of an object in the moment I'm creating that abstraction or when I'm looking specifically at it deciding if it needs to be changed. I don't want to be forced to remember all those decisions all the time. If some prototype code or script is couple of screens long, sure you can easily fit it in your head and maybe you don't need additional assistance, but when it grows larger, pretty quickly it's very nice to separate process of thinking over shape of objects and process of using them.
- Vinnl 7y ago
  Interesting. There are downsides to using TypeScript (build chain complexity is the major one for me, although that's getting less and less relevant as more and more tools gain native TypeScript support), but the three you mention are not relevant to me. - I don't know what unreleased API's you're referring to, but I generally haven't seen the need to use them - if they're unreleased, I try to avoid them. - Especially for projects with fast iterations, TypeScript has been massively useful. Changing the API around, which I do often at the start of a project, is just so much easier when you've got TypeScript to make most of the required changes, or to tell you where you have to make changes. - Type availability might be a problem, but I also generally stick to major packages for which it's not. But yes, I have learned to contribute to DefinitelyTyped - which luckily is a relatively smooth process.
- joshAg 7y ago
  The way we've been using typescript is that when you're first implementing the API using 'any' is just fine, but it's not ready for release until all the 'any's are removed. What I've found is that there tends to be a happy medium between making everything 'any' at the start and never using 'any' at all that roughly corresponds to how defined our implementation is. When we're designing the implementation as we go, there tends to be lots of 'any', but when we spent time defining the interfaces, there's not as much need for using 'any', because instead there's a specific type. The type itself usually doesn't remain static, but where it's used does. So for example, when we're adding a rest endpoint, when we know the required and optional arguments/response, we can make a type and validator function and then there's not really a need for 'any' after the validation function, but if we don't know what the arguments/response will be (or the design is still at the 'make every argument optional' stage), then any sort of prototype will be littered with 'any' or '{[key: string]: any}' types.
  - no_wizard 7y ago
    I'm curious, and I'm prefacing this up front because I'm not always good at writing what I say in a way that may not feel like I'm coming from a good place, so here goes: Whats your testing story? This to me seems like not writing good, solid, abstracted tests before doing proper implementations of your code. This could be solved with good interface design, and perhaps be faster. I apologize in advance if this sounds harsh. This sounds like the exact thing folks on my team were trying to do, and it was turning things very sub-optimal. (Disclaimer: I'm a bit of a TDD/BDD idealogue. Not as hardcore as Uncle Bob[0], certainly, but close enough. I think writing Interfaces before Tests is acceptable, I think that might be where things differ, i guess). [0]https://blog.cleancoder.com/ https://blog.cleancoder.com/
    - joshAg 7y ago
      At least for interfaces between different modules/layers of abstraction, we use BDD almost exclusively. Our docs tend to be very well defined, so 'any' isn't actually used that often. We focus on end-to-end testing over unit and integration tests, which for the REST API backend means only looking at the request, the response, and the side-effects (especially db writes). For us the docs/spec comes first and then tests, implementation, and consumer use can (and does) happen in parallel. The REST API is defined using OpenAPI v3, and we use express-openAPI to generate request and response validator functions for every endpoint. Each endpoint needs a happy-path test for 1) every optional argument supplied and 2) none of the optional arguments supplied (if there's no optional arguments then this devolves into a single test), and all side-effects must be verified. The main place where we use 'any' or {[key: string]: any} and then just cast to what's expected tends to be the responses from the database, because the response validation code will catch any actual mismatches (the most common mismatch is forgetting to parseInt and trying to send back something like '1' instead of 1, but sometimes there's issues with the db field being nullable when it shouldn't or not nullable when it should be nullable). Here's the latest test run on master (hope the formatting works): ---------------------------------------------------------------|----------|----------|----------|----------|-------------------| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s | ---------------------------------------------------------------|----------|----------|----------|----------|-------------------| All files | 82.89 | 63.56 | 86.38 | 82.86 | | Branches are especially low, because we don't test most unhappy paths since we use a middleware error handler with generic error messages for different types of errors that's got something like >90% coverage instead of handling errors within each endpoint. The unhappy paths we do test thoroughly are things like our user-defined typeguards, our middleware error handler, our security handlers, and anything else where we validate unsafe/unknown inputs. We try to stay away from stringent TDD/BDD unit testing, because 1) the reward from the work required to get there doesn't justify the cost of getting there for us right now and 2) strict BDD/TDD unit testing makes it much harder and slower to try different implementations/refactor things, since every time you want to modify one-off helper functions you need to add a bunch of tests first. We found that cost is worth it at module boundaries (eg endpoints, auth, database), but not for most functions that are only ever called inside their module.
- verletx64 7y ago
  I’d recommend using ‘unknown’ over ‘any’, it’s truer to the code you’d probably end up writing if it was vanilla JS; fairly defensive stuff. On top of that don’t be hesitant to define ad hoc interfaces on your side of things; ultimately ‘any’ communicates zero information and provides zero defence. The more I start to use other techniques the more I feel that ‘any’ really should be the last escape hatch deployed.
manishsharan 7y ago
If you are going to learn a new programming language for web UI, why not go for Elm ? You get so much more than just static types with Elm.
- millstone 7y ago
  JavaScript interop I suppose. TypeScript allows incremental integration with other JS libraries, while Elm forces an awkward ports/messaging abstraction.
- iraldir 7y ago
  Looked at Elm and it looks quite interesting. however concerns for going to it - Skill transfer. If I learn react, I can use my JavaScript skill to understand how everything works under the hood. If I learn Typescript with React, knowing react, I can focus on learning new language feature while not learning at the same time how to build the application. With Elm, I have to learn the language and the framework, all at once, basically learning from scratch. - compatibilities with libraries. Here I definitely might be wrong, not knowing Elm enough, but okay, say you don't need a framework because it's included. What about utility library. Like i don't know, analytics or fancy animations? - Job Market. I'm not going to learn a language that I cannot use anywhere, and if I'm a company, I'm not going to choose a language for which is going to be hard to hire people. Now Elm sounds real cool and I want to like it. But it doesn't seem very wise to spend time doing that vs learning something like Apollo+Graphql, or Typescript, or Vue, which have much more obvious benefits to my career.
  - manishsharan 7y ago
    The job market is a chicken and egg type problem. Management would not allow Elm based projects as there are no othe Em programmers on staff. We cant ask for Elm programmig experience in resumes as we dont have any Elm based projects. I wonder how other languages,like Scala, managed to get traction in the enterprise whereas Elm has not even though it can solve real issues that we face with Javascript development.
    - 7y ago
rimher 7y ago
I see the same response everywhere on TypeScript: when a project becomes big enough, it's a good way to keep it under control. And I tend to agree: types can be annoying, but when stability and robustness come into play, TypeScript is most certainly the way to go. It enforces good behavior. And yeah, of course it slows JavaScript down, that's entirely the point..! JS allows you to do whatever you want, but that doesn't mean it's always the right choice
robmoorman 7y ago
React is already typed with props. I see no added use for TypeScript. Yet another list of packages makes maintaining very hard and inconsistent (as types are declared in variant ways). Explicit (and simple) functions as React (e.g. hooks) provides won't need strongly typed code, less readability in my opinion. If you're building a library / sdk, than Typescript comes in place and can make life easier for devs.
- PunchTornado 7y ago
  I don't understand. How would you strongly type every function and state variable in react without typescript?
- underwater 7y ago
  PropTypes are disabled for production builds and runtime only. The only advantage for using them over TypeScript or Flow that I've seen is when consuming third party React components. Otherwise the guarantees, feedback loop and terseness of static types are superior to PropTypes.
holografix 7y ago
For typescript to be very useful to indispensable the tooling needs to improve. If there was a checkbox on VSC that said “use typescript” for a project and I had to do nothing else for it to work then sure, I’d use it. For a single dev working on a fairly simple React + Redux app it’ll slow you down like no tomorrow.
- onion2k 7y ago
  What you're asking for mostly exists. You don't even need a checkbox. TypeScript support has been included with create-react-app since v2.1.0, with all the features enabled. VS Code ships with syntax highlighting and command completion for TS. If you want to try it use; npx create-react-app tsx-test yarn add typescript @types/react mv ./src/App.js ./src/App.tsx yarn start (WARNING: npx runs stuff from the internet on your machine) That will make a 'typescript' React app run on your machine. Obviously App.tsx isn't actually doing any TypeScript stuff, but if you add some it will work.
  - wereHamster 7y ago
    Even simpler, see https://create-react-app.dev/docs/adding-typescript https://create-react-app.dev/docs/adding-typescript npx create-react-app my-app --typescript
  - resurge 7y ago
    Note that they said "React + Redux". And that combo indeed takes a lot more time to get set up and understand the first time. I used this lib to get it to work: https://www.npmjs.com/package/typesafe-actions https://www.npmjs.com/package/typesafe-actions I wouldn't even know how to get it to work with just the regular react & redux types.
    - onion2k 7y ago
      typesafe-actions looks useful but you don't strictly need it. You can use redux with TS just by adding @types/react-redux. https://redux.js.org/recipes/usage-with-typescript#usage-with-react-redux https://redux.js.org/recipes/usage-with-typescript#usage-wit...
h0h0h0h0111 7y ago
I've been writing Typescript with React for quite a while now and these are my feelings so far: - Typescript type system is pretty awesome, and allows the expression of some things really elegantly; in particular, string literal types are quite cool for component props that feel "htmly", union and intersection types are great for making reusable/generic components and Partial<T> is cool for making typesafe component states (https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... is a great resource) - on a related note, the Typescript docs are very comprehensive - ... but docs for anything React related to Typescript (types of components, etc) are harder to come by - for the actual UI code there is some time wasted getting type signatures perfectly correct, particularly for React and HTML components, but I've built up a bank of helper functions in this regard. - using `any` nearly always comes back to bite you as you trick yourself into feeling typesafe - there is always a tradeoff between having perfectly exact types and not writing 139587123598 interfaces; expressing, for instance, mapStateToProps, mapDispatchToProps and mergeProps to compose into component props, or the former as a subtype the latter is pretty fiddly to get right and imo not worth the extra code - create-react-app typescript support has gotten pretty good now, but it's nigh-impossible to step outside their boundaries. For me, some older features of typescript I wanted that protobufjs generated typescript used was just not usable and I had to work around that with great difficulty - nearly all packages now have type definitions for them which is sick - at the end of the day, you can still resort to vanilla JS where typescript really, really gets in the way
- fabian2k 7y ago
  > ... but docs for anything React related to Typescript (types of components, etc) are harder to come by I just saw this linked today and didn't look it through entirely, but this React+Typescript cheat sheet looks very interesting for React-specific issues you might encounter with Typescript: https://github.com/typescript-cheatsheets/react-typescript-cheatsheet https://github.com/typescript-cheatsheets/react-typescript-c... For example it explained an issue with the type inference for custom hooks that confused me somewhat earlier. I really like Typescript so far, but you can easily encounter situations that are hard to figure out with only basic Typescript knowledge, especially when interacting with more complex libraries. This probably gets better with more Typescript experience, but it can be a serious speed bump as a Typescript beginner.
jinushaun 7y ago
Disappointed that the article alluded to but never explains why classes should be avoided in Typescript. (Which I agree, btw) If you’re used to classes, it’s really tempting to create classes for your models. But in Typescript, which gets compiled down to plain old JavaScript, you spend a lot of your time dealing with JSON and plain old JavaScript objects (POJO). These don’t have methods. These don’t have private members. These don’t have constructors. You actually don’t need any of that. You just want type safety around your JSON and POJO. That’s why more often than not, you’re going to be using interface. I’m not saying never use classes. But don’t use classes to define models. Use classes for controllers.
- Epskampie 7y ago
  I still don't hear a good argument as to why you should't use classes for your model. I use [serializr](https://github.com/mobxjs/serializr https://github.com/mobxjs/serializr) to convert json to my classes, and afterwards I can have all the deligtful methods I want. :-) I love the code clarity this gives, methods are where they are most logical, instead of on some helper object.
  - 0XAFFE 7y ago
    There is also class-transformer[1] and class-validator[2] which also do the same job but integrate a bit better into the whole typescript cosmos. [1] https://github.com/typestack/class-transformer https://github.com/typestack/class-transformer [2] https://github.com/typestack/class-validator https://github.com/typestack/class-validator
  - Roboprog 7y ago
    Method implies use of this, which implies they are probably not first class - such would be functions cannot be passed or returned, as the this reference won’t be bound if called as a function.
- brlewis 7y ago
  There's a historical reason why classes are used a lot for models. It's up to you to decide if this reason applies to your project or organization. A few years ago there was a dilemma between ES6 and TypeScript. A lot of JS developers chose to stay away from TS in order to follow the ES6 path instead. Then TS harmonized with ES6. But it retained a reputation for being an incompatible alternative to ES6 rather than just JS+type annotations. However, if you write classes, they look just like ES6 classes plus type annotations, allaying concerns.
jillesvangurp 7y ago
Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. I've been in CTO type roles and already insist on it when I can. I don't think I'm alone in this and many organizations only do typescript at this point.
- collyw 7y ago
  I am a backed developer 90% of the time, but I currently have to work on a Typescript / React application that an agency did for us - cleaning up the bugs. Is there a good resource to demonstrate how to get around the problems you get with typing? At the moment I am using @ts-ignore to get things done. (Saying "you are probably doing it wrong" isn't really very helpful).
  - verttii 7y ago
    https://github.com/piotrwitek/react-redux-typescript-guide https://github.com/piotrwitek/react-redux-typescript-guide This is a good list of how to use common React patterns in Typescript.
    - collyw 7y ago
      That looks like the type of thing I am looking for. I'll have a read through it.
  - amoerie 7y ago
    Generally, try the following steps: - turn off strict flags, turn them on again after everything compiles in non strict mode - ensure you have the correct typings for the libraries you're using. Some libraries include them, others require a @typings/xyz dependency. (E.g. React and ReactDOM) - try to hunt down the root errors. Much like C# or Java, one error can lead to hundreds of compilation errors down the line, but fixing the first root error can also make all of them go away in one fell swoop. - try to keep things simple and non dynamic. Typescript is very flexible and powerful, but think twice before you use crazy constructs. - enable emitOnError. It will allow you to test while you refactor, even though typescript complains. - ask yourself: if it works and typescript does not compile, is it because typescript can't understand or is it because typescript is seeing possible issues you've not taken into account? - don't think of typescript as something to get around of. Think of it as a helping hand that will guide you in your daily work and prevent a whole swath of runtime errors, but it needs to be fed with information about your data structures and libraries to work properly.
bauerd 7y ago
I'm currently trying to revive a 2yrs old codebase written with TypeScript/React/Redux. I made the capital error of not checking in node_modules apparently or pinning versions (ie using yarn or npm shrinkwrap), as I now get tons and tons of type errors from dependencies on build. Problem seems to be that all the @types packages are somehow out of sync/broken/hell I don't know. I also don't have access to CI logs anymore so I can't figure out which versions it used to resolve to … The @types definition packages for react-router, redux-thunk, etc. give me "error TS2605: JSX element type X is not a constructor function for JSX element". Most popular answer on GitHub is to rm -rf node_modules and rebuild, however that does nothing for me. I tried upgrading some @types selectively and triple-double checked that the resolved versions make sense, but nothing so far. A codebase that used to build cleanly now throws ~30 errors on build, without any changes to it. Insane. Always pin your exact versions in JS land …
- kyranjamie 7y ago
  Did you have your types root set to `node_modules` in your `tsconfig.json`?
- towndrunk 7y ago
  Is there a package-lock.json checked in? If you can get the earliest version you may be able to find the versions there.
  - kabes 7y ago
    Probably not, since package lock files were only introduced 2 years ago.
- slig 7y ago
  I had similar errors using an updated TypeScript compiler on an older codebase. There was a lot of breaking changes between TS versions and you're either stuck with an older version or you have to upgrade everything (as @types packages aren't usually backported).
- siempreb 7y ago
  > now throws ~30 errors on build Yep, it's a beautiful technology, total type safe heaven. Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at the same time. I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly. Good luck with it anyways.
jjakque 7y ago
I've done 2 commercial Typescript + React projects so far (along with few side projects using what I knew that time + what I want to try). My experience been: - Discourage 'any' but not been afraid of using it when must. I think it as the 'technical debt spelled out': when you want to put down an 'any' and get on with what you're doing, by all mean, but remember its existence and make sure the team is well aware. If the usage going to persist (example, using a library without @type), then you treat it as JS and have appropriate amount of validation around the occurrence. - Usage of "?" and "!" covers more scopes with less lines of code. For hobby/one-man project, I found their usages no-brainer, however I'm nervous when it comes working in a team of various experience level. - I've had real headache typing API responses. On one hand, you have absolute no control of others' code quality that you might as well have "number | string | null | undefined" for all parameters. But doing that almost defeats the purpose of typing it, so I'll need to use my educated guesses and judge reliability of each known parameters in responses. - TypeScript version of 'create-react-app' projects builds slower than its JavaScript counterpart without ejecting. It took 2~6 seconds per build while IIRC, it was <2 seconds for JS. I was keen to find a solution for this, but after a while it grow on me and I simple stop save after each line of code. - JSDoc is still relevant in TS code. It is great to document event emitters, exceptions etc. - tslint and prettier are must in my projects in order to retain sanity for unnecessary discussions around coding style.
- whatever_dude 7y ago
  > tslint and prettier are must in my projects You're probably tired of hearing this by now, but ESLint is the "official" way to go with TS from this point on. It has better integration with Prettier too, since Prettier formatting differences shows as errors/warnings.. and you can share JS/TS rules if needed.
  - jjakque 7y ago
    Thanks for pointing this out. It's simply a matter of time of phasing into preferable setup, consider the current setup is 'not yet broken'.
- eropple 7y ago
namelosw 7y ago
React is more functional favored. It's very recommended for functional languages having static type systems, at least for language like JavaScript heavily relies on object literal. The problem is, dynamic OOP languages like Ruby and Python are Okay to work with, since you know the class of an object you know a lot of things (schema, behavior, etc). But for JavaScript and React, mutable classes are not quite useful since they mutate themselves, and could stop the app from re-rendering. it's more likely people are using object literals, which can hardly go far. With TypeScript's structural and gradual type system, it's flexible and easy enough to type object literals with the union and intersection types, without forcing people to use classes.
verttii 7y ago
Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive. My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.
- Epskampie 7y ago
  Verbose? Do not agree at all. Adding types to function parameters for example is just a simple ": TYPE" I do not see how that could be much shorter. Furthermore, where possible (variable assignment, function returns) types are inferred, and do not need to be specified at all, leaving you with mostly plain JS syntax.
  - verttii 7y ago
    No algebraic data types leads to having to add an additional discriminating union type key. Besides that, no type signatures without parameters and other things just produce a lot more code than you'd have in a nicer type system.
- eropple 7y ago
  I feel almost the exact opposite: TypeScript is delightfully terse while still achieving its main goal of looking and feeling like JavaScript. I've used languages where things start looking like line noise (hi, Scala) and I very strongly do not get that feeling out of TypeScript. You have discriminated unions and the compiler is clever about them, so you can implement ADTs if you want them with a little but not a nasty level of boilerplate. (They can also be implemented with an abstract class if that's more your bag.) It lacks pattern matching because it intentionally doesn't include a runtime component, which I think is also wise. Options exist if you want to use them. I've seen people use Purify to good effect.
  - verttii 7y ago
    I guess it depends on what you compare with. If you're coming from Java or the like, surely TS does not feel particularly verbose. However, coming from a truly terse language like Haskell you'll just feel TS is too verbose and not very elegant. TS is the most verbose and least elegant of the languages I'm personally using, on par with Dart. ADTs not only feel dirty because they're not first class citizens (you build them with the TS primitives by adding a discriminating union key) but also somewhat useless since you don't have pattern matching. Although pattern matching would not be a trivial problem to solve in TS. It could be solved with the compiler, however, you'd still have to hack the compiler API quite a bit too and TS doesn't even support integrating custom extensions with a config file like Babel does. Btw thanks for pointing me to that ts-purify, it looks good!
davidjnelson 7y ago
Typescript is awesome!!! The creator of it answers “why typescript” in a video[1] with a hilarious answer which includes his observation that large javascript codebases become read only :-D I’m giving a talk on typescript Friday. Some good stuff to understand is index signatures for object lookups, union types, intersection types, combining index signatures with named properties, and compile time immutability with readonly, Readonly<T>, ReadonlyArray<T>, ReadonlyMap<T>. The language is so much fun to both write and read. There’s a lot of depth to it as well. Excited to get to use it. 1. https://m.youtube.com/watch?v=wYgSiFaYSSo https://m.youtube.com/watch?v=wYgSiFaYSSo
- cryptica 7y ago
  >> javascript codebases become read only :-D This is BS. I've built very large JS projects with hundreds of thousands of lines and never had this problem. If your architecture is well designed and modular then refactorings are easy and localized to just a small number of files. On the other hand, TypeScript encourages spaghetti code which makes refactorings span more files; complex active instances end up getting passed around all over the place and makes your code brittle and fully dependent on TypeScript to make any changes. TypeScript allows you to write a lot of spaghetti code and allows you to delay having to think about architecture until your code is a total complete unmaintainable mess. With JS, you will discover if you architecture is a mess a lot sooner and you will learn more and adapt faster.
  - davidjnelson 7y ago
    Glad you enjoy large javascript projects and it works well for you. Architecture is important regardless of what language you are using.
    - cryptica 7y ago
      Thanks. I feel like there should be a lot less discussion about tools and a lot more discussion about architecture. I find that with good architecture, the language doesn't really matter at all. I've built high quality very complex projects in both JavaScript and TypeScript (both alone and as a team lead). My point is that I (and people of my skill level) can complete the project/subproject much faster with JavaScript so it gives me a lot more extra time to write tests.
izolate 7y ago
I get why TypeScript is quickly becoming the standard, but the problem with it is that it's still JavaScript, and contains all the warts thereof. If at some point your attention turns to the very real benefits of static typing, why not choose an objectively better language? That's why after ~10 years of being a JS/Node developer, I switched to Dart, not TypeScript.
lifeisstillgood 7y ago
I just want to stop using JS on the browser side. We can compile C to WASM, which gives us effectively most dynamic languages on the browser. Say Python. I have a plan to put a tiny web framework together just having Python doing the front end stuff. Not react or anythng but enough for "most" use cases (I know I know) But JS just feels like it changes too fast, its been well over a decade of wheel-reinventing when the fundamentals of tabular display, layout and so forth have to be relearnt every year or two.
- hombre_fatal 7y ago
  Meanwhile I think JS is one of the best dynamically programming languages and your post just feels like it's belaboring the same old Python vs Ruby or tabs vs spaces debates. Frankly I don't find any of the other client application platforms any more compelling than what we have with the web.
  - lifeisstillgood 7y ago
    I disagree. JS should be like SQL - everyone's second language and a standard that can be taken from job to job and company to company and still be effective. But while I this week used my decades old SELECT skills for a quick two day job, I have also been utterly stumped trying to modify react codebases. JQuery is probably the closest thing to SQL in the JS world and it is fine - but there appear to be few technical reasons not to use it and lots of fashion reasons. And so while I could just stick to JQuery and some widgets, the weight of development seems to be in the morass of change that is so very hard to stay on top of. Yes this feels like crotchety old timer moaning, even to me. But there is something there. I am having trouble expressing it however.
    - hombre_fatal 7y ago
      Client development was never trivial. Your old iOS/Android skills also expire due to SDK changes. Apple recently switched out the entire language you're using. I don't think SQL is a great example either. Your next company could be using any database where you aren't even writing SQL. And you're expected to know more than standard SQL to, say, use Postgres. Your rant here to me is like getting mad that "just SQL" isn't enough because you constantly have to learn more at your next job that uses Postgres, DynamoDB, etc or that "just <language>" isn't enough because your next job uses a different framework than you're used to. I don't think your rant is consistent, so it just comes off as confused anger towards JS client development. Maybe you don't have the stomach for client development where code must run on a machine you don't control? That isn't a disparaging remark either, it's very reasonable to prefer the cozier environment of writing code for machines you do control (like application servers).
greenpizza13 7y ago
In 2019 is this article adding anything to our collective knowledge? There's nothing new here at all.
yenwel 7y ago
The whole discussion of typed vs untyped is stupid. Types and structures are all around us (albeit simple or infinitely complex, eg inductive vs coinductive). It is rather a discussion about typesystems that check type constraints immediately before shipping and/or after shipping while running the program. Without a proper typesystem the programmer has to check the types in his mind, or the end user gets a runtime error. For small hacks or prototyping type checking is not really required because of low overhead. But in non trivial larger, long running systems with a lot of maintenance the cognitive overhead is too big to not use a typechecker. Even if you decompose in microservices or microfrontends you still stuff like schema definitions and IDLs. Even hardcore ecmascript evangelists use linters extensively before shipping (potatoe/potato linter/typechecker)...

225 points by skn0tt 7y ago

wintorez 7y ago

“TypeScript solves problems that I don’t have, in a way that I don’t like.”

JoeyJoJoJr 7y ago
What are the problems that Typescript solves that you don’t have?

hki99 7y ago

During my internship we've built a large prototype using React+Typescript, and here are some of my key take aways from it: - Quite often when using unreleased APIs, you turn to using "any" all over the place. - Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features). - Lots of frustration when a package doesn't have types (although most major ones do have them). Otherwise it has been a joy writing the application, and it does "document" your components significantly better.

latchkey 7y ago
Development time isn't slower when you factor in all the bugs it saves you from dealing with down the road when you're either wonder what is the type of an object or why something isn't working during runtime that a compiler could have caught.
- a_wild_dandan 7y ago
  Also, if you're working with an untyped APIs, define the types you're using. It doesn't have to be complete or perfect. But having that formal contract will save you time and make explicit your assumptions. In the best case, you can contribute those types to the API to everyone's benefit.
altschuler 7y ago
Beyond a certain size and complexity (which is not that much), I find that the argument of typescript (and other typed languages) being less productive than untyped dynamic ones, is not true when you look at it as a whole. It might feel slower, especially to begin with, but once you get used to the language and semantics you save a vast amount of time, by the bugs you _don't_ debug and by not having to jump through the code all the time to find out what that function or module was called or what parameters it accepted. This of course is less true if you're using a lot of untyped packages, but as you said, most do have types either natively or in the DefinitelyTyped project. For most modules it's also feasible to declare the module typings manually, even doing it gradually for the parts that you happen to need at a given time.
ghego1 7y ago
IMHO TypeScript saves a lot of time as soon as any project grows over few thousands lines of code. I'm working on a large project in which both backend and frontend are in JavaScript (node+PWA) and without TS it would have been close to impossible to proceed at the speed we did. Thanks to TS we easily know what types must be passed between client and server, and we can easily refactor or edit code without worrying that some mis-type somewhere will brake things. We don't use any anywhere (literally), it's not trivial, but as soon as you get to know TS well enough it's absolutely feasible, at least since TS 3.x.
andyhmltn 7y ago
>- Quite often when using unreleased APIs, you turn to using "any" all over the place. What unreleased APIs are you needing to warrant this? We've used any a couple times, but usually just as a placeholder until the data model is locked down. >- Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features). Again, I can't say I've had this experience. Development time is _initially_ a tiny bit slower, but once you've setup types, the time saved from fixing type related issues adds up very very fast. Also, autocomplete / autoimporting has actually sped up my development time hugely. Not having to worry about figuring out relative paths or imports and just being able to type a component to import it is magic. >- Lots of frustration when a package doesn't have types (although most major ones do have them). This is true, but I've found that 95% of the packages we use do have types. The few that don't, tend to be very small indie packages that don't do a lot, so the lack of types isn't a huge issue.
aquadrop 7y ago
I think the threshold of when Typescript starts being helpful is reached very quickly. Because there's always some schema in code, yes you can assign any value in JS, but then you have to remember it and account it in other code etc. There's always some schema, you just have to keep it in your head. And with TS I can offload it to the code/IDE to help me. I want to make decision about shape of an object in the moment I'm creating that abstraction or when I'm looking specifically at it deciding if it needs to be changed. I don't want to be forced to remember all those decisions all the time. If some prototype code or script is couple of screens long, sure you can easily fit it in your head and maybe you don't need additional assistance, but when it grows larger, pretty quickly it's very nice to separate process of thinking over shape of objects and process of using them.
Vinnl 7y ago
Interesting. There are downsides to using TypeScript (build chain complexity is the major one for me, although that's getting less and less relevant as more and more tools gain native TypeScript support), but the three you mention are not relevant to me. - I don't know what unreleased API's you're referring to, but I generally haven't seen the need to use them - if they're unreleased, I try to avoid them. - Especially for projects with fast iterations, TypeScript has been massively useful. Changing the API around, which I do often at the start of a project, is just so much easier when you've got TypeScript to make most of the required changes, or to tell you where you have to make changes. - Type availability might be a problem, but I also generally stick to major packages for which it's not. But yes, I have learned to contribute to DefinitelyTyped - which luckily is a relatively smooth process.
joshAg 7y ago
The way we've been using typescript is that when you're first implementing the API using 'any' is just fine, but it's not ready for release until all the 'any's are removed. What I've found is that there tends to be a happy medium between making everything 'any' at the start and never using 'any' at all that roughly corresponds to how defined our implementation is. When we're designing the implementation as we go, there tends to be lots of 'any', but when we spent time defining the interfaces, there's not as much need for using 'any', because instead there's a specific type. The type itself usually doesn't remain static, but where it's used does. So for example, when we're adding a rest endpoint, when we know the required and optional arguments/response, we can make a type and validator function and then there's not really a need for 'any' after the validation function, but if we don't know what the arguments/response will be (or the design is still at the 'make every argument optional' stage), then any sort of prototype will be littered with 'any' or '{[key: string]: any}' types.
- no_wizard 7y ago
  I'm curious, and I'm prefacing this up front because I'm not always good at writing what I say in a way that may not feel like I'm coming from a good place, so here goes: Whats your testing story? This to me seems like not writing good, solid, abstracted tests before doing proper implementations of your code. This could be solved with good interface design, and perhaps be faster. I apologize in advance if this sounds harsh. This sounds like the exact thing folks on my team were trying to do, and it was turning things very sub-optimal. (Disclaimer: I'm a bit of a TDD/BDD idealogue. Not as hardcore as Uncle Bob[0], certainly, but close enough. I think writing Interfaces before Tests is acceptable, I think that might be where things differ, i guess). [0]https://blog.cleancoder.com/ https://blog.cleancoder.com/
  - joshAg 7y ago
    At least for interfaces between different modules/layers of abstraction, we use BDD almost exclusively. Our docs tend to be very well defined, so 'any' isn't actually used that often. We focus on end-to-end testing over unit and integration tests, which for the REST API backend means only looking at the request, the response, and the side-effects (especially db writes). For us the docs/spec comes first and then tests, implementation, and consumer use can (and does) happen in parallel. The REST API is defined using OpenAPI v3, and we use express-openAPI to generate request and response validator functions for every endpoint. Each endpoint needs a happy-path test for 1) every optional argument supplied and 2) none of the optional arguments supplied (if there's no optional arguments then this devolves into a single test), and all side-effects must be verified. The main place where we use 'any' or {[key: string]: any} and then just cast to what's expected tends to be the responses from the database, because the response validation code will catch any actual mismatches (the most common mismatch is forgetting to parseInt and trying to send back something like '1' instead of 1, but sometimes there's issues with the db field being nullable when it shouldn't or not nullable when it should be nullable). Here's the latest test run on master (hope the formatting works): ---------------------------------------------------------------|----------|----------|----------|----------|-------------------| File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s | ---------------------------------------------------------------|----------|----------|----------|----------|-------------------| All files | 82.89 | 63.56 | 86.38 | 82.86 | | Branches are especially low, because we don't test most unhappy paths since we use a middleware error handler with generic error messages for different types of errors that's got something like >90% coverage instead of handling errors within each endpoint. The unhappy paths we do test thoroughly are things like our user-defined typeguards, our middleware error handler, our security handlers, and anything else where we validate unsafe/unknown inputs. We try to stay away from stringent TDD/BDD unit testing, because 1) the reward from the work required to get there doesn't justify the cost of getting there for us right now and 2) strict BDD/TDD unit testing makes it much harder and slower to try different implementations/refactor things, since every time you want to modify one-off helper functions you need to add a bunch of tests first. We found that cost is worth it at module boundaries (eg endpoints, auth, database), but not for most functions that are only ever called inside their module.
verletx64 7y ago
I’d recommend using ‘unknown’ over ‘any’, it’s truer to the code you’d probably end up writing if it was vanilla JS; fairly defensive stuff. On top of that don’t be hesitant to define ad hoc interfaces on your side of things; ultimately ‘any’ communicates zero information and provides zero defence. The more I start to use other techniques the more I feel that ‘any’ really should be the last escape hatch deployed.

manishsharan 7y ago

If you are going to learn a new programming language for web UI, why not go for Elm ? You get so much more than just static types with Elm.

millstone 7y ago
JavaScript interop I suppose. TypeScript allows incremental integration with other JS libraries, while Elm forces an awkward ports/messaging abstraction.
iraldir 7y ago
Looked at Elm and it looks quite interesting. however concerns for going to it - Skill transfer. If I learn react, I can use my JavaScript skill to understand how everything works under the hood. If I learn Typescript with React, knowing react, I can focus on learning new language feature while not learning at the same time how to build the application. With Elm, I have to learn the language and the framework, all at once, basically learning from scratch. - compatibilities with libraries. Here I definitely might be wrong, not knowing Elm enough, but okay, say you don't need a framework because it's included. What about utility library. Like i don't know, analytics or fancy animations? - Job Market. I'm not going to learn a language that I cannot use anywhere, and if I'm a company, I'm not going to choose a language for which is going to be hard to hire people. Now Elm sounds real cool and I want to like it. But it doesn't seem very wise to spend time doing that vs learning something like Apollo+Graphql, or Typescript, or Vue, which have much more obvious benefits to my career.
- manishsharan 7y ago
  The job market is a chicken and egg type problem. Management would not allow Elm based projects as there are no othe Em programmers on staff. We cant ask for Elm programmig experience in resumes as we dont have any Elm based projects. I wonder how other languages,like Scala, managed to get traction in the enterprise whereas Elm has not even though it can solve real issues that we face with Javascript development.
  - 7y ago

rimher 7y ago

I see the same response everywhere on TypeScript: when a project becomes big enough, it's a good way to keep it under control. And I tend to agree: types can be annoying, but when stability and robustness come into play, TypeScript is most certainly the way to go. It enforces good behavior. And yeah, of course it slows JavaScript down, that's entirely the point..! JS allows you to do whatever you want, but that doesn't mean it's always the right choice

robmoorman 7y ago

React is already typed with props. I see no added use for TypeScript. Yet another list of packages makes maintaining very hard and inconsistent (as types are declared in variant ways). Explicit (and simple) functions as React (e.g. hooks) provides won't need strongly typed code, less readability in my opinion. If you're building a library / sdk, than Typescript comes in place and can make life easier for devs.

PunchTornado 7y ago
I don't understand. How would you strongly type every function and state variable in react without typescript?
underwater 7y ago
PropTypes are disabled for production builds and runtime only. The only advantage for using them over TypeScript or Flow that I've seen is when consuming third party React components. Otherwise the guarantees, feedback loop and terseness of static types are superior to PropTypes.

holografix 7y ago

For typescript to be very useful to indispensable the tooling needs to improve. If there was a checkbox on VSC that said “use typescript” for a project and I had to do nothing else for it to work then sure, I’d use it. For a single dev working on a fairly simple React + Redux app it’ll slow you down like no tomorrow.

onion2k 7y ago
What you're asking for mostly exists. You don't even need a checkbox. TypeScript support has been included with create-react-app since v2.1.0, with all the features enabled. VS Code ships with syntax highlighting and command completion for TS. If you want to try it use; npx create-react-app tsx-test yarn add typescript @types/react mv ./src/App.js ./src/App.tsx yarn start (WARNING: npx runs stuff from the internet on your machine) That will make a 'typescript' React app run on your machine. Obviously App.tsx isn't actually doing any TypeScript stuff, but if you add some it will work.
- wereHamster 7y ago
  Even simpler, see https://create-react-app.dev/docs/adding-typescript https://create-react-app.dev/docs/adding-typescript npx create-react-app my-app --typescript
- resurge 7y ago
  Note that they said "React + Redux". And that combo indeed takes a lot more time to get set up and understand the first time. I used this lib to get it to work: https://www.npmjs.com/package/typesafe-actions https://www.npmjs.com/package/typesafe-actions I wouldn't even know how to get it to work with just the regular react & redux types.
  - onion2k 7y ago
    typesafe-actions looks useful but you don't strictly need it. You can use redux with TS just by adding @types/react-redux. https://redux.js.org/recipes/usage-with-typescript#usage-with-react-redux https://redux.js.org/recipes/usage-with-typescript#usage-wit...

h0h0h0h0111 7y ago

I've been writing Typescript with React for quite a while now and these are my feelings so far: - Typescript type system is pretty awesome, and allows the expression of some things really elegantly; in particular, string literal types are quite cool for component props that feel "htmly", union and intersection types are great for making reusable/generic components and Partial<T> is cool for making typesafe component states (https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... is a great resource) - on a related note, the Typescript docs are very comprehensive - ... but docs for anything React related to Typescript (types of components, etc) are harder to come by - for the actual UI code there is some time wasted getting type signatures perfectly correct, particularly for React and HTML components, but I've built up a bank of helper functions in this regard. - using `any` nearly always comes back to bite you as you trick yourself into feeling typesafe - there is always a tradeoff between having perfectly exact types and not writing 139587123598 interfaces; expressing, for instance, mapStateToProps, mapDispatchToProps and mergeProps to compose into component props, or the former as a subtype the latter is pretty fiddly to get right and imo not worth the extra code - create-react-app typescript support has gotten pretty good now, but it's nigh-impossible to step outside their boundaries. For me, some older features of typescript I wanted that protobufjs generated typescript used was just not usable and I had to work around that with great difficulty - nearly all packages now have type definitions for them which is sick - at the end of the day, you can still resort to vanilla JS where typescript really, really gets in the way

fabian2k 7y ago
> ... but docs for anything React related to Typescript (types of components, etc) are harder to come by I just saw this linked today and didn't look it through entirely, but this React+Typescript cheat sheet looks very interesting for React-specific issues you might encounter with Typescript: https://github.com/typescript-cheatsheets/react-typescript-cheatsheet https://github.com/typescript-cheatsheets/react-typescript-c... For example it explained an issue with the type inference for custom hooks that confused me somewhat earlier. I really like Typescript so far, but you can easily encounter situations that are hard to figure out with only basic Typescript knowledge, especially when interacting with more complex libraries. This probably gets better with more Typescript experience, but it can be a serious speed bump as a Typescript beginner.

jinushaun 7y ago

Disappointed that the article alluded to but never explains why classes should be avoided in Typescript. (Which I agree, btw) If you’re used to classes, it’s really tempting to create classes for your models. But in Typescript, which gets compiled down to plain old JavaScript, you spend a lot of your time dealing with JSON and plain old JavaScript objects (POJO). These don’t have methods. These don’t have private members. These don’t have constructors. You actually don’t need any of that. You just want type safety around your JSON and POJO. That’s why more often than not, you’re going to be using interface. I’m not saying never use classes. But don’t use classes to define models. Use classes for controllers.

Epskampie 7y ago
I still don't hear a good argument as to why you should't use classes for your model. I use [serializr](https://github.com/mobxjs/serializr https://github.com/mobxjs/serializr) to convert json to my classes, and afterwards I can have all the deligtful methods I want. :-) I love the code clarity this gives, methods are where they are most logical, instead of on some helper object.
- 0XAFFE 7y ago
  There is also class-transformer[1] and class-validator[2] which also do the same job but integrate a bit better into the whole typescript cosmos. [1] https://github.com/typestack/class-transformer https://github.com/typestack/class-transformer [2] https://github.com/typestack/class-validator https://github.com/typestack/class-validator
- Roboprog 7y ago
  Method implies use of this, which implies they are probably not first class - such would be functions cannot be passed or returned, as the this reference won’t be bound if called as a function.
brlewis 7y ago
There's a historical reason why classes are used a lot for models. It's up to you to decide if this reason applies to your project or organization. A few years ago there was a dilemma between ES6 and TypeScript. A lot of JS developers chose to stay away from TS in order to follow the ES6 path instead. Then TS harmonized with ES6. But it retained a reputation for being an incompatible alternative to ES6 rather than just JS+type annotations. However, if you write classes, they look just like ES6 classes plus type annotations, allaying concerns.

jillesvangurp 7y ago

Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used by default over untyped javascript in professional environments. It's like having tests, which are also not generally considered optional. I've been in CTO type roles and already insist on it when I can. I don't think I'm alone in this and many organizations only do typescript at this point.

collyw 7y ago
I am a backed developer 90% of the time, but I currently have to work on a Typescript / React application that an agency did for us - cleaning up the bugs. Is there a good resource to demonstrate how to get around the problems you get with typing? At the moment I am using @ts-ignore to get things done. (Saying "you are probably doing it wrong" isn't really very helpful).
- verttii 7y ago
  https://github.com/piotrwitek/react-redux-typescript-guide https://github.com/piotrwitek/react-redux-typescript-guide This is a good list of how to use common React patterns in Typescript.
  - collyw 7y ago
    That looks like the type of thing I am looking for. I'll have a read through it.
- amoerie 7y ago
  Generally, try the following steps: - turn off strict flags, turn them on again after everything compiles in non strict mode - ensure you have the correct typings for the libraries you're using. Some libraries include them, others require a @typings/xyz dependency. (E.g. React and ReactDOM) - try to hunt down the root errors. Much like C# or Java, one error can lead to hundreds of compilation errors down the line, but fixing the first root error can also make all of them go away in one fell swoop. - try to keep things simple and non dynamic. Typescript is very flexible and powerful, but think twice before you use crazy constructs. - enable emitOnError. It will allow you to test while you refactor, even though typescript complains. - ask yourself: if it works and typescript does not compile, is it because typescript can't understand or is it because typescript is seeing possible issues you've not taken into account? - don't think of typescript as something to get around of. Think of it as a helping hand that will guide you in your daily work and prevent a whole swath of runtime errors, but it needs to be fed with information about your data structures and libraries to work properly.

bauerd 7y ago

I'm currently trying to revive a 2yrs old codebase written with TypeScript/React/Redux. I made the capital error of not checking in node_modules apparently or pinning versions (ie using yarn or npm shrinkwrap), as I now get tons and tons of type errors from dependencies on build. Problem seems to be that all the @types packages are somehow out of sync/broken/hell I don't know. I also don't have access to CI logs anymore so I can't figure out which versions it used to resolve to … The @types definition packages for react-router, redux-thunk, etc. give me "error TS2605: JSX element type X is not a constructor function for JSX element". Most popular answer on GitHub is to rm -rf node_modules and rebuild, however that does nothing for me. I tried upgrading some @types selectively and triple-double checked that the resolved versions make sense, but nothing so far. A codebase that used to build cleanly now throws ~30 errors on build, without any changes to it. Insane. Always pin your exact versions in JS land …

kyranjamie 7y ago
Did you have your types root set to `node_modules` in your `tsconfig.json`?
towndrunk 7y ago
Is there a package-lock.json checked in? If you can get the earliest version you may be able to find the versions there.
- kabes 7y ago
  Probably not, since package lock files were only introduced 2 years ago.
slig 7y ago
I had similar errors using an updated TypeScript compiler on an older codebase. There was a lot of breaking changes between TS versions and you're either stuck with an older version or you have to upgrade everything (as @types packages aren't usually backported).
siempreb 7y ago
> now throws ~30 errors on build Yep, it's a beautiful technology, total type safe heaven. Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at the same time. I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly. Good luck with it anyways.

jjakque 7y ago

I've done 2 commercial Typescript + React projects so far (along with few side projects using what I knew that time + what I want to try). My experience been: - Discourage 'any' but not been afraid of using it when must. I think it as the 'technical debt spelled out': when you want to put down an 'any' and get on with what you're doing, by all mean, but remember its existence and make sure the team is well aware. If the usage going to persist (example, using a library without @type), then you treat it as JS and have appropriate amount of validation around the occurrence. - Usage of "?" and "!" covers more scopes with less lines of code. For hobby/one-man project, I found their usages no-brainer, however I'm nervous when it comes working in a team of various experience level. - I've had real headache typing API responses. On one hand, you have absolute no control of others' code quality that you might as well have "number | string | null | undefined" for all parameters. But doing that almost defeats the purpose of typing it, so I'll need to use my educated guesses and judge reliability of each known parameters in responses. - TypeScript version of 'create-react-app' projects builds slower than its JavaScript counterpart without ejecting. It took 2~6 seconds per build while IIRC, it was <2 seconds for JS. I was keen to find a solution for this, but after a while it grow on me and I simple stop save after each line of code. - JSDoc is still relevant in TS code. It is great to document event emitters, exceptions etc. - tslint and prettier are must in my projects in order to retain sanity for unnecessary discussions around coding style.

whatever_dude 7y ago
> tslint and prettier are must in my projects You're probably tired of hearing this by now, but ESLint is the "official" way to go with TS from this point on. It has better integration with Prettier too, since Prettier formatting differences shows as errors/warnings.. and you can share JS/TS rules if needed.
- jjakque 7y ago
  Thanks for pointing this out. It's simply a matter of time of phasing into preferable setup, consider the current setup is 'not yet broken'.
eropple 7y ago

namelosw 7y ago

React is more functional favored. It's very recommended for functional languages having static type systems, at least for language like JavaScript heavily relies on object literal. The problem is, dynamic OOP languages like Ruby and Python are Okay to work with, since you know the class of an object you know a lot of things (schema, behavior, etc). But for JavaScript and React, mutable classes are not quite useful since they mutate themselves, and could stop the app from re-rendering. it's more likely people are using object literals, which can hardly go far. With TypeScript's structural and gradual type system, it's flexible and easy enough to type object literals with the union and intersection types, without forcing people to use classes.

verttii 7y ago

Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive. My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

Epskampie 7y ago
Verbose? Do not agree at all. Adding types to function parameters for example is just a simple ": TYPE" I do not see how that could be much shorter. Furthermore, where possible (variable assignment, function returns) types are inferred, and do not need to be specified at all, leaving you with mostly plain JS syntax.
- verttii 7y ago
  No algebraic data types leads to having to add an additional discriminating union type key. Besides that, no type signatures without parameters and other things just produce a lot more code than you'd have in a nicer type system.
eropple 7y ago
I feel almost the exact opposite: TypeScript is delightfully terse while still achieving its main goal of looking and feeling like JavaScript. I've used languages where things start looking like line noise (hi, Scala) and I very strongly do not get that feeling out of TypeScript. You have discriminated unions and the compiler is clever about them, so you can implement ADTs if you want them with a little but not a nasty level of boilerplate. (They can also be implemented with an abstract class if that's more your bag.) It lacks pattern matching because it intentionally doesn't include a runtime component, which I think is also wise. Options exist if you want to use them. I've seen people use Purify to good effect.
- verttii 7y ago
  I guess it depends on what you compare with. If you're coming from Java or the like, surely TS does not feel particularly verbose. However, coming from a truly terse language like Haskell you'll just feel TS is too verbose and not very elegant. TS is the most verbose and least elegant of the languages I'm personally using, on par with Dart. ADTs not only feel dirty because they're not first class citizens (you build them with the TS primitives by adding a discriminating union key) but also somewhat useless since you don't have pattern matching. Although pattern matching would not be a trivial problem to solve in TS. It could be solved with the compiler, however, you'd still have to hack the compiler API quite a bit too and TS doesn't even support integrating custom extensions with a config file like Babel does. Btw thanks for pointing me to that ts-purify, it looks good!

davidjnelson 7y ago

Typescript is awesome!!! The creator of it answers “why typescript” in a video[1] with a hilarious answer which includes his observation that large javascript codebases become read only :-D I’m giving a talk on typescript Friday. Some good stuff to understand is index signatures for object lookups, union types, intersection types, combining index signatures with named properties, and compile time immutability with readonly, Readonly<T>, ReadonlyArray<T>, ReadonlyMap<T>. The language is so much fun to both write and read. There’s a lot of depth to it as well. Excited to get to use it. 1. https://m.youtube.com/watch?v=wYgSiFaYSSo https://m.youtube.com/watch?v=wYgSiFaYSSo

cryptica 7y ago
>> javascript codebases become read only :-D This is BS. I've built very large JS projects with hundreds of thousands of lines and never had this problem. If your architecture is well designed and modular then refactorings are easy and localized to just a small number of files. On the other hand, TypeScript encourages spaghetti code which makes refactorings span more files; complex active instances end up getting passed around all over the place and makes your code brittle and fully dependent on TypeScript to make any changes. TypeScript allows you to write a lot of spaghetti code and allows you to delay having to think about architecture until your code is a total complete unmaintainable mess. With JS, you will discover if you architecture is a mess a lot sooner and you will learn more and adapt faster.
- davidjnelson 7y ago
  Glad you enjoy large javascript projects and it works well for you. Architecture is important regardless of what language you are using.
  - cryptica 7y ago
    Thanks. I feel like there should be a lot less discussion about tools and a lot more discussion about architecture. I find that with good architecture, the language doesn't really matter at all. I've built high quality very complex projects in both JavaScript and TypeScript (both alone and as a team lead). My point is that I (and people of my skill level) can complete the project/subproject much faster with JavaScript so it gives me a lot more extra time to write tests.

izolate 7y ago

I get why TypeScript is quickly becoming the standard, but the problem with it is that it's still JavaScript, and contains all the warts thereof. If at some point your attention turns to the very real benefits of static typing, why not choose an objectively better language? That's why after ~10 years of being a JS/Node developer, I switched to Dart, not TypeScript.

lifeisstillgood 7y ago

I just want to stop using JS on the browser side. We can compile C to WASM, which gives us effectively most dynamic languages on the browser. Say Python. I have a plan to put a tiny web framework together just having Python doing the front end stuff. Not react or anythng but enough for "most" use cases (I know I know) But JS just feels like it changes too fast, its been well over a decade of wheel-reinventing when the fundamentals of tabular display, layout and so forth have to be relearnt every year or two.

hombre_fatal 7y ago
Meanwhile I think JS is one of the best dynamically programming languages and your post just feels like it's belaboring the same old Python vs Ruby or tabs vs spaces debates. Frankly I don't find any of the other client application platforms any more compelling than what we have with the web.
- lifeisstillgood 7y ago
  I disagree. JS should be like SQL - everyone's second language and a standard that can be taken from job to job and company to company and still be effective. But while I this week used my decades old SELECT skills for a quick two day job, I have also been utterly stumped trying to modify react codebases. JQuery is probably the closest thing to SQL in the JS world and it is fine - but there appear to be few technical reasons not to use it and lots of fashion reasons. And so while I could just stick to JQuery and some widgets, the weight of development seems to be in the morass of change that is so very hard to stay on top of. Yes this feels like crotchety old timer moaning, even to me. But there is something there. I am having trouble expressing it however.
  - hombre_fatal 7y ago
    Client development was never trivial. Your old iOS/Android skills also expire due to SDK changes. Apple recently switched out the entire language you're using. I don't think SQL is a great example either. Your next company could be using any database where you aren't even writing SQL. And you're expected to know more than standard SQL to, say, use Postgres. Your rant here to me is like getting mad that "just SQL" isn't enough because you constantly have to learn more at your next job that uses Postgres, DynamoDB, etc or that "just <language>" isn't enough because your next job uses a different framework than you're used to. I don't think your rant is consistent, so it just comes off as confused anger towards JS client development. Maybe you don't have the stomach for client development where code must run on a machine you don't control? That isn't a disparaging remark either, it's very reasonable to prefer the cozier environment of writing code for machines you do control (like application servers).

greenpizza13 7y ago

In 2019 is this article adding anything to our collective knowledge? There's nothing new here at all.

yenwel 7y ago

The whole discussion of typed vs untyped is stupid. Types and structures are all around us (albeit simple or infinitely complex, eg inductive vs coinductive). It is rather a discussion about typesystems that check type constraints immediately before shipping and/or after shipping while running the program. Without a proper typesystem the programmer has to check the types in his mind, or the end user gets a runtime error. For small hacks or prototyping type checking is not really required because of low overhead. But in non trivial larger, long running systems with a lot of maintenance the cognitive overhead is too big to not use a typechecker. Even if you decompose in microservices or microfrontends you still stuff like schema definitions and IDLs. Even hardcore ecmascript evangelists use linters extensively before shipping (potatoe/potato linter/typechecker)...