Google's IDX, Supabase, and Jamstack

Episode Description

A panel discusses Google's Project IDX, Supabase's launch week features, and hot takes on Jamstack's death and developer tooling trends.

Episode Summary

This PodRocket panel episode brings together Anthony Campolo, Josh Goldberg, and host Paul Mikulskis to cover several trending topics in web development. The conversation opens with Google's Project IDX, a browser-based IDE powered by their AI model Codey, where the panel debates whether it can differentiate itself from existing tools like VS Code, Codespaces, and GitHub Copilot, or whether it risks ending up in the Google graveyard. The discussion evolves into what IDEs actually need: Josh argues for better error reporting over AI features, while Anthony counters that AI-powered error explanation is transformative for beginners. They then shift to Supabase's eighth launch week, highlighting features like real-time broadcast and presence, AI SQL editing, and the broader trend of open-source backend tools empowering developers to control their own deployment destiny. The hot takes section covers Josh's advocacy for separating formatters from linters, Anthony's examination of the Jamstack term's decline now that Netlify has abandoned it, and Paul's enthusiasm for Kyle Simpson's Socket Supply Company and its client-first, offline-first philosophy that puts user data ownership front and center.

Chapters

00:00:00 - Introduction and Google's Project IDX

Emily welcomes the panel — Anthony Campolo, Josh Goldberg, and Paul Mikulskis — before diving into Google's newly announced Project IDX, a browser-based IDE built on Google Cloud and powered by the Codey AI model. The group considers whether IDX brings anything meaningfully new to a space already crowded with Codespaces, StackBlitz, and CodeSandbox.

Anthony points out that Google's AI model Bard hasn't impressed developers so far, and questions whether Google's training data can compete with OpenAI's access to GitHub repositories. Josh sees a potential upside in Google building on a newer codebase that could enable features difficult to retrofit into VS Code, like integrated deployments and previews. The panel agrees that even if IDX doesn't dominate, increased competition in the editor space is a net positive.

00:04:01 - Google Graveyard Fears and Browser-Based Development

The conversation turns to developers' trust issues with Google, given the company's history of shutting down popular products like Google Domains and Google Reader. Anthony suggests Google may treat projects like a VC portfolio where most will fail, which becomes problematic when real users depend on those products. Josh draws a parallel to Microsoft creating Bing to avoid relying on a competitor.

The panel also examines the limitations of browser-based development tools, with Josh raising concerns about offline usability and developers working without reliable internet. Paul asks whether browser-based IDEs risk siloing talent, and Anthony notes that while multiple companies compete in the browser editor space, the underlying reliance on Chromium still concentrates power with Google in a concerning way.

00:09:46 - What IDEs Actually Need and the Role of AI

Josh argues that what IDEs truly need is better error reporting and feedback rather than flashy AI integrations, noting that beginners on platforms like Codecademy struggle most with incomprehensible error messages, not deployment pipelines. Anthony pushes back, making the case that ChatGPT's ability to explain error messages in plain English would have been transformative for him as a beginner and represents the most impactful use of AI in developer tooling.

The discussion broadens into whether AI should be embedded within editors or used as a separate conversational tool. Josh compares the current state of AI coding tools to early autonomous vehicles — promising but far from replacing incremental improvements in existing tooling. Paul raises concerns about developers becoming dependent on AI explanations at the expense of building deeper problem-solving skills, particularly in operations and terminal-based environments.

00:21:15 - Supabase Launch Week and Real-Time Features

The panel transitions to Supabase's eighth launch week, with Anthony running through the highlights including a Postgres language server, Hugging Face integration, local dev tooling, Studio 3.0 with an AI SQL editor, and marketplace integrations. Paul highlights the new real-time broadcast and presence capabilities, which use in-memory CRDTs for client-to-client state sharing, drawing comparisons to how Google Docs works.

Josh speculates that real-time functionality could become the next major wave in web development over the coming years, potentially tying into TC39 proposals around observables or signals. The group discusses Supabase's scalability on its cloud offering versus self-hosting, with Anthony noting that companies hitting scale limits likely have enough traction to work directly with Supabase's team, while Josh observes that Supabase has maintained a fresh, developer-friendly energy despite being around for several years.

00:28:37 - Open Source Ecosystem and Deployment Evolution

Paul celebrates the growing open-source, community-driven ecosystem where tools like Supabase paired with platforms like Vercel offer a compelling alternative to fully proprietary stacks. Josh adds that even deployment platforms now face open-source competition from services like Flight Control, suggesting developers are in a "gilded age" of controlling their own deployment destiny.

Anthony agrees that deployment tooling has improved dramatically, referencing the concept of a "universal deployment machine" where a full-stack codebase connects to a Git repo and deploys seamlessly. The panel sees a healthy trend toward giving developers more choices and flexibility, with open-source foundations providing security and transparency even when commercial layers add convenience and polish on top.

00:31:31 - Hot Takes: Formatters, Jamstack's Death, and Client-First Apps

Josh opens the hot takes segment by advocating for keeping formatters and linters separate — using Prettier or Dprint for formatting and ESLint for logic concerns — acknowledging it may not be the spiciest opinion. Anthony then tackles the ongoing debate around the term "Jamstack," explaining that since Netlify, the term's originator, has abandoned it in favor of "composability," the community consensus is shifting toward declaring Jamstack officially dead, even though the architectural patterns it championed have become mainstream web development.

