Friends don't let their friends write TypeScript

So I was reading a reddit thread, and I decided that instead of responding to one of the commenters pronouncing his endearment to TypeScript, I am just going to blog about it instead, because I really think this needs to be out there.

According to the Ionic framework, they claim the following benefits of TypeScript since their work is primarily in the AngularJS space.  I am going to respond to each and explain why using TypeScript is going to not only ruin your day, but waste your company's money and put your job at risk.

So here are the Pros:

• Optional static types
• Type Inference
• Access to ES6 and ES7 features, before they become supported by major browsers
• The ability to compile down to a version of JavaScript that runs on all browsers
• IntelliSense

 Optional static types.

This is a feature of JavaScript not TypeScript. And in fact, TypeScript is still catching up on a lot of what plain old javascript already offers. How can you consider this an advantage when all you're doing is giving the engineer what they would have had without your superset already?


Type inference.

Ok, I'll get into the "types" issue in bullet five, but that aside.. How does this strengthen the TypeScript case?  All I have to say is.. again. JavaScript already does this. You don't need a superset. You're adding paperwork to the process where it simply is not necessary.

Cheating ES6/7
I find the "Access to ES6 and ES7 features before they become supported" as a very dubious claim, since essentially TS is a superset of ES6, ES7, so the *only* features they can possibly add are syntactic sugar. Sugar that you likely wouldn't need unless you're already using TS.

Browser Compatibility
Ok look. The vast majority of browser compatibility issues have absolutely nothing to do with the ECMA spec, and everything to do with CSS incompatibilities. But for the cases where there are JS API issues, shims exist for virtually every browser and version, which is essentially what TS is doing to begin with, it's just shimming at "compile" time rather than at run time, which means that shim code is going whether you care about it or not, need it or not, or want it or not. You no longer have the choice to serve a shim. You're serving it. And with AngularJS we can support IE 7 forever. I love that. That was sarcasm.

Intellisense.
Ok, now we're getting to the real reason any developer wants to write TypeScript.  In a static type world, we can have pre-defined rules that enable text editors to give instant feedback on written code without the engineer knowing ahead of time what the API is.  They don't want to understand their code, they want their text editor to tell them how to write it. This is so very very very flawed at every level.


Why can Intellisense be bad? Well for starters: If your API is so complex that you need it, then you are probably writing your code wrong to begin with. I understand AngularJS needing it, because the API is utterly abyssmal to work with and is constantly changing. The early releases of the api were so fluid and complex we couldn't keep up with it, and intellisense renderers could barely even handle it!  Personally I believe this is why there was a massive exodus of engineering talent from the Angular community into the other (mainly React) spaces. At least in other spaces where you're learning something new, it was still just JavaScript, and not a layer that smelled like javascript but tasted like castor oil.

Fundamentally, if you don't know what you're doing, regurgitating autocomplete statements until the red squigglies go away is not going to improve your understanding. This means it doesn't push the engineer to be better at his job, but just madlib their way through a few lines of code and move on to the next madlib some more until it just magically works.

Intellisense makes for a good reminder when you just can't remember the parameter order, but most modern JS editors already do this. You DO NOT NEED a static-typed language for intellisense, just better intellisense.

How TypeScript will ruin your day:

The stack traces in TypeScript are literally unintelligible. Since you're bound to an ever-changing API, syntax errors are a very very common mishap, and more frequently than not, it results in a stack dump that looks like something out of a linux kernel. Spending hours digging through it to figure it out when you just missed an apostrophe is nightmarish at best, and a total gutbuster at worst.  Using plain old javascript, you can set breakpoints easily, step through easily, and KNOW what is going on. You're empowered to engineer the shit out of your thingy.  In TypeScript you have to figure out what it is doing first, then figure out how to make it do what you want it to do.  TypeScript is adding a layer of magic, where magic is simply not required. Engineering is.

How TypeScript is costing your company money:

TypeScript adds complexity and nuance to something that did not require it.  There was a very basic reason that JavaScript did not support static types: Flexibility. The only argument against flexibility is.. responsibility.  Now that you have guardrails in the form of static types, you don't have to worry about engineering mishaps. Oops, unless you do. With TypeScript, you can bail out at virtually any time and go back to JavaScript, which means you completely lose every advantage you claimed. But what if you needed to do it to solve a problem? Exactly. You needed to bail out because the guardrails weren't helping, they were hurting. This means you are spending Engineering dollars on a technology that simply is not required to solve your company's problems.  A couple of answers against this position are: Code reviews (don't let them do that), and we Lint, so we don't let our engineers do that. Ok that's great. So now what're saying is: We don't let our engineers solve the problems the way that would work for them, so we force them to "get creative" and then have solutions that are half-baked nonsense just to get the job done, when it could have been much simpler to just use JS to begin with.

How TypeScript puts your job at risk:

Being constantly put into a situation where docs, APIs and frameworks are constantly changing, adding a layer of complexity means you not only have to learn a new api every time you add something, but you have to know how TS integrates with that API, and when anything in that chain changes? You guessed it, you have to know how to change it and how to fix it. What happens when you can't? What happens when there are incompatibilities where their didn't exist one before, and now you have to punt the story because the only alternative is changing components or libraries forcing a re-write of a ton of logic?  What happens when this happens more than once? Twice? Three times? How many times can you keep going back to the business with an "I'm sorry, I need to re-write this" before their answer is: "No, you have to work with what you have, or gtfo".

JavaScript needs more Elegance and Simplicity not Clumsiness and Confusion.

