DEV Community: Brad Traversy

TypeScript Is the Default for Writing JavaScript

Brad Traversy — Mon, 24 Aug 2026 16:35:00 +0000

JavaScript is FAR from dead, but its job description has changed. For a lot of modern web work, TypeScript has become the default way to write JavaScript, even though the code that ships is still plain JavaScript underneath.

That shift shows up everywhere: React, Vue, Angular, Node.js, monorepos, mobile apps, desktop apps, and even the application layer around AI. The real question is no longer whether people use JavaScript. It is where raw JavaScript still fits best, and why so many projects now start with TypeScript instead.

I also created a YouTube video on this topic.

TypeScript Has Become the Default Across the Modern Stack

A big part of the answer is simple scale. GitHub's 2025 Octoverse report says TypeScript became the number one language on GitHub by monthly contributors, passing both Python and JavaScript. The 2025 State of JavaScript survey found that respondents spent an average of 77% of their JavaScript and TypeScript coding time writing TypeScript.

That does not mean TypeScript replaced JavaScript. GitHub still saw more new JavaScript repositories overall. But the trend is obvious: TypeScript has become the normal choice for modern application development, especially once a project starts growing beyond a tiny script.

React, Vue, Angular, and Node.js Have Made Typed Workflows Feel Standard

The front end is where the shift feels most visible. React supports TypeScript fully, Vue is written in TypeScript and supports it first class, and Angular has used TypeScript classes for components since Angular 2. You can still write regular JavaScript with React or Vue, but many popular app starters now default to TypeScript, while tools like Vite place JavaScript and TypeScript templates side by side.

The back end has moved too. Current versions of Node.js can run .ts files directly when they use erasable TypeScript syntax, stripping the types before executing the remaining JavaScript. Node does not type-check the code, read tsconfig.json, or support every TypeScript feature through type stripping, but the built-in support still makes simple TypeScript workflows easier.

That becomes especially useful in a monorepo, where the front end, an API, a background worker, and a shared package all live together. Instead of defining a user, product, or API response in three different places, you define it once and reuse it everywhere.

A few patterns make that appeal really clear:

Shared types cut duplication across client, server, and worker code.
Zod lets you define a schema once, infer TypeScript from it, and validate real data at runtime with the same source of truth.
React Native projects now often default to TypeScript for mobile work.
Electron templates commonly use TypeScript for desktop apps.
Vercel's AI SDK puts TypeScript right at the center of AI application code.

Once you stack all of that together, TypeScript is not just a nicer editor experience. It has become a shared language across a huge part of the application stack.

TypeScript Won Because It Made JavaScript Feel Safer and More Legible

The appeal is not mysterious. TypeScript brought ideas that developers already knew from languages like Java, C, and C++ into the JavaScript world. That mattered a lot when JavaScript still had a reputation as a toy language, mostly good for form validation and dropdowns.

The practical wins are what keep people using it:

Renaming a shared field, like changing name to fullName, can instantly reveal every component, API route, or function that still depends on the old field.
Autocomplete becomes more accurate because the editor understands what a function expects.
Types act like contracts, so different pieces of the codebase describe how they fit together.
Refactors get safer because you can jump to definitions and rename things across a project with more confidence.

There is also less friction than there used to be. Frameworks, libraries, and build tools now support TypeScript extremely well, and its inference has improved enough that you often get strong type checking without annotating everything manually. That means you can pick up better autocomplete, safer refactors, and clearer feedback without turning the whole project into a ceremony festival.

It's just one more useful layer of feedback.

And that matters even more when AI is writing part of the code. An agent can still produce perfectly typed garbage, so TypeScript should never replace tests or code review. It just gives you another check on top of the others.

Learn JavaScript First, Then Add TypeScript When the Project Earns It

Beginners should still learn JavaScript first. If the goal is web development, skipping straight to TypeScript syntax is backwards. Learn functions, objects, arrays, scope, asynchronous JavaScript, the DOM, and how the language behaves at runtime before layering anything on top.

That foundation matters because weird TypeScript bugs are usually really JavaScript problems in disguise. Once those fundamentals are solid, TypeScript becomes the next step, not the first step. You do not need to become a type-system wizard. You just need to recognize the types you will see in real projects and learn how to read the errors.