Paul closes with his enthusiasm for Kyle Simpson's Socket Supply Company and its client-first philosophy, where user data lives on the device rather than in the cloud. He finds it a refreshing reminder that developers should focus on building better apps for users rather than just better tools for themselves. The panel wraps with contact information and a teaser for upcoming listener question episodes.

Transcript

00:00:11 - Emily Kochanek

Welcome back to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at LogRocket.com.

I'm Emily, producer for PodRocket, and we're back with our panel episode where we cover a wide range of topics trending in the world of web development, as well as going through some of our hosts' hot takes about what they're fired up about in the world of web development right now. Before we get into it, let's welcome our panel. First, we have Anthony Campolo, advocate at Edgio and host of the FSJam and JavaScript Jam podcasts. Welcome back, Anthony.

00:00:54 - Anthony Campolo

Hey, happy to be here.

00:00:56 - Emily Kochanek

Awesome. Glad to have you back. Next we have Josh Goldberg returning. Josh is an open source maintainer in the TypeScript ecosystem working on TypeScript ESLint. Welcome back, Josh.

00:01:08 - Josh Goldberg

Thanks for having me.

00:01:10 - Emily Kochanek

Always. And finally, we have one of our PodRocket hosts, Paul, joining to round out the panel. Welcome back, as always, Paul.

00:01:18 - Paul Mikulskis

Happy to be here.

00:01:19 - Emily Kochanek

Now let's get into our topics. August has been a bit of a sleepy month, so we're going to go through a few things.

First, let's touch on Google's Project IDX. In early August, Google introduced Project IDX, a browser-based development experience built on Google Cloud and powered by Codey, a foundational AI model. This is a tool that helps build, manage, and deploy full-stack apps. IDX is being billed as the next productivity booster. There's a lot of thought on whether it's going to be different enough from Codespaces, StackBlitz, and CodeSandbox, and it brings up questions of how it will compare to Copilot and its AI model. So let's discuss first: what are your thoughts on having another IDE enter the space?

00:02:04 - Anthony Campolo

The more, the merrier.

00:02:07 - Josh Goldberg

Yeah, it's been a while since we've had an IDE fight in the real world. It's exciting to think it might happen again.

00:02:12 - Emily Kochanek

What do you see this bringing that other IDEs haven't brought yet? What is making this special? Because I do feel like we do have so many IDEs.

00:02:21 - Anthony Campolo

Google really wants it to be special at this point. It's not really special, though, to have a browser-based cloud editor with AI. So I think that if you didn't have Copilot along with all this, like, Codespaces stuff, then it could be considered an innovation. But I think they just want to get a piece of the whole AI developer scene. And their first model, Bard, just didn't seem very good based on having used it myself and hearing from others. So I'm curious to see how it does on code-type stuff. I don't use Copilot. I literally just write my code to ChatGPT and ask it questions. So I'm not really sure which way works better, but they're probably fairly similar because they both talk to GPT. Whereas with Google, did they get to train on the sum total of GitHub? The public repos, sure. I don't know about private repos, though, whereas OpenAI probably trained on everything.

00:03:26 - Paul Mikulskis

Yeah, for all we know, OpenAI was training on Harry Potter and knows everything about Harry Potter.

00:03:32 - Anthony Campolo

So GPT-2 actually, one of their example use cases was Harry Potter fanfiction back in 2019.

00:03:40 - Paul Mikulskis

Definitely in the public domain.

00:03:42 - Emily Kochanek

Yes.

00:03:42 - Paul Mikulskis

Yeah.

00:03:43 - Emily Kochanek

So when it comes to Google, like they obviously have unlimited resources. Do you think that they might be able to dominate this space? Or, Anthony, are you saying do you think that devs are already reliant enough on GPT and Copilot that this is just noise in a very crowded space?

00:04:01 - Anthony Campolo

Well, I think if you want to dominate a space, you need to have a tool that doesn't get canceled. So that's going to be the first thing they're going to have to accomplish, just getting back developers' trust and wanting to use a tool. We haven't mentioned yet that none of us have used this thing because it's not actually public. You can just go look at videos and join a waitlist. I did join the waitlist, but so far we haven't gotten a crack at it.

00:04:26 - Emily Kochanek

This is all speculation, but I think a lot of people are worried that, to your point, Anthony, that this is going to go into the Google graveyard. In your opinions, what do you think that this would need to do to make sure that doesn't happen again? Speculation, but you're very smart.

00:04:44 - Anthony Campolo

Well, I don't use a ton of Google stuff in general. It's never really been like in terms of developer things. Obviously, I'd use the search engine. I have a Gmail account, but yeah, the fact that they can shut down domains, which seems as central to web development as you can possibly get, doesn't really seem like anything is safe. And they had an RSS reader that was really popular for a while, and so I'm not sure if it comes down to actual usage or whether they can strategically align it with some product.