In an ever-changing community we need stability, clarity and clean APIs, not auto-documented APIs that are inefficient and far too complex for their intended purpose. In the JS space we need frameworks, not supersets (which really is just a SUPER BIG framework) and languages. We need well-documented and intuitive APIs that empower our engineers to do amazing things, not remove their power and then make them revolt to get their job done.

The whole argument of type safety is lost when the engineer can bail out of it at any time and do their own thing. If this is needed anywhere for anything the entire premise of the language is completely lost in my eyes.

Intellisense is Hurting You More than Helping You

Just because your editor tells you what the next expected parameter is, does not mean it's going to do what you think it's going to do. The only way to understand an API is to read the fucking manual and learn what it does. Code with Dominance, not with submission. If the framework of choice is so goddamn complicated that it takes too much time to research either 1) you need more time to do the task or 2) Likely you're going to fuck it up anyway, so you better damn well have good test coverage so you understand what you're doing. Intellisense is not going to help with either of these.

Understanding the code as you write it will, in the end, benefit you, your company and your users. Chances are if you don't understand it, the next guy who does your job won't understand it either. This means that all that work you "saved" by madlibbing your way through a project is utterly and completely wasted, because maintaining your code is going to be even more mysterious and intricate.

Good JavaScript Engineers code like TypeScript Engineers Anyway

Concepts of solid OO programming are not going to change between languages. Either you know how to write solid code or you don't.  Introducing an entire layer of complexity is just madness. Either you're going to code in a testable and maintainable way or you're not. The language is not going carry you. If the language IS carrying you, then sooner or later it will drop you, and that will be very painful.

I don't know if you've noticed, but JavaScript apps have a lot of dependencies. Do we really need another one?

The depency spaghetti in the JS ecosystem is so brutally complex that we have seriously had to revise NPM and most folks are switching to yarn these days, because keeping your dependencies aligned is no longer a simple task.  If you can write an app that without it, why the fuck would you even consider adding an entire STACK on top of it? This is the reason that I believe that webpack is the worst thing that has ever happened to javascript. It has made it "simple" to manage garbage, so what did the community do? They created MORE GARBAGE since it was easier, now it's a total clusterfuck.

Gaming Streams - Pit or Panacea

Streamed gaming has some really attractive features, but they come at a high cost.  For those who don't understand gaming streams, this is a new digital phenomenon where services will render the graphics of video games and then display them to you over a virtual terminal with which you can play the game. Think something like Microsoft's Remote Desktop, but scoped only to a single running program (a game).

For a user, streaming a game has the following amazing benefits:

• No installation is required.
• It is hardware independent, as long as you can I/O to the stream, you can play the game. Even Mac users.
• Hacks or exploits are impossible, making competitive play more fair.
• The compute required to operate the game is no longer your own responsibility to provide.

There are more, these are just the key benefits off the top of my head. But as gamers adopt this delivery method as more and more the "standard", I would urge a significant degree of caution. There are a number of reasons that adopting this delivery model as an industry is potentially a catastrophically bad idea.

Why is this a bad idea? I'll break it down.

1) Content control means company control.

As the game-streaming services ramp up, we have several services competing for your gaming dollar. However, as market forces evolve, winners will clearly emerge where the only real players in the space will be reduced to a small handful of companies. These companies will then have very real and direct control over which games you have to choose from.

2) The loss of the independent game company. 

Since the content is controlled, it will then stifle the growth of independent game developers. How does this happen you ask? Indy developers will never be given the chance to grow and become big game companies. A prime example of how this happens is the podcast. The landscape evolved from a ragtag group of independents to a star-studded list of mainstream media types dominating it. Thereby suppressing and limiting the growth of the innovators that made the media amazing. Now the Top 10 Podcasts are pretty much a stagnant list of the same old suspects, forever.

3) Kiss modding goodbye.

Since code is no longer installed and run on a machine you own, that means you will always run the code that is running on the stream. This means any change, option, or setting, will be vetted, and gated by the streaming company in question. To publish a mod to a game, it will be necessary to "clear" it with the streaming company who will then either give the thumbs up or down, thereby deciding for you which mods you have the opportunity to run.  Ok, everyone sees this as an inconvenience and really most gamers mod very very little (unless you're a Minecraft player). The problem with this is that so many times in the past entire game genres have been born from mods!  A mod is simply a slight tweak of the game to affect a change in play that reflects a different idea than the original creator intended. This doesn't sound big, but without modding DOTA would never have been created, nor the entire MOBA genre. Modding is at the core of Minecraft, and without it, there would really be no Minecraft as we know it. In a streaming world, these innovations simply never would have been realized and we wouldn't have missed them.

4) Your choice will no longer be yours.

Right now you can choose to play any one of millions and millions of games. Whether you install it from CD (WTF?), download it or stream it. The choice is yours of what you play. In a streaming world, the palette that you choose from is far more limited in scope, and denies you the opportunity to even know what other options exist. As streaming services become more and more prevalent game distributors will take them more and more seriously, and eventually will distribute only to streaming platforms. As that change permeates, people will stop installing games and they will, instead, rely on the choices provided by the streaming services.



In the end, you will decide the fate of video game streaming. If you subscribe to, pay for and promote the usage of streaming services, you are selecting a future that essentially limits your future choices. But hey, maybe you're one of those people who doesn't like choice, and that's OK. Until it's not. In this paradigm, the list that is provided might not contain anything you like. And in this pit where innovation has been stifled and the independents run out of the field,  video gaming will simply wane into another footnote of human entertainment, like pogs.

Not all change is growth, but growth demands change.  I think before we hand the keys to the castle to a vaulted few, we should take a moment to consider: Do we really want this?