Dev Time Scaling: To Server or Not to Server

Episode Description

JavaScript Jam panelists debate the post-Node era with Deno and Bun, critique DevOps theater in companies, and argue whether beginners should start with TypeScript.

Episode Summary

This JavaScript Jam Live session covers three main topics shaping the web development landscape. The discussion opens with Anthony Campolo introducing his new Twitch stream before the panel pivots to whether we've entered a "post-Node era" with the rise of Bun and Deno as alternative JavaScript runtimes. Theo Browne draws a sharp distinction between the two: Deno aims to restore the simplicity of writing and running JavaScript like you would in a browser, while Bun focuses on raw speed without rethinking workflows. Jason contextualizes these runtimes as products of the shift from heavy VMs to edge compute. The conversation then turns to a Hacker News article arguing that DevOps has lost its meaning, with most companies simply relabeling their ops teams. Theo offers a vivid counterexample from his experience at Twitch, where over-engineered Kubernetes infrastructure and not-invented-here syndrome crippled developer productivity, contrasting it with his startup Ping, where a single package.json powers the entire operation. The final segment sparks a lively debate on whether new developers should learn TypeScript from the start. Theo argues strongly for TypeScript-first education, proposing tutorials written in TypeScript that delay explaining the type system, while Ishan and Nathan explore the tension between abstraction-driven productivity and understanding fundamentals. The panel converges on the idea that developer productivity should guide the learning path, with deeper knowledge pursued incrementally.

Chapters

00:00:00 - Introduction and Stream Logistics

The episode opens with host Scott Steinlage welcoming listeners to JavaScript Jam Live, a weekly Wednesday show covering JavaScript and web development for developers of all experience levels. There are some initial technical difficulties getting co-host Ishan Anand set up as a speaker on Twitter Spaces, including a cryptic null error when the co-host invite gets canceled mid-click.

Ishan returns from PTO and introduces the JavaScript Jam newsletter, available through composability.dev, which recaps each week's discussion and previews upcoming topics. Anthony Campolo then shares his new Twitch stream called "AJC and the Web Devs," explaining how it differs from his FSJam podcast by incorporating video and live pair-programming with guests. He recaps his first two episodes and previews a solo Bun walkthrough for episode three.

00:09:53 - The Post-Node Era: Deno, Bun, and the Future of JavaScript Runtimes

Ishan introduces the idea that we may be entering a "post-Node era," drawing a parallel to the proliferation of JavaScript frontend frameworks. Anthony pushes back on the framing that one runtime needs to "kill" another, suggesting multiple good options can coexist. The panel explores what problems Deno and Bun are actually solving, referencing Ryan Dahl's famous talk on his regrets about Node and citing security, TypeScript support, and cleaner architecture as key motivations.

Theo Browne offers a compelling framework for understanding the distinction: Deno is about restoring the simplicity and elegance of writing a quick script, much like you would in a browser console, while Bun is laser-focused on making existing workflows faster without fundamentally rethinking them. He positions Deno as competing more with Python than with Node, and Bun as a direct Node competitor. Jason adds historical context, noting that Node was built for a VM-centric server era, while Deno and Bun are products of the edge compute age. The practical advice from Theo is to use Deno when it solves a specific problem rather than learning it preemptively.

00:25:22 - Midpoint Break and the DevOps Identity Crisis

Scott delivers the midpoint station break, encouraging audience participation and promoting the composability.dev newsletter. Ishan then introduces a Hacker News article arguing that DevOps has become so universally praised that companies are afraid to admit they don't actually practice it, often just renaming their ops teams. Jason confirms this matches his experience with most established companies, calling out the pattern of relabeling without real change.

Theo offers a different angle from his experience at large tech companies like Amazon and Twitch, where the problem isn't relabeling but rather small startups prematurely hiring DevOps engineers because they built overly complex infrastructure instead of leveraging tools like Vercel, GitHub Actions, or Planetscale. He argues that not-invented-here syndrome is one of the most damaging patterns, citing Twitch's struggle with a massive Kubernetes-based infrastructure that a small startup team easily outpaces with simpler tooling.

00:34:29 - Kubernetes, Serverless, and Developer Productivity

Theo shares a detailed example from Twitch, where over-engineered infrastructure requiring Terraform configs and Kubernetes clusters for every feature dramatically slowed development. He contrasts this with Ping, his startup, where a single package.json powers everything and a talented engineer built full-stack features for six months without ever needing to understand what an endpoint was, thanks to tools like tRPC and Next.js abstracting away the complexity.

The conversation broadens into the Kubernetes versus serverless debate. Theo memorably calls Kubernetes "the Flutter of infrastructure" — great for a specific problem, but usually overkill. He then plays devil's advocate, acknowledging that developers often optimize for personal convenience over company cost, but argues that developer time at hundreds of dollars per hour almost always outweighs the infrastructure savings of self-managed solutions. The panel agrees that serverless and edge technologies have made this calculus increasingly clear, and Ishan ties this back to the Composability Summit theme of building adaptable, modular digital experiences.

00:45:21 - Should Beginners Start with TypeScript?

Jason praises Theo's composability talk, and Ishan transitions to the final topic: whether TypeScript has become essential knowledge for every web developer. Theo argues passionately that it has, noting he doesn't do any web development without TypeScript and proposing that even brand-new developers should start with it. His vision is a tutorial written entirely in TypeScript that teaches JavaScript fundamentals first and only introduces the type system partway through.

The panel debates whether this approach introduces too much "magic" for beginners. Anthony and Ishan push back, noting that many production sites still run vanilla JavaScript and that understanding fundamentals matters. Nathan threads the needle by comparing it to the Ruby on Rails experience, where convention over configuration meant developers often couldn't distinguish framework from language. He frames it as a skill floor versus skill ceiling problem: beginners should reach productivity quickly through abstraction, then deepen their understanding incrementally. The panel converges around the idea that developer productivity should drive learning priorities, with resources like Matt Pocock's Total TypeScript on GitHub recommended as excellent starting points.

01:07:57 - Learning Resources and Closing Remarks

Jason mentions Matt Pocock's TypeScript resources as particularly helpful for experienced JavaScript developers transitioning to TypeScript. Nathan shares the specific GitHub organization — Total TypeScript — which includes both beginner and advanced workshop-style courses with tests and exercises. He also plugs his own Twitch stream where he walked through the beginner course live, and the panel agrees to include these resources in the next newsletter.

Ishan wraps up the discussion by reflecting on the importance of "learning to learn" as a foundational developer skill, sharing an anecdote about volunteer coding education where the first lesson taught was how to Google effectively. Scott closes the show by encouraging listeners to follow the speakers, subscribe to the newsletter at composability.dev, and join again next Wednesday at noon Pacific. The episode ends with appreciation for the lively disagreements that drove the conversation forward.

Transcript

00:00:00 - Scott Steinlage

Hello, welcome, welcome. Jason, what's up? I invited you up there. All right, well, we'll just wait here for a few minutes for more people to jump on in.

00:00:16 - Ishan Anand

Hello.

00:00:18 - Scott Steinlage

Hey, what's up, dude? Ishan should be joining us here.

00:00:27 - Anthony Campolo

And...

00:00:29 - Scott Steinlage

Make sure he is aware. There he is, actually. All right. Speaking of... all right, let me invite co-host. Send. There you go. Ishan, I sent you the co-host invite there. I don't know if it...

00:01:03 - Ishan Anand

Here.

00:01:03 - Scott Steinlage

I'll cancel it, redo it. Sometimes it, like, pops up on your thing and goes away.

00:01:10 - Nathan

Real quick.

00:01:13 - Scott Steinlage

Added speaker. Okay, I'll just add you as a speaker. I don't know why the co-host thing isn't working, but there you go.

00:01:22 - Theo Browne

Here we go.

00:01:23 - Ishan Anand

There we go.

00:01:25 - Scott Steinlage

There we go. Cool.

00:01:26 - Ishan Anand

Actually, you canceled it right as I was clicking on it, so then it gave me this really cryptic error message: "Null." Somebody did not test that workflow in Twitter Spaces.

00:01:40 - Anthony Campolo

Hey, we got the whole team here.

00:01:42 - Theo Browne

All right.

00:01:42 - Ishan Anand

Yeah, it's been a while.

00:01:46 - Anthony Campolo

I saw the email. There's a JavaScript Jam newsletter.

00:01:50 - Ishan Anand

Yeah, we had a newsletter go out. We can talk about that in a second, but do you want to kick us off, Scott?

