6 ms·

If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny n

by sethc2 7y ago

If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny new technology? It is still using the same tech in Node, which you already know the benefits and pitfalls for, but it isn't like there is no overhead to start consuming Typescript if you haven't used it before. My hope is for those who agree with the author's premise, that it is still using the same "boring" technology and more people switch to it, because over the last two years when we switched to use Typescript, it has gotten significantly more valuable as more and more people have used it because now a majority of the dependencies I take on have type definitions provided via DefinitelyTyped, or are included with the package.

nemild 7y ago
I would go for it, but just the fact that you're asking shows that you're less susceptible to injecting needless technology. Typescript has also been used for years, and it has a place as Javascript is used for more complex products than it was intended. I wrote a short bit in "Handling Hype" here arguing that you need to dig into your problem, assess claims, and weigh tradeoffs: https://www.nemil.com/mongo/1.html https://www.nemil.com/mongo/1.html
fnord77 7y ago
See that slide that shows the bipartite graph of Problems on the left and Technology on the right. Typescript would be an extra edge in that graph and thus would impact the equation in the subsequent slides. So it would be a shiny new technology.
- lvh 7y ago
  Can you elaborate? I don't quite understand. (I also think TypeScript is a great example of a category breaker here since it's a lot closer to a linter than a database. Sure, you have a new compiler stage so it's not quite free :-))
