Skip to content

TypeScript is rather lovely

I have been working full-time as a TypeScript backend-only developer for a few weeks now. It is honestly quite good.

Old habits

I Have a history of adopting early Microsoft technologies, even though I mostly try not to work with them full-time. I suppose this is an experiment in some regard. Can I stick to one language and one area without going a bit crazy?

When ASP and later .NET were new. I was keen to migrate my Visual Basic + MFC to C# under the Microsoft guise that it would be a magic bullet for problems I never had. I trusted I would at some point.

TypeScript is definitely a modern language, worlds better than the original C#, and the predecessors Visual Basic and MFC. For one thing it is higher-level. For another despite enabling strict typing, it has lessons learned from other languages about inferred typing and auto-typing. It also has some decent visual studio code integration.

It might be worth remembering that it all compiles to JavaScript, and the type you might expect from being auto-generated; but with the aid of source-maps and JavaScript ES2020 tooling, it is much more like getting a new tool that fits in, than changing to something unfamiliar.


As with any new team, I am trying to learn the nuance that the rest of the team understand about each other, the code they write and how they write it. I am also trying to raise test coverage as I hand on heart believe that if you do not test something; you are communicating the lack of value of that thing.

Why would you not, check the door is locked. All your valuables are inside.

I am happy to see a test-suite with I think over 50% coverage. I am also genuinely happy to have people who are passionate about the work they and others do.

Having shipped my part of the first feature within two-weeks, with some really lovely API best-practices such as using content-negotiation to version an API; learning to setup, configure and augment the systems; I am currently enjoying digging through some legacy code, implementing a new algorithm and taking ownership of the codebase.

A new team is not without struggles and frustrations though. No matter what lovely people, other can be; you are still teaching each other habits. Not all of them will immediately sit well.

New Shiny things

As with any new shiny things, the language has also let me down as much as helped me. Perhaps not in equal measure, but enough that I feel like it is currently roughly even.

Traditional JavaScript can be a headache if loose typing was the why. I am in favour of rigid and small things, not AIO software. Due to this a lot of the code you will import will be JavaScript with type definitions to try to protect you. This is likely not transpiled from TypeScript, so the type definitions can be a bit of a mare.

The language supports unions, generics, and all those seemingly wonderful, but PITA things I loathe to extensively use. One exception to this was Promise<T>. My gosh that check saves my bacon if I forget to add an await. It does not work in reverse though. You can absolutely await a regular function, and I am yet to see a warning.


SendGrid has a particularly wide-ranging send method I wanted to close down the use-cases for. This was thwarted by my own team-mates wishes to send multiple recipient emails. It is not a use case we had, but apparently one they wanted.


Express JS framework has been another. You can write handlers without type hints for the body type. I in-fact prefer that, as writing types for non-typed code seems like a particularly convoluted set of lies about the code. Especially when paired with Joi validations.


One of the bugs I paired with another dev with, when one of the team was away, centred around lies the TypeScript told about the ORM. An object of Object type, which happened to be a foreign-key in a database, was coming back as a number unless the Object was prior loaded. The TypeScript compiler could only do so much, so the type-hinting as a user seemed to cause more problems than it solved.

This became more of a problem when I wanted to riff on some SQL. I found despite intelligent suggestions, the size of TypeORM was still a majestic beast to tame.

Some whining about Planning

Types also seem to be no substitute for good planning. Not waterfall planning. Thinking with others, before you do something. They should also be more complex than basic types.

So far, I have been sticking to others defined types and minimising my Cambrian explosion of types. I am usually not so controlled, and often enjoy making many descriptive types, aliases, and interfaces to try to get my code to read as prose.

Luckily has a TypeScript track. I can scratch the itch to do things my way, in my own time.