00:02:01 - Scott Steinlage

Yeah, absolutely. Hi, y'all. Welcome. Welcome to JavaScript Jam Live. This is where we party all day and all night. No, I'm just kidding. This is every Wednesday, 12:00 PM Pacific Standard Time. We talk about JavaScript and anything really web-development-related. In fact, if you're a beginner at this or you've been doing this a long time, it doesn't matter. We love to hear from everybody. Some of the greatest conversations that we've had up here are from those in the audience participating. So if you're out there in the audience and you want to participate, you want to ask a question, we encourage it. Not just asking a question, but also giving your opinion too. Feel free to request to come up as a speaker, and we'll be more than happy to have you up here participating in the conversation. With that being said, we have our lovely co-host here, Ishan, who is going to be chatting it up throughout the duration here, for the most part, with all of you too, as well.

00:03:16 - Theo Browne

Looking forward to it.

00:03:18 - Ishan Anand

Yeah. And I think I'm back from PTO. I think I missed the last two weeks, so it's great to be back. And, you know, as Anthony noted, we had the newsletter go out. So those of you who are listening that aren't on the newsletter, you can actually go to composability.dev and then sign up, give your email address. You'll eventually be able to go to javascriptjam.com as well and sign up for the newsletter. It'll be the same newsletter that we'll be sending out, talking about both composability, which is what the summit was about, as well as topics in the JavaScript and web development ecosystem in general. And so it's our little news newsletter. We'll be publishing out what we think is interesting on the web, and one section of it is going to be about what we talked about last week in these weekly sessions and then what looks interesting to talk about in the next session. So feel free to use the newsletter. There'll be a link in there where you can suggest a topic for us to talk about. We want this to be like our JavaScript Jam Live sessions, which means they're driven as much by you guys as they're driven by us.

00:04:32 - Ishan Anand

So that's the newsletter. There's a couple things I put in there for us to talk about that came up in the last week, but I'll first open it up to the panel here. Is there anything that's on folks' minds in the web dev JavaScript ecosystem that's top of mind besides what I put in the newsletter for this week, or anything I missed from the last two weeks that you think is worth revisiting? Okay, I'm hearing not actually. Wait, let me just do a sound check. Can you guys still hear me? Did I lose connection?

00:05:14 - Anthony Campolo

You're here.

00:05:15 - Ishan Anand

Okay, great.

00:05:15 - Anthony Campolo

Hit us with the topics.

00:05:17 - Jason

Okay, so not to sidetrack too much, but I found the newsletter in my spam box. I'm not sure why.

00:05:26 - Ishan Anand

Oh no, same.

00:05:28 - Anthony Campolo

Yeah, same. And how did you get my email? Because I'm sure I've given you my email lots of times. I don't know if I signed up for a JavaScript Jam newsletter, though.

00:05:37 - Ishan Anand

You probably signed up for composability.dev. You know, as a speaker on composability.dev, you probably signed up for the conference to watch it. That's where we got your email. Great. Actually, Anthony, I just knew your email and I manually typed it in.

00:05:54 - Anthony Campolo

I mean, I would hope you'd have my email by now. I've given it to you in different services.

00:06:02 - Ishan Anand

Oh, actually, speaking of. So this is a sidetrack. Anthony is the host of a podcast, FSJam, which I've been a big fan of. But you just launched a second podcast...

00:06:17 - Anthony Campolo

Do you want to talk about the stream? It's not a podcast. There's a very important distinction here. This is something that confuses my partner too, when I talk about whether I'm doing a podcast or a Twitter Space or a stream or any of those three things. So to me, FSJam has never had a video component, not even just, like, showing our faces when we talk, like at all. Whereas I see a stream as something where there's video and then there's also usually screen sharing. So I've created a stream where I do, like, if you know Learn with Jason or Alex Cho's Front End Horse or Ben Myers' Semantics. There's a lot of streams like this, or even Teach Jenn Tech's stream. The streams where you have a host, they bring on a guest, the guest usually walks them through some sort of project that they build. So it's a bit like pair programming, which I really like. And typically the host drives. They're the ones coding, while the guest kind of talks them through things or kind of helps them figure out the project. The idea being that they're the expert and you're the noob, and you're giving them a chance to kind of teach something, but you're setting them up to teach something hopefully comprehensible and, like, bounded in scope.

00:07:24 - Anthony Campolo

So yeah, I've been hosting streams for my companies in the past. I hosted the StepZen stream for a while. I currently host the QuickNode stream, and I just love streams. And I wanted to finally kind of pull the trigger on that because Ben Myers gave me a sweet name. He told me I should call it AJC and the Web Devs. And my philosophy on projects is once you have a good name, you have to start it. So that was why I started it.

00:07:48 - Ishan Anand

You know, I have a friend in college where that was how we did business ideas and band names. Like, forget the music. As soon as we get a good name for the band, let's start. But you actually executed. So do you want to tell people the domain name, or if we just Google AJC and the Web Devs, that should be the best?

00:08:07 - Anthony Campolo

The place you would want to find it would be Twitch.tv/AJCWebDev. So it's still my same handle, AJC WebDev. And you can find it on Twitch. I'm also uploading them after the fact to YouTube, but that's not really as important. If you want to watch them live as they're happening, you watch on Twitch, and you can also check out the videos on demand up to two weeks after they air. So if you go to Twitch.tv/AJCWebDev, you'll see the last two episodes. If you Google AJC and the Web Devs, I have gotten good SEO for that because my first episode will pop up first on YouTube. My first episode was with Ben Myers, speaking of him again, and he helped me build out a social share card for the show using HTML and CSS. It's a really fascinating concept where you build, like, a page that has a title and two little floating image heads and, like, your show name and the date, and you can fill in the HTML to create new social share cards for each episode. So that was episode one, and then episode two was with Ryan Carniato.

00:09:12 - Anthony Campolo

Just to talk about Solid because he's a good friend, and I've already had him on the podcast and wanted to learn more about Solid and thought that would be a good hook-y episode for people who are interested in new front-end stuff. Solid is pretty hyped.

00:09:27 - Ishan Anand

Do you want to give us a preview of what episode three is?

00:09:30 - Anthony Campolo

Episode three will be a solo stream that I'll be doing by myself, and I'm going to be running through Bun for the first time. I'm obviously aware of Bun. We talked about Bun, I think, last week on here, and I'm going to be going through the docs and their kind of hello world. I literally haven't used it yet, so it's going to be me kind of going in fresh and seeing what happens and what I can build with it.

00:09:53 - Ishan Anand

Oh, well, you know, that's almost like a perfect seg to the third item in the newsletter, which was, you know, Bun just launched Oven, and they announced, I think, like 7 million in new funding just recently. You know, it's definitely looking like... so that would be the next topic to move to. There's both the fact that Bun launches Oven, but then there's this... it seems like we're in a new era where it's called the post-Node era. Let me throw this as a proposition, see if it resonates with folks and if people can agree or disagree. But it's a post-Node era, just like... and one prediction of this is not only will we have Bun and the other, like Deno, but we could end up like JavaScript frameworks where it's just like there's a new runtime coming out all the time. It feels like what we're seeing with JavaScript front-end frameworks. Maybe that's too much of an exaggeration.

00:11:02 - Anthony Campolo

It's funny you say that, because the reason why I decided to do Bun is because someone actually messaged me about the show, was asking me what my next episode would be. I'm gonna do a solo stream. What should I do it on? And he's like, could you do it on Bun? Do you think it's really going to be able to take on Node? And my response to him was exactly what you said. I don't think we need to be in a world where something kills another thing to be a viable thing. I think we could be in a world where there's just multiple good options that have different trade-offs, and people can pick whichever they want. And there may be a front-runner, like React is the front-runner, but that doesn't mean Svelte's a bad choice or Solid's a bad choice. It just means it's not the most popular choice. And I think that it would be awesome if the back end was the same way. There's just various good choices people can choose from.

00:11:51 - Ishan Anand

So it sounds like you... so do you believe that we're going to end up in a post-Node world, but it will continue to be dominated by Node, is kind of the prediction you're making?

00:12:00 - Anthony Campolo

Yeah, I mean, I think we've been in a post-Node world. I've been using Deno, for example, in apps and talking about it and kind of promoting it for at least two years now. So I think that Deno has been a viable alternative to Node, depending on your reliance on the npm ecosystem. But beyond that, there's nothing wrong with it. It works just fine. So I think we've already kind of been there. I think Bun is helping reinforce that and make it a mainstream idea that there are alternatives to Node. Yeah, I think it's great.