So I just don't really know what the thinking is. And it may be like an AWS thing where each project has a different team with a different idea, and then they all kind of shoot for the moon, and they treat it like a VC thing where most of them are going to fail. I think that can be a good approach if you don't put the failures out as a product, have people use them for a couple of years, and then declare it a failure.

00:05:42 - Josh Goldberg

Yeah. There's an interesting, almost sweet kind of irony here where Microsoft had a similar situation with Bing, where Microsoft made Bing, among other reasons, because its products could not use Google. It's just not a good idea when you're a major multinational corporation to rely heavily on another major multinational corporation that competes with you.

So here we see Google wanting to pull developers away, I'm assuming, from VS Code and Microsoft, GitHub, and Copilot. But they also have a much newer codebase, which gives them the opportunity to innovate in the editor space. Just going through the dev introduction page, they're talking about all sorts of features that I think would be rather difficult to add to VS Code today, like having integrated app deployments and previews. So my hope is that this avoids the Google graveyard jinx or curse and is able to do something significantly better than VS Code. At the very least, that would be awesome on its own. At the very best, that would probably spur innovation in the editor space, which I think has been lacking the last few years, but worst or maybe even average case scenario.

00:06:46 - Josh Goldberg

We just have another entrant that spurs people to do better with AI. No matter what, it's probably good. This is, I think, exciting and a nice thing to see.

00:06:55 - Anthony Campolo

It's interesting you brought up the deployment thing because I was thinking they're at a disadvantage because they're not under the same umbrella as GitHub. It's all under the same company as the editor. But you're right in the sense that you hook up to a GitHub repo, which then usually hooks up to a deployment provider. So you have a deployment provider that has a really good Git integration, like your typical Jamstack. That's nice, but if you have an editor in your cloud, then you're deploying to Google Cloud and no one wants that.

00:07:28 - Josh Goldberg

Yeah.

00:07:29 - Paul Mikulskis

I think it's more than just an IDE potentially, and this is like a full-stack buy-in that we're faced with right here. And it could fundamentally change the way that somebody could enter themselves into the market and deploy their app.

00:07:43 - Anthony Campolo

I do agree in general that two years ago, I got really into Gitpod, and I was like, this is the future of dev because it was really easy to get spun up. But you could also do serious work, and you could also integrate it with your PR workflows. So it was really useful for the Redwood team. And it was a company that Tom had been investing in. So I think that in general, especially for newer devs, coding in the browser is just the way to go now, and having tools like this really bring down the barrier of entry. It's just a question of can it ever be as snappy as local dev, which is what's always going to hold it back.

00:08:25 - Josh Goldberg

I'm always concerned with browser-based tools. I do a lot of work on airplanes. I've worked a lot with people who are not in super fast home internet situations, and most tools that I've seen built for the browser do not adapt well to offline use. Google is probably better positioned than most in the industry to make an offline-capable web tool, and I would love to see this become the editor for, say, Chromebooks over the years. But it's difficult, and I'm scared of people inherently aligning toward something that just fundamentally does not work in offline or partially offline environments.

00:09:00 - Paul Mikulskis

Are either of you concerned about the siloing of talent with browser-based tools? Because that's sort of like the [unclear] joke that you pushed there, Josh, is true for a lot of the population on our planet.

00:09:13 - Anthony Campolo

That said, Chrome is so big, but there are lots of different companies that are building editors in Chrome. We named them all at the top. There's five or six of them, so I feel like there's actually good competition in the browser editor space. I agree in terms of the actual browsers, even the non-Chrome ones are still using Chromium. So that is definitely something that I think is slightly separate in conversation, but is very interesting. The fact that one company that can control the browser gets to control the internet to a very large extent.

00:09:46 - Emily Kochanek

In that same vein, I think, Josh, you mentioned this. If it does not become this next great idea, you hope that innovation comes from it. And to your point, Anthony, we don't always want the big companies dominating the space because that doesn't mean we're always going to get the best technology. What would you all want to see from IDEs in the future that maybe build on this? Or what do you think is lacking from current IDEs that you want to see evolve in the future?

00:10:18 - Josh Goldberg

I think the low-level primitives of surfacing complaints to users need a lot of work. Everything from unit test failures to build or lint or compile complaints. Right now, a lot of them are just plain text, maybe with colors, and a lot of editors, including and especially VS Code, and efforts like the error translator in the TypeScript space, try to just make sense of all the jargon that's being spit out at you. So I personally would be much more excited by an IDE that's just VS Code or JetBrains, but with way better error reporting and no other changes than any sort of AI shenanigan, especially if it's one that is like the third or fourth public tool to use a mascot called Cody.

00:10:56 - Anthony Campolo

Do you know about Wallaby and Quokka?

00:10:59 - Paul Mikulskis

Yeah. Oh, no. Enlighten us.

00:11:01 - Emily Kochanek

Yeah.

00:11:02 - Anthony Campolo

You want to talk about those, Joshua? They're cool. I feel like that's in line with what you're talking about.

00:11:07 - Josh Goldberg

I haven't used them in years. One of them just runs JavaScript continuously and shows you messages inline from console logs and values. And the other continuously reruns unit tests like the newer VS Code unit test runner. Am I remembering that right?

00:11:19 - Anthony Campolo