Still, JavaScript has real jobs that TypeScript does not always improve. Plain JavaScript can be the better choice when the work is small, quick, or intentionally simple:

A tiny script or quick prototype often does not need the extra setup.
A low-code project can move faster without types getting in the way.
Teaching fundamentals is sometimes easier when the type system is not clouding the lesson.
A one-off file that just needs a few lines and a run command can be better left alone.

Choosing JavaScript does not make the work amateurish. It means the tradeoff makes sense. TypeScript adds value, but it also adds concepts, configuration, and another class of errors to understand. Use JavaScript when simplicity wins, and reach for TypeScript when the project has enough moving parts to deserve the extra structure.

JavaScript still powers the web, but TypeScript now shapes how a huge part of the ecosystem gets built. The smartest choice is not picking a side; it is knowing when the typed version earns its keep.

This article was adapted from Has TypeScript Become the Default Way to Write JavaScript?.

I've Changed My Opinion On Vibe Coding

Brad Traversy — Mon, 18 May 2026 15:35:01 +0000

As I said in this video, I used to be pretty skeptical of vibe coding. Watching people ship apps without understanding a single line of what was generated always felt like a disaster waiting to happen, especially when beginners hit the first real bug and have no idea where to start. And the idea that you can build successful software or SaaS without learning software development? I never bought that for a second.

That said, my opinion has shifted a bit. The models are better, I've been using Claude Code, GPT-5.5, and OpenClaw in a much more serious way, and I've seen firsthand where AI can actually carry real weight. The catch is that it only works when you already understand what you're doing.

Vibe coding is the extreme end of the AI coding spectrum

There's a real spectrum when it comes to coding with AI. On one end, you have one-shot prompting with platforms like Lovable. On the other, you have autocomplete in VS Code. Somewhere in the middle is the sweet spot: let the agent write the code, but you still make the architectural decisions, write the specs, and test the result.

That middle ground is what I actually teach in my AI course, and it's a lot different from what I mean by vibe coding.

Vibe coding, to me, is when you're barely looking at the code at all. You're going off the vibes instead of the syntax, and for a long time I was totally against that. I still think a lot of people confuse "using AI" with "understanding software," and those are not the same thing.

Better models changed the equation, not the rules

A big part of why I've softened is simple: the models are just better now. Claude Opus 4.7 with Claude Code, GPT-5.5 with Codex, and even OpenClaw with GPT-5.5 are all good enough that, if you know how to direct them, they can do a lot of the heavy lifting.

I'm seeing less hallucination, more first-try success, and a lot less need to babysit every line the way I would have with something like GPT-5.3. That matters.

But the model getting better is only half the story. The other half is that I've learned how to work with these systems more effectively. I know how to manage context and memory, how to map out documentation and spec files, and how to steer the model toward the outcome I want.

That's exactly why I'm not willing to pretend the tool alone is enough. Better output does not erase the need for actual judgment.

Foundation still decides who can use AI well

I'm not budging on this part: vibe coding is not okay under any circumstance if you do not have a foundation in software development and architecture. If you do not understand the basics, AI does not magically create them for you.

A few things make up that foundation:

How the web actually works

You need to understand requests, responses, status codes, and what happens between the browser and the server. Without that, you're just guessing at what the app is doing.

How data is structured

You need to understand how to model data, how relationships work, and what an index is. If the data model is fuzzy, the app will be fuzzy too.

How to read code, not just write it

You need enough hand-written code under your belt that you can read code and actually see what it's doing, instead of skimming past it like noise.

How debugging feels in real life

You need to have been burned by enough bugs to recognize bad patterns. That kind of pattern recognition does not come from prompting.

You do not need a CS degree. You do not need to memorize sorting algorithms. You do not need to be a genius. But you do need to have built things from scratch, broken them, fixed them, and learned what failure looks like.

That confidence is the dangerous part.

Beginners should use AI to learn faster, not skip learning

I am not saying beginners should stop using AI tools. That ship has sailed, and fighting it is the wrong move. The better move is to change what you use them for.

Use AI to accelerate learning, not to bypass it.

There's a huge difference between those two things, and that difference is where most people go wrong. If you're new, let the model explain the code it generates. Type it out yourself. Break it on purpose. Then figure out why it broke.