00:12:34 - Jason

Well, and Node's not going anywhere. The install base is so massive, and the toolchain and ecosystem are beyond description. So it's not going anywhere. But these upstarts will definitely have their own place in the world. So just like React has become so dominant, but like we were just saying, we're going to get a lot of... we have a lot of new choices for very specific use cases. You know, Deno and Bun might not be super useful in a lot of different places today, but they're only a few weeks old or a year or two old.

00:13:08 - Ishan Anand

So, you know, take it from the perspective of somebody who's coming at this for the first time. All they've known is Node. It's just kind of like a fait accompli as the default. What would you express to them as the trigger that's been causing, you know, the post-Node era? How would you describe it? Like, what are Bun and Deno solving? I have my own view on this, but how would you express it? I'm curious from the panel on what's the hole they're filling or the differentiation there?

00:13:37 - Anthony Campolo

Well, Ryan was kind enough, and I'd be curious to get Theo's thoughts on this. Theo's been a Deno fan for a while, but Ryan laid out eight reasons why he thought we should move away from Node in the talk, which he did not name "10 Things I Regret About Node." This is a funny side tangent. The "Top 10 Things I Regret About Node" has eight regrets in it because he did not name it that talk. The conference renamed it to that talk. It's mostly that he felt that the dependencies were crazy, npm sucked, there were a lot of ideas in the project structure and things that he just felt like could have been cleaner, and he wanted to go for more of a Node-like ecosystem where you have a single binary, a standard library. And so there's a whole host of reasons that he has elucidated at length, but I think also just security. Like, you know, Node is not very secure. Deno is potentially more secure. So I would say that's kind of like the first set of reasons that particularly get cited.

00:14:40 - Ishan Anand

Yeah, I think you're talking about... so just for folks, if you Google "10 Things I Regret About Node," Ryan Dahl, who created Node, has a talk, as well as, I think, an article where he outlines the things that he wishes he had done differently, what he's learned from doing it. And I think there's security, built-in TypeScript, a bunch of other things. But is there anything that jumps out to you? Like, for me, when I looked at Deno, what I thought was really interesting, and maybe that just shows my bias as somebody who originally came from a C background, the way that they've structured it with a very... what's the right way to say it? Like, in Node, if they want to call out to the operating system or an OS API, they just kind of bind directly to it. And they're a lot more rigorous about, hey, there's this one single binding point that everything goes through, and that way you can control the API surface area as an embedder into a system a lot better. The other thing that I think is really useful is just their focus on this being really built to run not as long-lived servers, but what I view a lot of these guys doing is trying to optimize startup time and execution on the edge.

00:15:54 - Ishan Anand

Those are the two things that jump out at me, but I'm curious to hear what jumps out to other folks as well.

00:15:58 - Scott Steinlage

I think Theo was raising his hand here.

00:16:01 - Theo Browne

Yeah, I've been trying to go since I showed up. Goddamn.

00:16:06 - Scott Steinlage

Before you start, I just want to make sure you're going to provide us

00:16:09 - Theo Browne

with good captions for this. Yeah, I will do my best. I will write every word I say and manually mail them via paper mail to anybody who needs... anyways, I feel like we're doing the thing we love to do as engineers, where we talk a lot about features and implementation details and not about why. The need for Deno is much less like any one spec or technical change. It's much more a vibe. There is a specific vibe that Ryan was trying to go for with Node, which is take the elegance of writing a quick, simple script in your browser to the CLI with the power of JavaScript and all of the dynamic behaviors the language has. And as Node has evolved, as package.json has become more essential, as the ecosystem has become more and more complex, that elegance has been lost. It's no longer as simple as you write a JavaScript file and run it. And on top of that, TypeScript throws a huge wrench into things as well, where now you have to have a whole build chain just to make your TypeScript file into a JavaScript file that you can run. His goal was specifically to bring back the simplicity of writing JavaScript in the console and the web to the CLI and to make the simplest method for writing scripts in that mindset.

00:17:20 - Theo Browne

And when he worked on that, he took things he learned from Golang, from TypeScript, from Rust, and from these other communities and the way they did things around security and all these other things we're talking about here. But that wasn't the goal. Those were nice things he learned from his mistakes with Node. The goal was very specifically to bring back the simplicity and elegance of JavaScript on the web and treat the console more like a web browser.

00:17:43 - Ishan Anand

I think that's very well put. There's an episode of the Google guys, Jake and I forgot the other person there, the podcast HTTP 203, I think they call it, and they talk about how the great thing about Deno is it feels like it's got a lot of the web philosophy in it. But I really like how you described it, which is it's the simplicity of just writing a quick script in the command line like you would in the browser, to the extent that the APIs are the same that you'd use in the browser that you'd use inside a Deno environment. What do you think of Bun then? I'm curious.

00:18:26 - Theo Browne

I think Bun is doing the thing that we were all doing five minutes ago, where it's getting really nerdy about the specs, and it's incredibly nerdy about the specs. It's going to push a lot of stuff forward. It's actually actively improved the WebKit JavaScript layers and JavaScriptCore significantly. I think that those innovations are great, but they are not a rethinking of workflows. They're a challenge to the speed of the current workflows. I don't think Bun's ultimate goal is to change how we do development. I think its goal is very explicitly to speed up how we're currently doing development, whereas Deno is trying to rethink the whole flow.

00:19:03 - Ishan Anand

Interesting.

00:19:05 - Theo Browne

I see Bun as competing with Node, not Deno, and I see Deno as competing with Python more than Node, if that makes sense. Now they're changing that because that didn't work. But the initial plan for Deno was to be Python for TypeScript and JavaScript, basically.

00:19:24 - Ishan Anand

Can you walk that connection, the Python one, forward? I mean, I'm not sure actually I fully process that.

00:19:31 - Anthony Campolo

The...

00:19:34 - Theo Browne

My understanding of how people viewed Python is definitely not how they do anymore, but the way it was pitched to me back in the day, and I still think a lot think of it this way, is the easiest way to open up a file, write some code, and then run it on your machine. Node is nowhere near as elegant for a new developer writing their first code and running it, especially if they want to use the better version of JavaScript known as TypeScript. Those hurdles are not things that Bun is trying to cross. In fact, Bun almost inarguably makes it harder to do web development. Almost every post I've seen people comparing Bun's stats, about half or more of them have numbers that look like shit, and every single one of them isn't actually using Bun to run the code, which is hilarious. That's not how... I see the way Bun's doing things in that regard as almost inverse from how Deno is, where Deno's trying to make things easier. Bun doesn't care if they get harder as long as they get faster.

00:20:30 - Ishan Anand

Interesting. So I cut out for part of that, but I think if I were to fill in the blanks, basically what you're saying is the fastest way to get from writing a script to serving it on the web. Python was dead easy. And that's who, you know, Deno is competing with in a sense.

00:20:50 - Theo Browne

Not even just serving on the web, but even running on your own machine is way easier with Deno and Python than it is with Node and getting started there.

00:20:56 - Ishan Anand

Yeah, okay, that makes a lot of sense. Interesting. I'm curious if there are any folks in the audience or panel who want to jump in or add their take on Deno vs. Bun. Feel free to raise your hand. In the meantime, then I guess to walk this back to the original question: is it a post-Node world where we're going to see a Cambrian-like explosion of server-side runtimes, just like we see an explosion in JavaScript frameworks in a post-React world? Or do you think it's just going to settle down to Deno, Bun, and Node, and maybe one or two others?

00:21:41 - Scott Steinlage

I think Jason had something to say.

00:21:42 - Ishan Anand

Oh.

00:21:45 - Jason

Yeah, not directly on that particular flavor of the question, but maybe I'll get there. Node was invented in a completely different era, right? VMs were kind of avant-garde then. By today's standards, they're big, heavy runtimes. You're most likely running on some dedicated server somewhere. And so Node was great for that because it was much lighter than the alternatives, except for maybe Ruby. So it had its own kind of... it was a product of its own ecosystem, right? It was a hack on top of JavaScript to make it easy to run on the server. There were other options. There was Rhino and Narwhal and some other Java-based VMs that you could run JavaScript on the server. But Node won out, and the new upstarts, Bun and Deno, are just the product of today's systems, where we're moving from VMs being considered too heavy. So now we're moving to edge compute, and once we get to edge compute, you need a completely different type of runtime environment. So these systems will be much more aligned with the way we're probably going to want to build and deploy applications over the next decade.

