- 0 Posts
- 7 Comments
It’s a good way to get started, and then incrementally type as much as you can, preferably everything.
Later on, or if you start a new project with TypeScript, it’s a good idea to turn on noImplicitAny and only allow explicit any in very specific framework level code, unit tests or if you interface with an untyped framework.
The hassle really pays off later.
The EU introduced a limitation to how much power electric devices can consume in off or standby mode.
0.5 watt normally, 1 watt if they have a status display and 2-8 watts if they’re connected to a network.
On a yearly basis this saves as much electricity as one of the member states (Romania) used in a year.
My point is that small things add up to huge numbers.
I was working on an enterprise web application, there was a legacy system that everyone hated and we replaced it with a more modern one.
We got a ticket from our PO to introduce a 30 sec delay to one of our buttons. It sounded insane, but he explained that L1 support got too many calls and emails where users thought said button was broken.
It wasn’t, they were just used to having to wait up to 5 minutes for it to finish doing its thing, so they didn’t notice when it did it instantly.
We gradually removed that delay, 10 seconds each month, and our users were very happy.
Typescript is a language, Node is a platform and framework. You can use Typescript in your Node project, they’re not mutually exclusive.
The way I see it Typescript is more popular than ever, almost all (popular) libraries come with types and every job offer I get they use Typescript.
And with good reason, our team recently took over a small Javascript app and there are tons of bugs that would never have existed if they were using Typescript. Things like they refactored something but missed to update a reference, or misspelled a variable name, failed to provide a required parameter to a funcrion, referenced a field that existed in another config object etc.