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 TypeScript still is a fad at this point, his definition of fad is far lengthier than mine is.
I’m fairly sure TypeScript will remain in popular use longer than whatever project you’re working on 😅
No, because raw-dogging JavaScript isn’t something grown-up software shops do.
[Object object] would like a word
Can’t they just use JSDoc?
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 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?
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 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.
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
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.
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.
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.
Wow, he’s living in 2012 or whatever. A true time traveler.
When anyone in a professional setting says they don’t like having a mega corp supporting something I lose a bit of respect for their opinion tbh.
Yes we all know mega corps suck.
But if you’re using anything in a professional production environment that is meant to last in the long term this is 100% what you want.
Some of us are old enough to remember the browser wars and EEE, so I definitely understands not wanting to be sucked into some mega corps eco system with future lock-ins. Often you can’t do anyhhing else, but that doesn’t mean it doesn’t suck.
Same. Writing sites that relied on IE was always a stupid decision and kinda invalidated the point of writing a web app.
I think most people knew that and the managers fucked up big time pushing it. At least in my experience.
But that’s very different to choosing a programming language.
I mean it is fair to say sometimes it depends on the mega corp, if the whole thing relies on one corp if they’re funding dries up then the whole project dies. But I also don’t really think typescript would die without Microsoft now
Id rather quit than go back to pure JavaScript.
But it’s so sexy. Strongly typed language? *Scoff
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.
Typescript is the only way I can agree to code in Javascript. And the only way you can have a sane project without writing double or triple the amount if unit tests for each function just to check things that a compiler would do. However it is absolutely a lipstick on a pig thing with confusing behavior sometimes, but that’s because the underlying language it is trying to make bearable is bonkers
Static typing, for the win, and I’ll die on this hill.
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
TypeScript is the new DOC format.
Create a language/format. Spend all of your effort making it ubiquitous until it becomes the default “standard” in the workplace. Then charge a metric fuck-tonne for the “official” software that makes use of it.
It’s how Office became their cash cow. They create the proprietary doc format, get everyone using it, and once it’s embedded in the workplace, charge exorbitantly for the software that uses it.
Once they get everyone using TS as a new industry standard, they’ll find a way to make people have to pay for it. Mark my words.
I honestly think this is fearmongering. Yes, Microsoft is a shitty company that has done shitty things, but:
- the Typescript repo is licensed with Apache 2.0, which means the community can always fork it if they do bad/evil stuff
- there are competing type checkers in the works, which would fully remove any Microsoft influence from a developer using Typescript
- there already are competing compilers which are broadly used
The only real option they have to do what you’re describing is to implement new features that could be used for monetizing it - there would be some inertia regarding community forks. But even then I can’t come up with any monetization model that could make sense. Do you have a specific example in mind?
I hope you’re right. But my trust level for corporations is somewhere between 0 and 0.1
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?
I thought of Pascal, Java and C#, but pretty much any language listed here as “explicit / nominal / static” makes the cut:
https://en.wikipedia.org/wiki/Comparison_of_programming_languages_by_type_system
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.
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
I’ll riot if I ever need to write pure js again. 98% of web devs would be better served writing in TS. If you’re actually knowledgeable enough to write more efficient js, more power to you but honestly I was probably being generous saying 2% of web devs fall into that category.
Even then, it just leaves behind an illegible mess that the next dev has to gut and replace with typescript later. If someone wants to use JS on their hobby project, go for it. The extra tools that types enable are super valuable for a team.
