Typed brings a new level of sanity to web development. Better autocomplete, refactoring with a lot more confidence, — having a typechecker is great. There’s several typed language flavours that transpile to javascript. There’s TypeScript, Flow, Elm, ClojureScript, Reason, Kotlin, etc. Most of them, is TypeScript. Javascript less bugs popular While I think TypeScript is great — it’s not all sunshine and rainbows. Here’s the four biggest challenges I see TypeScript facing in the future. Configuring TypeScript can be overwhelming This is a general problem in the JavaScript world. Build systems are easy to figure out for newcomers. Webpack being impossible to configure is a running joke, and there’s also babel — and now TypeScript, which comes with its own setup difficulties. not I think that this labyrinth of complexity is one of the reasons opinionated build tools with no configuration like the angular cli, Create React App, and ParcelJS is gaining momentum. While TypeScript has some reasonably sane defaults, there’s still (count ’em) compiler flags in the file that gets created when setting up a project. Now, most of them have reasonably sane defaults, and a lot of them are added to prevent breaking changes - but after having helped debug my share of faulty files, I can tell you people get it wrong. 54 tsconfig.json tsconfig definitely All 54 of them! Now it’s definitely helped that the is generated with every flag as a comment, so it’s possible to see what knobs to turn, but it can still be overwhelming to figure out what JavaScript target to use, what module system to use, what libraries to include, etc. tsconfig.json Fitting TypeScript into the JS ecosystem Now while TypeScript comes with some configuration options, the complexities really start to explode when you want to combine it with the other build tools. Let’s assume we want to use TypeScript in our webpack build-pipeline. We do that using a loader, but should we use or ? Or should we just run and then use the compiled output and feed that into webpack? ats ts-loader "tsc --watch" Each of the webpack loaders comes with its own set of options. has 18 settings and has 19 different options. ats ts-loader But perhaps we should not use a TypeScript loader at all? Babel 7 has TypeScript support — it’s still in beta, but a lot of large projects use it already and it seems stable. However the babel TypeScript support is limited in some things you use rarely (const enums and namespaces being the big two) — so is that a tradeoff you’re willing to make for extra simplicity? knows how it feels @iamdevloper And then you of course need to make it work with your testing framework as well — has as a preprocessor for TypeScript, but that also has limitations and some 10-odd configuration options. And you better make sure that it’s configured the same way as your typescript-loader above, or you’ll run into inconsistencies that are very hard to debug. Jest ts-jest All of this is perfectly doable, and it doesn’t take me long to set up typescript projects nowadays, but I’ve spent hours, and I’ve been burned times to figure out what’s going on. It can definitely be difficult to get started. many many Type-system error messages are cryptic While the TypeScript goal is to type JavaScript as-is, this can be difficult considering how extremely dynamic JavaScript is. A task like that requires a complex type-system as the real life scenarios it has to type are very complex. The good part is, that the TypeScript type-system is full-featured, and you can do some amazing things with it. very The bad part is, that when it doesn’t work — it can be absolutely impossible to figure out what the hell is going on. Consider conversation I had on twitter some time ago: this had done some cool work with conditional types: @michlbrmly The specifics aren’t terribly important, but using some clever type-system magic it defines an object that contain both translate-able and non-translatable key for localization. The first thing to notice here, is that while these types are very clever — they’re also clever enough that even with comments describing them, I have a hard time figuring what’s going on. Now, the second problem is — if a library used these typings, and you specified a wrong type. This is the error message you would get: So.. what exactly is wrong here? It’s definitely impossible to tell from the error message. And this is not an isolated case, I’ve tried error messages like these before with react-redux among other things. It is a real fear to me, that as the type-system grows in complexity, at some point it will be so complicated as to be useless. If you can’t figure out what the types are telling you, they’re not helping as much as they’re just a gatling gun of incomprehensible error messages. TypeScript 3.0 has on , so hopefully this is something the team has their eye on. better error messages the roadmap Ecosystem fragmentation React Native 0.56 includes this snippet in their changelog “We’re migrating away from PropTypes and runtime checks and instead relying on Flow. You’ll notice many improvements related to Flow in this release.” With the several variants of transpile-to-js languages above, I think there’s a real risk of ecosystem fragmentation. “This library only has TypeScript types. Well? this one can only be used typed if you’re using Flow. But I’m using ReasonML, what should I do?” I think there’s a lot of duplicate effort currently typing the same libraries for interop between the different dialects of JavaScript. There’s no easy solution to this, as a type-system found in e.g. Kotlin can’t use types from TypeScript out of the box, as the type-system in Kotlin isn’t dynamic enough to understand things like mapped types. I think it makes sense for the good of the ecosystem, to consider whether we need some sort of standard type-format, just like we have with source-maps. It’s probably not going to be as complex as the TypeScript typings, but that’s probably also fine — most libraries don’t have typings that complex anyway, I think it’d be a tragedy if we ended up in different walled, typed gardens though. Boundary type-checking One of the stated goals of TypeScript is : non-goals this “ Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.” I think this has both pros and cons. For the most part — this is fine. There’s a few places where you’d want to use type information inside your app, dependency injection probably being the biggest. However this is solved in things like Angular and through using the experimental flag. InversifyJS emitDecoratorMetaData However, the big one where this would really help is with type-checking at the boundaries of your app. In most typed languages, you’re able to express that you’re accepting a request with an object that has X shape. In TypeScript, you can of course do the same — but as the type-information does nothing at run-time, there’s no way to ensure that the type you say you’re expecting is actually the one you get. If you care about the structure of the object, you’re going to need to specify it at run-time using something like or , but this requires you to specify types in a way, that is, in my opinion a lot less elegant than a TypeScript interface. class-validators io-ts Now TypeScript is actually doing something in regards to boundary-checking with the new top-type — which is basically a type we know nothing about. You can accept a boundary object with the type - and you’re then forced to at run-time check what type it actually is. unknown unknown I still think something like a run-time check, ala would make sense for TypeScript. Something like a keyword or a function that compiled to a function, that ensured that the object was actually the stated type. flow-runtime "validate" “validateType()” Though as this is explicitly against the design-goals, I probably wouldn’t hold my breath for this one — we’ll have to do with for now. unknown Do you see any other problems typescript is facing, or do you disagree with some of these? Reach out at @GeeWengel