00:22:56 - Anthony Campolo

Right.

00:22:57 - Jason

So that's kind of just my take on it. I think it'll be... and every time this happens, when Node came out, there were two or three other different ways of doing JavaScript on the server. We've just forgotten about them now because Node became so dominant. So who's going to win this round? Time will have to tell, but that's kind of the... we're entering into a new phase, a next era, of JavaScript runtimes.

00:23:24 - Theo Browne

Anyone remember io.js?

00:23:26 - Jason

Yeah.

00:23:29 - Ishan Anand

Yeah.

00:23:30 - Jason

I mean, because when Node came out, build toolchains didn't exist outside of Dojo, which I'm pretty familiar with. You know, you didn't build JavaScript ever, and that was kind of heretical at the time. So yeah, the world was completely different in 2008, 2009.

00:23:58 - Ishan Anand

So I guess pragmatically for the everyday engineer, is it worth at this point now bothering to learn Deno, or should they wait till they need it and just not worry about it?

00:24:15 - Theo Browne

If it solves a problem for you, use it. It solves some very specific problems for me. Every winter during the holiday season, I do the Advent of Code programming challenge, and I like using TypeScript for those. I don't like setting up a crazy fucking TypeScript environment to do those. So I use Deno every day for one month every year to do programming. It is phenomenal for that. I can't imagine a better toolset for quickly getting a TypeScript file running in a stressful programming challenge environment. I have that use case and it works really well for it. If you have things like that, it's nice, but I don't think you should go out of your way to learn Deno so much as use Deno if it solves a specific problem you're having with your TypeScript environments.

00:25:03 - Jason

Agree?

00:25:03 - Ishan Anand

Yeah, that makes sense. Okay, we're nearly at the halfway point, so I'll hand it over to Scott to do our station break and then I'll go on to the next topic. Sure. All right.

00:25:22 - Scott Steinlage

Hey, thanks everybody for joining us today. Greatly appreciate it. You've made it halfway through. Congratulations. Give yourself a pat on the back. There's been some great conversations. Thank you so much to everybody participating in this, both those up here right now speaking and those who came up to have a little chat. So if you're in the audience there, be sure if you're getting value from people up here, click on them, follow them. Because obviously if you're getting value from them here, you're probably going to get value from them other places as well. Now, we do this every Wednesday at 12:00 PM Pacific Standard Time, and we love it when everybody participates. By the way, if you're in the audience there and you have a question, and it doesn't matter whether you're new or you've been doing this for a very long time, we love to hear from everybody, okay? In fact, that's where we typically get the best conversations going on here, when people do come up from the audience and either ask a question or give their opinion on something. It just really brings the value to everybody here.

00:26:27 - Scott Steinlage

Also, the topic here is obviously JavaScript, but we also just dive around everywhere in the web development area. Feel free to speak on those things as well. I'll hand it back to Ishan. Thank you all so much. And don't forget, if you do want to sign up for our newsletter, we said at composability.dev there, and if you've already gone to composability.dev and partaken in that and watched the summit that we had, you're basically already on the list for the newsletter because that's part of that whole process too. This is an ongoing, like we spoke of before, if you don't recall, I'll remind you, this is an ongoing evergreen thing and we're going to continue producing more content, more speakers, things like that. All kinds of cool stuff coming your way, including the newsletter. So super exciting stuff. Looking forward to pushing more value out to you guys.

00:27:23 - Ishan Anand

Okay, thanks, Scott. So the other thing I had in the newsletter this week, and by the way, just to add on to that, you can always suggest a topic now by just raising your hand and we're happy to jump on that. Or in the newsletter there's a link you can click on where you could submit an idea for us to talk about if you prefer to do it that way. One of the things that was in there was an article, which some of you guys might have seen. It was on Hacker News. It was like, "DevOps is an idea so good no one admits they don't do it." Basically the gist of the article was that it's become such an assumed good thing that folks are scared to actually say they aren't doing DevOps. And what it's led to is almost... an example symptom of this is you've got people who aren't actually doing DevOps with their title changed to DevOps, and they're still doing IT operations. His example was John used to be an IT operations guy, but now he's a DevOps engineer. And he called this the most egregious example, when a company simply changes the job titles of all of its ops people.

00:28:39 - Ishan Anand

And the reason I pulled this out is when we go and we talk to folks in the market and in our company, we do see elements of this in some companies and not in all companies. And so the first thing I'm really curious about is, does this statement seem to jibe with folks, that there's a loss of meaning of the term DevOps where everyone says they do DevOps but they're not actually doing it? I mean, his statement in this article is, by now the term DevOps has lost all meaning. Now everyone just does, even when they're doing ops, they call it DevOps, basically. And again, the title is "an idea so good no one admits they don't do it." You can probably Google it or it's in the newsletter. So first let me throw it out there and see if folks feel like that's accurate or folks think that's inaccurate.

00:29:33 - Jason

In the companies I work with, I'd 100% agree with that assessment.

00:29:40 - Ishan Anand

Which is to say, 100% of them, you feel, say they're doing DevOps, but they're really not.

00:29:46 - Jason

Outside of the early startup space, any company that's been around for a while definitely has just relabeled their ops team.

00:29:55 - Ishan Anand

Yeah, I'm reminded back in the early days of the cloud era, there was a cartoon where somebody said it basically shows a guy switching the sign on the door from "data center" to "private cloud." And the guy asked him, "Are we done with our private cloud migration?" He's like, "Yup, we just changed the title on it." Okay.

00:30:17 - Jason

So there was one counterexample of that, of a company I won't name that was fairly old and actually had engineers on their team that were writing code and doing deployments and setting up development deployment infrastructure that most of us would consider true DevOps.

00:30:37 - Theo Browne

And it was.

00:30:38 - Jason

But that was the outlier.

00:30:40 - Ishan Anand

Interesting. Well, actually, so then let's make this really concrete for the audience. I can attempt my definition, but Jason, how would you define true DevOps?

00:30:51 - Theo Browne

I don't know.

00:30:52 - Jason

Let's see. I don't know if I have a canonical definition, but I'll give it a shot. So if you have a self-contained engineering team that can take everything from planning and code to deployment and production... startups almost always operate like this. They don't have dedicated people early on where all they do is maintain the servers. That's the counterexample if you've got DevOps people. And maybe if somebody wants to jump in with a better example, you have people on your team that are developers that can write code, that also know how to understand, not only understand but configure, design, and deploy your infrastructure to deploy that code. So it's basically a self-contained team.

00:31:39 - Ishan Anand

Theo, I see you with your hand up. Go ahead.

00:31:42 - Theo Browne

Yeah, I don't got a better definition. Honestly, DevOps is just a term I've never really cared for. I think every developer has their direct customer, and if you're a developer and your customer is the developers at your company, then you're DevOps. Like, that feels pretty straightforward to me. But generally speaking, the problems I see don't necessarily align with what I'm hearing here. While I totally trust that there's a lot of people in the industry who used to be IT people that are now given the title DevOps and don't really do anything different, that's not an experience I've personally had, at least at Amazon and Twitch and also Microsoft. Those were not things I saw at all. Really, something I do see a lot of, though, and it's been weird and kind of painful, is smaller startups, like we're talking less than 10 people, sometimes less than five engineers, starting to hire DevOps because their developer pipelines are so screwed that early, because they built everything the FAANG way or the big-company way. At a five-person startup, if you're not using GitHub and GitHub Actions, if you're not using things like Vercel and Planetscale, if you're not using these tools that make it very simple to build a good developer experience at an early stage...

00:32:53 - Theo Browne

You're fucking up, period. You're throwing away one of your best competitive advantages. There are companies who do developer optimization way better than anyone you can hire until you're big enough to hire a team. And it's very easy to fall in the trap of needing DevOps because your developers didn't optimize well enough in the first place.

00:33:17 - Ishan Anand

Interesting. So I see this actually in both large and small companies. There are large companies who will hire DevOps to build a platform that's like a Vercel, Edgio, Netlify, and they're trying to build out the same thing and they're not going to build it with the same level of DX as a platform dedicated to that. And I see that actually even at large companies. They're enterprises that do it because they think we need to do it ourselves. I actually ran into this in the early days of cloud where we'd have stuff on AWS, and customers who were in e-commerce were like, well, you run on AWS, so we can't, you know, and we're in e-commerce so we compete with them, so we can't do anything that's on their technology. But I see plenty of large companies that have that philosophy as well, that we need to build it ourselves. And I guess what I'm suggesting is that, for large and small companies, it almost doesn't make sense unless you're really at a large scale, even beyond 10 people.

