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?
Technicalities aside, TS is being pushed by MSFT in their SaaS custom components, and that right there will keep it relevant a while. MSFT is known for changing names a lot, but not for killing technologies.
After over 5 years of writing TS, I have had to do plain JS sometimes, and it is scary. It feels like walking blindfold. I’m spoiled.
MSFT is known for changing names a lot, but not for killing technologies.
Silverlight would like a word ;)
Personally I’d rather use JSDoc in my own projects for type annotations and call it a day. I find TS a bit annoying but that might be because I’m not that familiar with it.
That’s just Typescript with extra steps.
Though I have also done this once or twice for single-file projects where I didn’t want to deal with actually running
tsc. It has some annoying downsides though, e.g. you don’t get to have atsconfig.jsonand the syntax sucks.Microsoft had a proposal to allow TS annotations in JavaScript which would have been awesome and fixed the syntax issue.
Looks like it was discussed a year ago and hasn’t really made much progress. Seems like lots of people wanting to shoehorn runtime type checking onto it.
Is it? I just have it auto-generate in my IDE with snippets. If I was using TS I would still document using TSDoc anyway. You can use
jsconfig.jsoninstead.
A fad? No, definitely not. TypeScript brings features (and structure) that will /should probably make their way into JS.
It’s sort of like asking, “does SASS replace CSS” or “is liquid the next HTML?” They’re just implementations of features FE developers want in the core spec of JS, CSS, and HTML.
Hoping this is true. The biggest annoyance with typescript is needing some kind of compiler. Haven’t used Bun or Deno very much, both of which natively support TS, but there are still incompatibilities with the way Node does things and how certain modules were built (CommonJS vs ESM). I like writing JavaScript but the tooling is utter crap.
that will /should probably make their way into JS.
Not really, IMHO. The main advantage of TS is that it will help you catch errors without having to run a particular piece of code - i.e. you won’t have to move to the third page of some multi-page form to discover a particular bug. In other words, it helps you catch bugs before your code even reaches your browser, so it doesn’t bring you much to have them in the browser.
(There is a proposal to allow running TS in the browser, which would be nice, but you’d still run a type checker separately to actually catch the bugs.)
I think the important part is that the syntax will become standardised, rather than being defined by microsoft/typescript, potentially allowing for alternative implementations. It could also make the build step optional in some cases, which is something people dislike about typescript currently.
I believe both are true… and I also develop a LOT in Angular (with TypeScript).
TypeScript is great but the thing is that if you look at the history of TypeScript and JS/ECMAScript you’ll find out that TypeScript sometimes is the testing ground for the future features of ECMAScript - pretty much like what happens with Sass and CSS that how even has nesting and scopes.
The issue with TypeScript/Sass etc. is that it requires a compiler and that’s totally obnoxious and completely defeats the point of having interpreted code on browsers. Depending on the project it might be better to go for TypeScript + Angular/React or other compiled solution or simply something vanilla with jQuery or the Vue runtime (no compilation) and other libraries.
If TypeScript ever goes away the underlaying features that make it great will be implemented in ECMAScript in the same way that we got modules, classes etc. and I really hope it happens. Less compilation usually equals code more maintainable in the long run because you won’t require hundreds of dependencies that will eventually break to get it to compile.
The issue with TypeScript/Sass etc. is that it requires a compiler and that’s totally obnoxious and completely defeats the point of having interpreted code on browsers.
Shouldn’t WebAssembly be a solution to this? I.e. so you don’t have to interpret code but rather run the wasm binary (which is kinda interpretation as well but you get what I mean).
I love seeing webassembly getting traction because it enable cool stuff never thought possible before running in web browsers. But webassembly is a blackbox that can’t be tinkered with by end users. I dread the day webassembly become so widely used that average websites run under webassembly because that would be the end of blocking ads or tweaking websites behavior with greasemonkey scripts.
I don’t think adblockers rely on interpreting JavaScript, I think they would still work even if a site used WebAssembly.
Source: I can assure you every single ad-funded website would be doing this if that was the case.
ublock origin won’t help you blocking the ad elements if the entire website ui is rendered in a canvas (already starting to happen thanks to some frameworks like flutter) and can’t block the ad logic if it bundled in the wasm along with the rest of the app. It might still able to block the requests, but they’re starting to serve the ads from the same domain that serves the website so it can’t be blocked without breaking the website itself, and might begin to serve those over websocket so adblockers can’t block it by url path. With javascript, an ad blocker might still be able to monkey patch the ad logic on runtime to break it, but with black box like wasm I’m not sure if such thing is possible.
Once tooling and frameworks make it easier for average webdevs to use webasm, I’m sure ad companies will begin to offer it in their ads sdk. Thankfully most websites with ads are still care about SEO so at the very least we can be sure it won’t happen anytime soon, unless something changes in how google works that could enable this.
the entire website ui is rendered in a canvas (already starting to happen thanks to some frameworks like flutter)
That sounds like an accessibility nightmare.
Have you tried not being disabled?
Flutter devs actually defended this approach, saying the web in general is moving to this direction. I think they’ve mellowed out somewhat and released html renderer support, though it’s still default to canvas for desktop web browsers.
That’s not a solution, it is the exact opposite - adding even more compilation and complexity to things. The ideia is to move away from compiled stuff as much as possible. WebAssembly makes sense for very complex and low level stuff that you can’t run interpreted with reasonable performance.
Less compilation usually equals code more maintainable in the long run. Think about it: if you don’t need a compiler and the hundreds of dependencies that will eventually break things will last way more time. Websites from the 90’s still work fine on modern browsers and you can update them easily while compiled stuff is game over once you lose the ability to install run said compiler and related dependencies.
TypeScript sometimes is the testing ground for the future features of ECMAScript
They have an explicit policy to only include features that are stage 3 already (i.e. that are pretty much certain to land in the language as-is). The only times they’ve diverged from this is long in the past (I think
enumis the main remnant of that, for which I’d recommend using unions of literal string types instead), andexperimentalDecoratorsunder pressure from Angular - which has always been behind a flag explicitly named experimental.So I really wouldn’t worry too much about that.
Your manager is an idiot.
They already said he is a manager, no need to repeat
JavaScript will implement the things that work out in TypeScript. So… yes and no?
after reading the title I thought he’d suggest something better than TS would take its place, but going back to JS? nah
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 front-end land people like the 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
Javascript is a fad.
Reject web dev; return to native.
Typescript makes writing Javascript a reasonable thing to do. Your manager is a fad.
Your manager is a fad.
If only…
TypeScript might not be here to stay, but typed JavaScript definitely is. I’ve switched to writing 100% TypeScript, and haven’t looked back. The fact that just adding types to one of my (admittedly more complex) libraries surfaced 3 unknown bugs was eye opening to me.
Wait until they realise its pointless…
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.
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.
Is 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.
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.
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 godsendInteresting 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.
He might’ve watched this video: https://youtu.be/5ChkQKUzDCs
TL;DR: Big projects, like Svelte, Drizzle and Turbo ditched TypeScript
Have you tried slapping your manager?