Yeah, that's the idea. Basically, it gives you constant feedback about the state of your code in terms of what would it spit out if you ran it right now, which is really useful once you have it turned on.

I think we're seeing this more with terminals, things like Warp. I feel like you got the sense that there are a lot of UX improvements that could be had here with the editor. I don't know, because I just use the editor I have and I've figured out how to use it, and I don't really figure out what's missing. But I feel like, Josh, you work on tooling a lot more than me, so you're probably constantly hitting weird VS Code things just through TypeScript.

00:11:57 - Paul Mikulskis

And I really like that call out too, because I feel like this is in line with the ethos of a lot of people who are coming into the space now that want a better tool, not a more efficient tool. Like, we can already build everything. The app that you want to build probably has already been built in some flavor, so we don't need to do it faster. Maybe we just need to do it better with a better tool. And something like that fundamentally brings a different user experience with your information and the way you're processing it.

Versus Josh, he called out these are AI shenanigans, right? I like that word. It's fun.

00:12:31 - Josh Goldberg

The word shenanigans is so broadly, universally applicable to so many things in tech. But yeah, honestly, I'm not even coming at this from the perspective of someone who works in dev tooling. I'm coming at it from an educator perspective, new people who are learning to code. Most of the time their concerns are not, "Man, I really wish I could deploy simultaneously to 15 different clusters and get [unclear]." It's, "I have 15 lines of squigglies and ASDF, and I have no clue what any of this means, and it's all one of two text colors." Like, go on to Codecademy and look at the learner forums, and it's so much more biased to those intro-level things than any of the stuff we're talking about here. So that's why this is cool. And I think it's a really nice long-term play, but short term, it's not what I'm particularly excited about.

00:13:12 - Anthony Campolo

Well, I'm going to make the case that the AI is the most important thing for what you just said here, because one thing that I've found ChatGPT can do really well is that when you're writing code and you have something broken, you have an error message, just like a normal stack trace. Nothing too wild. And what I do is I basically give ChatGPT the code in the file, and then I say, run this command to start it. And then this is the error I got.

Depending on what the project is, the complexity of the code, whether I'm using third-party libraries, all that stuff, a lot of times it will just tell me in plain English exactly what's broken, exactly what could be changed to possibly fix it, and that sort of thing. That just reading error messages was so hard for me, and I think hard for a lot of beginners, because you don't know that you're getting a specific line that applies to a specific thing and has a certain context along with it, and the context is not always present in the larger project.

00:14:12 - Anthony Campolo

And asking ChatGPT to explain my error messages for me, if I had that when I was a beginner, it would have made a huge difference.

00:14:22 - Paul Mikulskis

Do either of you feel like ChatGPT is the end tool here? Like, we could march forward with a better UI/UX on the local dev side with some sort of textual, because it feels like Google is really taking this cloud thing seriously, where it's like we own the repo, we're going to take control of the deployment pipeline at a very tooling operational capacity versus let me go read a few paragraphs from ChatGPT. These are two different interfacing levels with the team or the individual.

00:14:51 - Anthony Campolo

I think this is a question for the entire AI industry right now. In every single product that's going to be built in AI, which is how much do we want to embed the AI smarts within the application? You could have it in the editor, just give you an additional explanation for your error messages, and that would not be interfacing with it in the same kind of chat way. But you could have it embedded within the program. So I think it's always going to be a little bit of both.

I like actually being able to talk to a thing because it's rubber ducking to a certain extent, but it's clearly not the best interface because it's just silly to type your code out when, if it was just in your editor, which is the idea with Copilot, it should be aware of your project already and you wouldn't have to explain, I'm trying to do this and it's broken. It would just know.

00:15:41 - Josh Goldberg

I want to point out more directly this time that there literally is already an AI that is context-aware, called Cody from Sourcegraph, which is, in my experience, probably the best AI I've ever used for debugging. But I want to make another analogy here. I want to bring up the concept of smart cars or self-driving cars, because when you bring up autonomous vehicles, everyone gets all excited about Tesla and self-driving and Waymo and all this. And that, to me, is like the AI we're seeing now: real early stage, very promising, very exciting.

But the vast majority of cars on the road, aka editors, are not that. They are like my Subaru, which keeps lane assist and can drive at a constant pace with a maximum or minimum distance with the car in front of me. Innovation does not often favor massive leaps forward. It much more often favors incremental little steps that improve on what's there before. So as you're saying, Anthony, the AI long term will be awesome. That is a better solution in the abstract than little guiding in the tool.

00:16:35 - Josh Goldberg

Like having something explained to you, rubber ducking, etc., is better, but it's going to be a while, I think, before we have AIs that are cheap, that are able to do that at scale economically and are significantly better than an editor that just gives better feedback.

00:16:49 - Anthony Campolo

You already get the feedback from the editor regardless. So I guess what do you mean by feedback from the editor?

00:16:54 - Josh Goldberg

Right now, ChatGPT and other AIs are non-deterministic and they're expensive. Expensive financially, like they are costing Microsoft, Google, and so on whatever untold millions of dollars per year. And they are expensive computationally. It's not something you can easily run at your computer, which is why we're tying IDEs like IDX to the cloud.