sudhirj 7y ago
I’d say talk about it with the team, see there’s enough buy in from the existing team and enough awareness of the extra stuff to learn for both current and future team members. Then try it incrementally on some of the most hairy or type bug ridden parts of the codebase (so you can quickly prove utility) or on some smaller / newer parts of the code (so you can quickly prove compatibility). Then a wider rollout should build up its own momentum if it’s anywhere as helpful as you’re hoping it’s going to be.
steve_adams_86 7y ago
A wonderful thing about TypeScript is that if you decide you don't like it or need it, you still have recognizable and refactorable JavaScript. On the other hand, if you have a ton of relational data and get excited about the latest nosql DB, you're going to have a hell of a time unravelling that mess.
KaiserPro 7y ago
It fits in the ruby part here: http://boringtechnology.club/#33 http://boringtechnology.club/#33 It would be something that you are adding to the stack. Yes, you are intending to replace something, but in practice there will still be legacy nodejs hanging around. But crucially this one: http://boringtechnology.club/#43 http://boringtechnology.club/#43 If you are spending time (and therefore money) changing from one language to another, you are not making features for the business. Yes, you might get more speed re-implementing features, but its almost never going to make up for the hit you took in porting everything.
- yellowapple 7y ago
  It ain't just about speed, though. If TypeScript is able to prevent entire classes of bugs, then that lowers the ongoing maintenance costs relative to the costs of maintaining the non-TypeScript version. It'll also make implementing new features easier and faster (and therefore cheaper) in the long run specifically because of that avoidance of bugs interfering with delivery of those features. Both of those factors can (and often do) easily outweigh the upfront cost of porting everything. Even speed alone, though, can help substantially reduce other more tangible costs; if your TypeScript backend is faster than your non-TypeScript backend, then that translates to needing less server resources to achieve the same result (and/or being able to handle heavier loads without needing to upgrade or expand your server resources).
  - KaiserPro 7y ago
    I see those arguments but: o the new feature speed is only gained after a complete re-write o in 80% of businesses people cost >> than hosting o re-writing always introduces more bugs The only time that I would agree to something like this, is to get all my teams onto the same platform. Again, thats not a technical decision though.
  - redisman 7y ago
    ES6 to TS is more refactoring than a re-write. Just start with the core library and some TS linting and fix things as you go. The time it takes to 80-20 a microservice project into TS is usually less than it takes to hunt down a confused type bug (ie. someone thought this was an array but it's a string). This is not a "re-write": function(param1, param2) {} function(param1: string, params2: number) {}
sthomas1618 7y ago
Per the presentation, you would need to weigh the benefits/costs. Since TypeScript is a superset of JavaScript, I would argue the cost of adding is very low. The benefits will be naturally high due to type definitions reducing bugs and cognitive overhead.

by sethc2 7y ago

nemild 7y ago

I would go for it, but just the fact that you're asking shows that you're less susceptible to injecting needless technology. Typescript has also been used for years, and it has a place as Javascript is used for more complex products than it was intended. I wrote a short bit in "Handling Hype" here arguing that you need to dig into your problem, assess claims, and weigh tradeoffs: https://www.nemil.com/mongo/1.html https://www.nemil.com/mongo/1.html

fnord77 7y ago

See that slide that shows the bipartite graph of Problems on the left and Technology on the right. Typescript would be an extra edge in that graph and thus would impact the equation in the subsequent slides. So it would be a shiny new technology.

lvh 7y ago
Can you elaborate? I don't quite understand. (I also think TypeScript is a great example of a category breaker here since it's a lot closer to a linter than a database. Sure, you have a new compiler stage so it's not quite free :-))

sudhirj 7y ago

I’d say talk about it with the team, see there’s enough buy in from the existing team and enough awareness of the extra stuff to learn for both current and future team members. Then try it incrementally on some of the most hairy or type bug ridden parts of the codebase (so you can quickly prove utility) or on some smaller / newer parts of the code (so you can quickly prove compatibility). Then a wider rollout should build up its own momentum if it’s anywhere as helpful as you’re hoping it’s going to be.

steve_adams_86 7y ago

A wonderful thing about TypeScript is that if you decide you don't like it or need it, you still have recognizable and refactorable JavaScript. On the other hand, if you have a ton of relational data and get excited about the latest nosql DB, you're going to have a hell of a time unravelling that mess.

KaiserPro 7y ago

It fits in the ruby part here: http://boringtechnology.club/#33 http://boringtechnology.club/#33 It would be something that you are adding to the stack. Yes, you are intending to replace something, but in practice there will still be legacy nodejs hanging around. But crucially this one: http://boringtechnology.club/#43 http://boringtechnology.club/#43 If you are spending time (and therefore money) changing from one language to another, you are not making features for the business. Yes, you might get more speed re-implementing features, but its almost never going to make up for the hit you took in porting everything.

yellowapple 7y ago
It ain't just about speed, though. If TypeScript is able to prevent entire classes of bugs, then that lowers the ongoing maintenance costs relative to the costs of maintaining the non-TypeScript version. It'll also make implementing new features easier and faster (and therefore cheaper) in the long run specifically because of that avoidance of bugs interfering with delivery of those features. Both of those factors can (and often do) easily outweigh the upfront cost of porting everything. Even speed alone, though, can help substantially reduce other more tangible costs; if your TypeScript backend is faster than your non-TypeScript backend, then that translates to needing less server resources to achieve the same result (and/or being able to handle heavier loads without needing to upgrade or expand your server resources).
- KaiserPro 7y ago
  I see those arguments but: o the new feature speed is only gained after a complete re-write o in 80% of businesses people cost >> than hosting o re-writing always introduces more bugs The only time that I would agree to something like this, is to get all my teams onto the same platform. Again, thats not a technical decision though.
- redisman 7y ago
  ES6 to TS is more refactoring than a re-write. Just start with the core library and some TS linting and fix things as you go. The time it takes to 80-20 a microservice project into TS is usually less than it takes to hunt down a confused type bug (ie. someone thought this was an array but it's a string). This is not a "re-write": function(param1, param2) {} function(param1: string, params2: number) {}

sthomas1618 7y ago

Per the presentation, you would need to weigh the benefits/costs. Since TypeScript is a superset of JavaScript, I would argue the cost of adding is very low. The benefits will be naturally high due to type definitions reducing bugs and cognitive overhead.