00:34:29 - Theo Browne

Yeah, there are definitely use cases where I would say, like at Twitch, for example, if we had bought in on Vercel for our internal tools, we could have moved a lot faster, but instead we had to have multiple infra people and the DevOps person focused on the internal safety tools team for a while, and everything's broke. We had to pull them back in, and now they're having a crazy problem with the stage team because nobody wants to work on the Kubernetes cluster. There shouldn't be Kubernetes. It should all be Lambda functions. And as a result, two of the three engineers who know Kubernetes have left the company, and there's this one 20-year-old kid holding together all of internal safety at Twitch because they made a developer-ops problem by introducing a need for developer ops too early. Very, very common problem. Not-invented-here syndrome is the fucking worst. And one of the best advantages we have as startups is not falling for that trick, because it lets us move faster than the big companies. Twitch is currently in the middle of spending some horrible millions-of-dollars number on a team of 20-plus engineers trying and failing to clone a product I built in three months.

00:35:29 - Ishan Anand

Wow, that's a really salient example. And the thing that's encumbering them is basically to be clear, just to underscore it, it's not the features, it is the tooling to do the development that is encumbering them.

00:35:44 - Nathan

Correct?

00:35:45 - Theo Browne

Absolutely. It is the state of how development goes at a company like that, especially the way they have engineered things themselves. They have this giant multimillion-file single-page app based on Create React App that powers all of Twitch's user experiences. Right now they have chaotic infrastructure that is all DIY-rolled. They refuse to use any third-party providers for video stuff, which makes sense for their core infrastructure. But when they're making a pivot from something like RTMP to WebRTC, realizing they don't have the ability to do it and then moving to peer-to-peer infrastructure halfway through the project, they just keep dooming themselves. And on top of all that, they don't really use the things that they're building because most of Twitch's engineers don't stream or use the platform. So all of these things have resulted in them not really being able to compete with us. But the infrastructure, absolutely. And the experience, as they've architected it, 100%. The requirement that you spin up every single feature as its own Kubernetes cluster, effectively, and you write a Terraform config for every new feature prevents you from moving as fast as startups need to.

00:36:54 - Theo Browne

All of Ping is a single package.json, and Twitch cannot keep up.

00:37:00 - Ishan Anand

Yeah, so give people... you gave the before, like if you're going to start work on a new feature, you've got to write a Terraform script or execute one. What's the after at Ping, to get started with everything just being a package...

00:37:15 - Theo Browne

JSON, you write the code that does...

00:37:18 - Ishan Anand

the thing and then you're done. Or at least you can start.

00:37:23 - Theo Browne

Usually you're done that fast too. One of the most mind-blowing moments I had at Ping, one of our best engineers, they were at [unclear] before starting at Ping. They'd been building game engines in Zig for fun and had never touched web dev at all. I gave them a side project just to work and contract them for a bit. It was super impressive how quickly they picked up TypeScript, got into the stack, brought them in. They were building a lot of features for our internal admin tools, for provisioning rooms and managing the full experience for users. When they signed on, they did this for half a year, super successfully, built a bunch of our internal tools, the back end, the front end, the API layer between them and all that. We started speccing out a new project for call recording, for recording a call to have the assets for after the fact. And this had to be done on a real box with real inference. You can't serverless a recording and a transcode. It's way too heavy and way too long of a runtime. So we built a whole spec out for it.

00:38:16 - Theo Browne

And at the end they were so shy asking this question. They said, like, "I feel so dumb asking this question, but what's an endpoint?" Up until that point, the concept of an endpoint hadn't mattered. They had been developing at Ping, full-stack, for six months, but because of how we used tools like tRPC and Next.js and TypeScript, they were able to write functions and then call them, and everything did what it was supposed to.

00:38:40 - Ishan Anand

They didn't have to worry about the actual, you know, marshaling in between the front end on the client to the server. It just kind of bridged everything for them.

00:38:49 - Theo Browne

They didn't have to understand beyond some code runs on our computer, some code runs on theirs. That was all they had to understand. They didn't have to think about where the servers were coming from, how the database connected to them, what would happen if somebody hit this super fast a whole bunch in a row, how we make sure the API layer doesn't change when somebody else comes in, making sure they had enough code coverage to actually ship the feature, having a dedicated QA person that has to come in a week later, test it, and not really know what they're testing. All of those steps that are inherent to the way Twitch did things were so irrelevant that the concept of an endpoint was foreign to them. And that stood out to me since.

00:39:30 - Ishan Anand

Yeah, I think you've mentioned that in a past episode a few months ago, and I definitely remember that. It's such a surprising data point, and it speaks a ton to the power of a really great abstraction. You don't have to worry about it because it's all in the mechanics, taken care of for you. One other thing, though, that you said caught my attention, which is they've built a lot of things under Kubernetes when it should all be Lambda functions. That's a statement I hear over and over and over again. It does feel like Kubernetes was kind of overkill for a lot of problems. It got a lot of popularity. It's useful, but it definitely pulled people into... basically, they need more personnel and infrastructure ops in order to execute on it. Would you agree with that or disagree?

00:40:25 - Theo Browne

Absolutely. Kubernetes is the Flutter of infrastructure. It solves a very specific problem better than anything else, but you probably shouldn't be using it.

00:40:34 - Ishan Anand

I love... okay, I've not used Flutter, but I can extrapolate. That's another, I would call it, big technology not-invented-here-syndrome technology. I see a lot of, you know, especially enterprise companies, less so the small 10-person company, adopting it, thinking that, well, we need to do this in Kubernetes, and then they need a large ops team to manage it, and it hits productivity. So that experience definitely resonates. If there's anybody who has a difference of opinion, please raise your hand. Would love to hear.

00:41:11 - Theo Browne

I can play the other side of this one because I do think about this a lot too. Like, I have a bunch of investors who are heavy infra people, and one of my big closest mentors who I still look up to a ton gives me a lot of crap for my takes here.

00:41:24 - Ishan Anand

Okay.

00:41:25 - Theo Browne

I think there's a problem where developers will optimize to do things the way that's easiest for them, unaware of how expensive that is for the company. Like, we look at the cost of a Lambda function invocation, we're like, "Oh my God, that's going to cost us $80 a month. If I spin up my own Kubernetes cluster with autoscaling, it'll cost us $40 a month," not realizing that their time is 300-plus dollars an hour, and it's going to take them two weeks to set it up and then a few hours every week from that point forward to make sure it doesn't go down. You'd have to be spending hundreds of thousands of dollars a year on infrastructure through Lambda before it makes sense for that developer to do that. And if you're at that point, you need those developers. If Ping is successful, I'm going to have to hire somebody like Primagen, the famous Rust dev from Netflix, to come rewrite all my terrible TypeScript code in Rust in order to make us cost-effective. But that's not the problem that we have right now. And most companies don't have that problem yet, even really big ones.

00:42:29 - Theo Browne

Infrastructure is cheap, Lambdas are cheap. Edge is even cheaper. You can avoid so many of the runtime costs that things like Kubernetes save just by not using them and using serverless technologies instead. And that reality has finally started to set in hard. I feel like I used to get a lot of pushback when I said that, and nowadays I feel like everybody's pretty aligned that if you can make it serverless, you definitely should.

00:42:56 - Ishan Anand

Yeah. So you know what you reminded me of, and I agree that's a great description of kind of the other side of the argument, there was a post on Hacker News. I'm actually trying to Google it right now. It was something like "a single server." And forget about Lambda versus Kubernetes. He's like, here's how much processing you can do. He does the math on how many requests per second you can serve with a single bare-metal server. And then he goes all the way to compare it against something like Lambda. And he's like, look, the cloud premium is real. There is a cost there. But it goes back to what you talked about. What is more valuable, your developer time or your infrastructure costs? And if you're a very large company, then it could be your infrastructure costs. But I remember this article back in the early days of Twitter, and people were saying they made a mistake building on Ruby. It's harder to scale. And the CTO at the time had a blog post where he said, well, you can say that, but had we used a more scalable solution, we may never have discovered Twitter.

00:44:08 - Ishan Anand