But at the end of the day, they just give you the thing that you were trying to figure out yourself, which can be helpful but is not the same as a tool giving you a better little red squiggly or explaining, "Hey, you missed the semicolon here. That's why this for loop is running infinitely," or something like that.

00:17:26 - Anthony Campolo

VS Code doesn't do that though. It doesn't explain your errors to you.

00:17:29 - Josh Goldberg

Yes, we are in agreement. That is annoying and troublesome.

00:17:33 - Anthony Campolo

Yeah, I think with self-driving cars, if it makes a single mistake, people could die. Whereas we make dozens of mistakes in our code every single day. We're working on code. So if ChatGPT can be correct 95% of the time, that's going to be correct more often than I am. And that's not the same as driving. It seems to be not crashing every single time.

So yeah, I think it's like it can be an accelerator. It can make you go faster. And I don't know, man. I feel like for a beginner, being able to actually have something that explains things to you in English, like you're a person, you don't get that from using it. I don't know, maybe. But when I was learning, I used VS Code and I felt like I was never really getting useful feedback from my environment until I learned how to code well enough to understand the environment I was even in.

00:18:28 - Paul Mikulskis

I feel like there's another anxiety that I have about things being very silver spoon-fed, whether it be explaining in a squiggle or on ChatGPT. Coming from the ops world myself, I started in a terminal, SSH'd in and vi-ing stuff. I don't know when the AI is going to come there. Maybe they'll have some WebSocket service you can hook your shell up into in the future or something that can assist you.

But there's also value, I feel, in being able to bleed skills from this higher application space down into the operations, down into the deployments and spaces like this. I don't know if you guys share this anxiety at all. Do you think talent is being siloed? Are we creating artificial mental barriers between who we can hire and at what level we can hire that skill?

00:19:19 - Anthony Campolo

Yes. That's not really because of the companies or tools, though. It's just because it's really hard to even understand how to get into tech and have a path for it and have role models. And yeah, so I feel like that's going to be a big thing in terms of just getting more people involved in tech. There's centralization around Silicon Valley, and that can always be an issue, but it's also really big. There's a lot of startups, a lot of companies.

00:19:49 - Josh Goldberg

Paul, I'm actually not sure I follow you. Could you give an example of what two silos you envision might be made more distinct by this?

00:19:57 - Paul Mikulskis

Yeah. Well, I feel like if I was debugging a Python script in VS Code and I had an AI kind of explain to me why something crashed or why my types, which I know aren't required in Python. I like to use types when I can, though. Like, why isn't this checking out? Why am I getting a squiggle?

Versus when I first started my career, I was in a console with no colors, and there was no Vim. You're in vi and whatever default was there, like hacking together a production script to fix some servers. And the skills that you might, if you come from the other end of the stick, which I have colleagues who have come from the other end of the stick, where you start with writing software and you get more into operations, you really want to foster and grow those skills of problem solving and understanding text-based feedback and input.

00:20:49 - Josh Goldberg

Yeah. It's interesting. I don't know. It might be inevitable. 30 years ago, people were complaining that manual memory management was going away as a skill. Rightfully complaining, it's useful to know, and also wrongfully complaining because it's a waste of time if you're working in JavaScript. So I don't know.

By the way, I'm aware of what I just said is probably going to get quote-tweeted to death on X.com. But yeah, I think it's a good point. I don't know, I think we'll have to see it shake up. It's hard to say.

00:21:15 - Emily Kochanek

I'm going to rein us in a little bit so we can keep on track. But love this discussion emanating from IDX, and I guess we'll see what happens. I think it's releasing at the end of August, maybe, or beginning of September. But we're going to move on now. We're going to go to the Supabase launch week mid-month.

Supabase had its eighth launch week, and it introduced a slew of new features, including branching, Hugging Face, the Vercel integration, and more. So before we get into the new updates, does anyone want to just explain what Supabase is?

00:21:50 - Anthony Campolo

It's a database that's like Firebase, but better because it's Postgres and the developers there actually care and are very cool.

00:22:01 - Emily Kochanek

Love it, love it. All right.

00:22:05 - Emily Kochanek

Did any of you look at the new features? What did you think of them? Do you like the improvements that they came up with?

00:22:11 - Anthony Campolo

Supabase is just, they always ship so much. This is their eighth launch week. I remember when they started doing launch weeks, and the amount of stuff they launched just in this one alone is pretty amazing. There's Postgres language server, Hugging Face integration, which is an AI thing, and Supabase local dev. I remember they used to just make you spin up this crazy docker-compose file, so that's probably the solution for that. Supabase Studio 3.0, which comes with an AI SQL editor, so you can write English-language queries in a database and get SQL, which is something that database people probably wanted for 50 years. And yeah, marketplace integrations, HIPAA, can't go without HIPAA.

But I don't really have any projects on Supabase. I've tried all these databases, but I'm not running a company on it. So a lot of this stuff is just like, cool, but I'm not really going to use it. I might check out the AI SQL thing, though.

00:23:15 - Paul Mikulskis

I think one cool thing they also had was this new kind of real-time channel capability. I forget the name exactly, but you can have these subscribers and consumers, and you can push updates. There's a really cool example I saw where this guy was giving talks. He was a public speaker and he wanted ways for people to interact, like from their phones and send emojis onto his presenter screen. And he was able to throw it together with this. It's probably some WebSocket-based API that they rolled out for us, which is neat.

