Skip to content
DevMeme
885 of 7435
The Unrequited Respect of a TypeScript Developer
Languages Post #1000, on Jan 27, 2020 in TG

The Unrequited Respect of a TypeScript Developer

Why is this Languages meme funny?

Level 1: When Friends Fight

Imagine two friends on a playground who each have a favorite toy. One friend loves action figures and the other friend loves building blocks. They both say, “It’s cool that you like something different – we can still play together and be friends!” That’s like the first part of the comic: both characters promise to respect each other’s favorite. But then, in an instant, one friend suddenly yells, “Ew, your toy is gross! Get it away from me!” and pushes it out of his face. 😮 The other friend is left standing there, shocked and hurt, because just a second ago they were going to be respectful and play nice. This is exactly what’s happening with the programmers in the meme. They both like making things, but they prefer different tools to make those things. At first they agree to get along, but then one loses his temper and insults the other’s tool. It’s funny in the comic because it’s so over-the-top and sudden – kind of like if a friendly debate on which superhero is cooler suddenly turned into a shouting match. But it also feels a bit sad, because the poor JavaScript friend just wanted to share what he likes and got yelled at for it. The simple lesson: even if we like different things (whether it’s toys, superheroes, or programming languages), we shouldn’t be mean about it – otherwise someone’s feelings will get hurt and playtime (or coding together) won’t be fun anymore.

Level 2: To Type or Not to Type

Let’s break down the scenario in simpler terms. We have two developers talking about their favorite way to write code for the frontend (i.e., the part of software that runs in your web browser). One developer says, “I like JavaScript,” and the other replies, “And I prefer TypeScript.” These are two closely related programming languages used heavily in web development. JavaScript (JS) is the traditional language of the web – it’s what makes web pages interactive. Every time you click a button and something changes on the page without reloading, that’s likely JavaScript at work. TypeScript (TS) is essentially JavaScript with some extra rules. The key difference is in the name: TypeScript introduces the idea of static types to JavaScript.

In a statically-typed language like TypeScript, you explicitly specify the types of variables and function outputs (like saying “this variable will hold a number, and only a number”). The computer (actually, the TypeScript compiler) checks your code before it runs and yells at you if you try to do something weird with types, like treating a number as a text string. Dynamically-typed languages like JavaScript don’t enforce that at compile time – a variable can hold a number at one moment, then be reassigned to a string later, and JavaScript won’t complain until you actually run the program and maybe hit an error (or maybe not, if you never misuse the value). Each approach has pros and cons, and that’s where the debate comes from.

So in the comic, the JavaScript fan is basically saying “I like the old-school, dynamic JavaScript,” and the TypeScript fan is saying “I prefer the newer, safer TypeScript.” Initially, they claim they “respect each other” – meaning, they’re suggesting it’s okay to have different preferences. This is something we often say in the developer community: different tools for different folks, live and let live. There’s even a popular mantra, “use the right tool for the job,” implying that there’s room for multiple technologies. However, what happens next in the comic completely contradicts that nice idea. The TypeScript developer suddenly shouts, "Get that dirty bullshit out of my face!" at the JavaScript logo and shoves it away. Essentially, he’s saying, “Actually, no, I don’t respect your choice at all – I think JavaScript is garbage. Begone!”

This is a humorous exaggeration of what we call language rivalry or tech tribalism. Sometimes developers become really attached to their favorite language or tool. Instead of just saying “I prefer X but Y is fine,” they start acting like they’re on Team X vs. Team Y in a sports championship. Tribalism in this context means grouping up and being loyal to your “tribe” (your chosen language, here) while looking down on the other “tribe.” In real life, it might not be as blunt or rude as the comic (that level of insult would be pretty unprofessional in person), but you do get people essentially implying the same sentiment: e.g., “Ugh, why are you still writing plain JavaScript? That’s so error-prone and messy. Use TypeScript like a real developer.” Conversely, a staunch JavaScript supporter might say, “TypeScript just slows me down with all its rules. Real coders don’t need a nanny checking types for them.” Those attitudes echo the "get that BS out of my face" vibe, just in more office-friendly words.