We never pivoted into being as successful as we could have. In some sense, it's a good problem to have. So yeah, I definitely agree that, especially in the early stages of a digital experience, the ability to iterate and adapt is really, really critical. I mean, that was one of the themes of the Composability Summit. It's this idea that when you build things in Lego blocks, you can build and rebuild and adapt as needed. And some of the hard data on this, or soft data, depending on how you look at it, was this McKinsey survey they did, and I think it was something like 9 out of 10 business leaders were saying, "We don't believe our business model and our digital experiences will stay the same over the next 18 months. We're going to have to change fundamentals of our business model," which means you probably have to change fundamentals of your digital experience, which means that more now than ever, change is a huge factor. And so you don't have to deal with baking all these things down into something that's harder to modify. That makes a lot of sense.

00:45:21 - Jason

Well, Theo's rant a while back on the replaceability of software components or pieces that you build your software from, that one among your rants, is particularly salient and well put. So my hat's off to you there on that. But that one in particular, you're focusing on front-end tech, but it applies up and down the stack of just, you know, don't build or use things you don't need or that solve problems you don't have. And you can always solve them later.

00:45:54 - Ishan Anand

I will double down on what Jason just said, and my criticism of your talk on the Composability Summit, Theo, was that you did not do the Ship of Theseus as a meme or as a talk topic as much. Yeah, I know, I get it.

00:46:12 - Theo Browne

That was the talk that I had thought through the most and was most ready to give, and it was close enough. I agree. I could have done a more composability-focused Composability Summit talk, but I didn't have the time to write that talk.

00:46:25 - Ishan Anand

Well, you know, we've got the newsletter. We are going to have additional talks and content. It's not a one-time thing. We'll have evergreen stuff. So there's a second chance for all of us on that. So I look forward to that. I think it's a really important and powerful metaphor, so I look forward to that down the road. So I'll just leave this for anybody else who wants to raise their hand if there are any other thoughts on this in the last 10 minutes. There was one other thing I put in. There's actually two other things, but I think we have time for everything that I put in the newsletter. That also came up, Theo, that you were talking about, might be a good seg, is TypeScript. You mentioned you had this engineer who did game design and you ramped him up with TypeScript. We had a link in the newsletter on just a quick tutorial on TypeScript for folks. But I guess the proposition I want to propose for debate here is: if you haven't bothered to learn TypeScript, you need to now. It has reached the point where you're behind the curve for not knowing that.

00:47:43 - Ishan Anand

And you know, when we posted it, we also put the link to the Stack Overflow survey showing that TypeScript is more loved than even JavaScript. Is that a proposition folks would agree or disagree with, as a strawman to throw out there?

00:47:59 - Theo Browne

This is the take that I've been preaching forever. I didn't like web development until TypeScript made me like web dev. Yeah, everyone should. My biggest issue with this take is that TypeScript learning materials are mostly focused on learning what makes TypeScript different from JavaScript and learning TypeScript assuming you already know JavaScript. A thing I've wanted for a long time is a JavaScript tutorial written in TypeScript for new devs. That is, it's TypeScript the whole way through, but it ignores the type part for as long as it can and then says, "By the way, that colon thing that we've been telling you to ignore, this is actually what that does," to teach you JavaScript with error correction and red squiggly underlines and autocomplete, and then get you to TypeScript after.

00:48:42 - Ishan Anand

Wait, so I thought I understood what you were saying, but basically you're proposing you teach people TypeScript without actually showing them how to do it?

00:48:50 - Anthony Campolo

Teach a tutorial that is written in TypeScript but that would make sense to a JavaScript developer, which is something that you could do very seamlessly with Create T3 App, maybe.

00:49:01 - Theo Browne

So I'm talking about even a newer developer, like somebody who's never coded before. I want them to be able to start with TypeScript, but right now the learning materials are not at a point where they can. If you are a brand-new developer and you want to start with web dev, you probably need to start with a JavaScript tutorial and then hope you can find a TypeScript tutorial focused on your level as a JS dev. What I am proposing is something like freeCodeCamp, but it's in TypeScript the whole way through. It just doesn't talk about the TypeScript part until halfway or so through. So you are learning TypeScript as your first language.

00:49:37 - Ishan Anand

You don't even realize you're in TypeScript. That's your starting point.

00:49:41 - Theo Browne

Yes.

00:49:42 - Jason

So does that... to bring this back to the beginning of the discussion, does that bring us back to your tutorial should start with Deno if you're going to... yeah, beginner course is using Deno because it's TypeScript baked in?

00:49:56 - Ishan Anand

No, I.

00:49:58 - Theo Browne

If it was in a better place and browser compatibility was more consistent, maybe. But I think this should be with either a pre-baked browser instance with VS Code and everything, like put in CodeSandbox-style. Because I don't think that anyone should have to set up anything on their machine for this first-level tutorial. I was just bringing this up super quick as a... I think TypeScript is... I was trying to agree with Ishan's take so hard that I think beginner devs should use it too, and was saying the only thing holding us back right now is the quality of education materials for new developers starting with TypeScript.

00:50:32 - Scott Steinlage

You know what?

00:50:35 - Scott Steinlage

Yeah, no, I'd say the same thing, and that actually would be a good back-to-basics kind of topic to go through, you know, in the future. And another thing I thought about too is it's very similar. I mean, just think about this. Instead of doing vanilla JS, a lot of people started off in React. It's the same thought process.

00:50:57 - Ishan Anand

That's a great analogy.

00:51:00 - Jason

The only downside is you can't just pop open your browser's console and start typing TypeScript. Well, that's true.

00:51:08 - Theo Browne

That's changing. There's a proposal that's getting through pretty far that looks like you'll be able to paste TypeScript code into your console and have it run. While losing that sucks, I feel like we've, to an extent, lost that already. Any vanilla JavaScript code you look at probably has a require statement in it. You can't copy-paste that into your console anyways. I kind of have seen this as a disingenuous argument for a while.

00:51:29 - Anthony Campolo

Yeah, for that reason, that's totally true. You can't run React in the console anyway. So it's like... you just need a REPL. If you have a TypeScript REPL, you just need a way to run code arbitrarily. There are very simple ways to do that. It doesn't require using dev tools to...

00:51:45 - Theo Browne

Back to the React example of this kind of being like starting with React, I half agree, half really want to push back on that because there are a lot of times where I write JavaScript or do web dev where I'm not using React. There are precisely zero where I'm not using TypeScript. TypeScript is the replacement for JavaScript. It is what you're going to move to anyways. React is probably how you're going to make UIs. It might die in the near future. You might have a job that doesn't use it. You might go to back end. Who knows? React is great and we all love it. And yes, a lot of people are starting with React, not JavaScript. I think starting with TypeScript, not JavaScript, makes way more sense and is done way less often, for no good reason other than the education materials.

00:52:28 - Ishan Anand

I'm going to slightly disagree. Oh, go ahead.

00:52:31 - Nathan

Sorry, I actually gotta grab the door now, so you can go first, Ishan.

00:52:37 - Ishan Anand

No, no, I was gonna slightly disagree, but go ahead.

00:52:43 - Theo Browne

Thanks. I need to get the door.

00:52:44 - Nathan

Yeah, I gotta take a minute off.

00:52:46 - Anthony Campolo

So I disagree that everyone's gonna write TypeScript all the time.

00:52:50 - Theo Browne

Forever.

00:52:50 - Ishan Anand

Yeah, I think we're too much in the cutting edge. I'll give you an example. It's a little bit niche, but there are plenty of sites that are not using React yet, that are not using TypeScript. They're still vanilla JS, and going back to that, typing things in the console.

00:53:08 - Anthony Campolo

And Theo hates those sites and thinks they're an abomination.

00:53:11 - Ishan Anand

Well, yeah, but unfortunately they're like, well, I don't know, 80%. I don't know what the numbers are.

00:53:15 - Theo Browne

Yeah, and I think that 80% of the jobs that are hiring are not working on those dead sites. These metrics are always so fascinating to me because people share these as though that's where 80% of the jobs are. They aren't. The reason these sites are on the old tech is because they're not changing, they're not updating them, they're not meaningfully improving them. Like, of the 70% of the web that's on WordPress, 50% of it is hackable as shit and hasn't been updated for years. That's just the reality of the web. I think that we're too excited about those numbers because they make us feel better about not changing our tech stacks, when the jobs are using the better technologies, and if they're not, then the companies that are going to run laps around them.

00:53:56 - Ishan Anand

