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?
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.
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
The developer of Svelte moved from Typescript to JSDoc and explained in depth in an interview (you can find it on youtube). ECMA (the dudes making Javascript/ECMAscript) also started noticing that maybe static typing would be useful and there’s a proposal to add typing to it. Whether that’s moving forward or not, no idea, but if it were to come to vanillaJS, it’s imaginable that typescript would be much less useful than it is now.
If JavaScript implements type safety then I believe it will go away. If not then it will continue to be used.
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.If I was using TS I would still document using TSDoc anyway.
Yeah but you wouldn’t put the types there. Putting types in JSDoc is awkward.
You can use jsconfig.json instead.
Unfortunately not. I even went as far as reading the source code for VSCode. There’s no way to e.g. set
noUncheckedIndexedAccess.
Your manager is an idiot.
They already said he is a manager, no need to repeat
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
As a Go dev, its simplicity is arguably taken too far. For example there are no union types or proper enums
That’s fair, I know they’re actively rejecting inheritance, but I wish you could make like a prototype. Like say, a function can take a struct with these fields. Which yeah an interface can do but is much more clunky
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.
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.
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.
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.
You can have hundreds of dependencies whether you use a compiled or interpreted language, that really has nothing to do with that.
Also compilation has lots of benefits, including being able to do lots of static analysis to find bugs. I definitely don’t agree that we should move away from compilation in general or WebAssembly specifically. WebAssembly doesn’t have to be only used for low level stuff, you can write your code in a high level language and compile to WebAssembly just fine.
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.
Oh I’m not worried, at all.
No. Dynamic typing, though, is absolutely a fad.
It might not be a fad, but it’s definitely a local maximum and/or a limitation that many devs seem to be stuck with.
Dynamic typing is not a fad.
Python is older than Java, older than me. It is still going strong.
This just blew my mind. I had always assumed Java was older. I started writing hobby projects in Java in the 90s. I don’t think I heard about Python until the early 2000s.
“Strong”… how many actual projects run on python?
Half of the internet ( backend) runs on java, banking, your government systems, etc.
It’s not a fad, it’s just unusable for anything other than research project and small time scripting, which to be fair, it’s what it’s designed for.
I work in investment banking environments (calculations). Python is everywhere. Java and C++ as well.
Yeah calculations, not actual software… how is this hard to understand… you don’t write long lived, stable software that multiple developers work on that needs to do real work in python
So, calculations are not actual software… I’ll stop there.
No, it’s a script
Well, no
You have no idea. Python (and Ruby) are used widely in the industry. Large parts of YouTube are written in Python, and large parts of GitHub are written in Ruby. And every major tech company is using Python in their offline data pipelines.
I know of systems critical to the modern web that are written in Python.
With how shit youtube is I am not sure you made a great case for python mate.
And every major tech company is using Python in their offline data pipelines
Thats a meaningless statement, ETL tools can execute python as part of a multi step process and then yeah they use python in their data pipeline, but the ETL tool that orchestrates it is which is the actual value add software is not written in Python it’s written in Java, I know this for a fact…
With how shit youtube is I am not sure you made a great case for python mate.
I’m not good with names about logical fallacies but that sure is one. You asked for “actual projects” and YouTube is one of the biggest and most popular platforms out there. That you personally dislike it is irrelevant.
ETL tools can execute python as part of a multi step process and then yeah they use python in their data pipeline, but the ETL tool that orchestrates it is which is the actual value add software is not written in Python it’s written in Java
So what’s your point, that interpreted languages don’t count because they’re interpreted? Why stop there? It’s the actual C compiler that was used to compile the JRE that brings the value here, so your ETL tool doesn’t count.
You’re either a troll or a joke.
If you dont know the difference between software and script I am not sure I can explain it to you…
That distinction is not relevant at all in this discussion.
But hey, I think that’s one I know: should count as a strawman.
Python also has a statically typed option these days.
Edit: Previously said “strongly” instead of “statically”
Which one? There is static typing with the
typingmodule, but that’s not strong.I should have said statically typed, fixed.
Ah, gotcha, thanks! I’d have loved a strongly-typed option.
The static typing system is slowly getting there, but many useful Python patterns can’t be expressed yet. You can, for example, write a function that appends an item to a generic tuple - but you can’t concatenate two tuples. I really hope they keep expanding on the system!
Isn’t Python already strongly typed?
No:
$ python Python 3.10.13 (main, Jan 28 2024, 03:02:00) [GCC 13.2.1 20230918 (Red Hat 13.2.1-3)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def handle_foo(value: list[int]) -> bool: ... return 42 ... >>> print(handle_foo(False)) 42
A language that helps me write Javascript without writing Javascript? Nah, that ain’t no fad, that’s a grace from whatever god is up there.
You should check out Google Web toolkit, totally signs like your kind of thing.
Typescript is for people who hate JavaScript, for the most part. The bulk of the people who have been writing JavaScript for years and aren’t Java converts are still using JavaScript and will continue to do so. The Java developers will continue writing Java, no matter what language they are programming in.
Thank you for the suggestion. I’ll check that out. I’m actually only writing TS temporarily for work. I’m going back to C# in a couple of weeks.
As long as JavaScript is being used, TypeScript will be used. It makes writing JavaScript tolerable.
Imo they’ll add typing to vanilla js, which will kill ts.
And also JS.
Well “kill” is perhaps a strong word but it definitely won’t be JS anymore at that point. The changes required to bake in strong type support would be radical.
the can’t add proper typing without adding a compiler. Whatever they add will be closer to puthon’s type hints. I’ve had to write primary in python lately and type hints help very very slightly, and tools like pyright catch so many false errors due to lack of hints in libraries that we’re forced to add ignore statements on too many lines. I genuinely don’t understand how there can be so many languages and all of them be painful to use
I genuinely don’t understand how there can be so many languages and all of them be painful to use
What about kotlin?
yes I heard it’s great. Scala was one language where I didn’t constantly feel like getting hit in the head with a hammer and I’ve heard Kotlin has a similar experience. I’m not interested in Android development so I haven’t tried it
Kotlin isn’t just for Android; IMO unless you’re trying to do purely functional programming, it’s preferable to Scala for JVM work.
Yeah anywhere were you would use Java. Scala has a too high adoption cost. Kotlin is better suited for enterprise, has a stronger ecosystem and better interop with Java. I did enjoy scala though when experimented with it. The only thing I missed was the lack of control flow, no labels, continue, break
I have very minimal pain in Go
I’ve heard good things about it, looking forward to learning it (hopefully soon)
I was able to pick it up extremely quickly. Just basically looking at existing projects. Tbh, I don’t even know how I learned it.
That would be a great solution, because while I love Typescript, I hate compiled web code. One of the coolest things about the internet is that as it’s supposed to work, you can download the source code for any website you go to. It’s open source by design. I hate closed source websites and I hate compiled website code that helps close the source it’s quite a contradiction because typescript is awesome and I recognise that compilation is the only way to get it to run on our web infrastructure. So it would be great if we could just type JavaScript and solve the contradiction that way.
Doesn’t typescript compile to js anyways? Is it obfuscated?
It’s not intentionally obfuscated or minified. Generally it just strips out types and comments, but depending on how it’s configured, it will rewrite certain things to work in ES5. At my work our build process uses a separate minification and bundling step, which also serves to a obfuscate our proprietary code.
It transpiles to js and there is some level of stripping for optimization yes.
And the ts devs support this
And I’m sure Microsoft would be happy to not have to do it anymore. And I personally would much prefer an actual typing system rather than a glorified linter.
Tho I wonder if it will end up being like jQuery, in the sense that, by the time core jQuery features got added to vanilla js, jQuery had developed new features that validated its continued existence. Maybe TS will go further than what gets absorbed into JS and keep it alive.
Honestly, I’ve never used jQuery despite writing JS for over 10 years. Just because I hate the reliance on massive nebulous packages so many have. Especially when I looked into it years ago, so much of what I saw jQuery being used for was stuff that was extremely easy to implement yourself. How has it changed?
jQuery is a lot smaller and less nebulous than its competitors (looking at you,
Reactliterally every JavaScript framework).Jquery was what was popular when i learned js. I’m kinda glad it was, honestly: jQuery is a little unique in that it doesn’t have magic to it the way js frameworks do. Everything you can do in jQuery, you can do in vanilla JavaScript pretty easily. With, say, React, how is a newcomer supposed to understand how a series of React components become HTML?
So jQuery kept it “real” for me. Fewer abstractions between me and the HTML meant it was easier for me to connect the dots as a self taught developer.
As for how it’s changed, it’s more any how vanilla JavaScript has changed. A lot of the things that made jQuery so much easier and cleaner than vanilla are now baked in, like document.querySelector(), element.classList, createElement(), addEventListener()… It had Ajax methods that, before jQuery, were a tremendous pain in the ass.
jQuery was great, but, you basically had to use it with something like PHP, because it had no back end. So when angular came out (and a few others that aren’t around anymore and I’ve forgotten), it allowed you to replace both PHP and jQuery, and developers rejoiced.
Why did they rejoice? I’m not actually sure there was reason to, objectively speaking. As developers, we like new tech, especially if that new tech requires us to think about code differently, even if, in retrospect, it’s a hard argument to make to say that, if we had just stuck with PHP and jQuery we would be somehow worse off than we are with React.
Of course, in tech, when a new system changes how we think, sometimes (not as often as we’d like) it helps us reconsider problems and find much more elegant solutions. So, would we have all the innovations we have today if all these js frameworks has never existed? Obviously we can’t really answer that – but it’s a toke of copium for when we get nostalgic for the PHP/jQuery days.
(Also, for you newer people reading this, you should probably be aware that the PHP/jQuery mini-stack is still very quietly used. You’ll definitely see it, especially in php-baaed COTS.)
Thanks for informing me, but I still kinda wonder why someone would use it today?
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 ;)
Based solely on gut feel, I think Typescript will become less popular as Wasm grows
I think you’ve got a point here, in that the sort of Devs who want to be able to refactor their code without breaking everything are also going to be the group who lean more into having code that actually runs quite fast; but given that reasonML is awesome and didn’t get much mindshare my position here is that wasm will only start to eat into tyspecript’s lunch well after a huge subset of TS can be compiled to wasm (or maybe python ((I blame the xkcd guy for python’s unreasonable popularity, I feel it’s hugely overrated))).
When will Wasm grow, according to your gut? I feel like I’ve been waiting for a decade now.
By saying gut feeling I hope I am being clear I have zero tangible evidence? 😅
Maybe over the next decade its usage will grow? Or maybe it will end up relegated to performance critical applications, or JS/TS just end up with the same/better performance anyway.
The next step is to implement things like this:
https://github.com/WebAssembly/tool-conventions/blob/main/Coredump.md
After that, all we need is a rich ecosystem of libraries in other languages. It’s still a fair way off, but it’s coming.
WASM made huge strides last year. You can run entire operating systems inside a WASM hypervisor now, and lots of packaging and transpiling projects came of age last year.
Great, but can you access the DOM?
JavaScript will implement the things that work out in TypeScript. So… yes and no?
Imagine changing your file extension from .js to .ts and calling it a fad. JS is TS. The difference is that TS does more (by actually doing stuff before runtime as a static analyzer, similar to eslint). If TS is a fad, then modern web dev is a fad.
Which, to be fair, it is.