I like how Supabase keeps hammering on real time because that's one thing that Firebase is able to pull a lot of people in with. So it's great to see them pushing that envelope more.

00:23:55 - Anthony Campolo

Real-time broadcast and presence. Is this it? Is this what you're talking about?

00:24:00 - Paul Mikulskis

I honestly don't remember the name of the product that they released.

00:24:05 - Anthony Campolo

It says presence can be used to share state between clients. Each client maintains their own piece of state within the shared state. It uses in-memory CRDTs. That makes sense. This is like how Google Docs work.

00:24:19 - Paul Mikulskis

Client-to-client communication is getting more and more popular, which is exciting to see. Yeah, keeping the data on the nodes.

00:24:25 - Josh Goldberg

We've recently had a lot of innovation in server-to-client, like with RSCs, Astro, Remix before that, and so on. I wonder if in the next two to three years, real time is going to be the next big shake-up. Or maybe JavaScript will have bigger TC39 proposals around observables or signals. If more platforms like Supabase start pushing real time and Vercel adds some sort of integration, that'd be wonderful.

00:24:48 - Paul Mikulskis

Have either of you tried Qwik yet?

00:24:51 - Anthony Campolo

A little bit, yeah.

00:24:52 - Paul Mikulskis

I feel like it plays into the real-time world a little bit with the way it streams the JavaScript over.

00:24:59 - Anthony Campolo

Yeah, I feel like with real-time streaming in, the framework is a little bit different. I was thinking of, like, PartyKit.

00:25:07 - Paul Mikulskis

I always see people complaining about, "Oh, once I get to X number of active connections in Supabase, the thing conks out." And if you develop deep into the real-time capabilities, there might need to be some migratory things that you need to develop to take yourself off of Supabase. But it is open source, right? So you can always host it yourself, give it the juice it needs.

I guess this is like, in the cloud sense of things, one thing that Firebase does, it'll just scale seamlessly as much as you need it to. Like Anthony introed us into this segment, there's a difference in attitude and team behind what's driving these tools. Have either of you guys seen a team that has felt hindered by the cloud offering of Supabase at all, or is that still to be seen?

00:25:58 - Josh Goldberg

I've been on teams that have been hindered by the cloud offerings of the company they were tied into, but not specifically Supabase.

00:26:06 - Anthony Campolo

Not more than any other kind of tool like this in the space. I feel like with a lot of these things, if you're worried about hitting scalability issues, that means you have enough users that you can book a call with the CEO of the company and talk it out, and maybe get a deal or let them know when you're going to have high traffic or something like that. So I think that people have this idea that these things are just faceless companies. Actually, there's people behind it. So if you're concerned about a certain thing, one, talk to them about it and see if you can work it out.

I feel like they have so much VC money that they can just throw money at the problem for a certain amount of time. How long they can do that is, of course, the open question. But I think if you're worried about that kind of stuff, then you're going to be running on AWS, and that's just it.

00:27:00 - Josh Goldberg

It's nice to work with the company while they're still all fresh and exciting and full of money, instead of trying to nickel-and-dime you. And it's odd because Supabase has been around for quite a while now. It's been quite a few years, and they still feel like a young, fresh, exciting company in mostly positive ways. I don't know how long a company can keep that up, but same with, like, Vercel. For the most part, it's very nice to see that they are offering all this stuff that works really well.

00:27:25 - Paul Mikulskis

And now they're integrating so we can meet those two worlds together. So, like, one thing that they're touting, just to call back to our first topic here, is they're like, okay, we can full-stack your way to success here. Deployment.

And then I feel like now we're talking about the flip side of the coin where it's like, hey, there's this open source backend as a service called Supabase. Awesome team behind it. And now if you're concerned about deployment, you can hook it right up to Vercel. So it feels like we're getting a chasm sometimes where it's like, you can take the red pill or the blue pill, and the do-it-yourself, open source community wave is getting stronger and stronger. And it's really an enticing option for people coming into the field.

I mean, you go into Vercel and the deployment is beautiful to look at. If you go back ten years, you're looking at just console logs or some other crap that you really don't want to look at. So I'm just very excited about the open-source, community-driven ways. Even though, like, I know Vercel is a hosted cloud platform, it's not open source, but Supabase is part of this puzzle piece here that really drives home, hey, maybe you can not buy into a completely full-stack solution.

00:28:37 - Anthony Campolo

You see that with Appwrite too. I feel like with any of those things, you're going to use it because you want to use the service, or you're running it yourself and you want to host it yourself from the beginning. So you're not inhibited by the specific design decisions that this one thing made for a platform. So, yeah, I don't know. I've never really found that argument to be really that persuasive beyond it gives you a sense of security, knowing that you can run it just because you can introspect it, and you could check it for bugs and security vulnerabilities and things like that.

So I think the best case scenario is as much stuff is open source as possible, and then companies can have proprietary stuff to run that way better and way sweeter. But with that, I'm sure none of that's going to be open source.

00:29:26 - Josh Goldberg

