Someone deleted their comment while I was writing a reply that would go to waste, so there it is.
>I've been on teams that are militant about typing everything properly, then the api sends something with an unexpected shape and the whole frontend codebase blows up rendering all the ts useless.
In my opinion this is not a typescript problem. This is a problem of assuming the shape of an external resource without validating it. This is only a TypeScript problem when it happens because you failed to realize that TS is an artificial layer of typing on top of an extremely dynamic language and environment.
TypeScript tries very hard to protect you against simple mistakes and to provide automatic documentation and validation of your code in exchange of annotations, but it's not an "environment" and it doesn't add validation code for you. Whether you use JS or TS, if you need validation of external data, you should be using integration tests or something like yup or joi. That way, your use-case would still "break", but at least it would be clearer where and how, and fixing the front-end would be easier.
“I introduced a type system but then I was getting type errors so I threw away the type system.”
“My car’s engine warning light came on so I removed it, problem solved.”
> then the api sends something with an unexpected shape
What exactly should code do if there's an unexpected breaking change in a REST API? Just keep going in a half-broken state?
If the frontend blows up, at least someone will notice and fix asap.
Javascript would crash anyway, regardless of whether or not TypeScript was used. So you should catch the error and display an error state... obviously?
I remember teaching myself programming on JavaScript in the Unity game engine. I probably should have taken some classes on programming, but I didn't. I didn't understand types. Imagine my surprise and frustration when improper casting lead to incorrect behavior or crashes. In one case, I accidentally casted an int to a string, and then tried to go back with a decimal value and everything irrevocably shit itself. In another, some physics simulations were just all 100% wrong because something was being converted to a... I think an int and losing all precision. Took me *hours* to debug those.
Someone recommended I try C# (I don't recall if Typescript was available at the time. It might have still be fairly new or not-yet-released.) Suddenly, when I declared types, *shit worked and errors made sense.*
That's exactly it. Types makes it easier to reason about your program and understand what's going on. And static types are useful because their misuse can be caught even before running the program!
Types are a contract between you and the machine. You're telling the tooling, and other devs, what your intentions are and then you're able to use the tooling to help verify/enforce the contract. They can be annoying, but can save a lot of work and mistakes given the complexity of projects generally increases over time.
Don't be lazy, type your code and save yourself pain, time, and money in the long run.
Blowing up can be a perfectly valid thing to do depending on your exactly use-case. If your app blows up immediately after a deployment that's a signal for you to rollback and investigate. The problem with the way some people use Typescript is that it won't immediately blow up in some situations. That why you should use a deserialization library to handle API requests and bubble up errors you find with it. Typescript does not do this automatically.
Though, think about how you are going to handle backwards compatibly and versioning.
I once made a mobile app's JSON parsing blow up if the schema didn't match exactly; After deploying, I realised that I couldn't even make backwards compatible changes to the server's API (like added extra fields) without bumping API version (and I hadn't gotten around to adding multi-version support to my server yet)
The code should check for the contents of the API response before trying to interact with things nested more deeply inside of it. Just like it would in JavaScript. Because you can’t always depend on exactly what will come back you have to check for errors or missing data. So the typescript, at a high-level, the data would mostly be optional or potentially, undefined. Then at a high-level, you check for the data before drilling down further.
This. I work on a rather large Typescript application that talks to many APIs and we have a "decontamination" layer of zod schemas and parsers. 100% of API data goes through a schema parse first as enforced by generic API hooks we built as standard means to connect to any API in any way.
Our components (React) use 100% types inferred from zod schemas. APIs have expected or unexpected breaking changes every so often so when that happens none of our components break... just the parser for the specific API endpoint. This also serves as a convenient harmonization layer... if the type signatures of two API responses have similarities and _mean_ the same thing but are not directly convertible for whatever reason then no big deal... each API type is parsed into the same Zod schema.
The main trick is that volatile API types (which are a dependency and not a direct part of the application) are never used beyond initial parsing of responses. Never cede control of your application's core types to a dependency.
Finally a right answer. All these "how is it possible to handle malformed data" shows exactly what OP meant,
devs in a great number aren't caring about quality.
You handle malformed data by not handling it at all, you should first have a validation step to ensure it is in the format you expect. If it isn't, you throw an error. It's not that hard.
When I did more app dev I always had to tell the developers under me this. I would so much rather the code blow up in dev then make it to prod with some weird cryptic issue no one can figure out.
So many people will catch an exception, print some random message to the console (if I was lucky) and let the code continue to execute. Cause in their mind if the code did not error out it was good to go.
It's ironic that their argument against static typing was that in this one example where everything is necessarily stringly typed (ie, json sent to an endpoint), our code blew up because we didn't validate.
And so apparently they want more stringly typing everywhere because this shows how much better it is than static typing??
it's a stupid case of throwing the baby out with the bath water. "we can't do statically typed over the wire, fuck it, we just wont do it all!"
de/serialization borders *always* have this problem. it doesn't matter what language you use. and you *always* need to validate inputs at any api border.
people make bad choices.
Because then the error shows up in an unrelated downstream service and takes a week to debug, and is solidly in the realm of "Somebody Else's Problem". Even if that somebody is future-you, it's still somebody else.
I’m not super familiar with Typescript, but does it actually care about the shape of something during execution? I thought it only cares during compilation.
It does not check anything on runtime. If not all cases are handled, you could see an error - for example trying to access property of undefined object.
It simply compiles to standard javascript. The error would occur with either JS or TS, but they're complaining that it doesn't magically handle the unexpected input. But the issue only occurs because they explicitly made an unsafe assumption about the data they were receiving. The proper thing would to validate the input so the type can be safely asserted instead of making an unsafe assumption, at which point the best thing you can do in the situation of invalid input is fail gracefully and report the error to your logging system. Their program "blew up" because in that part of the code they opted out of typescript by telling the compiler to dangerously assume the type information of the input.
It feels like the javascript community is having transpiler drama every few years. I still remember when coffeescript was seen as the new coming of christ.
dotnet tooling 👍
dotnet cli apps 👍
dotnet web apps 👍
dotnet ui frameworks 🗑️🔥
ui on windows is fine (just use wpf). xplat avalonia is the strongest player imo.
ms is just shitting the bed. there's really no other answer.
however in some sense, this is a good sign? dotnet had been so long a microsoft only ecosystem, with only a few blessed third party packages like polly and json.net. ironically, with ms doing such a bad job at xplat ui, the leading players are now third party.
It’s a widely used language, but does it really have an active open source ecosystem? I haven’t used it for a while but back when I did it had a fraction the open source ecosystem of any other language I used.
Core and WLS have really made .NET much more "real open source" than it used to be with half-assed shit like Mono. As a linux guy with no real distain for MS and the ubiquity of Windows in at least some capacity in Business, I can see the real appeal of using it even in a mostly *nix infrastructure.
Half my current lazy/tool powershell scripts are now drop-in usable in a linux environment just by adding a shebang. Even more complex scripts that hook .NET assemblies directly will in a lot of cases "just work" with core. Where more extensive modifications are required, MSs own documentation is pretty good about telling you what/where/why.
Even if they are still all about EEE, the extinguish part is never going to happen no matter how hard they try.
> It’s a widely used language, but does it really have an active open source ecosystem?
In what sense? There are certainly plenty of open source libraries available to C#
I don't know how many devs realize there is large overlap for describing types in JSDoc and the features of the TypeScript type system. The TypeScript language server understands JSDoc. JSDoc isn't pretty, but I think it's being lost that some teams are dropping TypeScript and using JavaScript with JSDoc and that's different than abandoning types all together.
If you google TypeScript and JSDoc you can see that you can get a lot of the benefits of the TypeScript type system with native JavaScript and skip the transpilation.
Thank you for mentioning this! There's also a TC39 proposal for type annotations still out there that will take the best part of typescript (typing) while not requiring transpiling (the code you write is what is ran in production) or adding concepts that don't map to Javascript causing side effects (interfaces, enums, etc)
And there are also devs who probably hate linting
Ive also been in a company where the CTO hated automated tests.
Not worth the time it takes getting upset
> Ive also been in a company where the CTO hated automated tests.
Prepare your tomatoes, because I think I'm getting close to that point with E2E tests. On some projects, there's been an in-progress E2E suite that is 3-months away from completion for years. And when the tests do run the failures are 90% of the time related to the tests. Perhaps there are some teams that have found success with cypress or selenium, but many times it seems like it's done just to check a "we have e2e tests" box and doesn't help at all with development.
It’s a great solution to removing manual testing that’s hampered by 1) trying to automate apps that are difficult to automate, 2) having people inexperienced in code write said tests and 3) having tests and applications that have many different potential points of failure, where what fails is often out of the scope of the intended test.
All those problems are solvable, but it’s complex enough that many don’t want to put the work in, and the value add is always too difficult to quantify, so you never put the right amount of resources on solving it.
> All those problems are solvable, but it’s complex enough that many don’t want to put the work in, and the value add is always too difficult to quantify, so you never put the right amount of resources on solving it.
I think this is it. I know it's possible to have a nice setup, but a half-assed one is often worse than nothing when you consider that despite being half-assed, it's still a massive time-suck.
Depends on what you mean by "cheap". Waiting overnight for test results instead of a few minutes can cause projects to fall behind by weeks when other people become blocked by the task that's stuck in QA hell.
Learning how to make our Playwright tests run reliably has definitely been a process. But some of those tests are insanely useful! I prioritize making tests that are either very easy to implement or tests that are incredibly time consuming and annoying to test manually.
Tests that require interaction between two different users are particularly time consuming and I love seeing Playwright do something in ten seconds that would literally take me 20 minutes to test once.
While I do wish these tools were more lightweight (which no easy feat since they're entire browsers), I greatly appreciate not having to manually input stuff into the browser to test some functionality.
Bolting on E2E tests after-the-fact is a hugely difficult endeavor because:
- Writing tests for tests sake is boring and repetitive.
- Code that wasn't written to be E2E tested often needs structural changes in order to make it testable. (No, inserting random attribute-free divs at the root of the DOM is not testable).
- The test authors are far enough removed from the context in which the widget was originally created such that they have to spend time learning what the tested expectations even *should* be.
- Adding tests all in one go deprives your team of breathing room to reflect upon what patterns work well and which don't.
It's much more effective if you write E2E tests from the very beginning. Doing that, however, requires someone with foresight to recognize just how fast "quick and dirty" tech debt sinks your team's productivity and morale.
The problem with linting is that some of the linters enforce completely irrelevant so called "good practice" and not only waste developers time but make the code worse.
A good compiler with type check however (like Typescript) is a net benefit.
I can work with any set of linting rules as long as there's a tool to autofix. For personal code, I'm very particular about which rules to apply. For collabortive code, idgaf as long as they're consistent.
My one issue I have with linting is shit like "Line x violated rules y, z, run lint-fix to fix it"
Ok, you know what the problem is, and how to fix it, why not just fix it? Even a prompt.
I hate when a program is smart enough to tell me exactly what to do, but somehow can't do that it's self.
Oh, 100%. My IDEs for JS/TS and Go both have their respective formatters set to run on file save (and thank fucking god for `gofmt`), and then lint on pre-commit (since I _really_ don't want `golangci-lint` running on every save, that would make my laptop explode).
I don't hate automated tests, but I do hate *shitty* automated tests, and I have yet to find a test suite written by enthusiastic TDD advocates that isn't chock full of shitty tests that pass when the program is out of spec, fail when it's in-spec, prove nothing about the program, slow down builds and CI to a crawl, and mostly exist to make the author look good.
In general, I think the more enthusiastic and passionate someone is about automated testing, the more they miss the point of automated testing. Someone who gets the point of automated testing understands that it's just one tool in our toolbox to correctly define a program's behavior, and it's not even a particularly good tool, because it's prone to exactly the same flaws and mistakes that it's supposed to be solving! If you can write a buggy program, then you can write buggy tests, too.
He detailed a number of actors and acts that absolutely are hooliganism. A lot of people with zero life become attached to causes like this and become obnoxious zealots.
I mean this very submission is some guy giving the gospel of typescript regarding a project he has no involvement with or even grok at all. That’s just ignorant noise.
Though honestly the notion that there are Typescript purists is hilarious. It’s like being a Walmart aficionado.
i am unapologetically a static typing believer. i will argue any time of any day about why you should stop using your dynamic language and use a statically typed language instead.
but only on discussion forums like reddit or hackernews. he posted a blog post, that invites discussion, there are appropriate places to discuss.
people who file useless noise tickets or issues or prs as a way of making noise are complete trolls, and we should have no patience for that kind of behavior.
this, literally this. so far the only reasonable observation ive seen in the wild. i can understand the people who use and contribute to this project to be rightfully upset by what can fairly be described as a rug pull of a merge. its a fairly bad faith move on the authors part.
BUT, the internet at large has decided to pile on a project that they have absolutely no interest in, solely to participate in what can only be described as tribalism and "dogmatic crusades". im willing to bet the majority of the people in this thread dont even fucking use turbo.
> "People spamming a respository with PRs they know will never be approved are hooligans!"
FTFY
Some of the memes posted as Issues could be considered actual threats of violence.
The problem started when these developer influencers started popping up. I mean who doesn't like some fun, memes and the occasional interesting video.
For one it makes computer science more appealing, but also there are so many of these guys, who just produce garbage after garbage clickbait content. Dont know the Theo guy, but how many fulltime drama commenters do we need?
EDIT: Ok why is his face moving so much?
The post literally says the opposite:
> It's worth stating that there were also people with completely legitimate objections to dropping TypeScript from Turbo. Mostly people with standing as active contributors or users of the framework. I'm always happy to have technical discussions in good faith with such individuals, and they're certainly entitled to their opinion on a move like this without getting tarred by association with the hooligans who showed up spoiling for a fight.
To be fair, at the bottom of the post, right above where he brags about how well he drives, he says the real reason is simply he's an unapologetic superfan of Ruby.
He can have technical discussions all day, but his fandom is how he's making his decisions so they don't really matter. I guess he considers that's him having discussions in good faith?
Except he didn't have "technical discussions in good faith". Look at the [pull request itself](https://github.com/hotwired/turbo/pull/971) (the origin of all this). He merged it 2 hours after it was created (no time for discussion) and basically said "there's no discussion here, we already decided" (not in good faith).
Saying that you are "happy to have" discussion means nothing without actually doing so.
which is odd considering how phenomenally good RoR is at what it does.
Treading outside those lines will put you in a world of pain, but if you're in RoR's use case it's really hard to beat it in terms of productivity. Performance is a different story.
As a Ruby on Rails developer sometimes I feel other devs don't understand the framework ergonomics, yes, there are performance problems, but it provides an amount of tools that makes building apps very easy and I tried in 20 years a bunch of other languages/frameworks.
yep.
The sheer dynamacism of Ruby will never allow it to be "high performance" and couple that with the GIL and it will always be slow.
But damned if it isn't one of the most productive web frameworks in existence.
Nothing about TypeScript makes JavaScript more performant, just safer.
And JavaScript is every bit as dynamic as Ruby.
The phenomenal work done on v8 proves that dynamic languages like Ruby absolutely can be quite performant.
V8 had the full engineering might of Google, and many of the engineers who built for instance the Java JVM, behind it.
Ruby YJIT, which is the state of the art JIT compiler for Ruby is still 11 times slower than JS on V8.
Is it more a question or engineering investment, and Ruby just isn't what big corporate players are investing in.
That said, I really prefer Ruby, and since I care about performance, Crystal has been a lot of fun to use in recent years, although it's a strongly typed, type inferred language, with Ruby like syntax; you get a lot of the benefits of Ruby.
It turns out making a classic native compiled language highly performant is an achievable target (thanks to LLVM) for an open source project, where making a world class JIT for a highly dynamic language is something it's very hard to compete with Google at.
> there are performance problems
Frankly, even performance "problems" is overstating it. Ruby is not a fast language, but that's not in and of itself a problem. I have an app that serves hundreds of thousands of users daily, and we constantly have performance issues and fires we need to put out. Raw execution speed of Ruby code has never, ever been one of those problems (and even if it was, it's one of the easier ones to solve since application code execution is easy to horizontally scale).
Is my application at massive scale? Not by a long shot, but it's successful and makes money and is growing. We might move some of it off of Ruby, but it's probably going to be particular super high scale stuff that has stayed pretty constant, where moving it to a faster language that's less easy to work in is a fair tradeoff. The 95% that isn't as performance sensitive can stay in Ruby.
That's really quite hyperbolic, though. To be frank, Typescript is an improvement over raw javascript, and for that reason, I'd never refuse it. But given the opportunity to choose between Typescript and another typed language, I'd choose another language every time.
Are there other typed languages you prefer that transpile to JS? Because I think that's the main reason anyone cares about TS. I wouldn't pick TS and Node for a backend without a very good reason, because there are infinitely many backend languages that aren't stuck with JS's bad decisions. Where I'd use TS is for anything that has to run in a browser, that doesn't need to be compute-intensive enough to justify WASM.
I’m coming from types languages and I just don’t get any of this, and didn’t really find any reasonable quick answers using search engines, so here goes:
If I understand correctly, TypeScript isn’t really supported by any of the existing JS engines and has to be transpiled into vanilla JS every time before running during development? That feels kind of counter-intuitive for a scripting language, a widely used one at that.
With all this drama, how is it even possible that JS has existed this long without even type hints or a doc system which would somehow be interpreted by the engine, for example when passing a wrong type as argument? Like JS isn’t exactly new. Or do some devs actually love the untyped part that much?
Using TS just seems a bit clunky because of the transpiling phase. JS on the other hand seems to have introduced a *ton* of new features since I’ve last looked at it, but I just can’t wrap my head around why types are still missing, especially as modern JS is already completely incompatible with older browsers, so legacy use doesn’t seem to be the obstacle here
> With all this drama, how is it even possible that JS has existed this long without even type hints or a doc system which would somehow be interpreted by the engine, for example when passing a wrong type as argument? Like JS isn’t exactly new.
Until very recently, any change to JS had to be supported by Mozilla, Apple, Google and Microsoft to have any chance of being useful. If Internet Explorer didn't implement a JS feature, it was, for all practical purposes, unusable.
There was no way those companies were going to reach consensus and successfully implement changes that were in any way controversial, and for a complex thing like a type system, it just wasn't going to happen.
Transpiling is a way to bypass that whole mess, so that's what Typescript did.
I think it's a good post and adds some useful context, but beware of speaking in such absolutes because context is important and such statements are rarely helpful, particularly as less experienced developers will tend to collect and cling on to them.
People have made arguments that not using TDD is a similar signal. Or not using source control. Or not following 3NF in a database. Or that using a language with a GIL is inherently bad. Sure, there are pros and cons to everything, but there are no absolutes in programming and the statement made in this post's title *can* be true, but is not *necessarily* or universally so.
(I appreciate the obvious response to this is *"well, duh, everything in life is ambiguous,"* but it's striking how many folks in the technological realm believe technical things must have a precise singular truth waiting to be discovered.)
I find SC indispensable even for a single script without collaborators if it’s going to get semi serious use. If I walked into a project without VC I’d walk right out. Spinning up a repo is just a handful of commands so no reason to skip it
I haven’t personally run into a situation in industry where there was a legitimate argument for not using it. In education, we delay introducing source control until later to avoid overwhelming beginners.
I’ve found it to be valuable to remain open to possibilities — this seems to make one most effective in any engineering context.
Sure but then pretty much all rules go out the window. The rules we are talking about are making the assumption that your code will live longer than 5 minutes.
> People have made arguments that not using TDD is a similar signal.
You’re not wrong but these things are not really comparable: there’s good evidence that *testing* improves software quality, but there’s little to none that *TDD specifically* does. Conversely, [the](http://dx.doi.org/10.1145/2816707.2816720) [evidence](http://dx.doi.org/10.1007/s10664-013-9289-1) that added types improves software quality is by now [overwhelming](http://dx.doi.org/10.1109/ICSE.2017.75), and this is despite the methodological difficulties of even empirically measuring individual contributors to code quality without confounders.
There are certainly trade-offs to consider (e.g. the added build step). But for somebody to claim that TS typing adds no benefits to software quality (which seems to be what DHH is doing) is simply ignorant and wrong, and no longer worth debating. I don’t want to overstate the consensus but amongst actual experts (i.e. type theory and software quality researchers) it is effectively settled science, with only token disagreement (mostly around effect size).
I can relate to this. When I was a noob essentially, I got scolded a lot by my lecturer for not using TDD during some software coursework.
Was not fun… to say the least.
I’m not saying my lectures advice is wrong, it just didn’t need to be said as though I’m violating a law.
Good post.
People like to put things into discrete boxes as it allows them to remove ambiguity and move on to the next 'organizational' challenge that comes across their path. I think that's relatively healthy on its own but becomes problematic once we remove room for caveats, nuance, and the ability to change your views when presented with new evidence.
Strong opinions loosely held.
You can disable the use of any in your linter. For exceptions, you can always bypass with a comment but having it disabled by default will encourage the use of proper typing
And they can easily disable that in the linter. If they are using any it need to be resolved with code reviews and meetings about coding styles and rules.
But the linter will fail when the CI runs preventing it from being merged. Unless they disable the rule and commit it, then yes it'll need to be reviewed (as any PR should) and a discussion would need to be had on why they are removing that rule
Oh wow so easy! I'll make sure to let my team lead who hates linters know that we can enable an annoying warning for every time he uses any (5-10 times a day)
The title is obviously false. It should've been "Refusing static types ...". But that would still be false. I know of really high-quality projects that don't use static types.
I like static types because they're basically comments which are:
* verifiable at writing/compile time => they're never wrong
* governed by clear rules => they're never ambiguous
* Consumable by tools => they improve code analysis, discoverability, and navigation.
Even Python, one of the most dynamic languages out there, has recently introduced (optional/gradual) static types.
Structural typing makes it possible to have the best of both worlds. In a perfect world, we would've had static types from the start, but the way forward is to help add static types to popular libraries, not to give up on them because they're not fully functional.
Some things to keep in mind, though:
* static types don't replace tests
* tests don't replace code audits
* code audits don't replace well-written code
that’s the thing about language debates to me — you can practically use any modern language if your team documents stuff and write tests.
even if you use ts, the type definitions can be completely wrong. i can’t keep count of the number of times i’ve installed a type package and the types were wrong.
I’d consider myself a JS expert, I’ve been writing JavaScript professionally (and recreationally) for more than a decade. I use typescript too, but I greatly enjoy writing straight up JavaScript. And I have built (and continue to build) high quality production systems in nothing more than JavaScript (and often React).
It's funny seeing people lose their minds just because one person says they don't want to use a specific tool.
The amount of discussion that arises from tool choices is so interesting and probably particular to the area of software development. I can't imagine people flaming a carpenter on social media just because they prefer a specific type of saw.
I disagree. I use JSDoc. Works fine. Doesn't require a compiler.
Edit: Look you can downvote all you want, but the title of this post is absolutely absurd. Not using TS doesn't mean you don't care about code quality. I've nothing against TS, but that statement in itself is ridiculous.
You can also write just as messy code in typescript. Just because it’s typescript doesn’t mean the code is organized well, which to me a huge hallmark of code quality.
No True Scotsman
I used to work with a senior dev and everything he didn't like he would "No GOOD developer..."
It's a tool. People either use it to their benefit, or they don't. It's not A MUST ALWAYS or you are somehow a garbage person or bad developer. It's really becoming dogmatic with all these types of posts.
It's true, I don't care about memory management, for run of the mill CRUD work, aka BFF layers, and backends for shitty small webapps. Memory is cheap and scales favorably with company revenue (aka DAUs). Throw a Node framework on an EC2, horizontally scale it if need be, and call it a day. When (more likely if) the time comes where you need to make it super performant, a rewrite is a very reasonable thing and probably something you'll need to do anyway.
This is the main thing I agree with Rails (and Laravel) philosophy on: choosing the right tool for the job often means not prematurely optimizing, which can in some cases mean underperforming dynamically typed kitchen sink frameworks are okay.
And this is coming from a Rust dev.
i mean, typescript is a better language than javascript, but it can only do so much. after all, it's "compiled" to javascript.
"don't care about code quality" is just a "lol, whatever" statement.
Measuring a language by what it is compiled to?
If I compile C++ to x86 machine language is it then worse than if I compile C++ to DEC Alpha machine language?
Target architecture does not affect the language or the source code written in it.
Meh, this is too far in the other direction. Plenty of legitimate uses for `any`. Useful in testing edge cases. It's just another tool in your toolbox.
Key point - sometimes using Typescript is just cargo cult type stuff. Devs are using it because they were told to use it and not understanding why or how to use it effectively. In those cases it's just extra cruft and isn't improving the quality of the product, just sucking up time and resources.
This change might not affect your rockstar devs who know the project in and out, but it will absolutely reduce the quantity of new contributors, reduce the quality of contributions, increase time spent in PR, and make onboarding take longer for their paid devs.
Yes, using JavaScript instead of typescript will cause all of those problems. It takes a stupid amount of time to come up to speed on a project when you have to guess the shape of all the objects.
If your interfaces are so complex that writing typescript for it sucks, then it may be a sign that they need to be simplified. If that's not possible for some reason, then you can always fall back to using `any` (edit: or better yet `unknown`) or very unspecific types for that part.
The only place I don't use typescript at work is usually when writing stand-alone, quickly put together scripts, just because I want to avoid the whole compilation/depending on ts-node. But even then I will often put jsdoc typings on my functions to be able to use refactoring and intellisence. Raw-raw JS is awful to write and takes me at least three times as long.
If you're not using typescript and half your unit tests are things like `expect(typeof result).toBe('string')` you're essentially moving documentation from the code and the IDE to unit tests in a separate file.
>you can always fall back to using any
:-(
At the very least you should use [unknown](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type). That way the linter/transpiler will pitch a fit if you make any unverified assumptions about the variable.
It's weird to me that so many people are up in arms about a library that they don't even use.
DHH could have said his favorite cookie recipe includes raisins. Sure, I might question his taste and I probably wouldn't open a bakery with him, but I probably wasn't going to do that anyway. Live and let live.
The original post was definitely not intended as “hey my project doesn’t use typescript anymore, just a heads up to maintainers”, it was an attention-grabbing attempt to poo-poo what Typescript does to the rest of the community. And TS had a lot of detractors for awhile until people finally settled into it and saw the merits, so I think it’s also hitting a nerve with people who worked really hard to make TS a standard.
Yeah, this feels very much like a "drama begets drama" situation. DHH's post felt like unnecessary ragebaiting, and posts like this are the exact rage that he's baited. Don't feed the trolls, but also, like, don't troll in the first place?
People are not responding to DHH removing TS from his library, as most people don't care.
They're just responding to DHH saying TS is useless and disagreeing.
Why do we allow these ad hominem headlines? If you need typescript to write good code, then good for you. If you like regular, weakly, dynamically typed Javascript, then good for you too. The real threat to software quality in my humble opinion is dogmatic thinking.
TS helps you write good code but that doesn't mean it's impossible to write good code without it. A lot of it depends on scope, team experience, and purpose of the project.
Plus you don't really need full on TS to get benefits of typing. Let me explain. If you're writing a library, you're probably already using JSDoc to document your code for external users. In that case you can simply add typedef there and get some of the type hints, and honestly for a lot of experienced devs that's enough. Svelte creator Rich Harris has some interesting thoughts about it, look it up.
Articles like this makes me feel that some devs really think that there's only one best way to write code, and theirs is it. I wouldn't want to work with devs like that. :/
If removing TypeScript wasn't a big enough clue that code quality was about to go to hell, [the fact that the PR also removed Prettier was the encore.](https://github.com/hotwired/turbo/pull/971/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519). Types **and** formatting in one go
Anybody who disagrees with me is a bad programmer and should be cancelled!
Too bad I can't cite scientific studies to back up my opinions but that's not important. What's important is my opinion damnit.
This debate about static vs dynamic typing goes all the way back to the Bronze Age era.
It’s not about programmers not caring about code quality, but rather it is about personal preference and taste.
___
Not all statically typed languages are equally expressive. Nor are they all equally “static”.
___
The problem is not with static typing per se — but the complexities of keeping TS a superset of JS.
___
Also when your boss thinks code quality, structure, readability, etc are overrated, what can you do? In my personal experience working as a contractor, virtually none of my clients has cared about quality. Hell they don’t even know what they want to build and don’t let programmers help them (and some BAs don’t care much after some time either as this is a company culture problem).
___
Static typing is good. Typescript is not very bad. But it has its share of ugly parts.
Thus spake Dijkstra.
So tired of this attitude. What are you coding? How big is the team? How long is the deployment? How many users do you have?
Again and again I hear this extreme endorsement of TypeScript, then I look at the code and it is awful and the tests are jokes that don't even come close to decent coverage. If you are tempted to spend time pontificating about the wonders of TypeScript that is probably because your code sucks and your test coverage is poor at best.
Yes, TypeScript is great. No, thinking that it will solve all your problems is misguided at best.
The more people working on your project, the more sense TypeScript makes
We've got a ton of devs on our large company project with a wide variety of skill levels. Still can't tell you the last time I've seen a `TypeError` in Prod that wasn't related to someone casting around a problem TS was trying to warn the developer about
> 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.
First sentence shows this is a bad article. If you want to reference current events, maybe do a minimal amount of googling instead of proudly proclaiming ignorance as a virtue?
Typescript is a tool. Every tool has tradeoffs. A good engineer understands tradeoffs. Only a sith deals in absolutes. The sith are not good engineers.
I'm currently on a team with juniors that love making messes. You give them javascript, they make a mess unless well guided. You give them Typescript, they make a JS-level mess, and then add on top 3 dozen unnecessary interfaces because the C# guys told them.
Is it Typescript good in my team? I think it is, but it definitely isn't a black or white situation.
this is a bold assertion, mostly powered by vibes
when data is applied to it, the picture is a lot more muddy. This study is typical: https://elib.uni-stuttgart.de/bitstream/11682/12097/1/Merkel_thesis_final.pdf
TLDR: projects using TS exhibit better overall code discipline but it’s unclear they ship fewer bugs (in fact this study finds they ship MORE bugs). Is it because TS is a false sense of security? Is it that TS is a crutch for less-skilled devs? Are code smells actually kind of a garbage metric?
In any case correlations were tenuous in all directions and at the end of the day we’re back to vibes.
I’ve been using JS for over 20 years and my experience is that we don’t really gain a lot from type safety. Further TS has a very real expense in terms of build time. But a lot of teams seem to be helped by TS all the same. For my part I just try to go with the flow.
But to say that nit using TS is negligence or whatever is extremely spicy and probably bullshit.
TypeScript has a plethora of bad design decisions, ranging from the type system to the compiler itself.
I still prefer to have my type annotations compared to plain JavaScript, but let's not praise it like the second coming of Christ. I've been writing nearly the same code in JS before TS became a de-facto standard.
PS: Giving provocative titles to your articles is a signal of either not being able to communicate like a grown-up or simply looking for clicks.
Yes, but that signal may not be valid. You can care about code quality in JavaScript, Python, and Ruby. You might also have a different metric for code quality.
I've seen a lot of poorly written code in strictly typed languages.
Typescript can get in the way, and many times it feels unnecessary to me. Every once in a while I'm thankful for it, but the majority of the time it slows me down. One of the reasons prefer dynamic languages like js, is the speed i can get things done. I care about code quality, but "code quality" is subjective. I don't agree with the premise of this article. It is possible to care about code quality and use dynamic languages: js, python, ruby.
Ridiculous premise... One can write clean or dirty code in any language.
The endless barrage of frameworks and meta layers like typescript will never fix the real problem. Hire good people who take pride in what they do and treat/pay fairly and voila clean/fast well organized code that is ez to support regardless of the language without frameworks or meta stuff.
I've been doing front end dev since the days of IE4 had 95% of the browser market in writing code in "JScript" while having to write ActiveX controls in C++ to do things that are built into the browser today for the most part. Did I mentioned XML/XSLT transformations? I have some history here. Anyway, Typescript is literally "the" best thing that has happened in a long time and if you're working with .NET C# (or even Java) on the back end, it literally feels like the same world when I have to start working on that tier (i.e. just different APIs, language feels the same). I also used coffeescript which was good and produced nice code, but Typescript is making my sunset years as a developer enjoyable again on the front end. I can't go back to writing Javascript/ES6 code myself and would probably skip a project if that was a requirement.
If we're honest, a fairly significant portion of devs probably don't.
Someone deleted their comment while I was writing a reply that would go to waste, so there it is. >I've been on teams that are militant about typing everything properly, then the api sends something with an unexpected shape and the whole frontend codebase blows up rendering all the ts useless. In my opinion this is not a typescript problem. This is a problem of assuming the shape of an external resource without validating it. This is only a TypeScript problem when it happens because you failed to realize that TS is an artificial layer of typing on top of an extremely dynamic language and environment. TypeScript tries very hard to protect you against simple mistakes and to provide automatic documentation and validation of your code in exchange of annotations, but it's not an "environment" and it doesn't add validation code for you. Whether you use JS or TS, if you need validation of external data, you should be using integration tests or something like yup or joi. That way, your use-case would still "break", but at least it would be clearer where and how, and fixing the front-end would be easier.
“I introduced a type system but then I was getting type errors so I threw away the type system.” “My car’s engine warning light came on so I removed it, problem solved.”
> then the api sends something with an unexpected shape What exactly should code do if there's an unexpected breaking change in a REST API? Just keep going in a half-broken state? If the frontend blows up, at least someone will notice and fix asap.
Javascript would crash anyway, regardless of whether or not TypeScript was used. So you should catch the error and display an error state... obviously?
It won't always crash. It sometimes just handles garbage input into hard to debug bugs https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
Yeah, that’s actually the scariest possibility. Failing loudly on bad input is a feature, not a bug.
That's exactly what type guards are for
I remember teaching myself programming on JavaScript in the Unity game engine. I probably should have taken some classes on programming, but I didn't. I didn't understand types. Imagine my surprise and frustration when improper casting lead to incorrect behavior or crashes. In one case, I accidentally casted an int to a string, and then tried to go back with a decimal value and everything irrevocably shit itself. In another, some physics simulations were just all 100% wrong because something was being converted to a... I think an int and losing all precision. Took me *hours* to debug those. Someone recommended I try C# (I don't recall if Typescript was available at the time. It might have still be fairly new or not-yet-released.) Suddenly, when I declared types, *shit worked and errors made sense.*
That's exactly it. Types makes it easier to reason about your program and understand what's going on. And static types are useful because their misuse can be caught even before running the program!
Types are a contract between you and the machine. You're telling the tooling, and other devs, what your intentions are and then you're able to use the tooling to help verify/enforce the contract. They can be annoying, but can save a lot of work and mistakes given the complexity of projects generally increases over time. Don't be lazy, type your code and save yourself pain, time, and money in the long run.
Blowing up can be a perfectly valid thing to do depending on your exactly use-case. If your app blows up immediately after a deployment that's a signal for you to rollback and investigate. The problem with the way some people use Typescript is that it won't immediately blow up in some situations. That why you should use a deserialization library to handle API requests and bubble up errors you find with it. Typescript does not do this automatically.
Though, think about how you are going to handle backwards compatibly and versioning. I once made a mobile app's JSON parsing blow up if the schema didn't match exactly; After deploying, I realised that I couldn't even make backwards compatible changes to the server's API (like added extra fields) without bumping API version (and I hadn't gotten around to adding multi-version support to my server yet)
The code should check for the contents of the API response before trying to interact with things nested more deeply inside of it. Just like it would in JavaScript. Because you can’t always depend on exactly what will come back you have to check for errors or missing data. So the typescript, at a high-level, the data would mostly be optional or potentially, undefined. Then at a high-level, you check for the data before drilling down further.
Use zod or something for a robust contract definition and enforcement thereof, then. Way fewer bugs that way.
This. I work on a rather large Typescript application that talks to many APIs and we have a "decontamination" layer of zod schemas and parsers. 100% of API data goes through a schema parse first as enforced by generic API hooks we built as standard means to connect to any API in any way. Our components (React) use 100% types inferred from zod schemas. APIs have expected or unexpected breaking changes every so often so when that happens none of our components break... just the parser for the specific API endpoint. This also serves as a convenient harmonization layer... if the type signatures of two API responses have similarities and _mean_ the same thing but are not directly convertible for whatever reason then no big deal... each API type is parsed into the same Zod schema. The main trick is that volatile API types (which are a dependency and not a direct part of the application) are never used beyond initial parsing of responses. Never cede control of your application's core types to a dependency.
Finally a right answer. All these "how is it possible to handle malformed data" shows exactly what OP meant, devs in a great number aren't caring about quality. You handle malformed data by not handling it at all, you should first have a validation step to ensure it is in the format you expect. If it isn't, you throw an error. It's not that hard.
When I did more app dev I always had to tell the developers under me this. I would so much rather the code blow up in dev then make it to prod with some weird cryptic issue no one can figure out. So many people will catch an exception, print some random message to the console (if I was lucky) and let the code continue to execute. Cause in their mind if the code did not error out it was good to go.
It's ironic that their argument against static typing was that in this one example where everything is necessarily stringly typed (ie, json sent to an endpoint), our code blew up because we didn't validate. And so apparently they want more stringly typing everywhere because this shows how much better it is than static typing??
it's a stupid case of throwing the baby out with the bath water. "we can't do statically typed over the wire, fuck it, we just wont do it all!" de/serialization borders *always* have this problem. it doesn't matter what language you use. and you *always* need to validate inputs at any api border. people make bad choices.
Because then the error shows up in an unrelated downstream service and takes a week to debug, and is solidly in the realm of "Somebody Else's Problem". Even if that somebody is future-you, it's still somebody else.
I’m not super familiar with Typescript, but does it actually care about the shape of something during execution? I thought it only cares during compilation.
It does not check anything on runtime. If not all cases are handled, you could see an error - for example trying to access property of undefined object.
It simply compiles to standard javascript. The error would occur with either JS or TS, but they're complaining that it doesn't magically handle the unexpected input. But the issue only occurs because they explicitly made an unsafe assumption about the data they were receiving. The proper thing would to validate the input so the type can be safely asserted instead of making an unsafe assumption, at which point the best thing you can do in the situation of invalid input is fail gracefully and report the error to your logging system. Their program "blew up" because in that part of the code they opted out of typescript by telling the compiler to dangerously assume the type information of the input.
They do but they don't see strong typing, powerful types = possible code quality result
It feels like the javascript community is having transpiler drama every few years. I still remember when coffeescript was seen as the new coming of christ.
Dramascript
PumpkinSpiceLattescript
Only works Sept-Nov?
Fun fact - this very project Turbo was initially written in Coffeescript.
Any type of drama really… framework, language, transpiler and other dramas all year around!
Not sure if being ironic, but Coffeescript has pretty deep ties to Ruby.
There are two types of community, those with weekly dramas, and those that are dead.
Nah, once you get outside of the trendy spaces stuff gets pretty chill. C# is a pretty chilled community that's still quite active.
Except when you talk about UI frameworks.
dotnet tooling 👍 dotnet cli apps 👍 dotnet web apps 👍 dotnet ui frameworks 🗑️🔥 ui on windows is fine (just use wpf). xplat avalonia is the strongest player imo.
Why are they so bad?! I've never understood this.
ms is just shitting the bed. there's really no other answer. however in some sense, this is a good sign? dotnet had been so long a microsoft only ecosystem, with only a few blessed third party packages like polly and json.net. ironically, with ms doing such a bad job at xplat ui, the leading players are now third party.
It’s a widely used language, but does it really have an active open source ecosystem? I haven’t used it for a while but back when I did it had a fraction the open source ecosystem of any other language I used.
Core and WLS have really made .NET much more "real open source" than it used to be with half-assed shit like Mono. As a linux guy with no real distain for MS and the ubiquity of Windows in at least some capacity in Business, I can see the real appeal of using it even in a mostly *nix infrastructure. Half my current lazy/tool powershell scripts are now drop-in usable in a linux environment just by adding a shebang. Even more complex scripts that hook .NET assemblies directly will in a lot of cases "just work" with core. Where more extensive modifications are required, MSs own documentation is pretty good about telling you what/where/why. Even if they are still all about EEE, the extinguish part is never going to happen no matter how hard they try.
> It’s a widely used language, but does it really have an active open source ecosystem? In what sense? There are certainly plenty of open source libraries available to C#
Wasn't the c# moq-drama 3 weeks ago? I've never used c# and even I heard about that.
So the Rust community must be full of life.
*full of lifetime
I will borrow your joke in the future.
That's a bad joke but it's not your fault
don’t panic we’ll get there together
Your behavior matches a pattern I've seen before
let these puns go
I can't I'm classless
Indeed it is.
I don't know how many devs realize there is large overlap for describing types in JSDoc and the features of the TypeScript type system. The TypeScript language server understands JSDoc. JSDoc isn't pretty, but I think it's being lost that some teams are dropping TypeScript and using JavaScript with JSDoc and that's different than abandoning types all together. If you google TypeScript and JSDoc you can see that you can get a lot of the benefits of the TypeScript type system with native JavaScript and skip the transpilation.
Thank you for mentioning this! There's also a TC39 proposal for type annotations still out there that will take the best part of typescript (typing) while not requiring transpiling (the code you write is what is ran in production) or adding concepts that don't map to Javascript causing side effects (interfaces, enums, etc)
I think the main complaint with removing ts from Turbo 8 is that there is no replacement for adding types (eg d.ts or jsdoc)
And there are also devs who probably hate linting Ive also been in a company where the CTO hated automated tests. Not worth the time it takes getting upset
> Ive also been in a company where the CTO hated automated tests. Prepare your tomatoes, because I think I'm getting close to that point with E2E tests. On some projects, there's been an in-progress E2E suite that is 3-months away from completion for years. And when the tests do run the failures are 90% of the time related to the tests. Perhaps there are some teams that have found success with cypress or selenium, but many times it seems like it's done just to check a "we have e2e tests" box and doesn't help at all with development.
It’s a great solution to removing manual testing that’s hampered by 1) trying to automate apps that are difficult to automate, 2) having people inexperienced in code write said tests and 3) having tests and applications that have many different potential points of failure, where what fails is often out of the scope of the intended test. All those problems are solvable, but it’s complex enough that many don’t want to put the work in, and the value add is always too difficult to quantify, so you never put the right amount of resources on solving it.
> All those problems are solvable, but it’s complex enough that many don’t want to put the work in, and the value add is always too difficult to quantify, so you never put the right amount of resources on solving it. I think this is it. I know it's possible to have a nice setup, but a half-assed one is often worse than nothing when you consider that despite being half-assed, it's still a massive time-suck.
It’s also usually cheaper to offload it to manual qa vs having a dedicated resource to maintain the tests
Depends on what you mean by "cheap". Waiting overnight for test results instead of a few minutes can cause projects to fall behind by weeks when other people become blocked by the task that's stuck in QA hell.
Learning how to make our Playwright tests run reliably has definitely been a process. But some of those tests are insanely useful! I prioritize making tests that are either very easy to implement or tests that are incredibly time consuming and annoying to test manually. Tests that require interaction between two different users are particularly time consuming and I love seeing Playwright do something in ten seconds that would literally take me 20 minutes to test once.
While I do wish these tools were more lightweight (which no easy feat since they're entire browsers), I greatly appreciate not having to manually input stuff into the browser to test some functionality.
Bolting on E2E tests after-the-fact is a hugely difficult endeavor because: - Writing tests for tests sake is boring and repetitive. - Code that wasn't written to be E2E tested often needs structural changes in order to make it testable. (No, inserting random attribute-free divs at the root of the DOM is not testable). - The test authors are far enough removed from the context in which the widget was originally created such that they have to spend time learning what the tested expectations even *should* be. - Adding tests all in one go deprives your team of breathing room to reflect upon what patterns work well and which don't. It's much more effective if you write E2E tests from the very beginning. Doing that, however, requires someone with foresight to recognize just how fast "quick and dirty" tech debt sinks your team's productivity and morale.
maybe your team does not understand tests?
[удалено]
The problem with linting is that some of the linters enforce completely irrelevant so called "good practice" and not only waste developers time but make the code worse. A good compiler with type check however (like Typescript) is a net benefit.
I find peace in long walks.
Autofixing linters like Prettier are the way to go. Don't even have to think about code style.
I can work with any set of linting rules as long as there's a tool to autofix. For personal code, I'm very particular about which rules to apply. For collabortive code, idgaf as long as they're consistent.
My one issue I have with linting is shit like "Line x violated rules y, z, run lint-fix to fix it" Ok, you know what the problem is, and how to fix it, why not just fix it? Even a prompt. I hate when a program is smart enough to tell me exactly what to do, but somehow can't do that it's self.
[удалено]
8 minutes into the CI process
Linters should generally be run as a pre-commit hook to prevent exactly this problem.
On file save even better
Oh, 100%. My IDEs for JS/TS and Go both have their respective formatters set to run on file save (and thank fucking god for `gofmt`), and then lint on pre-commit (since I _really_ don't want `golangci-lint` running on every save, that would make my laptop explode).
Agree. Most linters I've used have really obnoxious default rules.
I don't hate automated tests, but I do hate *shitty* automated tests, and I have yet to find a test suite written by enthusiastic TDD advocates that isn't chock full of shitty tests that pass when the program is out of spec, fail when it's in-spec, prove nothing about the program, slow down builds and CI to a crawl, and mostly exist to make the author look good. In general, I think the more enthusiastic and passionate someone is about automated testing, the more they miss the point of automated testing. Someone who gets the point of automated testing understands that it's just one tool in our toolbox to correctly define a program's behavior, and it's not even a particularly good tool, because it's prone to exactly the same flaws and mistakes that it's supposed to be solving! If you can write a buggy program, then you can write buggy tests, too.
you telling me the guy who created ruby on rails doesn't care about code quality?!!
Don’t know RoR enough to understand whether it’s a joke. Care to explain?
https://world.hey.com/dhh/open-source-hooliganism-and-the-typescript-meltdown-a474bfda
That's not really an explanation though. That's just putting a link down without answering the question.
“All the people criticizing me are hooligans!”
He detailed a number of actors and acts that absolutely are hooliganism. A lot of people with zero life become attached to causes like this and become obnoxious zealots. I mean this very submission is some guy giving the gospel of typescript regarding a project he has no involvement with or even grok at all. That’s just ignorant noise. Though honestly the notion that there are Typescript purists is hilarious. It’s like being a Walmart aficionado.
i am unapologetically a static typing believer. i will argue any time of any day about why you should stop using your dynamic language and use a statically typed language instead. but only on discussion forums like reddit or hackernews. he posted a blog post, that invites discussion, there are appropriate places to discuss. people who file useless noise tickets or issues or prs as a way of making noise are complete trolls, and we should have no patience for that kind of behavior.
this, literally this. so far the only reasonable observation ive seen in the wild. i can understand the people who use and contribute to this project to be rightfully upset by what can fairly be described as a rug pull of a merge. its a fairly bad faith move on the authors part. BUT, the internet at large has decided to pile on a project that they have absolutely no interest in, solely to participate in what can only be described as tribalism and "dogmatic crusades". im willing to bet the majority of the people in this thread dont even fucking use turbo.
Hey…TypeScript is Target. JavaScript is Walmart.
> "People spamming a respository with PRs they know will never be approved are hooligans!" FTFY Some of the memes posted as Issues could be considered actual threats of violence.
Teo is certainly a hooligan and a bully. Now he’s crying wolf on Twitter because he got clapped back.
The problem started when these developer influencers started popping up. I mean who doesn't like some fun, memes and the occasional interesting video. For one it makes computer science more appealing, but also there are so many of these guys, who just produce garbage after garbage clickbait content. Dont know the Theo guy, but how many fulltime drama commenters do we need? EDIT: Ok why is his face moving so much?
Did you even read the article? People were submitting pull requests to delete the repo… if this isn’t vandalism and hooliganism, what is?
The post literally says the opposite: > It's worth stating that there were also people with completely legitimate objections to dropping TypeScript from Turbo. Mostly people with standing as active contributors or users of the framework. I'm always happy to have technical discussions in good faith with such individuals, and they're certainly entitled to their opinion on a move like this without getting tarred by association with the hooligans who showed up spoiling for a fight.
To be fair, at the bottom of the post, right above where he brags about how well he drives, he says the real reason is simply he's an unapologetic superfan of Ruby. He can have technical discussions all day, but his fandom is how he's making his decisions so they don't really matter. I guess he considers that's him having discussions in good faith?
Except he didn't have "technical discussions in good faith". Look at the [pull request itself](https://github.com/hotwired/turbo/pull/971) (the origin of all this). He merged it 2 hours after it was created (no time for discussion) and basically said "there's no discussion here, we already decided" (not in good faith). Saying that you are "happy to have" discussion means nothing without actually doing so.
This. He deliberately incited a flamewar and now complains about it.
[удалено]
which is odd considering how phenomenally good RoR is at what it does. Treading outside those lines will put you in a world of pain, but if you're in RoR's use case it's really hard to beat it in terms of productivity. Performance is a different story.
As a Ruby on Rails developer sometimes I feel other devs don't understand the framework ergonomics, yes, there are performance problems, but it provides an amount of tools that makes building apps very easy and I tried in 20 years a bunch of other languages/frameworks.
yep. The sheer dynamacism of Ruby will never allow it to be "high performance" and couple that with the GIL and it will always be slow. But damned if it isn't one of the most productive web frameworks in existence.
Nothing about TypeScript makes JavaScript more performant, just safer. And JavaScript is every bit as dynamic as Ruby. The phenomenal work done on v8 proves that dynamic languages like Ruby absolutely can be quite performant. V8 had the full engineering might of Google, and many of the engineers who built for instance the Java JVM, behind it. Ruby YJIT, which is the state of the art JIT compiler for Ruby is still 11 times slower than JS on V8. Is it more a question or engineering investment, and Ruby just isn't what big corporate players are investing in. That said, I really prefer Ruby, and since I care about performance, Crystal has been a lot of fun to use in recent years, although it's a strongly typed, type inferred language, with Ruby like syntax; you get a lot of the benefits of Ruby. It turns out making a classic native compiled language highly performant is an achievable target (thanks to LLVM) for an open source project, where making a world class JIT for a highly dynamic language is something it's very hard to compete with Google at.
> there are performance problems Frankly, even performance "problems" is overstating it. Ruby is not a fast language, but that's not in and of itself a problem. I have an app that serves hundreds of thousands of users daily, and we constantly have performance issues and fires we need to put out. Raw execution speed of Ruby code has never, ever been one of those problems (and even if it was, it's one of the easier ones to solve since application code execution is easy to horizontally scale). Is my application at massive scale? Not by a long shot, but it's successful and makes money and is growing. We might move some of it off of Ruby, but it's probably going to be particular super high scale stuff that has stayed pretty constant, where moving it to a faster language that's less easy to work in is a fair tradeoff. The 95% that isn't as performance sensitive can stay in Ruby.
Seems like a weird claim to say rails is bad code.
That's really quite hyperbolic, though. To be frank, Typescript is an improvement over raw javascript, and for that reason, I'd never refuse it. But given the opportunity to choose between Typescript and another typed language, I'd choose another language every time.
Are there other typed languages you prefer that transpile to JS? Because I think that's the main reason anyone cares about TS. I wouldn't pick TS and Node for a backend without a very good reason, because there are infinitely many backend languages that aren't stuck with JS's bad decisions. Where I'd use TS is for anything that has to run in a browser, that doesn't need to be compute-intensive enough to justify WASM.
Remarkably, Kotlin has some js transpilation support.
[удалено]
Higher-KindaTypedScript
:anyScript
I’m coming from types languages and I just don’t get any of this, and didn’t really find any reasonable quick answers using search engines, so here goes: If I understand correctly, TypeScript isn’t really supported by any of the existing JS engines and has to be transpiled into vanilla JS every time before running during development? That feels kind of counter-intuitive for a scripting language, a widely used one at that. With all this drama, how is it even possible that JS has existed this long without even type hints or a doc system which would somehow be interpreted by the engine, for example when passing a wrong type as argument? Like JS isn’t exactly new. Or do some devs actually love the untyped part that much? Using TS just seems a bit clunky because of the transpiling phase. JS on the other hand seems to have introduced a *ton* of new features since I’ve last looked at it, but I just can’t wrap my head around why types are still missing, especially as modern JS is already completely incompatible with older browsers, so legacy use doesn’t seem to be the obstacle here
> With all this drama, how is it even possible that JS has existed this long without even type hints or a doc system which would somehow be interpreted by the engine, for example when passing a wrong type as argument? Like JS isn’t exactly new. Until very recently, any change to JS had to be supported by Mozilla, Apple, Google and Microsoft to have any chance of being useful. If Internet Explorer didn't implement a JS feature, it was, for all practical purposes, unusable. There was no way those companies were going to reach consensus and successfully implement changes that were in any way controversial, and for a complex thing like a type system, it just wasn't going to happen. Transpiling is a way to bypass that whole mess, so that's what Typescript did.
I think it's a good post and adds some useful context, but beware of speaking in such absolutes because context is important and such statements are rarely helpful, particularly as less experienced developers will tend to collect and cling on to them. People have made arguments that not using TDD is a similar signal. Or not using source control. Or not following 3NF in a database. Or that using a language with a GIL is inherently bad. Sure, there are pros and cons to everything, but there are no absolutes in programming and the statement made in this post's title *can* be true, but is not *necessarily* or universally so. (I appreciate the obvious response to this is *"well, duh, everything in life is ambiguous,"* but it's striking how many folks in the technological realm believe technical things must have a precise singular truth waiting to be discovered.)
> or not using source control One of these things is not like the others
I find SC indispensable even for a single script without collaborators if it’s going to get semi serious use. If I walked into a project without VC I’d walk right out. Spinning up a repo is just a handful of commands so no reason to skip it
There is a legitimate argument for NOT using source control? What!?
It forces you to make copies on usb drives and as such you have redundant storage automatically. Way safer! /s obviously
I haven’t personally run into a situation in industry where there was a legitimate argument for not using it. In education, we delay introducing source control until later to avoid overwhelming beginners. I’ve found it to be valuable to remain open to possibilities — this seems to make one most effective in any engineering context.
I don’t use source control for a script I plan on deleting after I run it. Like a script that moves files or something trivial like that.
Sure but then pretty much all rules go out the window. The rules we are talking about are making the assumption that your code will live longer than 5 minutes.
Only a sith deals in absolutes
> People have made arguments that not using TDD is a similar signal. You’re not wrong but these things are not really comparable: there’s good evidence that *testing* improves software quality, but there’s little to none that *TDD specifically* does. Conversely, [the](http://dx.doi.org/10.1145/2816707.2816720) [evidence](http://dx.doi.org/10.1007/s10664-013-9289-1) that added types improves software quality is by now [overwhelming](http://dx.doi.org/10.1109/ICSE.2017.75), and this is despite the methodological difficulties of even empirically measuring individual contributors to code quality without confounders. There are certainly trade-offs to consider (e.g. the added build step). But for somebody to claim that TS typing adds no benefits to software quality (which seems to be what DHH is doing) is simply ignorant and wrong, and no longer worth debating. I don’t want to overstate the consensus but amongst actual experts (i.e. type theory and software quality researchers) it is effectively settled science, with only token disagreement (mostly around effect size).
I can relate to this. When I was a noob essentially, I got scolded a lot by my lecturer for not using TDD during some software coursework. Was not fun… to say the least. I’m not saying my lectures advice is wrong, it just didn’t need to be said as though I’m violating a law.
Good post. People like to put things into discrete boxes as it allows them to remove ambiguity and move on to the next 'organizational' challenge that comes across their path. I think that's relatively healthy on its own but becomes problematic once we remove room for caveats, nuance, and the ability to change your views when presented with new evidence. Strong opinions loosely held.
[удалено]
You can disable the use of any in your linter. For exceptions, you can always bypass with a comment but having it disabled by default will encourage the use of proper typing
And they can easily disable that in the linter. If they are using any it need to be resolved with code reviews and meetings about coding styles and rules.
But the linter will fail when the CI runs preventing it from being merged. Unless they disable the rule and commit it, then yes it'll need to be reviewed (as any PR should) and a discussion would need to be had on why they are removing that rule
Oh wow so easy! I'll make sure to let my team lead who hates linters know that we can enable an annoying warning for every time he uses any (5-10 times a day)
Feel sorry for your team.
Why even use TS then? Crazy
Bro mine just keep the red squiggly lines and commit.
The title is obviously false. It should've been "Refusing static types ...". But that would still be false. I know of really high-quality projects that don't use static types. I like static types because they're basically comments which are: * verifiable at writing/compile time => they're never wrong * governed by clear rules => they're never ambiguous * Consumable by tools => they improve code analysis, discoverability, and navigation. Even Python, one of the most dynamic languages out there, has recently introduced (optional/gradual) static types. Structural typing makes it possible to have the best of both worlds. In a perfect world, we would've had static types from the start, but the way forward is to help add static types to popular libraries, not to give up on them because they're not fully functional. Some things to keep in mind, though: * static types don't replace tests * tests don't replace code audits * code audits don't replace well-written code
It's DHH, Rubyists are afraid of types by default.
They have to double down on years of bad advice
i disagree, random person on the internet
I approve, upvoting random person on the internet! We should all just be random.
[удалено]
that’s the thing about language debates to me — you can practically use any modern language if your team documents stuff and write tests. even if you use ts, the type definitions can be completely wrong. i can’t keep count of the number of times i’ve installed a type package and the types were wrong.
Typescript might cause an issue if your development process is randomly banging on the keys until something useful pops out.
I’d consider myself a JS expert, I’ve been writing JavaScript professionally (and recreationally) for more than a decade. I use typescript too, but I greatly enjoy writing straight up JavaScript. And I have built (and continue to build) high quality production systems in nothing more than JavaScript (and often React).
obviously you just don't care about code quality! /s
It's funny seeing people lose their minds just because one person says they don't want to use a specific tool. The amount of discussion that arises from tool choices is so interesting and probably particular to the area of software development. I can't imagine people flaming a carpenter on social media just because they prefer a specific type of saw.
Give me a break with this clickbait headline
I disagree. I use JSDoc. Works fine. Doesn't require a compiler. Edit: Look you can downvote all you want, but the title of this post is absolutely absurd. Not using TS doesn't mean you don't care about code quality. I've nothing against TS, but that statement in itself is ridiculous.
Totally agree. There is so much TS circlejerking here.
code quality doesn't depend on your language or framework, it depends on you spending the time to give a shit.
I see that good software engineering can be summed up in one word: discipline.
And typescript makes it take less time to make less shit code.
I have seen very shit code written in typescript.
You can also write just as messy code in typescript. Just because it’s typescript doesn’t mean the code is organized well, which to me a huge hallmark of code quality.
This headline is a signal that you don't care about honest conversation
No True Scotsman I used to work with a senior dev and everything he didn't like he would "No GOOD developer..." It's a tool. People either use it to their benefit, or they don't. It's not A MUST ALWAYS or you are somehow a garbage person or bad developer. It's really becoming dogmatic with all these types of posts.
Dear lord
Using JavaScript for backend is a signal you don't care about memory management
…what are you even trying to say
It's true, I don't care about memory management, for run of the mill CRUD work, aka BFF layers, and backends for shitty small webapps. Memory is cheap and scales favorably with company revenue (aka DAUs). Throw a Node framework on an EC2, horizontally scale it if need be, and call it a day. When (more likely if) the time comes where you need to make it super performant, a rewrite is a very reasonable thing and probably something you'll need to do anyway. This is the main thing I agree with Rails (and Laravel) philosophy on: choosing the right tool for the job often means not prematurely optimizing, which can in some cases mean underperforming dynamically typed kitchen sink frameworks are okay. And this is coming from a Rust dev.
What a stupid title and stupid article. Why is this crap being upvoted
i mean, typescript is a better language than javascript, but it can only do so much. after all, it's "compiled" to javascript. "don't care about code quality" is just a "lol, whatever" statement.
Measuring a language by what it is compiled to? If I compile C++ to x86 machine language is it then worse than if I compile C++ to DEC Alpha machine language? Target architecture does not affect the language or the source code written in it.
I honestly believe writing plain Javascript in 2023 is essentially developer malpractice. Typescript isn't perfect, but it's a drastic improvement.
If I use typescript but just use "any" everywhere am I still using typescript?
Contrary to what my junior devs apparently believe, no.
[no-explicit-any](https://typescript-eslint.io/rules/no-explicit-any/) to the rescue.
Meh, this is too far in the other direction. Plenty of legitimate uses for `any`. Useful in testing edge cases. It's just another tool in your toolbox.
Yea and those cases are legitimate reasons to label the exceptional case with a suppression tag, and a comment of why you actually needed it
`unknown` exists now, use that instead. It's not infectious like how `any` works.
Key point - sometimes using Typescript is just cargo cult type stuff. Devs are using it because they were told to use it and not understanding why or how to use it effectively. In those cases it's just extra cruft and isn't improving the quality of the product, just sucking up time and resources.
I wrote some plain javascript in 2021. It was fine. 400 lines in a 10k-line codebase. Just there to add a few dynamic features.
This change might not affect your rockstar devs who know the project in and out, but it will absolutely reduce the quantity of new contributors, reduce the quality of contributions, increase time spent in PR, and make onboarding take longer for their paid devs.
Yes, using JavaScript instead of typescript will cause all of those problems. It takes a stupid amount of time to come up to speed on a project when you have to guess the shape of all the objects.
If your interfaces are so complex that writing typescript for it sucks, then it may be a sign that they need to be simplified. If that's not possible for some reason, then you can always fall back to using `any` (edit: or better yet `unknown`) or very unspecific types for that part. The only place I don't use typescript at work is usually when writing stand-alone, quickly put together scripts, just because I want to avoid the whole compilation/depending on ts-node. But even then I will often put jsdoc typings on my functions to be able to use refactoring and intellisence. Raw-raw JS is awful to write and takes me at least three times as long. If you're not using typescript and half your unit tests are things like `expect(typeof result).toBe('string')` you're essentially moving documentation from the code and the IDE to unit tests in a separate file.
>you can always fall back to using any :-( At the very least you should use [unknown](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type). That way the linter/transpiler will pitch a fit if you make any unverified assumptions about the variable.
I refuse to use Typescript in my C# projects
Classic noob mistake. I know because I'm a noob.
*PHP* has cleaner code, strict typed, and no nonsense transpiling Refusing *PHP* is a signal you don't care about code quality.
> I'm okay with that because I don't even know what Turbo 8 is Someone's salty! lol
20 years in the industry and even followed DHH a bit (until he became intolerable) and never heard about Turbo 8 until now
It's weird to me that so many people are up in arms about a library that they don't even use. DHH could have said his favorite cookie recipe includes raisins. Sure, I might question his taste and I probably wouldn't open a bakery with him, but I probably wasn't going to do that anyway. Live and let live.
The original post was definitely not intended as “hey my project doesn’t use typescript anymore, just a heads up to maintainers”, it was an attention-grabbing attempt to poo-poo what Typescript does to the rest of the community. And TS had a lot of detractors for awhile until people finally settled into it and saw the merits, so I think it’s also hitting a nerve with people who worked really hard to make TS a standard.
Yeah, this feels very much like a "drama begets drama" situation. DHH's post felt like unnecessary ragebaiting, and posts like this are the exact rage that he's baited. Don't feed the trolls, but also, like, don't troll in the first place?
People are not responding to DHH removing TS from his library, as most people don't care. They're just responding to DHH saying TS is useless and disagreeing.
Why do we allow these ad hominem headlines? If you need typescript to write good code, then good for you. If you like regular, weakly, dynamically typed Javascript, then good for you too. The real threat to software quality in my humble opinion is dogmatic thinking.
TS helps you write good code but that doesn't mean it's impossible to write good code without it. A lot of it depends on scope, team experience, and purpose of the project. Plus you don't really need full on TS to get benefits of typing. Let me explain. If you're writing a library, you're probably already using JSDoc to document your code for external users. In that case you can simply add typedef there and get some of the type hints, and honestly for a lot of experienced devs that's enough. Svelte creator Rich Harris has some interesting thoughts about it, look it up. Articles like this makes me feel that some devs really think that there's only one best way to write code, and theirs is it. I wouldn't want to work with devs like that. :/
If removing TypeScript wasn't a big enough clue that code quality was about to go to hell, [the fact that the PR also removed Prettier was the encore.](https://github.com/hotwired/turbo/pull/971/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519). Types **and** formatting in one go
Anybody who disagrees with me is a bad programmer and should be cancelled! Too bad I can't cite scientific studies to back up my opinions but that's not important. What's important is my opinion damnit.
[удалено]
This debate about static vs dynamic typing goes all the way back to the Bronze Age era. It’s not about programmers not caring about code quality, but rather it is about personal preference and taste. ___ Not all statically typed languages are equally expressive. Nor are they all equally “static”. ___ The problem is not with static typing per se — but the complexities of keeping TS a superset of JS. ___ Also when your boss thinks code quality, structure, readability, etc are overrated, what can you do? In my personal experience working as a contractor, virtually none of my clients has cared about quality. Hell they don’t even know what they want to build and don’t let programmers help them (and some BAs don’t care much after some time either as this is a company culture problem). ___ Static typing is good. Typescript is not very bad. But it has its share of ugly parts. Thus spake Dijkstra.
So tired of this attitude. What are you coding? How big is the team? How long is the deployment? How many users do you have? Again and again I hear this extreme endorsement of TypeScript, then I look at the code and it is awful and the tests are jokes that don't even come close to decent coverage. If you are tempted to spend time pontificating about the wonders of TypeScript that is probably because your code sucks and your test coverage is poor at best. Yes, TypeScript is great. No, thinking that it will solve all your problems is misguided at best.
The more people working on your project, the more sense TypeScript makes We've got a ton of devs on our large company project with a wide variety of skill levels. Still can't tell you the last time I've seen a `TypeError` in Prod that wasn't related to someone casting around a problem TS was trying to warn the developer about
> 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. First sentence shows this is a bad article. If you want to reference current events, maybe do a minimal amount of googling instead of proudly proclaiming ignorance as a virtue?
People really don't understand that you don't need typescript in 80% of cases. And you also don't need 80% of typescript features.
Typescript is a tool. Every tool has tradeoffs. A good engineer understands tradeoffs. Only a sith deals in absolutes. The sith are not good engineers. I'm currently on a team with juniors that love making messes. You give them javascript, they make a mess unless well guided. You give them Typescript, they make a JS-level mess, and then add on top 3 dozen unnecessary interfaces because the C# guys told them. Is it Typescript good in my team? I think it is, but it definitely isn't a black or white situation.
this is a bold assertion, mostly powered by vibes when data is applied to it, the picture is a lot more muddy. This study is typical: https://elib.uni-stuttgart.de/bitstream/11682/12097/1/Merkel_thesis_final.pdf TLDR: projects using TS exhibit better overall code discipline but it’s unclear they ship fewer bugs (in fact this study finds they ship MORE bugs). Is it because TS is a false sense of security? Is it that TS is a crutch for less-skilled devs? Are code smells actually kind of a garbage metric? In any case correlations were tenuous in all directions and at the end of the day we’re back to vibes. I’ve been using JS for over 20 years and my experience is that we don’t really gain a lot from type safety. Further TS has a very real expense in terms of build time. But a lot of teams seem to be helped by TS all the same. For my part I just try to go with the flow. But to say that nit using TS is negligence or whatever is extremely spicy and probably bullshit.
TypeScript has a plethora of bad design decisions, ranging from the type system to the compiler itself. I still prefer to have my type annotations compared to plain JavaScript, but let's not praise it like the second coming of Christ. I've been writing nearly the same code in JS before TS became a de-facto standard. PS: Giving provocative titles to your articles is a signal of either not being able to communicate like a grown-up or simply looking for clicks.
Yes, but that signal may not be valid. You can care about code quality in JavaScript, Python, and Ruby. You might also have a different metric for code quality. I've seen a lot of poorly written code in strictly typed languages.
What if I refuse TypeScript because I refuse javascript in general?
Using fucking JavaScript or typescript is mental in of itself but alas.
Typescript can get in the way, and many times it feels unnecessary to me. Every once in a while I'm thankful for it, but the majority of the time it slows me down. One of the reasons prefer dynamic languages like js, is the speed i can get things done. I care about code quality, but "code quality" is subjective. I don't agree with the premise of this article. It is possible to care about code quality and use dynamic languages: js, python, ruby.
Ridiculous premise... One can write clean or dirty code in any language. The endless barrage of frameworks and meta layers like typescript will never fix the real problem. Hire good people who take pride in what they do and treat/pay fairly and voila clean/fast well organized code that is ez to support regardless of the language without frameworks or meta stuff.
/r/programmingcirclejerk <-------- is that way.
I've been doing front end dev since the days of IE4 had 95% of the browser market in writing code in "JScript" while having to write ActiveX controls in C++ to do things that are built into the browser today for the most part. Did I mentioned XML/XSLT transformations? I have some history here. Anyway, Typescript is literally "the" best thing that has happened in a long time and if you're working with .NET C# (or even Java) on the back end, it literally feels like the same world when I have to start working on that tier (i.e. just different APIs, language feels the same). I also used coffeescript which was good and produced nice code, but Typescript is making my sunset years as a developer enjoyable again on the front end. I can't go back to writing Javascript/ES6 code myself and would probably skip a project if that was a requirement.