So I don't disagree with that. But when it comes to understanding the fundamentals of how things work, I think there is a place for understanding vanilla JS, just like there's a value in actually knowing what an endpoint is and how HTTP works. And you can only get so far when it appears like magic.

00:54:16 - Theo Browne

I think you can learn those things when you run into those problems, and you can learn those after the fact. I think that learning TypeScript from the start has that cost, absolutely. You don't understand the difference between JavaScript and TypeScript as early as you would otherwise. But it comes with the huge, way bigger positive of now you have error checking, autocomplete, and all these other awesome developer experience wins that make it easier to learn in the first place. It is a trade-off, yes, but we're talking a very small cost for a very big gain, with a lot of easy ways to pay off that cost. I don't necessarily agree that that's the same with React, because the gain is React is cool and you'll see something in the UI on your computer faster, but the cost is you're buying much more into a specific thing. I think that when you compare the cost and the benefit here, it's a huge difference between the two.

00:55:05 - Ishan Anand

I'm arguing against the idea of magic. I hesitate when a developer entry point is a point at which it's magic what happens between them. And I've run into situations where they can't learn it on the fly, but that may be an individual thing. Sorry, somebody else was going to go. Go ahead.

00:55:24 - Nathan

Yeah. So what Theo's saying definitely resonates for me a lot. And I've seen a couple different arenas, and so I think, I mean, I know what you're saying as well, Ishan, because it's very hard for new devs to get dropped into a framework where there's magic setters or getters or just things happen because that's the way it works. And that can be very jarring. But the trade-off is traditionally that the capabilities those devs get, if they're able to disregard the magic and be okay with the level of abstraction, they can get a lot further. And so the complexity in education that I think Theo's touching on really well is... and I saw this, I would say a good example is in the Ruby and Rails community. You had a bunch of devs come in and want to learn Rails, and there was this very jarring experience where people wouldn't know what was Ruby, what was Rails. They were all learning them both at the same time. Many beginning devs didn't know which was what. They wouldn't actually know what was the language and the framework.

00:56:23 - Nathan

And I think that there are benefits there, but the education around it, like the fact that when you're a junior dev and you hit a wall... I mean, first off, fundamentally, in 2022, if you're starting with TypeScript, let's be honest, you're learning JavaScript, you're learning a lot of ECMAScript, and a lot of the stuff you're doing day to day is like ES2016 and later. And then you're also learning TypeScript and probably some compiling toolchains and a bunch of tooling on the front end, and there's probably some Babel stuff. So it's a tough field. And I think what Theo's getting at, because I felt this, is when I go to learn TypeScript, there's a huge bisection in the documentation community. And as a new dev, I think it's one of the worst things not knowing whether to Google the issue you're hitting with the word TypeScript or with the word JavaScript or with the word React. And that can be very unsettling. And that's, I think, the root of what Ishan's getting at, that you don't know which piece is doing what and don't have that fundamental understanding.

00:57:22 - Nathan

That being said, that is definitely a risk and that's a problem that needs to be addressed. The deeper knowledge of vanilla JS fundamentals will always be helpful and will always give a better understanding of what's happening. But for a brand-new dev, I can resonate with what Theo's saying because I've just picked up TypeScript more in the last year, and I started with their handbook. And I love a lot about their docs, I hate a lot about their docs, but I got sucked into TypeScript for JavaScript developers, TypeScript for OOP developers, TypeScript for this, and they just start you off with JavaScript.info and MDN too. So they kick you off right at the beginning and say, well, go learn JavaScript first. I think what Theo is getting at is it would be really cool to have a tutorial that's just "learn to build a JavaScript application," and it starts with the same material you would see in beginner JavaScript applications, but it's just using TypeScript the whole way and it doesn't make a big deal out of TypeScript until the benefits become obvious. So it doesn't do a bunch of talking about the type system and how to type objects and generics.

00:58:25 - Nathan

None of that is presented the way most TypeScript tutorials present it as kind of first-class citizens. But it's more of a, hey, here's a beginning to programming that will use JavaScript plus TypeScript plus some stuff along the way, and you get to discover some of those pieces as you go, rather than comprehensively learning how TypeScript is completely different than JavaScript, which is what a lot of the resources are.

00:58:48 - Ishan Anand

I think you really...

00:58:51 - Theo Browne

That was a super good way to align our takes here. My only thing I want to say is, I think because people learned React and never could tell the difference between React and JavaScript, because people learned Rails and can't tell the difference between Ruby and Rails, if those were like an 8 or 9 out of 10 concern and problem, learning TypeScript instead of JavaScript is like 2 out of 10. And because those 8s and 9s were so bad, we're scared of doing the 2 out of 10 one. I have to run for my show. Come check it out on Twitch, if you guys are into that. Peace.

00:59:19 - Ishan Anand

Yes.

00:59:20 - Scott Steinlage

Hey, so who's going to create this? Is my question.

00:59:24 - Nathan

I've got a couple drafts that I'm working on. You're asking about education.

00:59:29 - Scott Steinlage

All right, Nathan's here. Theo, [unclear].

00:59:30 - Ishan Anand

Yeah, I look forward to that. Yeah, I agree with what Theo said. I think you really captured and threaded the needle between both arguments. And I think part of it is my own personal bias, A, how I learn, and B, the context I get pulled into, which recently or in the last couple years has been in performance, where those details mattered. But I actually absolutely agree when I sit and reflect on it, it's about what we talked about earlier, developer productivity. And I think if that's the overriding metric, then yeah, it does actually make sense to potentially learn just pure TypeScript first.

01:00:05 - Theo Browne

Yeah.

01:00:05 - Nathan

And I think the gap that we're identifying is very understandable too, because if you look at classical curricula development, like if you look at higher education, computer science programs pretty much always trail the industry significantly enough that you hear every college student saying, wow, I don't learn anything useful in my college classes. Oh yeah, I was making web apps on Tomcat with Java and JSP. I knew the second I started that class I was never going to use any of those technologies again in my...

01:00:33 - Theo Browne

life, and I haven't.

01:00:35 - Nathan

But that's part of the difficulty of trying to develop and design a repeatable curriculum for technology that evolves yearly. And I think that's why there's a big gap. It's like, today nobody's really solved the problem of how to best educate a web developer entering the industry in 2022. Most people were busy inventing what 2022 is over the last couple years. And so education is always going to inherently trail. And I've experienced it a lot, working with a lot of juniors and mentoring a lot of junior devs. And so the recent one I can give is from React stuff, where I was working with a dev through some stuff and he just started typing code. And I was like, that's not right. And I was like, well, dude, what are you doing here? What's this syntax? What are you writing? And he says, "Oh, well, that's the hook syntax." And he's got two square brackets on the left side of an assignment. I'm like, well, that's not a hook. You're calling a hook, but what are you actually doing there? And he's like, "I don't know, this is what you do for hooks." And it was simply object destructuring.

01:01:41 - Ishan Anand

Yes.

01:01:41 - Nathan

And I'm sitting there, I'm just like, dude, this guy didn't learn 2016. So for him the gap in knowledge was like, go to the MDN docs for ECMAScript and go look at object destructuring. Go look at the nullish coalescing operator. Just look at the newer JavaScript stuff. So that's where I'm like, even vanilla JS isn't really a good intro these days. Because it's like, no, you kind of got to learn JS 2022. And that's super weird and nuanced unless you just go and read a shit ton of modern code where everybody's kind of coalesced and you're like, okay, I see arrow functions now, okay, I see destructuring, I see spread operator. You pick that up. But none of the tutorials do a good job of like, hey, here's your hello world, now let's go do something with object destructuring. That's so far down the rabbit hole that you get to those fundamentals, when in reality you will probably encounter them pretty quickly in real code. And those are things that I think... it's really painful to have that, like, what's React? What's just ECMAScript? And again, you go to the console and some of these things don't even work.

01:02:42 - Nathan

So it's like, well, some of that's not really your JavaScript, but it's your Babel compiler.

01:02:46 - Ishan Anand

Exactly.

01:02:47 - Nathan

And that's even more confusing. So like, oh, you got a polyfill going on there. Something weird.

01:02:52 - Ishan Anand

Well, so that's the world I run into. And that's why I argue for understanding all the basic parts. But when you think about developer productivity, does it really matter if they know whether that comes from Babel or not, if it just makes them more efficient? It's what you talked about before. I think maybe it's an inherent trade-off. Do you know if it's Rails or Ruby? Does it really matter? Right? You just know that you get a ton of productivity out of it. And I'm not a Ruby on Rails developer at all, but a lot of developers I respect use it and are completely productive in it, and massively productive. But they say, look, there's a ton of magic underneath it. And it's hard to wrap your head around getting productive with it at the same time as understanding all that magic that's happening under the hood. You kind of have to just accept certain elements of magic to keep moving forward and cranking something out. But there will be a gap unless you go back.