Yeah, that's one of the big advantages of VS Code, right? That it is totally open source. That's why it's got a lot more extensions, community contributions, etc. than, say, something like JetBrains.

I do want to note, though, that continuing the trend of open source stuff, even platforms like Vercel have competition from more open source, or at least open spec-friendly competitors like Flight Control, where nowadays all you need is some platform, say AWS, and you can have everything running in open source or with a company like Flight Control that lets you eject as much as you want. So I think we're in maybe not a golden age, but at the very least, a gilded age of being able to control your own destiny as a deployer.

00:30:11 - Paul Mikulskis

That's what we all want to hear. We're in the next gilded age.

00:30:15 - Anthony Campolo

Yeah, I totally agree. I think that deployment tools in the last couple of years have gotten really good. And there was this term Tom used when he talked about Redwood: the universal deployment machine. You just have this hunk of code that's a back end and a front end, and you hook it to a Git repo and you hook that thing to someone else's thing, and then their thing runs your thing. And we're not there for all frameworks and all deployment platforms, but it's getting closer and closer for most people.

00:30:45 - Emily Kochanek

We're going to move into our hot take section. But before we do that, I do want to say that this episode was brought to you by LogRocket. LogRocket offers session replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience. With LogRocket, you can find and solve issues faster, improve conversion and adoption, and spend more time building a better product.

Okay, now we're going to get into my favorite part, which is the hot takes, where we talk about things that we're either annoyed by, excited about, or just can't get over. So let's start with Josh. Tell us your hot take, and then Paul and Anthony, feel free to discuss.

00:31:31 - Josh Goldberg

Oh no. We were talking before the podcast about how it feels like August was dead. I was scouring Twitter. I don't know what hot takes to send out. My big bully pulpit lately has been to use a formatter for formatting and a linter for linting, but I don't even know if that's a hot take anymore. I haven't gotten a lot of pushback on that from most people, so I don't know. Can someone shout something at me?

00:31:54 - Paul Mikulskis

So, Josh, you're saying keep Prettier for Prettier and keep the linter for the linter?

00:31:59 - Josh Goldberg

Yeah. Right now there are two popular formatters in the JavaScript space, Dprint and Prettier. Prettier is much more popular. Dprint is written in Rust and is faster and used by Deno. And then the big linter in JavaScript land is still ESLint. The two don't do each other's concerns particularly well. Prettier is almost incapable of running lint rules that check for logic, and ESLint, although it can run formatting rules, is not particularly good at it.

So use ESLint for definitely logic and maybe also style concerns, and then formatters like Prettier for formatting concerns. It's not the most exciting hot take. I think that's why a lot of people aren't getting passionate about it. I'm sorry, I don't have something like tabs versus spaces to bring to the table. This is an embarrassing first showing for me, and I do feel bad about myself.

00:32:42 - Emily Kochanek

It's totally fine.

00:32:42 - Emily Kochanek

We'll have you back on again when things are a little more active.

00:32:45 - Paul Mikulskis

I'm sitting here totally agreeing with Josh, so dang it.

00:32:51 - Emily Kochanek

No controversies on this one. Well, how about Anthony? Do you want to give us your hot take?

00:32:57 - Anthony Campolo

I don't know if that's, like, a hot take, but just a conversation that was happening, and I feel like this conversation has happened every year for a couple of years now about the term Jamstack. What do people here have strong feelings about the term Jamstack?

00:33:14 - Paul Mikulskis

The acronym itself, Anthony?

00:33:16 - Anthony Campolo

Well, it hasn't been an acronym for years.

00:33:21 - Paul Mikulskis

I used the wrong word, the term.

00:33:23 - Anthony Campolo

So it started as an acronym, and they tried to phase out the acronym because they want it to be a more general definition. So Jamstack used to mean JavaScript, APIs, and markup, but they found that what they were trying to explain is like a static site hooked up to APIs with component frameworks. And that didn't entirely get the idea across because you had things like Eleventy, which don't particularly fit into that mold, or even like Hugo. So Jamstack became more and more basically whatever features Netlify supported, because they're the ones who started with the term originally.

And the last two years especially, there was a lot of conversation among people in the community about whether the term should be dropped or not. Redwood actually dropped it first. Redwood dropped it like two years ago. We used to say, "We're bringing full stack to the Jamstack," and now we say, "We're the JS framework for apps and startups." And Netlify dropped Jamstack, and now they're using terms like composability and composable web, which Edgio is a year ahead of them on.

00:34:35 - Anthony Campolo

We had a composability summit, and that is the idea. You have a decoupled front end, back end, and you can use pieces to slot your app together like Lego pieces. So yeah, a lot of people are just no longer using the term Jamstack. With the exception of all of these Git-based CMS tools, you have things like TinaCMS and CloudCannon and Plentí, and they were created as, like, the thing that goes along with the Jamstack. If you wanted still to have a content management system and a visual editor and stuff like that. So I'd be curious to see how those companies, if they stick with the term Jamstack, or if they try and rebrand because they're still like, you can go to any of these companies and they'll have a Jamstack CMS link on their website.

So yeah, and I wrote an issue about this on JavaScript Jam that we could link to, and I got very good SEO on it. If you Google, "Is the Jamstack dead?" it'll be the first thing to come up.