To understand why someone would be so passionate, let’s clarify JavaScript vs TypeScript differences in practice:

  • JavaScript is very flexible. You don’t have to declare types. You can do things quickly without a build step – just run it in the browser or Node.js and it works (or fails at runtime). It’s great for quick prototyping and was the only choice for front-end web for a long time. But that flexibility means the computer won’t catch certain mistakes. For example, if you accidentally treat a number like a string, JavaScript might not stop you until it’s too late (or sometimes it’ll just convert types silently, which can be confusing).
  • TypeScript adds a compilation step (you write TS, then transpile/compile it to get plain JS that the browser understands). During that compile step, it will catch a lot of mistakes. It’s like a built-in spellchecker or safety net for your code’s logic. It forces you to be explicit about what’s what. For instance, if you say a function should return a number but accidentally code a path that returns text, TypeScript will error out before you even run the code. This can save you from shipping bugs. On the flip side, it means you have to set up that compilation (so your build process is a bit more complex), and you have to write extra code (type definitions) which can feel tedious for small simple scripts.

Let’s look at a quick example to see this difference:

// JavaScript Example (dynamic typing):
let answer = "42";       // answer is a string right now
answer = 42;            // now answer is a number - JavaScript allows this
console.log(answer * 2); // This will print 84 if answer is number, 
                         // but if answer was accidentally a string like "42",
                         // JavaScript might treat it as "42" and do string things or NaN.
// TypeScript Example (static typing):
let answer: string = "42"; 
answer = 42; // Error: Type 'number' is not assignable to type 'string'
console.log(answer * 2); // TypeScript would not even let us get here if answer isn't a number

In the JavaScript snippet, we were able to change answer from a string to a number later – no immediate complaint from JavaScript. If we mistakenly assumed answer was still a string and tried string operations, we might get unexpected results. In the TypeScript snippet, we explicitly declared answer should be a string. When we then try to set it to 42 (a number), TypeScript throws an error while compiling. It’s preventing a potential bug (treating numbers as strings or vice versa) before the code ever runs. This illustrates why a TypeScript user might call plain JavaScript “dirty” or “unsafe”, because in JS you might not find such bugs until the code is actually running. Meanwhile, a JavaScript purist might retort that the TypeScript approach is overkill for simple situations, akin to having an overzealous editor who won't let you proceed without dotting every i and crossing every t.