01:03:51 - Theo Browne

Yeah.

01:03:51 - Nathan

And I think that's a trade-off that varies based on the technology and the community. So in Rails, their whole philosophy was convention over configuration. So in Rails, because of that philosophy, ignoring the magic was incentivized and rewarded, because ignoring the magic, all you had to do was know how to name your stuff, know where to put the files, know how to do all of that. And they intentionally wanted you to not know any of the magic. So I think in that environment, I was encouraging devs like, dude, you really don't need to know how a view gets rendered. It just doesn't matter. You're fine. Just call the render function.

01:04:32 - Ishan Anand

Yep.

01:04:34 - Nathan

And on the flip side, I think where I would land on the topic is that comprehensively understanding what's happening and what's going on will always give improvements. As a developer, it will always make you do better or have more capacity to figure out weird bugs, to figure out performance issues, to build good software. But it's hardly ever necessary at a base level. And so I guess the way I would frame it is, in the context of video games, think about the skill ceiling and the skill floor. I think the skill floor should be low, where it's like, hey, you get to this point and you can be very productive and effective without understanding any of the magic. And that's great. But once you get to that point and you are being productive, go and read, you know, JavaScript: The Good Parts. Go and follow Douglas Crockford. Go find some of those crazy talks. Watch the React reactivity talk, the "What is Reactivity?" stuff. Understanding the conceptual foundations will always push you closer to that skill ceiling. And it's incredibly high. And so that's where I think, like working in Rails, I had a buddy I worked with who knew the internals of Rails enough to reach in and use them for complex database queries.

01:05:48 - Nathan

So you couldn't do certain queries with ActiveModel, but you could use the relational algebra library that Rails implemented ActiveModel with, and then you could compose your own complex queries. So when people really get the magic, there is powerful stuff you can do. You can hook into the framework, you can do a lot more stuff, and arguably be more efficient over the long term. But also you could have a developer that doesn't know any of that stuff accomplishing the same goals, feasibly. So it's one of those things where I think you've got to find that skill floor where it's like, okay, I have enough of the basics to go on faith and be effective at what I'm producing. And then beyond that, you should push yourself toward that skill ceiling because you can most likely always become a better developer in many ways by learning the deeper conceptual stuff. But it's just like, I think my one issue with Ishan, with your logic and where you were going, is just don't try to do that comprehensive learning before. Don't make that your threshold or that your goal, because that's where juniors get tripped up. It's like, well, okay, I'm starting to learn TypeScript...

01:06:53 - Nathan

Write this TypeScript thing. They sent me to the MDN docs for JavaScript. I'm going to go learn every single thing about JavaScript, and then I'm going to go back to the TypeScript handbook. I'm going to finish everything in the TypeScript handbook, then I'll start writing code. And that's where I push back more. I think you have to give good pauses to, like, it's okay for me to go and learn stuff and just deal with the magic for a while.

01:07:13 - Ishan Anand

Yeah, no, I'll acquiesce that. That, you know, look, there has to be some level of abstraction you're going to operate at because you can't think about everything all at once. So, and that's why I said like, if, if the metric is developer productivity and you're not, as I said, I'm biased. I was very biased from basically the perspective of problems that I've been dealing with, which are where those details matter. But if you're just cranking out something new, new, and you're at the zero to one stage of building something rather than optimizing it, I think that makes a lot of sense. Like, who cares about the magic? Let's just get something done that makes a lot of sense. So I can go along with that. But really valuable discussion.

01:07:57 - Jason

I think just, I'll jump in. As someone who's been writing JavaScript since the beginning of time, I've recently started to try to figure out TypeScript. I guess I'm late to the party. But Matt Pocock on Twitter, I don't know if anyone's familiar with him, he's got some really good stuff. And I don't know if it's necessarily all that well geared toward beginners because I haven't been a beginner in a very long time, but it was very helpful for me as someone who's gotten pretty far down the JavaScript rabbit hole trying to understand why and how I should use TypeScript.

01:08:39 - Nathan

Yeah, that's a good tutorial. So that's at github.com/total-typescript.

01:08:46 - Jason

Yep, that's the one.

01:08:47 - Nathan

He's got an org with a couple different things. There's a beginner's tutorial in there that's incredibly easy that I think everybody should like. It should be pretty accessible. And I actually did that on a live stream on Sunday. I actually went through and did some of that, which is pretty fun.

01:09:01 - Ishan Anand

Can you shout that out again?

01:09:02 - Nathan

Good resource.

01:09:04 - Ishan Anand

Yeah, let's add that to next week's newsletter. Sorry, go ahead.

01:09:10 - Nathan

Yeah, so on GitHub, the org is called Total TypeScript. So it's github.com/total-typescript. And he's got an advanced course that's a workshop format that's a little bit more like... I couldn't really work my way through that independently just because it's designed for a workshop session that he runs. But then there's a beginner's one that's awesome, and it's got tests and exercises and solutions and everything. So that was really fun. I went through that over the weekend.

01:09:36 - Ishan Anand

Did you do a stream of that? Did I hear you correctly or you just did it on your own?

01:09:40 - Nathan

Yeah, yeah. So that's Twitch.tv/ElectroBrew, and there should be a VOD in there.

01:09:46 - Ishan Anand

Let's link to that as well. I think that that would be great for.

01:09:49 - Scott Steinlage

Yeah, Twitch.

01:09:51 - Nathan

I'll dig up the VOD and link it. I'll tweet or something.

01:09:54 - Scott Steinlage

Okay. Tweet it for sure.

01:09:59 - Ishan Anand

Yeah. The last thing I'll just add on this that you remind me of, maybe the way to also thread the needle here is... one of the things you need to learn as a dev is learning to learn. I'm reminded of one of my colleagues who did volunteer teaching of kids programming, and he said the very first thing we teach them is how to Google, not how to code. It's how to Google so that they can figure out... he was doing this for underprivileged kids in a foreign country, and so they didn't necessarily have that background of just like, hey, just expect that you're not going to know all the answers and you're going to have to learn how to find the answer. And that's going to be actually the most foundational skill for development. And there's a... I forgot the science fiction book, but Marc Andreessen in an interview has a description of it. I can't remember the name of it, but it's a whole science fiction book about a world where people don't know how to do anything other than Google for things.

01:11:01 - Ishan Anand

I'll have to find the name of that. But the key thing I think that threads this is knowing how to get past what you're calling the skill ceiling. Okay, we are actually past time, but this has been a really great discussion. So I appreciate, especially when people disagree with me, because that's how you learn. So thanks to Theo and Nate, especially on that last one. I guess at this point I'll hand it over to Scott to close us out. Awesome.

01:11:39 - Scott Steinlage

Thank you all so much for joining us today. Don't forget, if you got value from the folks on the stage right now, go ahead and click on their face. Follow them. Because if you got value from them here, you are definitely going to get value from them elsewhere. Thank you so much to everybody that did come up and speak today, Theo, Nate, Jason, Anthony, and so many others. I'm sure I missed a couple people, but thank you all so, so much. Greatly appreciated. We are here every Wednesday at 12:00 PM Pacific Standard Time. So be sure to join us again next week where we're going to be talking about more awesome stuff. As always, thank you so, so much. And if you haven't gotten our newsletter yet and you want to know what happened the week before and what's going to be happening in the following week, be sure to go to composability.dev and subscribe there, and then you'll receive our lovely newsletter that we've been putting together. We just did the first week this week. So really cool stuff, and we're going to put things in there like linking to Nate's Twitch there and his thing he just did and that GitHub deal as well.

01:12:42 - Scott Steinlage

So for learning TypeScript, you know, lots of fun stuff. Anyway, yeah, thank you all so, so much. Greatly appreciate it. And we will see you all next week on Wednesday at 12:00 PM Pacific Standard Time.

01:13:00 - Nathan

Thank you so much for having me.

01:13:01 - Theo Browne

Guys.

01:13:01 - Nathan

Take it. Take it easy. All right.

01:13:03 - Ishan Anand

Thanks, everyone.

01:13:04 - Scott Steinlage

Appreciate it. All right, all right. I know y'all are waiting for the outro. Okay, peace.