00:35:37 - Paul Mikulskis

Well, Anthony, do you feel like it's dead or do you feel like it's evolving in its present-day use case?

00:35:44 - Anthony Campolo

Yeah. So this conversation started with Brian Rinaldi, who was doing Jamstack before the term Jamstack was invented and will do it long after. And his take is what a lot of other Jamstack pioneers are saying. They're saying the term is dead because now this is just the way people do web development. And Jeff Escalante said it was the most outrageous concession in a web dev argument he's ever heard, that we lost because we have become the sum total of web development.

So I don't think that's entirely true, but there is something to it. People are very comfortable using things like Vercel and Netlify and having a back end spun up somewhere else that they connect their project with. That's what I was always getting across with FSJam. FSJam Podcast is short for Full Stack Jamstack because the Jamstack was always just a front end. There was no back end. Then you had things like Supabase come around, and all of a sudden you had a back end to go along with this really nice front end. So I think full-stack Jamstack became the thing, not Jamstack.

00:36:47 - Anthony Campolo

And that's why I will continue to use the term for the foreseeable future until Chris and I come up with a better one, I guess.

00:36:57 - Josh Goldberg

Who cares? What? I truly do not see the value in debating this. It was a term that got public adoption and was good for marketing, but it's been quite a few years and we've evolved quite a lot in the industry. I quite like how Kent C. Dodds puts terms like SPA and MPA and whatnot to the forefront, but this feels like something that got much more exposure and bloat than it should have.

The term Jamstack evolved to mean so many different things to so many different people that you can't define it officially. Dead or alive, it's just floating in the ether. Also, who is the official? Who is officiating the death of it? What governing body standards procedure has determined which terms are officially alive or dead at this point?

00:37:40 - Anthony Campolo

So Jamstack started with Netlify, and Netlify created Jamstack. And since they stopped using it, that's why people now are considering it, quote unquote, dead. And because Brian Rinaldi, someone who wrote a book called The Jamstack Book, wrote this article, that kind of kicked this off. So I think this is, as someone who's been seeing this conversation play out over many years, the first time where it's very clear that the majority of people are saying, like, yeah, we're ditching the term.

So I think it is likely we can actually declare it officially dead. Some people are declaring it dead, probably prematurely last year or two, but I think what they pioneered and what we have now with tools like Netlify and Vercel has become pretty significant. So yeah, I don't know. I'll pour one out for the Jamstack.

00:38:35 - Emily Kochanek

Paul.

00:38:36 - Emily Kochanek

Do you have anything controversial you want to talk about?

00:38:40 - Paul Mikulskis

Perhaps not controversial, but something that was inspiring to me is I had the privilege, thanks to Emily. She put together an episode with Kyle Simpson, and I don't know if you folks have heard of Kyle, but.

00:38:52 - Anthony Campolo

Getify.

00:38:53 - Paul Mikulskis

Right. So he's working on Socket Supply Company. That's his mission right now. And it's like this framework for you to deploy client-first applications. You own the data on your phone, on your computer, and it implements these native APIs. And it was just so inspiring talking to Kyle because he was like, listen, this cloud stuff, it's got to stop. It's got to stop. You don't need to put your grocery list in the cloud. It can just live on your phone.

And that's a refreshing thing to hear. It feels empowering to the user. And so I feel like 99% of the time we lose sight of making better apps, and we're looking at making better tools for us, for Josh and Anthony and Paul. And I'm like, this is a breath of fresh air. So I love to see that. I think it's important to remind ourselves of who we're building for, and it's not us.

00:39:44 - Emily Kochanek

Well said. I also enjoyed that interview very much.

00:39:48 - Short split interjection

Strongly agree.

00:39:48 - Emily Kochanek

Yeah. And if anyone's interested, it should be coming out when this releases, probably the week after. So watch out for that on PodRocket.

All right. Thank you all for joining us today. We are coming up on time. I would love to know, each of you, where our listeners can find you. Josh, do you want to start it off?

00:40:07 - Josh Goldberg

Sure. I am Joshua K. Goldberg on Mastodon, Twitter, Bluesky, GitHub, Twitch, and YouTube.

00:40:18 - Anthony Campolo

I'm AJC Web Dev on all the things: GitHub, Twitter, Twitch, and AJCWebDev.com. Check my stuff out. I also host podcasts and do a weekly Twitter Space with JavaScript Jam and write a newsletter. I get to do a lot of that stuff through my job at Edgio. So yeah, putting out content all the time.

00:40:45 - Emily Kochanek

And Paul.

00:40:47 - Paul Mikulskis

I'm just here. I'm on PodRocket every week, getting the privilege to interview some of the great minds. So just go to PodRocket.

00:40:55 - Emily Kochanek

Hell yeah. All right. Thank you, everyone, for joining us today. Hope everyone had a great summer, and we will be back next month with listener question episodes. So if you have any questions about web development, feel free to send them my way. My Twitter handle will be in the description. Thank you again, everyone, for joining me today.

00:41:16 - Paul Mikulskis

Thanks, Emily.

00:41:17 - Josh Goldberg

Thanks for having us. This was fun.