A few days ago, David Heinemeier Hansson
announced
that Turbo 8
is dropping TypeScript
. I'm okay with that because I don't even know what Turbo 8 is. However, over the past few years, some frontend programmers have tried to sell me the idea that "TypeScript is useless, just use tests". I think people with such opinions either don't care about code quality or simply don't know what TypeScript is. Here, I will explain why you should use TypeScript.
Man there have been hot take after hot take in the programming communities over the past few days. Here, I’ll give my hot take since nobody asked:
If I have to touch your code and I can’t tell what inputs it’s supposed to accept, what it should do with those inputs, and what outputs it should produce, I’m probably deleting your code and rewriting it from scratch. Same goes for if I can trivially produce inputs or states that break it. If your code is buggy, it’s getting fixed, even if that takes a rewrite.
When working with others, write readable and maintainable code that someone with much less context than you can pick up and work on. It really doesn’t matter if you need to use TypeScript, mypy, tabs, doc comments, or whatever to do it.
When doing your own project, it doesn’t matter. It’s your code, and if you can’t understand it when you come back to it then you’ll probably rewrite it into something better anyway.
100% agree. Typescript is just a bandaid on top of a broken language. Sure it’s better than bleeding, but it’d be preferable not to get injured in the first place.
Expect to see more posts like this. With a few projects announcing they’re dropping support for TypeScript we’re going to have developers worrying that this tech that they’ve sunk so much time into is suddenly becoming obsolete, so they’re going to evangelise hard in favour of it as a defence strategy. Same thing happened when Perl went out of flavour.
I said a few, friend 😛 I agree it’s not a big deal, but for developers that are totally entrenched in that ecosystem it might be alarming. Hence OP’s post.
I’ve seen so many front-end libraries come and go over the 25 years I’ve been doing this. Be good at programming in general, and you can usually hop on board the incoming train pretty easily and hop off again before it goes off a cliff. You can’t really get too attached to anything in an ever changing industry.
Reading the responses here, why are people so mad about types? Maybe I’m biased coming from a background of statically typed languages and mathematics. I’d rather have a good typing system that makes me think about data than just hoping I’ve thought about a problem right.
I dunno. I think it is people don’t want to think about their code and what they are asking the computer to -actually- do. I’ve had to fix more issues due to incorrect assumptions that were allowed / looked OK in JS that would have been easily seen and/or prevented in TS (or any strong static typing system). Yes, TS may be annoying, but there are -reasons- it is. If you’re asking it to do something that is innately dumb, TS makes it -HARD- to do it, so you manage a large majority of the potential use-cases that you may not know you’re asking the runtime to manage/assume for you.
I have valid criticisms of statically typed languages, based around code patterns that are both expressive and efficient that are either difficult or impossible to implement in a statically typed language without “an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”
Typescript, however, is different. Its type annotation functionality is not the same as a static type system, which means I get to keep all those things I like about dynamically typed languages while still having compile-time validation.
Flip-side, however, is the complete lack of runtime validation in typescript, and the fact that junior developers trip on that a lot. I would call that a real advantage of javascript (if not enough to stop me from using Typescript). Having no check at all is better than being convinced typescript is protecting you when it’s not.
I’m half joking, but the problem with typescript is that it’s JavaScript with types. The industry needs to stop retrofitting types to dynamically typed languages. The type system is an intrinsic part of the language design and if you’re going to have it, it should be there from day 1. Being dynamically typed wasn’t a language bug. It is a feature designed for a certain class of problem. I’m sure 90% of proponents only want it so they get better completion in their IDE, but I personally think it makes a lot of code far more difficult to read.
After having to use TypeScript in a project, I don’t see much usefulness. It feels more like a weird linter, than an actual language with extra features. It’s tons of ugly boilerplate for little gain, at least so far in my experience.
Writing code that can’t be scientifically proven to be correct on all hardware it might run on means you don’t care about code quality. /s
The Internet is full of people with a bloated ego trying to justify their opinion and gatekeeping others.
I see this more and more in software as well.
Not sure if it’s always been like this, or if I just notice it more.
Same way there’s thousands of people giving you a guide to write a task list in , but as soon as you want to use anything slightly more complex than what you can learn from working a few hours with something you quickly run out of material and is usually left to fend for yourself.
WASM allows arbitrary code execution in an environment that doesn’t include the DOM… however it can communicate with the page where the DOM is available, and it’s trivial to setup an abstraction layer that gives you the full suite of DOM manipulation tools in your WASM space. Libraries for WASM development generally provide that for you.
For example here’s SwiftWASM:
let document = JSObject.global.document
var divElement = document.createElement("div")
divElement.innerText = "Hello, world"
_ = document.body.appendChild(divElement)
It’s pretty much exactly the same as JavaScript, except you nee to use JSObject to access the document class (Swift can do globals, but they are generally avoided) and swift also presents a compiler warning if you execute a function (like appendChild) without doing anything with the result. Assigning it to a dummy “underscore” variable is the operator in Swift to tell the compiler you don’t want the output.
That is disturbing. From my perspective, anyway. There are already so many great (and more appropriate) stacks for web backends, why Frankenstein a Frankenstein into it?
Well, usually because you’ve got a team of frontend folks needing to do a backend.
There’s one other advantage, which is that you can have a compile-time shared model between backend and frontend. You also have that advantage with WASM, but not with a traditional backend/frontend technology split…
Compile time is my biggest issue with TypeScript. I’ve used JavaScript for decades with compile time measured in, what, a millisecond or two. Having to wait for TypeScript drives me nuts.
I wrote some TypeScript modules to process a bunch of documentation in markdown to a ton of output formats via pandoc + latex.
No real reason for it, except that I was able to start with the export module of a node-based thing written in JavaScript and iterate from there until I had a working system in CI/CD.
Because at the end of the day TypeScript is still Javascript and it’s still bad. Just has some verbose formats to try and make weakly typed language (javascript) appear to be strongly typed. It adds more build steps to what shouldn’t be there; build steps make sense for apps, they make much less sense for libraries.
I’m sorry. Whoever wrote that should give up trying to write articles. It’s poorly written and will never convince anyone to change their mind. It’s shit. “I know how to convince people they’re wrong. Insult them. Setup a ton of strawman arguments. Genius.”
Second one. Just realized there were two. Being close together and the first being long enough to get trailing “…” it all just looked like one big link when I first saw it. May just be Kbin displaying it that way.
build steps make sense for apps, they make much less sense for libraries.
This might be true, but it’s not about build steps, it’s about having detailed iformation of the types of the objects that the library is serving. not knowing the typing of the functions a library is serving is… poor. Maybe typescript is too strict and having something like type hinting like python has would be enough since linters pick up the hints from the libraries, but doing just JS only fuck the people that use the library.
Or a signal that you’d rather not support the worst way to introduce type systems to frontend dev. While I’m not sure that applies to DHH, I am sure there are other devs that understand compromising all your goals to codepend on Node or even JS itself isn’t that much of a win and rather see support for better options.
maintainability is arguably not a value-added for the end user. But still absolutely important. Robustness of code is arguably not visible to an end-user, until it fails. And that’s very important. Features are great, but quality is still important and is basically the mortar between the bricks that are features. Only caring about features leads to poorly written applications.
If you can’t see that writing readable code is part of the means to that end, I don’t know what to tell you. If nobody can maintain the codebase because it’s a mess of spaghetti logic and 20-deep dependency trees (I’m looking at you, every JavaScript project I’ve ever seen), the end product is going to suffer while also making every single engineer working on it want to leave.
This is not a controversial take in professional software development.
Funny, it sure seems like “maintainability should not be a priority” is a pretty controversial take to me.
You are making a lot of assumptions. You don’t know what my product is, how it is developed, what it’s used for, what its lifecycle is. Whether improving maintainability or code quality would be a net benefit, and whether using type script would be a possible solution.
You also didn’t bother to find out.
You just charge at me guns blazing, trying to string me up for heresy.
Funny, it sure seems like “maintainability should not be a priority” is a pretty controversial take to me.
How many things can you prioritize?
In my world we prioritize one. And that not the one.
Weird. In most cases priorities change as the situation demands. The application doesn’t matter when it comes to maintainability. Tech debt will take down any application if you keep ignoring maintainability at the expense of just delivering more and more. You sound more like a manager than a developer.
Even their excuses if a “24h only event app” don’t hold water
Even in that case, a business would be wanting to make many of those apps, and this commenter is arguing making a new one from scratch every time over massively simplifying things with quality reusable code.
Even their own example shows how terrible it is an idea to deprioritize code quality/readability.
I think vzq’s point is that you can write good, readable code that doesn’t do what the user wants. Same with other metrics that are ripe for navel-gazing like code coverage.
It’s bordering on a false dichotomy… but I also believe that dynamic, untyped languages have proven exceptionally useful for rapid prototyping and iteration.
I must admit that I write that deliberately to annoy the “code quality is everything” brigade.
I have no issues prioritizing maintainability where needed, but in my experience people that dogmatically prioritize code quality are not honest with themselves. They almost never chase code quality in general. They are always looking to enforce some burdensome standard or specific tool or archaic process or fiddly CICD script, and if you push back they go cry in a corner about the abstract virtue of “code quality”.
Just be straight with me. You enjoy using type script. Tell me how it adds value to the product and the customer.
Stop trying to shame me into it. I can’t be shamed. I have no shame. I’m a professional software engineer.
You’re setting up a theoretically boogie man that no one said exists and then setup the extreme opposite point of view. You’re annoying the people that are actually sane. You’re being dogmatic in your one views and too extreme.
The idea behind Turbo is your server sends HTML/CSS to the client, and when the content needs to be updated… the server simply sends new HTML which Turbo will inject into the page. You can also annotate links so they fetch new content from the server instead of navigating to a new URL.
Your server side code can be written in whatever language you prefer… Turbo being a 37Signals project I assume they’re using Ruby. It’d work fine with TypeScript too if that’s your thing. Turbo just uses HTTP / JSON to talk to the server and doesn’t have a server side component.
You can have client side code, but AFAIK there’s pretty minimal interaction with Turbo - you might for example add an event listener that processes the HTML and as converts ISO date/times into Date.toLocaleString().
If you’re writing complex client side code then you shouldn’t be using Turbo at all.
This change doesn’t affect, at all, the language used by users of Turbo. What’s changed is the Turbo dev team themselves have chosen to write Turbo in vanilla javascript. And there are advantages to vanilla JS - it removes the compilation step from one language to another, for example.
And there are advantages to vanilla JS - it removes the compilation step from one language to another
IDK about the potency of the pc they used to compile but… it takes less than 10 seconds usually, booting up the testing server with the updated code though CI/CD takes much longer. it’s not abouthte compilation step, that’s a non-issue, it’s about the extra effort they don’t want to put to do the typing.
I prefer strong static typing for the most part. I find it difficult to mentally model code when it’s not clear what exactly is being passed to functions and whatnot. Can also use them to help ensure code correctness. TypeScript has been a welcome addition to my projects over the years and honestly I want them to implement more functionality like pattern matching expressions.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@beehaw.org
All things programming and coding related. Subcommunity of Technology.
Man there have been hot take after hot take in the programming communities over the past few days. Here, I’ll give my hot take since nobody asked:
If I have to touch your code and I can’t tell what inputs it’s supposed to accept, what it should do with those inputs, and what outputs it should produce, I’m probably deleting your code and rewriting it from scratch. Same goes for if I can trivially produce inputs or states that break it. If your code is buggy, it’s getting fixed, even if that takes a rewrite.
When working with others, write readable and maintainable code that someone with much less context than you can pick up and work on. It really doesn’t matter if you need to use TypeScript, mypy, tabs, doc comments, or whatever to do it.
When doing your own project, it doesn’t matter. It’s your code, and if you can’t understand it when you come back to it then you’ll probably rewrite it into something better anyway.
This is the core thesis of the article:
There’s no real substantiation of the claim; just the claim itself.
Maybe it’s true but it’s a weak argument.
100% agree. Typescript is just a bandaid on top of a broken language. Sure it’s better than bleeding, but it’d be preferable not to get injured in the first place.
And you can still apply the bandaid wrong.
Expect to see more posts like this. With a few projects announcing they’re dropping support for TypeScript we’re going to have developers worrying that this tech that they’ve sunk so much time into is suddenly becoming obsolete, so they’re going to evangelise hard in favour of it as a defence strategy. Same thing happened when Perl went out of flavour.
Only a few libraries announced dropping support due to their requirement generics. It’s not that big a deal. TS is still popular.
I said a few, friend 😛 I agree it’s not a big deal, but for developers that are totally entrenched in that ecosystem it might be alarming. Hence OP’s post.
deleted by creator
I’ve seen so many front-end libraries come and go over the 25 years I’ve been doing this. Be good at programming in general, and you can usually hop on board the incoming train pretty easily and hop off again before it goes off a cliff. You can’t really get too attached to anything in an ever changing industry.
I’d say the debate about using a strongly typed relational database and ORM is probably more of an impact on end-user turn around than typed language.
Whatever.
Reading the responses here, why are people so mad about types? Maybe I’m biased coming from a background of statically typed languages and mathematics. I’d rather have a good typing system that makes me think about data than just hoping I’ve thought about a problem right.
I dunno. I think it is people don’t want to think about their code and what they are asking the computer to -actually- do. I’ve had to fix more issues due to incorrect assumptions that were allowed / looked OK in JS that would have been easily seen and/or prevented in TS (or any strong static typing system). Yes, TS may be annoying, but there are -reasons- it is. If you’re asking it to do something that is innately dumb, TS makes it -HARD- to do it, so you manage a large majority of the potential use-cases that you may not know you’re asking the runtime to manage/assume for you.
I have valid criticisms of statically typed languages, based around code patterns that are both expressive and efficient that are either difficult or impossible to implement in a statically typed language without “an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”
Typescript, however, is different. Its type annotation functionality is not the same as a static type system, which means I get to keep all those things I like about dynamically typed languages while still having compile-time validation.
Flip-side, however, is the complete lack of runtime validation in typescript, and the fact that junior developers trip on that a lot. I would call that a real advantage of javascript (if not enough to stop me from using Typescript). Having no check at all is better than being convinced typescript is protecting you when it’s not.
So not typescript then.
I’m half joking, but the problem with typescript is that it’s JavaScript with types. The industry needs to stop retrofitting types to dynamically typed languages. The type system is an intrinsic part of the language design and if you’re going to have it, it should be there from day 1. Being dynamically typed wasn’t a language bug. It is a feature designed for a certain class of problem. I’m sure 90% of proponents only want it so they get better completion in their IDE, but I personally think it makes a lot of code far more difficult to read.
After having to use TypeScript in a project, I don’t see much usefulness. It feels more like a weird linter, than an actual language with extra features. It’s tons of ugly boilerplate for little gain, at least so far in my experience.
It is a weird linter, and it can definitely be misused. It saves me hours of work at least a couple times a month, however.
So what is it with Anakin’s picture? Javascript is the dark side of the, web development, force? XD
Seriously tho, valid points.
I think that’s an image caching bug.
Refusing rust and wasm is a signal you don’t care about code quality or security
See? You can keep playing that game all the way down to the most onerous language
Writing code that can’t be scientifically proven to be correct on all hardware it might run on means you don’t care about code quality. /s
The Internet is full of people with a bloated ego trying to justify their opinion and gatekeeping others.
I see this more and more in software as well.
Not sure if it’s always been like this, or if I just notice it more.
Same way there’s thousands of people giving you a guide to write a task list in , but as soon as you want to use anything slightly more complex than what you can learn from working a few hours with something you quickly run out of material and is usually left to fend for yourself.
Can wasm manipulate the DOM yet?
It can with some glue code that you better be writing in TypeScript if you care about code quality.
(As far as I know, it can’t manipulate the DOM directly. Maybe things changed in the past couple months since I checked, but I doubt it.)
WASM allows arbitrary code execution in an environment that doesn’t include the DOM… however it can communicate with the page where the DOM is available, and it’s trivial to setup an abstraction layer that gives you the full suite of DOM manipulation tools in your WASM space. Libraries for WASM development generally provide that for you.
For example here’s SwiftWASM:
It’s pretty much exactly the same as JavaScript, except you nee to use JSObject to access the document class (Swift can do globals, but they are generally avoided) and swift also presents a compiler warning if you execute a function (like appendChild) without doing anything with the result. Assigning it to a dummy “underscore” variable is the operator in Swift to tell the compiler you don’t want the output.
@RandoCalrandian @vitonsky
Languages are just tools, so let’s take the shortcut to the xkcd about editors 😁
Actually, if you really care about quality and types on the front end rust+wasm is not a bad idea 🤔
Now that I’ve typed that and read it back, were people using TypeScript for anything other than front-end web dev?
It was used pretty frequently for back end APIs too
That is disturbing. From my perspective, anyway. There are already so many great (and more appropriate) stacks for web backends, why Frankenstein a Frankenstein into it?
Well, usually because you’ve got a team of frontend folks needing to do a backend.
There’s one other advantage, which is that you can have a compile-time shared model between backend and frontend. You also have that advantage with WASM, but not with a traditional backend/frontend technology split…
Compile time is my biggest issue with TypeScript. I’ve used JavaScript for decades with compile time measured in, what, a millisecond or two. Having to wait for TypeScript drives me nuts.
🤷 people like nodejs and people like type hinting and IDE reflection. Typescript helps a lot with that
I wrote some TypeScript modules to process a bunch of documentation in markdown to a ton of output formats via pandoc + latex.
No real reason for it, except that I was able to start with the export module of a node-based thing written in JavaScript and iterate from there until I had a working system in CI/CD.
That’s actually pretty neat!
Because at the end of the day TypeScript is still Javascript and it’s still bad. Just has some verbose formats to try and make weakly typed language (javascript) appear to be strongly typed. It adds more build steps to what shouldn’t be there; build steps make sense for apps, they make much less sense for libraries.
https://dev.to/bettercodingacademy/typescript-is-a-waste-of-time-change-my-mind-pi8
https://medium.com/@tsecretdeveloper/typescript-is-wrong-for-you-875a09e10176
I’m sorry. Whoever wrote that should give up trying to write articles. It’s poorly written and will never convince anyone to change their mind. It’s shit. “I know how to convince people they’re wrong. Insult them. Setup a ton of strawman arguments. Genius.”
Whoever wrote that is bad and should feel bad.
Which one? There were multiple links in that comment.
Second one. Just realized there were two. Being close together and the first being long enough to get trailing “…” it all just looked like one big link when I first saw it. May just be Kbin displaying it that way.
This might be true, but it’s not about build steps, it’s about having detailed iformation of the types of the objects that the library is serving. not knowing the typing of the functions a library is serving is… poor. Maybe typescript is too strict and having something like type hinting like python has would be enough since linters pick up the hints from the libraries, but doing just JS only fuck the people that use the library.
We use TypeScript for our node.js backends.
We had two that started out vanilla, but it became too painful to maintain.
Or a signal that you’d rather not support the worst way to introduce type systems to frontend dev. While I’m not sure that applies to DHH, I am sure there are other devs that understand compromising all your goals to codepend on Node or even JS itself isn’t that much of a win and rather see support for better options.
Damn right. I care about getting features in the hands of my users. If code quality helps with that, if type script helps with that, I’m all in favor.
But the moment I care about code quality for its own sake you need to sack my ass like yesterday.
maintainability is arguably not a value-added for the end user. But still absolutely important. Robustness of code is arguably not visible to an end-user, until it fails. And that’s very important. Features are great, but quality is still important and is basically the mortar between the bricks that are features. Only caring about features leads to poorly written applications.
Less chance of security vulnerabilities, breaches, less bugs fixed more permanently, faster features, etc
Those things all sound like value adds for the end user…
What an utterly blind, self-centered view. Write good, readable code so you can actually maintain it and so your coworkers don’t want to kill you.
But you can do that in vanilla JS, too.
Even better, don’t use JS at all if you don’t have to.
You can write shitty code in TS too.
This is a really surprising retort.
In the end, the only thing that has value is what ends up in the user’s hands. The rest is only a means to an end, in the very best case.
This is not a controversial take in professional software development.
What is self centered and self absorbed is putting misguided notions of “craftsmanship” and maintainability over business needs.
If you can’t see that writing readable code is part of the means to that end, I don’t know what to tell you. If nobody can maintain the codebase because it’s a mess of spaghetti logic and 20-deep dependency trees (I’m looking at you, every JavaScript project I’ve ever seen), the end product is going to suffer while also making every single engineer working on it want to leave.
Funny, it sure seems like “maintainability should not be a priority” is a pretty controversial take to me.
You are making a lot of assumptions. You don’t know what my product is, how it is developed, what it’s used for, what its lifecycle is. Whether improving maintainability or code quality would be a net benefit, and whether using type script would be a possible solution.
You also didn’t bother to find out.
You just charge at me guns blazing, trying to string me up for heresy.
How many things can you prioritize?
In my world we prioritize one. And that not the one.
Weird. In most cases priorities change as the situation demands. The application doesn’t matter when it comes to maintainability. Tech debt will take down any application if you keep ignoring maintainability at the expense of just delivering more and more. You sound more like a manager than a developer.
Maybe, but you can push it really far before the breaking point is reached.
Even their excuses if a “24h only event app” don’t hold water
Even in that case, a business would be wanting to make many of those apps, and this commenter is arguing making a new one from scratch every time over massively simplifying things with quality reusable code.
Even their own example shows how terrible it is an idea to deprioritize code quality/readability.
I guess they are running some kind of shovelware company with constant bluffings.
Then I’m really glad I don’t live in that world.
I think vzq’s point is that you can write good, readable code that doesn’t do what the user wants. Same with other metrics that are ripe for navel-gazing like code coverage.
It’s bordering on a false dichotomy… but I also believe that dynamic, untyped languages have proven exceptionally useful for rapid prototyping and iteration.
I must admit that I write that deliberately to annoy the “code quality is everything” brigade.
I have no issues prioritizing maintainability where needed, but in my experience people that dogmatically prioritize code quality are not honest with themselves. They almost never chase code quality in general. They are always looking to enforce some burdensome standard or specific tool or archaic process or fiddly CICD script, and if you push back they go cry in a corner about the abstract virtue of “code quality”.
Just be straight with me. You enjoy using type script. Tell me how it adds value to the product and the customer.
Stop trying to shame me into it. I can’t be shamed. I have no shame. I’m a professional software engineer.
You’re setting up a theoretically boogie man that no one said exists and then setup the extreme opposite point of view. You’re annoying the people that are actually sane. You’re being dogmatic in your one views and too extreme.
Oh fuck me for wanting to give my users what they want and make money right?
This is a shitty response. You won’t make money if you design the app poorly and can’t maintain it.
It’s a business decision. Why would for example an app that’s only needed for a 24 hour event need to be maintainable?
Sometimes it’s ok to take the money and run. Feel free to make your case, but it’s not a developer’s call to make.
Except that prototypes never end up as just prototypes, they die or become the real app with lots of masking tape.
JSDoc: am I joke to you?
Maybe you should find out?
The idea behind Turbo is your server sends HTML/CSS to the client, and when the content needs to be updated… the server simply sends new HTML which Turbo will inject into the page. You can also annotate links so they fetch new content from the server instead of navigating to a new URL.
Your server side code can be written in whatever language you prefer… Turbo being a 37Signals project I assume they’re using Ruby. It’d work fine with TypeScript too if that’s your thing. Turbo just uses HTTP / JSON to talk to the server and doesn’t have a server side component.
You can have client side code, but AFAIK there’s pretty minimal interaction with Turbo - you might for example add an event listener that processes the HTML and as converts ISO date/times into
Date.toLocaleString().If you’re writing complex client side code then you shouldn’t be using Turbo at all.
This change doesn’t affect, at all, the language used by users of Turbo. What’s changed is the Turbo dev team themselves have chosen to write Turbo in vanilla javascript. And there are advantages to vanilla JS - it removes the compilation step from one language to another, for example.
IDK about the potency of the pc they used to compile but… it takes less than 10 seconds usually, booting up the testing server with the updated code though CI/CD takes much longer. it’s not abouthte compilation step, that’s a non-issue, it’s about the extra effort they don’t want to put to do the typing.
I prefer strong static typing for the most part. I find it difficult to mentally model code when it’s not clear what exactly is being passed to functions and whatnot. Can also use them to help ensure code correctness. TypeScript has been a welcome addition to my projects over the years and honestly I want them to implement more functionality like pattern matching expressions.