3 ms·

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, y

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) {}

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) {}