Now, why is the TypeScript guy in the comic so aggressive? It’s poking fun at how people argue on the internet or in heated discussions. The phrase "dirty bullshit" is obviously a very strong negative opinion. It implies he thinks JavaScript is unclean or bad practice. This probably comes from experiences where JavaScript’s lack of strict typing led to bugs or maintenance headaches. A developer who’s been burned by a mysterious undefined is not a function error at 2 AM (a classic JavaScript runtime error when you call something that isn't there) might develop a bitterness towards dynamic typing. When they discover TypeScript fixes some of those issues by catching mistakes early, they become a huge fan and start to view the old dynamic approach as “bad” or “inferior”. On the flip side, some developers have had negative experiences with overly strict languages or the extra setup TypeScript requires, and they might find TypeScript fans to be pedantic or elitist. The comic chooses the TypeScript guy to go berserk (shouting at the JavaScript guy) – but it could honestly go either way in real life. In some circles, TypeScript enthusiasts get mocked too (there are jokes calling them typesafety addicts or saying “just write tests instead”). The core joke is that even though these two technologies can work together, their fans are portrayed as immediately at each other’s throats.

The “respect each other” part is key. It sets up an expectation: oh look, they’re setting a positive example, acknowledging that different preferences can coexist. That’s what we’d teach in a healthy developer community – to respect other people’s tech choices because every tool has a context. But the quick reversal (“nope, just kidding, I actually hate your choice”) highlights a truth: often developers fail to practice that open-mindedness. Especially online, it’s common to see someone post “I personally like JS for this project” and another person respond with something akin to “JS? That’s crap, use TS, you fool” or vice versa. The meme is basically a dramatized version of a Twitter fight or a comments section argument. The Poorly Drawn Lines style of art (a simple, flat comic style) adds to the humor because it’s very deadpan. The characters have simple, almost expressionless faces, and then one suddenly says something outrageous. That contrast between the calm artwork and the extreme words makes it even funnier and more absurd.

In simpler terms: JavaScript vs TypeScript is the context, and the comic is saying that as much as we claim to be tolerant of each other’s choices, developers often lose their cool over this debate. It’s a classic case of a small disagreement blowing up.

For a newer developer or someone just learning: don’t be scared! 😄 This comic is exaggerating to make a point. In reality, plenty of teams use both JavaScript and TypeScript code side by side peacefully. Many JavaScript developers eventually learn to use TypeScript for bigger projects, and many TypeScript users still write quick scripts in JavaScript when it makes sense. They’re not really mortal enemies. The joke is highlighting a silly mindset that we sometimes slip into. It’s a reminder that, yes, people have preferences (and there are valid reasons for those preferences), but we should try not to be like the guy in panel 3. Unfortunately, as the meme shows, maintaining that respectful tone is sometimes easier said than done in the heat of a tech argument!

Level 3: Unhandled Promise Rejection

At first glance, this comic sets up like a peaceful coexistence between JavaScript and TypeScript users. They literally "promise" to respect each other’s choices – a clever nod to JavaScript’s Promise objects (used for async code) and the notion of a social promise. But almost instantly, that promise is rejected with extreme prejudice. In fact, any seasoned JS developer might jokingly label this outcome as an UnhandledPromiseRejectionWarning – in other words, a promise that got rejected without anyone handling it gracefully. The humor hits close to home because we’ve all seen “friendly” tech debates escalate into flame wars in seconds. The meme exaggerates it: one moment it's "I prefer this, you prefer that, and that's okay…" and before the sentence even finishes, it’s "GET THAT DIRTY BS OUT OF MY FACE". This sudden escalation is absurd, yet it satirizes a real phenomenon in developer culture: the rapid breakdown of civility in language wars.

From a senior developer’s perspective, the comic brilliantly captures the tribalism that can exist between programming language communities. We have two devs: one represents JavaScript, the dynamic, interpreted language that’s been the backbone of the web for decades; the other is TypeScript, the statically-typed superset of JavaScript introduced to bring some order (and types) to the chaos. In theory, these two should get along great – after all, TypeScript transpiles down to JavaScript (meaning all TypeScript code ultimately becomes JavaScript that browsers can run). They’re literally family. But as any veteran engineer knows, kinship doesn’t stop tech sibling rivalries. The meme’s punchline is especially ironic to those in the know: the TypeScript developer is pushing away JavaScript and shouting insults at the very language that powers his own code. It’s like a castle tower sneering at its foundation. The experienced folks chuckle (or groan) at this because they’ve witnessed such ironic hostility in real life. Perhaps someone on your team insisted on converting the whole codebase to TypeScript for maintainability, referring to the old pure-JS code as “garbage” – or conversely, a JavaScript guru calling TypeScript “unnecessary bureaucracy” with a few choice expletives. The comic distills that conflict to its essence, using the abruptly broken promise of respect as the comedic vehicle.

Delving deeper, this scenario highlights a classic debate in software engineering: static typing vs dynamic typing. TypeScript’s main selling point is type safety – catching errors at compile time, providing better tooling (like IntelliSense and refactoring support), and making large codebases easier to manage. JavaScript, on the other hand, offers dynamism and flexibility – no compile step, rapid prototyping, and a “make it work quickly” vibe. These are fundamentally different philosophies. An experienced developer recognizes that both approaches have merits and drawbacks. Static typing can prevent a whole class of runtime bugs (and many a production outage), but it also introduces overhead and can feel rigid for small scripts. Dynamic typing keeps things lightweight and flexible, but it can lead to runtime surprises if you’re not careful. This dichotomy often becomes personal for developers: some identify as disciplined architects who value strict types (the TypeScript camp), while others identify as agile pragmatists who value speed and simplicity (the JavaScript camp). When people’s technical preferences tie into their sense of expertise or identity, discussions can get heated alarmingly fast.

The meme nails this by showing the polite facade dropping immediately. The text "BUT WE STILL RESPECT EACH OTH—" being cut off mid-word in the second panel is a terrific storytelling touch: it visually implies “we couldn’t even finish pretending to be respectful.” It’s funny because it’s true – we often start tech discussions vowing to be open-minded, yet the moment someone praises a different tool or language, that tribal instinct kicks in. The TypeScript dev’s over-the-top line, "Get that dirty bullshit out of my face!", is obviously exaggerated for comedic effect – real colleagues (hopefully) won’t scream profanity at each other in person. But on internet forums, Twitter threads, or heated team meetings, you’d be surprised how quickly the tone can approach this level of hostility (minus maybe the direct profanity if HR is watching). The phrase “dirty BS” here specifically ridicules how each side often sees the other’s beloved tech stack as inferior or “unclean.” It’s the kind of language you might see in a sarcastic Hacker News comment or hear in a frustrated rant when a bug is blamed on “that stupid dynamically-typed nonsense.”

Why is this so relatable to senior devs? Because we’ve all been through or witnessed these “holy wars” over technology. In the panel, it’s JavaScript vs TypeScript. But zoom out and it echoes countless divisive debates in our field:

  • Tabs vs Spaces for indentation – an almost religious argument in many code communities (with tongue-in-cheek “tabs people” vs “spaces people” rivalries).
  • Vim vs Emacs (or modern IDE vs classic editor) – developers identifying strongly with their tools, sometimes to the point of absurdity.
  • Windows vs Linux vs macOS – the OS wars, where each camp derides the others’ choice as suboptimal or “noobish.”
  • Object-Oriented vs Functional programming – deep disagreements on how code should be structured, often with each side claiming the other produces unmaintainable code.
  • Framework feuds (Angular vs React vs Vue in frontend, or Django vs Rails, etc.) – new frameworks often come with enthusiastic proponents who view older ones as outdated, and vice versa.

These debates all share a common pattern: what starts as a technical discussion can turn irrationally combative, as if each choice is a badge of honor and the “enemy” must be discredited. The meme is specifically about language tribalism – a subset of this phenomenon where programming languages are the battleground. Seasoned devs have seen cycles of this. Back in the day, there were Java vs .NET fights, or C++ vs Java, or PHP vs everyone else. Now in the frontend world, it’s plain JS vs TypeScript (with maybe some older folks reminiscing the days of CoffeeScript or the emergence of Microsoft’s earlier attempt at typing with Flow or even JSDoc annotations). The context tag typescript_vs_javascript hints at exactly this ongoing saga. Front-end development historically was dominated by JavaScript, but as applications grew in size and complexity, TypeScript rose as a solution to manage that complexity. It’s widely adopted now, and many would say it’s becoming the default in professional settings – which can breed a bit of superiority complex in its fans (“we use the proper tool now”). Meanwhile, hardcore JavaScript fans sometimes resent the implication that their beloved language is “dirty” or incorrect without types. After all, JavaScript code can be elegant and robust; it just relies on different practices (like good testing, disciplined coding, perhaps JSDoc, etc.) to ensure quality.

The humor here also comes from a place of empathy: we laugh, perhaps a bit nervously, because we recognize this behavior in ourselves or colleagues. Perhaps at a meetup or on Slack, someone says “I actually like vanilla JS for small projects,” and a TypeScript enthusiast immediately jumps in with “vanilla JS? enjoy your undefined is not a function errors, bro.” The initial speaker then might get defensive and reply with something snarky about TypeScript fanboys writing any everywhere (which defeats the purpose of TS). Before you know it, a simple exchange devolves into belittling each other’s skills or intelligence – exactly the kind of instant breakdown the meme portrays. This shared experience of conversations spiraling out of control is what makes the joke land so well. It’s exaggerated in the comic (we hope no real developer literally yells “Get that BS out of my face” in an office), but it captures the feeling of how quick and disappointing these interactions can be.

From an architectural or team perspective, the stakes behind these arguments are not purely ego either. A senior engineer knows that choosing a language or adding TypeScript to a project has real consequences: it affects build processes, hiring (do we need all devs to know TS?), code complexity, and interoperability. If a codebase is all JS and one dev starts using TS, that can create friction in version control or build steps. Conversely, if a team mandates TS, folks who love quick scripting might chafe at the added ceremony for simple tasks. So, there’s a backdrop of practical tension: one side prioritizes reliability and scalability, the other prioritizes simplicity and agility. Ideally, a mature discussion balances these trade-offs. But in practice, personal preference and pride often override nuance – hence the meme’s instant face-plant of a “discussion.”

The meme also subtly nods to how quickly trend sentiments change in the web development world. One year, everyone jokes about JavaScript being quirky but unavoidable; the next year, TypeScript is the cool kid on the block and plain JS is derided as “raw” or “unsafe.” The mutual_respect_fail context tag captures that irony: they tried to show mutual respect, and it failed spectacularly. This resonates with veteran devs who have seen developers swear by one approach this year and completely switch allegiances the next. We respect each other… until our strong opinions flare up.

In summary, the comedic core at the senior level is about recognition: Recognizing the absurd speed at which cordial language debates blow up, recognizing the static-vs-dynamic type arguments we’ve heard a thousand times, and recognizing our own industry’s tendency to form camps around tools. It’s funny because it’s a mirror – an exaggeration of real interactions during code reviews, conference panels, or Reddit threads. And it’s a bit cautionary too: even though JavaScript and TypeScript are on the same team (one literally compiles to the other!), developers still manage to turn it into us vs them. A seasoned engineer will likely chuckle and think “Yep, I’ve seen that happen,” perhaps remembering a specific heated argument from their past. The meme captures that specific flavor of tech humor where we laugh at our own communal pettiness. It’s both a cri de cœur and a wink: “We said we’d be respectful, but who are we kidding? This is the programming world – let the flame wars begin.”

Description

A four-panel comic from 'poorlydrawnlines.com' depicting the relationship between JavaScript and TypeScript developers. In the first panel, two characters are shown; one holding a yellow 'JS' logo says, 'I LIKE JavaScript,' and the other, holding a blue 'TS' logo, replies, 'AND I PREFER TypeScript.' In the second panel, the JavaScript character begins to say, 'BUT WE STILL RESPECT EACH OTH - '. He is cut off in the third panel by the TypeScript character, who angrily shoves the JS logo away, yelling, 'GET THAT DIRTY BULLSHIT OUT OF MY FACE.' The final panel shows the dejected JavaScript character standing alone with the JS logo on his chest. The comic humorously exaggerates the zealotry sometimes found in the developer community, specifically satirizing the perception that many TypeScript developers, having embraced static typing, view vanilla JavaScript with disdain for its lack of type safety

Comments

7
Anonymous ★ Top Pick A TypeScript developer sees 'any' and thinks, 'Ah, the devil's type signature. A legacy incantation from the dark ages before compilation.'
  1. Anonymous ★ Top Pick

    A TypeScript developer sees 'any' and thinks, 'Ah, the devil's type signature. A legacy incantation from the dark ages before compilation.'

  2. Anonymous

    Kickoff: “JS and TS can totally coexist.” Week 3: code review devolves into a cage match over whether `unknown extends any ? never : string` is elegant type-safety or just Java in cosplay

  3. Anonymous

    The TypeScript developer's migration plan was perfect until they discovered half the team's "any" usage was actually a design pattern called "trust-driven development."

  4. Anonymous

    This perfectly captures the JS/TS discourse: we all claim to respect different tooling choices until someone suggests removing 'any' from the codebase, then suddenly it's a holy war about whether compile-time type checking is worth the cognitive overhead or just enterprise Java cosplay for the web

  5. Anonymous

    The JS - TS debate always ends the same: one side trusts the compiler, the other trusts prod to run static analysis via PagerDuty

  6. Anonymous

    TS: Because nothing says 'I respect JS' like rewriting it with types that vanish at runtime

  7. Anonymous

    Everyone’s neutral on JS vs TS - until someone sets 'strict': true at the repo root and npx tsc --noEmit dumps 4,000 compile‑time feelings into the PR

Use J and K for navigation