How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan(chiragswadia.medium.com)
chiragswadia.medium.com
How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
https://chiragswadia.medium.com/how-an-anti-typescript-javascript-developer-like-me-became-a-typescript-fan-a4e043151ad7
392 comments
It's probably worth taking a step back and interrogating why the actual "Why was I Anti-TypeScript?" a little bit more and use it as an opportunity for broader self development.
The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".
The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".
For me, I can handle the lack of static typing when I'm doing small scripts, like if it's going to be 100 lines or so of Python (my go-to language if I need to test some math out in a sandbox or do some file manipulation on my system). I might actually be a little faster in writing those scripts because of the lack of typing.
Once it starts getting any bigger than that, though, static typing really catches and points out a lot of problems before I even launch the program, that I'd otherwise be spending time debugging and looking for anyway, most likely.
I also think static typing has the benefit of enforced self-documentation a bit, so other developers know just by checking the type what sort of data they should expect to see in there, and not trying to give it garbage to begin with. Granted good variable naming and proper documentation would alleviate that, but that's never been fully consistent at any organization I've ever worked for.
And considering I mostly work with relational SQL databases, there's no escaping typing on the database end for that, so I might as well have models that map to the typing of what's in the database so I don't have to keep checking the database tables to make sure I'm giving it good data.
Once it starts getting any bigger than that, though, static typing really catches and points out a lot of problems before I even launch the program, that I'd otherwise be spending time debugging and looking for anyway, most likely.
I also think static typing has the benefit of enforced self-documentation a bit, so other developers know just by checking the type what sort of data they should expect to see in there, and not trying to give it garbage to begin with. Granted good variable naming and proper documentation would alleviate that, but that's never been fully consistent at any organization I've ever worked for.
And considering I mostly work with relational SQL databases, there's no escaping typing on the database end for that, so I might as well have models that map to the typing of what's in the database so I don't have to keep checking the database tables to make sure I'm giving it good data.
The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After your project gets to a certain size, and it need not be large, you start making smaller changes and moving code around -- having some guard rails there is a huge productivity boost. Being able to read code and know that it does what it says because you know the types also improves your productivity.
The critique of typed languages being slow to write was somewhat true in the past. However, more modern typed languages (e.g. Swift or Typescript) do a lot of inference and have some flexibility built in. Because of that I think you get many of the same benefits of loose typing while maintaining type safety. One worry I had with starting Typescript was a fear it was going to make engineers over-engineer things, which is a behavior that Java seems to promote -- that turned out to not be true. You can go off the deep-end on generics, but in practice I haven't seen this.
Also with Typescript, you're not so far from Javascript where it's an entirely new language. So if you love Javascript, you don't lose anything.
The critique of typed languages being slow to write was somewhat true in the past. However, more modern typed languages (e.g. Swift or Typescript) do a lot of inference and have some flexibility built in. Because of that I think you get many of the same benefits of loose typing while maintaining type safety. One worry I had with starting Typescript was a fear it was going to make engineers over-engineer things, which is a behavior that Java seems to promote -- that turned out to not be true. You can go off the deep-end on generics, but in practice I haven't seen this.
Also with Typescript, you're not so far from Javascript where it's an entirely new language. So if you love Javascript, you don't lose anything.
Don't want to oversimplify since the article has some useful insights, but overall it reads like a typical transition from thinking static typing is a burden to realizing type safety can be incredibly useful.
I distinctly remember that in college I believed the history of programming languages is purely evolutionary in the sense that newer languages are objectively better than older ones. As in - people wrote assembly until C came along and gave them if clauses and for loops and then came Java where you didn't need to manually manage memory anymore and could use classes and then with Python you didn't even need to specify types anymore!
I.e. the newest language with the most everything is the best!
Nowadays it feels like I'm replaying that in reverse - doing less and less OOP, loving statically typed languages, wanting to learn some Rust etc.
I distinctly remember that in college I believed the history of programming languages is purely evolutionary in the sense that newer languages are objectively better than older ones. As in - people wrote assembly until C came along and gave them if clauses and for loops and then came Java where you didn't need to manually manage memory anymore and could use classes and then with Python you didn't even need to specify types anymore!
I.e. the newest language with the most everything is the best!
Nowadays it feels like I'm replaying that in reverse - doing less and less OOP, loving statically typed languages, wanting to learn some Rust etc.
I think a large part of the support for Typescript comes from being able to create good tools for the language.
But, I still have an aversion to front-end development itself, because it just feels too _involved_. You have to set up so much, and it has become a lot more difficult since you need to install webpack, postcss, and many other plugins just to do a hello world app.
It's still bearable if you have to do all of that, and you _understand_ what is going on, but most of the time, especially when it comes to front-end, I do things "because that's how it's done".
This makes me feel very insecure about my code.
But, I still have an aversion to front-end development itself, because it just feels too _involved_. You have to set up so much, and it has become a lot more difficult since you need to install webpack, postcss, and many other plugins just to do a hello world app.
It's still bearable if you have to do all of that, and you _understand_ what is going on, but most of the time, especially when it comes to front-end, I do things "because that's how it's done".
This makes me feel very insecure about my code.
My problem with TypeScript is the lack of runtime benefits. Yes, you get some benefits of static checks during compile time, but at the cost of huge additional effort. This effort maybe makes sense for a large project with many team members pushing code, but for small hobby projects I think this just makes quick iteration far more difficult. To me this defeats the whole purpose of using a dynamic garbage-collected language to begin with.
If TypeScript was a first-class language, you could do all sorts of great runtime optimizations (perhaps a v8 fork will do this eventually?). In this case I would absolutely jump all over it, even for small hobby projects.
As it is, going from JS -> TS, one might as well just skip the extra translation step and just start writing everything in Go or Rust, especially for back-end nodejs/deno projects. In these languages the runtime benefits makes the abstractions worth the effort.
If TypeScript was a first-class language, you could do all sorts of great runtime optimizations (perhaps a v8 fork will do this eventually?). In this case I would absolutely jump all over it, even for small hobby projects.
As it is, going from JS -> TS, one might as well just skip the extra translation step and just start writing everything in Go or Rust, especially for back-end nodejs/deno projects. In these languages the runtime benefits makes the abstractions worth the effort.
After being an early adopter of TypeScript, I decided to skip TypeScript in my next projects for a few years because I thought it was not worth the hassle. I remember spending a lot of time in DefinitelyTyped to create and fix type definitions, and when Babel and ES6 were popular I used that instead.
I recently changed my mind and started to migrate a large JavaScript codebase to TypeScript, in strict mode. I consider my team to be composed of only good developers but still, I found so many bugs. I still spend time on DefinitelyTyped definitions, but if you do more than prototyping or work on a project also developed with other people for more than a few weeks, TypeScript is for sure worth it in my opinion.
I recently changed my mind and started to migrate a large JavaScript codebase to TypeScript, in strict mode. I consider my team to be composed of only good developers but still, I found so many bugs. I still spend time on DefinitelyTyped definitions, but if you do more than prototyping or work on a project also developed with other people for more than a few weeks, TypeScript is for sure worth it in my opinion.
Still not a typescript fan here. It feels like a half-baked language because of the insistence of not having a runtime (even though some information makes it through to the underlying js...so this objection of theirs isn't total). In a usual typed language, you could extract the type of an intersection type using pattern matching. But you can't do that in typescript. Instead you get to pick the most relevant ugly hack for your situation.
Typescript feels like every one of its features has some catch, and it's very irritating.
Typescript feels like every one of its features has some catch, and it's very irritating.
While I'm fan of statically typing, there is something with Typescript I don't like, but don't know exactly what it is. In my day-to-day it's mostly Kotlin and Elm, which also are both statically typed, which I don't mind and mostly don't even notice.
But with Typescript it is as if I'm always fighting the compilator, trying to make it happy with whatever code I wrote. Maybe it's just the JS ecosystem being too lax that makes having types for everything difficult? Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.
But with Typescript it is as if I'm always fighting the compilator, trying to make it happy with whatever code I wrote. Maybe it's just the JS ecosystem being too lax that makes having types for everything difficult? Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.
Currently maintaining a very large codebase in TS, and never going back to vanilla.
The initial migration found hundreds of bugs, typos, imperfections. And now every refacto, bugfix, new features... can be trusted.
More than that, when you use JS in the back and the front, your types can follow from the database, to the api, to react... even to your integration tests or your public SDK.
Add one more column in your DB and suddenly 1000 errors pops, but those are good errors, you just have to follow them until nothing scream and you have done a perfect migration. It can feels negative at first but it is actually very pleasant and reassuring, like having an angel watching over your code.
More than that, when you use JS in the back and the front, your types can follow from the database, to the api, to react... even to your integration tests or your public SDK.
Add one more column in your DB and suddenly 1000 errors pops, but those are good errors, you just have to follow them until nothing scream and you have done a perfect migration. It can feels negative at first but it is actually very pleasant and reassuring, like having an angel watching over your code.
Are there big companies still doing untyped JS at scale out there?
I'm not a frontend person and I always disliked dynamic type systems. But I vaguely remember the skepticism when Angular moved to TS. To me it made a lot of sense that most projects at Google, MS and the like would hugely benefit from a language that is kind of a C# on the JS runtime. And in 2021 I see TS pretty much everywhere, but maybe I'm missing something?
I'm not a frontend person and I always disliked dynamic type systems. But I vaguely remember the skepticism when Angular moved to TS. To me it made a lot of sense that most projects at Google, MS and the like would hugely benefit from a language that is kind of a C# on the JS runtime. And in 2021 I see TS pretty much everywhere, but maybe I'm missing something?
I like the post, but the author's original perspectives are something I was always perplexed by. There was a period in late 2000s and early 2010s where dynamic languages were all the range (Ruby, Python, CoffeScript) and static typic was seen as archaic and slow by an entire segment of development community and I never understood it.
>I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits.
I mean ... that is a perspective. EJB 2.0 was over-engineered for many use-cases. SOAP is an over-engineered standard for many use-cases. Static typing is not. Maybe for small scripts, static typing doesn't provide that much value (although even then I don't really buy it - why wouldn't you want to know what you're working with at any given time), but for sizable (web) applications that need to be maintained for years, it's critical.
>also it felt slow to work on, as I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem.
Another interesting perspective. Every single one of those compilation errors was a runtime error waiting to bite you in the butt. If you think solving compilation errors is slow, debugging and solving runtime errors is way slower. I'm glad the author learned the value of compile-time checks.
>The other reason was Advanced TypeScript concepts like Generics felt very hard to understand initially and I started feeling that I am in the Java world where every piece of code is strongly typed and overwhelming.
This right here is the big problem in a nutshell. There is nothing wrong with ignorance - we all start there. But it's one thing to be 'overwhelmed' by something when starting out, and another to being ANTI that something BECAUSE you don't understand it. The author admits he was overwhelmed by TypeScript and that caused him to be ANTI-Typescript. That is something you see in places. And that the author justified his Anti-Typescript perspective by having an ignorant view of Java to boot. The author talks about 'Java world', but does he have any experience with Java development at all?
>I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits.
I mean ... that is a perspective. EJB 2.0 was over-engineered for many use-cases. SOAP is an over-engineered standard for many use-cases. Static typing is not. Maybe for small scripts, static typing doesn't provide that much value (although even then I don't really buy it - why wouldn't you want to know what you're working with at any given time), but for sizable (web) applications that need to be maintained for years, it's critical.
>also it felt slow to work on, as I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem.
Another interesting perspective. Every single one of those compilation errors was a runtime error waiting to bite you in the butt. If you think solving compilation errors is slow, debugging and solving runtime errors is way slower. I'm glad the author learned the value of compile-time checks.
>The other reason was Advanced TypeScript concepts like Generics felt very hard to understand initially and I started feeling that I am in the Java world where every piece of code is strongly typed and overwhelming.
This right here is the big problem in a nutshell. There is nothing wrong with ignorance - we all start there. But it's one thing to be 'overwhelmed' by something when starting out, and another to being ANTI that something BECAUSE you don't understand it. The author admits he was overwhelmed by TypeScript and that caused him to be ANTI-Typescript. That is something you see in places. And that the author justified his Anti-Typescript perspective by having an ignorant view of Java to boot. The author talks about 'Java world', but does he have any experience with Java development at all?
This article echos the common complaint I've seen from people hesitant to adopt TS.
"I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem. "
Which is like saying, "I got rid of my carbon monoxide detector because it kept beeping at me"
"I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem. "
Which is like saying, "I got rid of my carbon monoxide detector because it kept beeping at me"
"First I didn't like it because it takes longer to learn, then I discovered the obvious features that are the reason TypeScript was invented in the first place."
Came from a statically typed background when I landed with JavaScript and - absolutely loved - the fact that it wasn't. I've been using TypeScript for the better part of four years for my day job, but I'll still use plain old JavaScript when the situation allows for it. TypeScript has become a religion, and I've seen folks screaming in Github issues because a 14 line package didn't export types.
TypeScript has its place and it's nice points. It's got downsides too. Just as using plain JavaScript does. Stop bemoaning people who don't use TypeScript. Stop lauding people who choose it as the default "because types." Right tool for the right job, and all that.
TypeScript has its place and it's nice points. It's got downsides too. Just as using plain JavaScript does. Stop bemoaning people who don't use TypeScript. Stop lauding people who choose it as the default "because types." Right tool for the right job, and all that.
Here's a project idea I'd really like to see: A version of Chromium, targeted at web developers, that is is modified to accept TypeScript syntax as a variant of JavaScript.
This hypothetical browser wouldn't perform type-checking, just be able to parse TS syntax and convert it to plain JS, in the same way tools like Babel do.
This would let you use TypeScript without the need for any transformation pipeline in dev. You could then separately run TypeScript in a console to get async checking. Then only when you build for production do you run everything through a compiler/bundler to get a plain JS bundle that will work in everyone's browsers.
This hypothetical browser wouldn't perform type-checking, just be able to parse TS syntax and convert it to plain JS, in the same way tools like Babel do.
This would let you use TypeScript without the need for any transformation pipeline in dev. You could then separately run TypeScript in a console to get async checking. Then only when you build for production do you run everything through a compiler/bundler to get a plain JS bundle that will work in everyone's browsers.
I like you can type check stuff like this:
type State = { id: "initial" } | { id: "running", speed: number }
const f = (s: State) => {
switch (s.id) {
case "initial": // s.id available
break;
case "running": // s.id and s.speed available
break;
}
}
Although I like the actual language of TypeScript more than JavaScript, it still doesn't feel useful enough to justify its usage. Computers' native language is Assembly but we rarely use it and prefer to code in C/Python/whatever because this is so much easier (+ portable). Browsers' native language is JavaScript and it isn't much harder nor less powerful than TypeScript, nor does it provide a seriously different perspective (like Clojure/Elm/Reason do) so why not just use JavaScript (you have to understand it anyway)?
>> satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits
I tend to rail quite hard against the “type everything” world view but I’ve always been crystal clear on the benefits of types at boundaries between components. They can be a succinct way to codify the invariants and contract between components in a software architecture - with a nice quick feedback loop when you appreciate it most (when you’re exploring an unfamiliar API). They can also be a total train wreck for productivity when abused.
Where they fall down for me and always become a productivity penalty is working inside those component boundaries. Tests are a better answer then. I care that the actual behaviour is sound, if i say concat(list1, list2); something like Java’s type system guarantees of only “hey you put two lists in, you get some list back which might or might not be a concatenation of the two you provided” aren’t sufficient, you might as well not type it at all. Tests are necessary.
In typescript you could actually type concat in a meaningful way but i digress.
I think tests are also a better tool for handling people boundaries, that is developers separated by time (i.e. myself in 1 year) or separated by space, (i.e. between groups of developers in different orgs). The fundamental difference is the explanation, a test explains how something should behave, an intention. A type is a terse expression of how a person interpreted the problem domain and is not guaranteed to be an appropriate or useful model, it’s just a rule.
There’s a possible exception to all of this for me - dependant types. I’m still learning and undecided on the value.
All said and done, I’m happy that things like mypy and typescript exist, but I’m not convinced they are a cost effective way to maintain reliable software if over-used or used in rubbish ways. Used appropriately, they’re great. Used all the time, no thanks.
I tend to rail quite hard against the “type everything” world view but I’ve always been crystal clear on the benefits of types at boundaries between components. They can be a succinct way to codify the invariants and contract between components in a software architecture - with a nice quick feedback loop when you appreciate it most (when you’re exploring an unfamiliar API). They can also be a total train wreck for productivity when abused.
Where they fall down for me and always become a productivity penalty is working inside those component boundaries. Tests are a better answer then. I care that the actual behaviour is sound, if i say concat(list1, list2); something like Java’s type system guarantees of only “hey you put two lists in, you get some list back which might or might not be a concatenation of the two you provided” aren’t sufficient, you might as well not type it at all. Tests are necessary.
In typescript you could actually type concat in a meaningful way but i digress.
I think tests are also a better tool for handling people boundaries, that is developers separated by time (i.e. myself in 1 year) or separated by space, (i.e. between groups of developers in different orgs). The fundamental difference is the explanation, a test explains how something should behave, an intention. A type is a terse expression of how a person interpreted the problem domain and is not guaranteed to be an appropriate or useful model, it’s just a rule.
There’s a possible exception to all of this for me - dependant types. I’m still learning and undecided on the value.
All said and done, I’m happy that things like mypy and typescript exist, but I’m not convinced they are a cost effective way to maintain reliable software if over-used or used in rubbish ways. Used appropriately, they’re great. Used all the time, no thanks.
I'm a senior developer and I've never touched TypeScript and don't have any desire to unless I have no choice.
I haven't worked on any projects that were large enough to warrant type checking or where I felt it would make a huge difference. Also I find it a bit verbose and ugly and I'm just not a fan of pseduo Javascript languages that need to be compiled down into JavaScript.
I haven't worked on any projects that were large enough to warrant type checking or where I felt it would make a huge difference. Also I find it a bit verbose and ugly and I'm just not a fan of pseduo Javascript languages that need to be compiled down into JavaScript.
Short article, felt like what has been said before numerous times. I will opine why I was hesitant at first. The biggest reason was I didn't want to start writing a bunch of not-js (as in not a "strict superset" of js) and also having to deal with writing my own type definitions. I remember trying things like flow and reasonml and got quickly annoyed bending over backwards to use non-reason/flow code.
It seems like as of 2021 though that typescript has sort of won and the community has done great work in covering virtually every package I seem to use. npm helpfully points out which libraries have typescript definitions or a @types/<package>. I'm still not entirely sold on the strengths of strong typing in terms of bug avoidance, but the IDE like features are enormous. For me personally I see typescript more as a forced, never stale or mostly-incorrect, JSDoc.
It seems like as of 2021 though that typescript has sort of won and the community has done great work in covering virtually every package I seem to use. npm helpfully points out which libraries have typescript definitions or a @types/<package>. I'm still not entirely sold on the strengths of strong typing in terms of bug avoidance, but the IDE like features are enormous. For me personally I see typescript more as a forced, never stale or mostly-incorrect, JSDoc.
Here's an alternative to TypeScript that people who dislike type complexity but want better tooling, might find interesting: https://github.com/keyboardDrummer/typeless
Disclaimer: I'm the author
Disclaimer: I'm the author
Not much said on the category of bugs caught by Typescript. That would have been an interesting discussion.
I dip between javascript and typescript and hesitate recommending it for large scale project for a large team as much as I would like to, coming from a background of typed languages on the backend. There appears to be a need for experienced senior typescripters on the team to prevent falling into certain traps and onboarding [1].
I do wonder though how he saw typing as over-engineering. It may cause intertia which he hints at in the next sentence but over-engineering is a bit uncharitable.
[1] https://medium.com/javascript-scene/the-typescript-tax-132ff...
I dip between javascript and typescript and hesitate recommending it for large scale project for a large team as much as I would like to, coming from a background of typed languages on the backend. There appears to be a need for experienced senior typescripters on the team to prevent falling into certain traps and onboarding [1].
I do wonder though how he saw typing as over-engineering. It may cause intertia which he hints at in the next sentence but over-engineering is a bit uncharitable.
[1] https://medium.com/javascript-scene/the-typescript-tax-132ff...
I was hesitantly open to TS when the hype was first ramping up. The team I was on (and I've seen this in lots of code elsewhere too) was doing stuff like this:
I've been toying with Erlang for years, once I grokked how they flow control can be done via different method signatures, the Other Way started looking really inadequate.
declare let myColor: Color | undefined;
I've been toying with Erlang for years, once I grokked how they flow control can be done via different method signatures, the Other Way started looking really inadequate.
I had the opposite experience. I like languages with static types a lot and I used to be a fan of TypeScript.
After using it for a few OSS projects and professionally, I came to the conclusion that, if I need types, I'll use a real statically typed language if I need types and JS for what doesn't matter.
TypeScript works but: - it's a major pain to work with if your dependencies don't have type definitions - if another developer in your codebase left a hole somewhere you won't be able to rely on your types, you'll get runtime errors and you basically ruin the capability to reason around your code - it's slow (hopefully deno's efforts will bring some news in that regard)
TL;DR: TypeScript should be much stricter and don't compromise with JS.
After using it for a few OSS projects and professionally, I came to the conclusion that, if I need types, I'll use a real statically typed language if I need types and JS for what doesn't matter.
TypeScript works but: - it's a major pain to work with if your dependencies don't have type definitions - if another developer in your codebase left a hole somewhere you won't be able to rely on your types, you'll get runtime errors and you basically ruin the capability to reason around your code - it's slow (hopefully deno's efforts will bring some news in that regard)
TL;DR: TypeScript should be much stricter and don't compromise with JS.
I've been using typescript for years and one complaint I have is that it hides really powerful features of prototype based programming and make javascript look like a normal class based language.
Not sure if I am a Typescript fan but I would most of the time choose Typescript over Javascript most of the time for frontend or backend NodeJs development.
I used to think the same. Coming from the Java world (might explain why I like it) colleagues convinced me that it would be better to use another runtime (JVM/CLR) than trying to use types on NodeJs (it was stupid). I used Typescript in the first versions it was painful, trying to find type definitions, writing my owns, etc. So I did not insist and moved to Javascript for NodeJs.
I rediscovered the language 1 year ago and uses it for some frontend (Vue) and backend (api gateway, lambda, mongoDB/dynamoDB) Nowadays I very much like the language, union and intersection types make it very expressive and precise. Compilation (or translation) is a little slow but bearable, and it is nice to have a common language and tooling between the frontend and backend. Most of the libraries provide and maintain typescript definition files when they are not themselves written in Typescript. Sometimes I think the language goes too far in the features, I had a look at the latest versions and was a little bit puzzled by the complexity. But even for small projects to larger ones, I definitely prefer statically typed languages (with type inference and even implicit ones) especially when time is limited to write tests and have a good test coverage.
I used to think the same. Coming from the Java world (might explain why I like it) colleagues convinced me that it would be better to use another runtime (JVM/CLR) than trying to use types on NodeJs (it was stupid). I used Typescript in the first versions it was painful, trying to find type definitions, writing my owns, etc. So I did not insist and moved to Javascript for NodeJs.
I rediscovered the language 1 year ago and uses it for some frontend (Vue) and backend (api gateway, lambda, mongoDB/dynamoDB) Nowadays I very much like the language, union and intersection types make it very expressive and precise. Compilation (or translation) is a little slow but bearable, and it is nice to have a common language and tooling between the frontend and backend. Most of the libraries provide and maintain typescript definition files when they are not themselves written in Typescript. Sometimes I think the language goes too far in the features, I had a look at the latest versions and was a little bit puzzled by the complexity. But even for small projects to larger ones, I definitely prefer statically typed languages (with type inference and even implicit ones) especially when time is limited to write tests and have a good test coverage.
Typescript is boring, and boring is definitely something need to be treasured in the frontend world.
Typescript + NodeJS + React + Server Side Rendering yeah...
I love my young colleagues, I really do. I enjoy their infectious enthusiasm and only quietly discreetly in the secrecy of my mind recall how we built strongly typed JSP sites that did more or less the same thing 20 years ago. But in those days we got excited by Struts, Tomcat and JMS.
Verily there is little new under the webdev sun...
Verily there is little new under the webdev sun...
I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.
As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.