- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
You must log in or # to comment.
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’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.
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.
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 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.
deleted by creator
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.
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.
I don’t even know what Turbo 8 is
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.
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’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.
JSDoc: am I joke to you?
Whatever.
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.
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.
So what is it with Anakin’s picture? Javascript is the dark side of the, web development, force? XD
Seriously tho, valid points.
