I was talking to my manager the other day, discussing the languages we are using at $dayjob. He kind of offhandedly said that he thinks TypeScript is a temporary fad and soon everything will go back to using JavaScript. He doesn’t like that it’s made by Microsoft either.
I’m not a frontend developer so I don’t really know, but my general impression is that everything is moving more and more towards TypeScript, not away from it. But maybe I’m wrong?
Does anyone who actually works with TypeScript have any impression about this?
If JavaScript implements type safety then I believe it will go away. If not then it will continue to be used.
Wait until they realise its pointless…
I hope not. I’m pretty sure me and my coworkers would be at each others’ throats if it were not for some form of typed JS holding our Frankenstein codebase together.
What’s the point of calling something a “fad”? If the technology works well and it provides value to you, why should you care what other people think?
(Example: Look at PHP)
The point of calling something is fad is a way to tell you that you shouldn’t invest a lot of time into this because that knowledge will become obsolete soon.
I mean this is particularly relevant in the JS world because every week there’s a new revolutionary framework that renders the previous framework obsolete. (Although, not sure if that’s slowing down now…)
Hi, I’ve been doing TypeScript in my day-job and hobbies for six and a bit years now. I would not write JS in any other way.
TS is also a superset of JS so all JS is valid (unless you turn on
strictmode). So there is no productivity loss/learning curve unless you want there to be.In fact, a lot of people who think they’re not using typescript are using it because their editors use typescript definitions for autocomplete and JSDoc type signatures are powered by typescript.
So there is no productivity loss/learning curve unless you want there to be.
It’s not significant but an extra build step can be annoying
For me, personally, yep; 100%. I’ve tried at least 3 times to convert, it just gets in my way. I’m way way faster with plain old JS. But I’m also a Rubyist so it is all ducks anyway.
Wow, he’s living in 2012 or whatever. A true time traveler.
Javascript is a fad, we should all move to WASM. 🙃
But no, TypeScript is not a fad. Unless a better “Typescript like” thing comes out - I know how in frontend land people like to make their own substitute framework that does something slightly different than an existing framework - But I don’t really see why anyone would want to make a NewTypeScript, and not just expand existing TypeScript
I don’t see it dying from my perspective. Its only been getting better and better. The only thing I could see displacing it in my org is maybe Rust due to WASM proving a transition path.
We use TS on the back end to leverage our teams existing skill set and libraries we’ve built up.
I know it’s a meme to use “the next best thing” in the ecosystem, but we’ve been really happy with the newish Effect library + Bun runtime. Effect is like a merger of the older fp-ts/io-ts libraries (same author works on both) with Zio from the Scala ecosystem. It vastly simplifies the former and the new stuff with dependency injection and defect management is refreshing. With the Bun runtime, we see a 15x faster startup time (great for dev). Its halved the RAM requirements in prod. We don’t even need to transpile… We still do for prod to tree-shake dev-only code to ensure its not available in prod, but deploying to dev is FAST.
20 years into the future, once WASM has been widely adopted, a browser within a browser will have been created, with its own equivalent javascript, which will then lead developers to create a WASM equivalent for a web browser running in a WASM browser, running on a bloated OS.
We use TS on the back end to leverage our teams existing skill set and libraries we’ve built up.
I know you said this, but I’m still curious why not just something like Go, which I was able to basically learn in 3 days- just coming from a mostly JS and C++ background
I’m coming from a Haskell/Scala background. This job just pays more. TS has been “good enough” for types. I don’t think I could be as effective without them at this point.
As a Go dev, its simplicity is arguably taken too far. For example there are no union types or proper enums
Yeah. I started as a C++ dev, fell in love with Go, then ended up on Rust.
Felt like a nice middle ground of “It’s got the types I need, but it feels good to dev on”
I really did enjoy using go for smaller projects though, would do so again.
Have you tried slapping your manager?
He might’ve watched this video: https://youtu.be/5ChkQKUzDCs
TL;DR: Big projects, like Svelte, Drizzle and Turbo ditched TypeScript
I don’t really get the appeal of strongly typed languages. Can’t you just use try/catch blocks, and/or use functional programming and return early if the data structure of whatever you’re working with isn’t what you expected?
I guess it can help older code easier to maintain because the expected data structure is right there, but you could also just include it in a comment above the function.
I personally find TS slows down initial production of a project and raises so many unnecessary errors.
Is there some huge benefit that I’m missing? Because I don’t really get the appeal. I mean, I do on some level, but I don’t really understand why so many people are absolutely obsessed with TS.
I like typescript because my API can generate types for my FE project.
So, if i change my API, i pull in fresh types and fix the errors, and i get in-ide hints for the shape of payloads, responses and events. Not everything is simple CRUD.
Also, if you pull in a library, having types is a godsendIs there some huge benefit that I’m missing?
For example I recently fixed a bug where a function would return an integer 99.9999% of the time, but the other 0.0001% returned a float. The actual value came from a HTTP request, so it started out as a string and the code was relying on dynamic typing to convert that string to a type that could be operated on with math.
In testing, the code only ever encountered integer values. About two years later, I discovered customer credit cards were charged the wrong amount of money if it was a float value. There was no exception, there was nothing visible in the user interface, it just charged the card the wrong amount.
Thankfully I’m experienced enough to have seen errors like this before - and I had code in place comparing the actual amount charged to the amount on the customer invoice… and that code did throw an exception. But still, it took two years for the first exception to be thrown, and then about a week for me to prioritise the issue, track down the line of code that was broken, and deploy a fix.
In a strongly typed language, my IDE would have flagged the line of code in red as I was typing it, I would’ve been like “oh… right” and fixed it in two seconds.
Yes — there are times when typing is a bit of a headache and requires extra busywork casting values and such. But that is more than made up for by time saved fixing mistakes as you write code instead of fixing mistakes after they happen in production.
Having said that, I don’t use TypeScript, because I think it’s only recently become a mature enough to be a good choice… and WASM is so close to being in the same state which will allow me to use even better typed languages. Ones that were designed to be strongly typed from the ground up instead of added to an existing dynamically typed language.
I don’t see much point in switching things now, I’ll wait for WASM and use Rust or Swift.
Can’t you just use try/catch blocks
No, because what if whatever you’re calling is updated and suddenly it throws a new exception where before it didn’t? Python or JavaScript or other interpreted languages will never warn you about that.
if the data structure of whatever you’re working with isn’t what you expected?
That sounds like a whole lot of boilerplate I have to write to verify every time that something is what I expect. Static typing does that for me much easier and more reliably.
Some languages like Rust have so good type systems that often when a program compiles, it just works. You don’t have to run the code to know that it functions if you only make a small change.
What kind of systems have you worked in? In small systems, the static analysis doesn’t matter as much, but the benefits become bigger and bigger the more code there is to analyze.
Interesting argument. I have used both typescript and JavaScript, but I spend 99% of my time writing firmware in C, because of this I LOVE strongly typed languages, and I get kinda annoyed/paranoid when my variable COULD change type quietly so end up doing (perhaps too much) type checks etc.
I can say with surety I hate programming in both Typescript and JavaScript, but I definitely hate Typescript less because of the typing.
Having said that, I don’t really like the compiled javascript that comes out of the typescript compiler, because it puts some distance between the user and the code and I am all for clarity, especially when people have to go out of their way to not run this code.
Let me reverse this question and ask what is the benefit of dynamic typing? What is gained from vaguely defined objects?
The purpose of typed languages is to ensure the bare minimum when it comes to safety. That when you’re accessing a field of an object that field is real, and that field is always going to be an int or a string.
Try/catch only goes so far before it becomes way more cumbersome than necessary, as is checking every field of an object.
Typescript is an example of a language that does static typing poorly, because by design it has to. It’s a quick bandaid fix over an inherently awful language.
To be honest Typescript and Javascript for me are both very bad Hacks driven languages. I explain myself: I’ve worked on a project for a client, with other devs who were experienced js/ts devs. Before to get on, I’ve read a book about them, went through the docs. But in the end, I would push PRs, and there was some hacky way to do stuff, now some stuff is just bad developers, choosing the hacky “obscure” undocumented way to do something, but other solutions were clear enough that deserved to be documented. Overall I am better off without using those
Unpopular opinion perhaps, but I rather have a language that allows me to implement hacky solutions than one that requires me to completely scrap and rearchitect everything.
I for example once had to overwrite a dozen or so of prototype methods in a JS class because the library a we were using just fell apart when doing certain things inside a Shadow DOM - it was a library that was released long before that feature. And completely rewriting huge chunks of code that interacted with that library would have wasted 100s of hours and the end result might have been really akward as well since many other systems are architected around how that one library worked. So instead it was a matter of patching in a few checks and workarounds for shadow dom elements.
And since its extremely well documented why we decided to to that, what these hacks do I don’t see an issue with that. Obviously this shouldn’t be the modus operandi everytime but its always good to have the option i.m.o. to dig yourself out of a hole.
In a small company with a non-complex product, there is a chance that TS creates more slowdowns than not.
In a large company with multiple cooks in the kitchen and a complex product, I’m personally of the mindset that there is substantial gain from typescript. I’ve had coworkers tell me it’s bullshit, and then I do the smallest lift possible to convert and the amount of bugs it reveals are insane.
Is it necessary? No, probably not. But unless everyone’s a 10/10 dev working on the world’s simplest product, why not just do it and enjoy the benefits?
INB4 JavaScript blahblah, yeah I’ve added type hints to pure JS projects too and discovered bugs. At this point I don’t get it. Typical resistance I get is that it’s too prescriptive and lacks JS’s dynamic nature - well, fuck off, I don’t want to read through 200+ lines of code where you’re changing types and shit on me willy-nilly.
The only valid argument against typescript is that it is too similar to vanilla JavaScript. It does not go far enough. We need type systems like Ocaml’s.
I suppose you can also complain about needing a build step, but I find this silly. There are so many tools that make this easy or automatic.
What’s so special about Ocaml’s type system?
I won’t remember everything, but one very important things comes to mind:
in Typescript, it is very difficult to assert on a type (let me know if you’re not familiar with what I mean by this and I can explain further). In OCaml, this is trivial using pattern matching.
Why would you need that? The idea of a type system is it doesn’t let you apply a function on a structure without the structure being of the right type. But the lack of type assertion in TS makes people follow hacky workarounds, which defeat the purpose of type system.
There are a couple of other things, like immutable types by default, automatic tail call optimization, functors enabling higher kinded types, etc.
Also in ocaml, you don’t have to annotate any types on any variable or parameter, and you’ll still get full type protection.
Oh, so what you’re describing is strong typing. I thought it was a unique feature of Ocaml. But in reality, any strong-typed language will have this as well.
And yeah, Typescript merely “suggests” typing, and it will allow you to build the project even if you ignore the type errors. A build system refusing to, well, build, if there are typing errors usually takes care of this, but again, the dev team may as well not implement this.
Any examples other than ocaml? From my understanding, ocaml’s type strength may only be found in a couple other languages. Haskell, scala, and maybe Rust. Any others?
