Hacker News Reader

Comment by koolba | Hacker News Reader

With TypeScript you can define a single set of interfaces shared by both your client side and server code. If you change an interface to return a different value or rename a member, you immediately know where it’s used and can update it in tandem. Static type checking let’s you know everywhere that something is used without a battery of tests running through your app.

This takes 99% of the fear out of refactoring and expanding APIs which leads to incredible agility in adding features to an existing code base.

View on HN

I used Typescript from the get-go on a new project recently and it's slowed down both mine and my team's development velocity a lot. Time will tell if it's a smart decision but in terms of prototyping or spiking something, I'm picking Rails every time and I think based on my current experience I'd be apt to retrofit Typescript to an existing project rather than integrate it from the beginning. I don't suppose you could recommend any good resources for better learning Typescript? The docs are OK but if there's a book or anything you'd recommend, I'd certainly appreciate it.

I don't have a book recommendation for you (what helped me was the standard documentation and about a year of daily dev time), but an observation:

Your team is likely using an overly restrictive tsconfig.json. No-implicit-any, for example.

Make it less restrictive, and you then have typing and no penalty for punting on it until later.

If using an IDE, the effort into defining types is immediately rewarded with autocomplete for API/backend AND client code, and we even export the types for use by a Monaco editor inside an internal app.

One more thing that IMO gets overlooked too often: TypeScript can typecheck your JSX markup. Compare that to any string-based templating engine, such as Knockout.js templates or jquery.tmpl, where you have to learn its snowflake DSL, you get no autocomplete, no checks for undefined variables or syntax errors…

If I never have to explain  vs  again, I'll be a happy man.

This is the type of thing to which I was referring. A server interface is updated to return a different data type or renamed, the client shares the same interface, type checking for TSX (TypeScript JSX) catches the name or type of the property is invalid, and you can immediately fix it.

No more grepping an entire codebase to see all the places that something is referenced and praying that you updated all of them. (And praying that you updated them correctly!)

I suspect you're right - we probably got a bit caught up in best practices to our detriment. Thank you for this.

>With TypeScript you can define a single set of interfaces shared by both your client side and server code.

If you don't have page-specific (or any, if you can) code on the client side, this stops being a problem in the first place.

It's funny how SPA fans here claim both good separation of concerns via web services and code/type sharing as features while in practice those things are mutually exclusive.

> If you don't have page-specific (or any, if you can) code on the client side, this stops being a problem in the first place.

Sure and that's a valid use case for server rendering. Though even in that situation having a typed mechanism for going from a model and view to HTML wins out over untyped templates that operate primarily on string replacement. You have the same problem server side when "first_name" in your model is renamed to "display_name".

Unless you have tests that lead to rendering every possible if/else branch in your rendering logic, you're not going to realize that you forgot to update your view template until that situation happens in production. The more complicated your views, the more likely you'll run into this situation.

> It's funny how SPA fans here claim both good separation of concerns via web services and code/type sharing as features while in practice those things are mutually exclusive.

I'm not sold on SPA either but for any application that involves an active client that makes it's own requests and maintains state, you end up needing some form of documentation for those interactions. It's not a panacea but well defined interfaces shared between the server and client solve a big part of that.

You get all of that for free with Java, plus you don't have to use javascript

You also get nullable types with Java, which severely cripples the confidence static typing is supposed to give you.

Or Go. Or Crystal, if similarity to Ruby is preferred. You get the advantages of static typing plus the performance of a compiled language.

>shared by both your client side and server code

How do you get that? Are you using GWT?

Reply on news.ycombinator.com