That process is where the actual growth happens, and it's also why the developers who will do well over the next few years are not just the ones who can prompt well. They're the ones who can prompt well, read code, design systems, and debug under pressure.

The AI handles the typing. You still have to handle the thinking.

Vibe coding works best after you've earned the right to trust it

Once you're past the learning stage, vibe away. Seriously. If you already have the foundation, AI can be an incredible force multiplier, and I've been using it that way in my own workflow and in my home lab with eight machines managed by OpenClaw.

But it should not become your entire workflow for every project. If you rely on it for everything, you will forget too much and become too dependent on it. That's where the trouble starts.

My position now is simpler than my old one. I am not against vibe coding anymore. I just think it should be a tool, not the whole system.

The AI handles the typing. You still have to handle the thinking.

And that is the whole line between useful and dangerous: let Claude, GPT-5.5, and the rest speed you up, but never let them replace the part of the job that actually makes you a developer.

This article was adapted from I've Changed My Opinion On Vibe Coding

I Built DevSheets.io - A Modern Cheat Sheet Site for Developers (And Why We Still Need Them)

Brad Traversy — Mon, 13 Oct 2025 11:37:53 +0000

We've all been there. You're deep in a coding session, need to remember that one Git command, or the syntax for a CSS flexbox property. You Google it, click the first result, and... ads everywhere. Outdated information. Slow loading. Ten paragraphs before getting to the actual answer.

That's why I built DevSheets.io - a modern, fast, and clean cheat sheet platform designed the way developers actually work.

The Problem with Existing Cheat Sheets

Don't get me wrong - there are some great resources out there. But many suffer from:

Information overload without structure - Everything on one massive scrollable page
Outdated content - Still showing jQuery examples in 2025
Terrible UX - Intrusive ads, slow loading, poor mobile experience
No search - Finding specific commands means Ctrl+F through walls of text

I wanted something that felt native to how we actually code - quick, focused, and just works. I have been creating educational content on web dev and other tech topics for years and I have taken the stuff that people often struggle with, and put it into short, concise sheets that are easy to understand.

It does not cost a dime and there are not even any advertisements. It is completely free to view all 50+ sheets.

What Makes DevSheets Different

1. Clean, Focused Design

Each cheat sheet is organized logically with a clear table of contents. No distractions, no ads. Just the information you need.

2. Modern Tech Coverage

We focus on technologies developers actually use in 2025:

React Router v7 (with the new Library and Framework modes)
TanStack Query for server state management
Docker commands and orchestration
Modern JavaScript patterns (async/await, modules, etc.)

3. Estimated Read Time & Difficulty

Every sheet shows how long it'll take to reference and the complexity level. Planning to learn TypeScript? You'll know it's a 10-minute intermediate-level reference before you dive in.

4. Built for Speed

The entire site is optimized for performance. No bloat, instant navigation, works great on mobile when you're pair programming and need a quick reference.

The Stack

For the tech-curious, here's what powers DevSheets:

Frontend: React 19, Next.js 15, TypeScript
Backend & DB - Next.js, Prisma, PostgreSQL (Neon)
Styling: Clean, responsive CSS with Tailwind CSS
DevOps - Vercel, Github Actions
Content: Structured data that's easy to update and maintain
Icons: Custom SVG icons for each technology as well as Heroicons

I'm also considering:

Dark mode toggle (because of course)
Downloadable PDFs for offline reference
Community contributions for niche technologies
Interactive examples for certain concepts

Why I'm Sharing This

I built DevSheets because I needed it myself. The best tools often come from scratching your own itch.

But here's the thing - I want your feedback. What cheat sheets are you missing? What could be better organized? What technologies should I add next?

Check it out at devsheets.io and let me know what you think in the comments.

For Fellow Builders

If you're thinking about creating a developer tool or resource:

Start with your own pain point - If you need it, others probably do too
Keep it simple - Don't over-engineer v1
Make it fast - Developers have zero patience for slow sites
Get feedback early - Build in public, share often

The web is full of resources, but there's always room for something done better, faster, or with more care for the user experience.

What cheat sheets do you find yourself referencing most often? Drop a comment below!

🔗 Visit DevSheets.io