Live at Render ATL 2022
A panel of front-end experts recorded live at RenderATL discuss frameworks, performance, caching, tRPC, and evolving trends in modern JS
Episode Description
JavaScript Jam Live discusses the SPA vs MPA pendulum, Astro's role in the framework ecosystem, and tRPC's approach to type-safe full-stack development.
Episode Summary
This JavaScript Jam Live episode, broadcast partly from Render ATL, opens with conference impressions before pivoting into a substantive debate about the current swing from single-page apps back toward server rendering. Theo argues the pendulum will eventually reverse again, noting that highly interactive products like video apps benefit from client-side patterns while content-heavy sites clearly belong on the server — and that the industry keeps over-prescribing whichever approach is trending. The conversation moves to how Google's Core Web Vitals tie real-user performance to search rankings, giving organizations a concrete ROI reason to care about speed. From there the panel examines Astro's SSR capabilities, with Theo positioning Astro less as a static-site builder and more as a competitor to Vite — a framework-for-frameworks that lets developers bring in React, Solid, or other libraries without becoming build-tool experts. The second half features tRPC creator Alex, who explains how tRPC eliminates the concept of endpoints by letting TypeScript inference flow from backend functions to frontend calls with zero code generation. The group contrasts tRPC's lightweight, incrementally adoptable philosophy with GraphQL's heavier upfront investment, framing the choice in terms of team size, number of clients, and how much architectural "runway" each option buys before you must commit to a direction.
Chapters
00:00:00 - Render ATL Kickoff and Conference Impressions
The episode opens with the hosts checking audio and welcoming panelists, including Scott broadcasting live from the Render ATL conference in Atlanta. He describes the workshop day setup, with free sessions at the Midtown Hotel and paid workshops at the main venue, plus a packed schedule of evening networking events across the city.
Ishan contrasts what he saw at the recent Remix conference — a notable emphasis on HTTP waterfalls and performance — with the Render ATL agenda, which features an unusually strong slate of talks on community, inclusivity, accessibility, and open source alongside the expected technical sessions. The observation sets the stage for a broader discussion about where the front-end community's attention is shifting.
00:03:46 - The SPA vs. Server Rendering Pendulum
Theo identifies "render as you fetch" as the dominant new trend in React circles, driven by both Remix's loader patterns and React Server Components. He argues that front-end developers are now having more backend conversations simply because frameworks like Remix and Next have pulled them in that direction. The panel explores whether this shift was organic or pushed by specific frameworks.
The conversation deepens as Theo predicts an aggressive swing back toward client-side rendering in the coming years, likening the SPA-versus-MPA cycle to the perennial imperative-versus-declarative debate. He cautions that interactive, application-style products — like video call platforms — will suffer if developers blindly adopt server-rendering patterns optimized for content sites. Ishan and Theo agree the real question is whether you are building a "site" or an "app," but Theo pushes for even more granular categories to avoid over-prescribing any single approach.
00:10:06 - Core Web Vitals, ISR, and Caching at the Edge
Ishan highlights Google's Core Web Vitals as a powerful incentive, explaining that tying real-user performance metrics to search rankings gives companies a financial reason — better organic traffic — to invest in speed beyond the usual "faster equals better conversions" mantra. Theo shares his own experience inheriting a largely static Next.js site and discovering that incremental static regeneration, while powerful, is poorly documented.
The discussion turns to how platforms like Layer0 support ISR and on-demand cache invalidation, and why recreating Next's caching behavior is difficult without an open spec. Ishan explains the complexities of cache-key normalization — UTM parameters, anonymous user IDs from social platforms — and argues that the cache-control header alone under-specifies what front-end developers actually need. He frames the Jamstack philosophy as serving data from the edge as often as possible, noting that a conventional SSR setup with good caching approaches that ideal except on the very first request.
00:18:43 - Astro, Vite, and the Framework-for-Frameworks Debate
Theo shares his current preferred stack for performance-sensitive sites: Astro for the static shell with Solid pulled in for dynamic behavior, reserving React for full applications. He praises Astro's SSR mode as the "PHP replacement" he has been waiting for — a simple model where backend code sits at the top of the file and HTML renders at the bottom, with type-safe data access in between.
The panel debates Astro's competitive positioning. Theo provocatively argues Astro competes more with Vite than with other frameworks, because it abstracts away the build pipeline so that framework authors and everyday developers no longer need deep Vite expertise. Anthony counters that Astro also eats into Eleventy's static-site territory from the dynamic end. They agree that meta-frameworks in general reduce the need for developers to understand build-tool internals, with Sveltekit cited as another example of the same philosophy.
00:26:16 - Mid-Show Break and tRPC Introduction
Scott and Ishan pause for a community break, welcoming new listeners to JavaScript Jam Live and encouraging audience participation. They explain the show's format — an open-mic Twitter Space covering anything JavaScript or full-stack — and invite attendees at Render ATL to join the conversation.
Anthony suggests bringing up tRPC, and Theo provides a concise primer: tRPC lets you write a function on the backend and call it on the frontend with full TypeScript type safety, wrapping React Query and deploying on Express-compatible servers, all without inventing any intermediate schema or language. The explanation sets the stage for tRPC's creator, Alex, to join the conversation and share deeper insights.
00:28:22 - Alex on tRPC's Design Philosophy
Alex introduces himself and shares that tRPC just crossed 6,000 GitHub stars. He describes tRPC as scratching the itch he felt missing PHP's simplicity — writing a database query inline and rendering HTML from it — but in a modern TypeScript environment. The group briefly discusses tRPC's relationship with Blitz, noting that fundamental design disagreements led the two projects in different directions, particularly around build tooling and context propagation.
Theo highlights what makes tRPC unique: because it lives entirely in TypeScript's type system with no code generation or file watchers, developers get instant type errors across backend and frontend without even saving a file. He shares an anecdote about an engineer who built full-stack features for months before realizing they had never learned what an "endpoint" was — a testament to how thoroughly tRPC abstracts away the network boundary. The panel compares this to AWS Smithy and concludes tRPC's power comes precisely from refusing to be language-agnostic.
00:39:01 - tRPC vs. GraphQL and Architectural Runway
Theo explains his adoption philosophy: he prefers piecemeal tools he can install alongside an existing stack rather than buying into a large opinionated framework. He recounts being burned at Twitch, where a full rewrite from Rails and Ember to GraphQL and Golang improved things but then locked the team into patterns that prevented further iteration. The GraphQL schema became a wall between frontend and backend developers.
Alex frames the tRPC-versus-GraphQL choice in terms of team scale: at small team sizes a hard-defined spec only slows you down, but at larger scales well-defined contracts help teams move faster. Theo extends this with a "runway" metaphor — tRPC is near-zero effort to adopt and buys meaningful runway without committing to a direction, while GraphQL demands a larger upfront investment but theoretically buys more runway, provided you bet on the right direction. Anthony adds that investing in a framework like Redwood means also investing in its team and community, not just its technical choices.
00:48:20 - Solid JS, Closing Thoughts, and What's Next
Scott shares his excitement about the remaining days at Render ATL and encourages listeners to follow the panelists and tune in weekly. Ishan asks for audience members attending the conference to share what talks they are most excited about, then surfaces a tweet from Ryan Carniato about Solid's paradigm where the component function runs only once, which can surprise developers coming from React's re-render model.
Theo reflects on his experience porting a React app to Solid, noting that by relying on tools like tRPC, Zustand, and React Query he spends very little time thinking about React itself and mostly works in JSX — making the jump to Solid's more literal reactivity model feel natural. The hosts wrap up with plugs for the upcoming Composability Summit at composability.dev and remind listeners that JavaScript Jam Live airs every Wednesday at noon Pacific. The episode ends at approximately 00:52:40.
Transcript
00:00:00 - Scott Steinlage
Test, 1, 2, 3. Can you hear me? All right, let me join in here. Let me get Anthony and Ishan. All right, I'm in here.
00:00:14 - Theo
Yo.
00:00:15 - Scott Steinlage
You can hear me? Hey, Brad. Sup, bro? Let's bring you up too, man. If you want to speak, you can
00:00:21 - Theo
be up here with us. You don't have to, but I encourage it.
00:00:26 - Anthony Campolo
How are the vibes in Atlanta?
00:00:28 - Scott Steinlage
Dude, the vibes are crazy out here. My gosh, there's just so much going on.
00:00:34 - Anthony Campolo
I could imagine.
00:00:37 - Ishan Anand
Anthony, I thought you were actually out in Atlanta for RenderATL. Are you showing up later, or what ended up happening?
00:00:43 - Anthony Campolo
Nope. No, I have some family duties to attend to. I could not make it, unfortunately.
00:00:48 - Theo
Mm.
00:00:48 - Anthony Campolo
My mom is visiting St. Louis. I was a no-go on any conferences for this week.
00:00:55 - Anthony Campolo
And I also had to pick between this and Graph Day, which would have been very hard to do as well. There's too many things to do.
00:01:01 - Ishan Anand
Well, when is Graph Day?
00:01:03 - Theo
Now.
00:01:04 - Anthony Campolo
It's happening.
00:01:06 - Scott Steinlage
Now, yeah.
00:01:09 - Ishan Anand
Oh, yeah. It looks like we've got Theo here.
00:01:11 - Scott Steinlage
Yeah, man, I'm excited.
00:01:14 - Ishan Anand
Theo, you left us with some really interesting thoughts to chew on last week, so we could continue that. I actually checked out your run-through on the RFC for the Next.js layout, so we could potentially go over that as well. That was really interesting. But Scott, you're down there in Atlanta for RenderATL. What's the vibe like? I think today's workshop day.
00:01:34 - Theo
Is that correct?
00:01:35 - Scott Steinlage
Yeah, sorry, I had my mic off. Yeah, today is workshop day, so there are actually, if you had RSVP'd prior, three workshops at the Midtown Hotel, which is where I'm actually at right now.
00:01:48 - Scott Steinlage
If you go look on Twitter, you can see the pictures I put up about five minutes ago. It's just such a beautiful hotel. It's insane, the amount of things they have here. And then the actual event is at The Gathering, and that is starting tomorrow. But the paid workshops are over there. So free ones here, paid ones there, and then there's a bunch of evening activities all over the city that you can RSVP for. A lot of them are already full if you haven't RSVP'd already. But it is insane, the amount of things you can do here, the amount of people you meet, and just the stuff that you can learn. So it's amazing.
00:02:25 - Ishan Anand
So I'm not down there and the conference hasn't happened yet. And last week we were at the Remix conference. My takeaway from that, if I was to summarize for folks in a technical sense, was what struck me was that for a React conference, a front-end development conference, I saw a lot more talks on performance and specifically waterfalls. I hadn't seen HTTP waterfalls for the longest time, and it was refreshing to see that in a front-end developer conference. When I look through the RenderATL list of topics, and the talks haven't happened yet, what strikes me as interesting is there's a lot of talks on areas that I typically don't see. I'm seeing a lot more about community and inclusivity and accessibility in addition to normal technical topics. So there's one here on error boundaries and serverless that I see James Q Quick is doing. But then there's stuff about how to get started with open source that Brian Douglas is doing, which makes a lot of sense given his open source work. There's stuff on inclusive design and accessibility. There's actually Shaundai doing Remix as a browser framework, which she's also done at Remix, but there's a lot more here that's on the social side or the human side, shall we say, than I've seen in conferences in the past.
00:03:43 - Ishan Anand
I don't know if anybody else looking at the agenda was struck by that as well.
00:03:46 - Theo
Generally, I've definitely seen a trend towards the render-as-you-fetch conversation, and I've seen a lot of stuff around that. Re: the Remix conference stuff, I think that's one of the big things that both Remix and the core React team are investing in right now with React Server Components, loader patterns, tying the data to routes rather than to components specifically, and generally trying to move fetch out of components directly. I think that's a general trend that we're seeing, and obviously the talks are going to follow that. Everything else, for the most part, from what I'm hearing, sounds like the usual variety. It's cool to have more backend-type stuff talked about in front-end communities, and I think that's just the consequence of Remix and Next catching on so much. I think front-end developers are talking about backend more, and as a result we're having more backend conversations. The only thing here that feels particularly different from years before is that render-as-you-fetch is the new meta.
00:04:44 - Ishan Anand
Yeah, and hence the focus on waterfalls as well. Do you feel like that was pushed by Remix, or do you think it was organic, like the React team was already going towards this with Server Components, it just hadn't materialized fast enough?
00:05:02 - Theo
Organic's a weird word. I feel like this is a thing that's been happening for a while. We've always seen the hatred for SPAs from a lot of different communities. The Rails community, for example, has been shitting on us forever, absolutely, single-page-app land. And I think that this is almost the expected extreme response. Something I argue about a lot is I think that render-as-you-fetch is great for a lot, but not for everything. And in an application like what I'm building at Ping, which is a video app for Zoom-like video calls in the browser, the render-as-you-fetch pattern is fine because most of the page content is cached and immediately loads, and loading spinners and delayed response actions and making a responsive experience is what we're optimizing for. Render-as-you-fetch's primary goal is reducing pop-in and loading state and, as a result, addressing waterfalls and resulting in a slightly faster experience to get a full content page. I would rather get a way faster experience for an empty content page and have a slightly slower fill-in for the content after, for application-type experiences.
00:06:08 - Theo
But it varies so wildly, and I feel like everybody's prescribing their solution as the solution for all right now, which has been its own frustrating thing. And I think we're going to see an aggressive swing the other way in a few years as a result of it.
00:06:19 - Ishan Anand
Aggressive swing, which way?
00:06:22 - Theo
I think right now we're swinging back to multi-page apps and server rendering. I think we're going to swing back to client side again, and we're going to be going back and forth between these forever. It's the new imperative versus declarative, where we just go back and forth all the time and complain a bunch.
00:06:36 - Ishan Anand
That's very interesting because one of the things I wrote down for a topic, I don't know if you saw, Nolan Lawson had an article, "The balance has shifted away from SPAs," about three weeks ago. We discussed this with the shared element transition API, things that came out of Google I/O, Chrome implementing paint holding, back-forward cache, and you've got Astro and similar frameworks really embracing MPAs. So what you're saying is these are on the hype cycle and your sense is we'll go back to SPAs again and client-side rendering, with maybe the benefit of server components and things like that.
00:07:10 - Theo
My, my, my feeling is this swing back is for very good reason. The community is moving back towards server rendering because we client-rendered way too much shit. It shouldn't have been client-rendered. But I have a feeling what we're going to see is the next Zoom clone or the next Twitter is gonna be made with something like Remix that's heavily server-rendered instead of something like Next with SPA behaviors. And it might seem better at the time, but we're going to see that the speed of switching between pages and things isn't as great as it is on your e-commerce site or your blog. And similar to how SPAs are over-prescribed right now, your blog shouldn't be a single-page app, and your Twitter clone shouldn't be a multi-page app.
00:07:52 - Ishan Anand
That makes sense. I do think that what's been happening is everyone thought they needed a single-page app, and for something that's purely content, it's hard to argue that you need all that overhead when a multi-page app, especially with the transition API and other things like that, works. Once you browse a piece of content and move on to the next thing, you don't need your scroll position to be held from where you last were and things like that. So it does feel like we over-client-side-rendered a lot of stuff. And the way I think about it is, are you trying to build an app or are you trying to build a site? Which is very similar to how Swyx has said Svelte is for sites and React is for apps. Is that kind of aligning with where you're thinking, or are you suggesting something different?
00:08:37 - Theo
Yeah, very much so. I think site versus app is a little too big of groups. I remember I saw a post a while back, I don't remember who it was, but it was like the different types of website, and they broke them down into five. It included content sites, static content sites, dynamic content sites, e-commerce sites, applications, media platforms, and what each of these is and how their needs differ. I wish I could find the post. It was really good. I have it saved somewhere. But yeah, I think that we're not quite granular enough in how we talk about the things we're building for. And that, combined with the fact that React is fast enough to do pretty much anything on a modern computer or phone, means it gets used because it works when you're developing it. And I think that's the problem that we don't talk about enough. It's the "if it works on my machine" thing. That's the reason why we're seeing so many SPAs shipped as blogs, or blogs shipping as SPAs.
00:09:43 - Theo
Because in your dev environment it feels totally fine, and when you ship it, it feels totally fine on your brand-new MacBook or your fancy computer. When you live on the West Coast and you're shipping on us-west-2, the impact of these decisions isn't felt enough, and I don't know how to fix that. Are you saying use the right tool for the job? I'm saying that using the wrong tool for this job should hurt more. Agreed.
00:10:06 - Ishan Anand
I think Google is actually the ally here on this with Core Web Vitals. I think a lot of people don't realize that they did two things. One is they made Core Web Vitals impact your search results. But now there's a clear benefit to performance beyond just, hey, I get better conversions. Better speed means better conversions. Everyone knows that mantra. But now what Google said is better speed means more organic traffic. So you can almost think of it as: a faster site never got new people to come to your site. If you wanted to get new people to come to your site and had to spend that money on ads, maybe you're better off spending that money on improving your site's performance. So that makes everybody in the organization now have an ROI baked around it. We can explain that to the CFO, so to speak, right? And then the other thing they did with Core Web Vitals is they made it defined by real user metrics. So it doesn't matter what your Lighthouse score is. It really matters what your users experience in their native environment, as long as, caveat, they're using Chrome. And there can be differences.
00:11:13 - Ishan Anand
I remember looking at the pre-Core Web Vitals Chrome UX Report, and you would see very different regional differences. So if you were, say, a site that was servicing folks in South Korea, they generally tended to have better scores because people had better connections. And so what affects your users will affect your traffic rank, and I think that'll get people to care. I think it's working its way through the ecosystem, and it'll also be calibrated to how much of a ranking effect they weight performance in the search result. I think that might help, but the awareness of that still seems very nascent.
00:11:49 - Theo
On this [unclear] too. I'm feeling triggered because in my new role, where we're now starting to utilize Layer0, I inherited a relatively young Next.js app that 90% of its surface area needs to be super SEO-optimized and is static. The struggle is real. Even the interactive parts are some buttons. It's not really a form or two, but it is. Yeah, you're just like, what are we
00:12:17 - Ishan Anand
getting for all this?
00:12:18 - Theo
I'm not really. The last thing I built was also a browser-based video thing. It has lots of interactivity, lots of other things going on, and it was really natural to use React for. But now I've inherited this app and I'm like, oh, you know, we just basically need to statically render the majority of it. And yeah, so it is definitely right tool for the job. I'm thinking, man, if this was a Rails app it would just be a cache header. That would be it. What's one thing Next... like Next does a terrible job of documenting the way the static revalidation and ISR behaviors work. If you turn on incremental static regeneration, which is a specific field you have to return in a page prop return, then you get really good behavior for this flow. In particular, the first time somebody loads the page, it gets built and then cached. You can choose how long it's cached for. You can even dynamically revalidate it by calling the new revalidate endpoint that they built. So if you have a page that you want to update when an admin pushes a change to it, you can add to that API call, when the change happens, a revalidate call on the page so that it creates a fresh cache instance of it.
00:13:30 - Theo
Then yes, in Rails you could just put a cache header on it. Technically in Next you still can do that if you're responding through API headers or take over the HTTP response, which you can do. But generally they're trying to build a better developer experience around this with workflows where you can't do that, in particular revalidation programmatically.
00:13:48 - Ishan Anand
And I'll just mention Layer0 does support ISR in Next, and we actually support what they call on-demand ISR, where you can target cache-clear things that have expired if your CMS or admin operator changes something. Yep, go ahead.
00:14:02 - Anthony Campolo
Do you offer similar things for non-Next frameworks also?
00:14:05 - Ishan Anand
Yes. So what we did is, when you said they don't document it well, they've documented it really well for developers. But if you are a platform and you're trying to recreate ISR and ISG, there's no open spec on what the behavior should be. You're just basically looking at what they do and then trying to imitate it. At least that was what it was like when we were trying to do this, I think maybe over 18 months ago. And so what we did is we took the primitives that you might need to have, if something is not there, do the rebuild, and created an API for that. And we did show a way to do that with Nuxt. The challenge, and this is where I think actually ISG and ISR are really brilliant, is it's a bunch of handshaking between the cache infrastructure and the front end too, to know, for example, that they have this placeholder page that gets spun up if it's effectively a miss, there's no built version of it. And then it knows once it's built that, hey, I can grab the JSON version, I can do a client-side transition to the now fully rendered version of the page, and then somebody else who navigates independently can come in and get just the fully hydrated or fully statically rendered version of that page.
00:15:23 - Ishan Anand
And all that handoff requires knowledge in the framework to do the right thing on the front end. And so we did this with Nuxt, but with Nuxt it's a little harder because it doesn't have the front end framework knowledge inherent in it. And so you have to add that.
00:15:37 - Anthony Campolo
Have you tried it with Svelte or SvelteKit?
00:15:39 - Ishan Anand
I have not tried it personally with Svelte or SvelteKit, but the API we built out to support it could make it work. But I have not personally tried it. We've done it with Nuxt because after Nuxt it's probably the next most popular.
00:15:52 - Theo
I was under the impression, sorry, I was under the impression SvelteKit in particular was going the Remix approach, where it wasn't doing caching as a framework primitive so much as you would throw a header on it and expect your deployment architecture and your CDN to do the right thing.
00:16:10 - Ishan Anand
So you might know more than I do. That seems to be a lot of the conventional way to handle caching. The challenge with that is that the Cache-Control header under-specifies caching in a lot of ways. It's hard to know, for example, how to do something like cache-key normalization. So if somebody adds a query parameter, is it the same thing, or is it different? A classic example we often use is when somebody shares something on social media, say from Instagram, and it goes to the web page. At least the last time we looked at this, there's like a million query parameters. There's UTM parameters that are used by Google Analytics client-side, there's maybe the SKU ID of the product, there's an additional parameter that Instagram added to every single link which is linked user ID, or at least an anonymous user ID, so that you could correlate: did the same person come back multiple times, or was it three independent visits
00:17:04 - Theo
if you got three hits.
00:17:06 - Ishan Anand
And so if a regular CDN looks at that and says, oh, these URL parameters are all different, I don't know which one is affecting the actual server-side rendering of it, the Cache-Control header doesn't let you say, oh, you should only listen to the SKU ID parameter, and those UTM variables and that underscore-user parameter, they don't matter. The client-side code will figure that out. And so that's one of the areas we've tried to iterate on and make it really clear: hey, let's get the caching really working as best as possible. Let's cache as much data as possible at the edge. Because at least our philosophy, Jamstack is really just about serving data from the edge as often as possible. In fact, that's what a CDN is. It should try to serve data as close to the user as possible and as often as possible. And if you can do that in a conventional setup where you're still doing server-side rendering, you're as close to Jamstack, or should I just say static Jamstack, except for the very first hit.
00:18:06 - Ishan Anand
And that's my challenge when it's just a Cache-Control header. It just doesn't specify things enough for a developer to optimize it. And it's also not a very native API for front-end developers. Developers. I've learned from watching what's happened with Next is that they find it easier when they're just sitting in React and writing the code around it. Even just a helper function that emits the right Cache-Control header just unlocks more productivity or usage from developers. At least that's been our experience. But I can talk forever on cache. So if Svelte is going the route of just Cache-Control header itself, is that correct?
00:18:43 - Theo
As far as I know, from when I last checked. My knowledge is admittedly quite a bit behind. I haven't built anything with SvelteKit since the first alpha. So right after they killed, what was the thing called?
00:18:54 - Anthony Campolo
The
00:18:56 - Theo
Sapper. It was right after. Yeah, I'm pretty friendly with the Snowpack guys. I love Fred to death. I'm much more knowledgeable of what's going on in Astro than I am in Svelte at the moment. Honestly, my take for those super performant solutions is if I cared I would use Astro as much as possible and then pull in Solid when I need dynamic behaviors. And that's what I do now for my blog and shit. And React is for apps.
00:19:22 - Ishan Anand
Oh, interesting. So we've had both Ryan from Solid and Fred from Astro on the JavaScript Jam proper pod to demo those solutions. I think both of those are really fascinating frameworks and approaches. I like what they're doing and I'm especially encouraged that Astro just added SSR support. I think of Astro with SSR and the View Transitions API, and some of that could mean things like blogs and e-commerce sites don't necessarily need to be single-page apps anymore
00:19:50 - Theo
and they don't need that overhead. Astro with SSR is the PHP replacement I've been waiting for. Personally, it is the quickest way to type-safe, write out a bunch of things you want on the top of the file, and then render HTML on the bottom of the file. It's so nice for that in particular. If I wanted to quickly hack out a site that is pulling data from a server dynamically and not have that run on client and have that be cached, Astro, even as somewhat fragile as it is because it's so new, is by far the fastest-to-get-up-and-running solution with the simplest DX for it, for sure. The magic of const user = await prisma.user... and just having a type-safe user you can inline in your HTML below that without having to build anything between the two, the backend code's on top, the HTML is on bottom, and as dumb as that sounds, the simplicity makes a ton of sense for a lot of the web.
00:20:51 - Ishan Anand
Yeah, it's like in those Vue single-file components, except even simpler. It's just here's the JavaScript that runs on the backend, and then here's everything kind of co-located together. I actually haven't played with Astro SSR yet. We are building out our Astro SSR support right now. It should be coming very soon. But yeah, I'm a big fan of the approach they took there, and actually we're working on potentially having some content at the upcoming Composability Summit around micro-frontends and potentially even Astro, as well as agnostic view, which is to kind of build components in a framework-agnostic manner, which I'm really looking forward to. You mentioned, right, all in. Oh sir, go ahead. What were you going to say?
00:21:29 - Theo
One of my favorite things about Astro is it feels like they're trying to build a framework for frameworks in a lot of ways. I could see a future where instead of Solid building out their equivalent of SvelteKit or Next, they would make templates with Astro being the other side. I've joked before with Fred, and he hates when I do it, but I think that Astro is competing more with Vite than it is with other frameworks because of its nature of, you bring in the dynamic framework you want. You can bring in React, Preact, Solid, whatever, in your Astro project, and it gives you the build pipe, the deployment solution, and the backend and render pipes for your dynamic web framework.
00:22:07 - Anthony Campolo
And it's also competing with Eleventy. It's coming at it from the two ends, eating the static side and the dynamic part at the same time. So if Eleventy can't figure out a good solution of bundling in something like React or a React-like framework, then people are going to start moving over to Astro because it gives them that little extra boost they can't get from a purely static tool like Eleventy.
00:22:28 - Theo
Mostly agree. I think the spice I'm adding is Astro looks like it's doing that, but what it's actually doing is competing with Vite because of the people it's replacing and the responsibilities it's replacing. I'm trying to think about this from a higher ecosystem-level perspective, not just where would I put this instead of something I'm already using more. How is this going to affect the way other web developers or other library and framework developers think about these things? And Astro feels to me more like something I would drop into my build pipe or framework than eagerly drop into my stack right now, due to how minimal it is but how clear its inputs and outputs are. Feels like a really nice part of a system rather than just another static site builder.
00:23:18 - Anthony Campolo
So I agree with that because I'm doing the same thing. I'm using Vite on projects and Astro projects. It's interesting to me from more of a camps perspective. People are in camps whether we want them to be or not. And so there are certain people in certain camps who are seeing these tools and want to jump from one to the other. But then the other interesting bit is that it can compete with Vite, but there's also all these other frameworks now using Vite as well. So the way Vite is going is being driven by all of these different projects using it at the same time for their own kinds of needs. So to me, Vite is the underlying layer that everyone's trying to agree on. Then the question is how much do you want to abstract Vite? Do you want to just expose Vite in your framework, or do you want to build your framework in a way that you don't know Vite is the underlying tool?
00:24:07 - Theo
Very fair. And what you just said is pretty much exactly Fred's stance. I tend to push and nudge and point out that right now almost every framework maintainer has to become a Vite expert if they want to have decent build times. The amount of time the Remix guys and Ryan on Solid, even Tanner Linsley in his free time, spend deep in the internals of Vite in order to make anything happen.
00:24:31 - Anthony Campolo
Yeah, I did this with Ben Holmes on Flank of the Oven, so I agree. I've been there.
00:24:37 - Theo
Yeah, I think that Astro is equally positioned to compete with that by doing the thing where, when I think of somebody who uses Vite versus somebody who works with Vite, Astro is going to make working with Vite feel unnecessary to a lot of people. Everyone will still use Vite for a bunch of shit, but right now there are too many developers who understand the internals of Vite that I honestly don't think need to. And Astro is challenging that ethos too.
00:25:04 - Anthony Campolo
I think you could make the same case for SvelteKit from that angle for sure. And that's why I definitely like meta-frameworks in general. Yeah, I think I agree with that take. I think I probably have a hard time with it because I already know the internals of Vite, so I get it, but most people shouldn't know that.
00:25:23 - Ishan Anand
Totally. So I'm gonna jump in here since we're halfway past and just do a conversation break. Welcome, everyone, to JavaScript Jam Live. JavaScript Jam is a podcast on front-end and full-stack development. JavaScript Jam Live is our Twitter Space equivalent. It is effectively what I like to call an open mic for anything JavaScript or full-stack web development related. We like to be audience-driven as much as possible. We have a rotating panel of regular guests that show up, but we love it when it's audience-driven. So if there's a question you have or a topic you want to talk about, feel free to raise your hand and we'll bring you up to the stage. And whether you're a beginner or an expert, we want to hear from you. We will jump between very deep topics to very high-level topics. Even things like how do I take my career to the next level has been a common topic we're willing to talk about.
00:26:16 - Anthony Campolo
So also, Alex, talk about tRPC, if we want to get... Alex, if you're here to talk about
00:26:20 - Theo
tRPC, was about to say that.
00:26:25 - Ishan Anand
Okay, let's.
00:26:25 - Theo
We got a legend in the audience.
00:26:26 - Scott Steinlage
Absolutely. But real quick, I do also just want to say, hey, if you are up here speaking, feel free to share this out with others. The more people we get in, the more effect we can have on other people and just the value that we can deliver. And that's what we're all about, just delivering value to as many people as possible and having fun while doing it.
00:26:44 - Scott Steinlage
And by the way, if you're listening in the audience there and you hear something that you like from these speakers here and you're really enjoying it and getting value from them, please follow them as well. That's what we're here for, to create community and just all benefit from this and have a good time.
00:26:57 - Scott Steinlage
And just a reminder, we are live here at RenderATL. It is popping out in here, guys. Really good time. And we've had several people stop by and scan the JavaScript Jam Twitter handle here and join in. So super exciting.
00:27:11 - Ishan Anand
So I think, Anthony, you were suggesting having Alex talk about tRPC. Let's see if we can get Alex.
00:27:19 - Anthony Campolo
Among all sorts of other topics he could pontificate on.
00:27:22 - Theo
I imagine it might be a little late where he is, but if he's down to talk, he's always a fun person to bring up. I can overview for...
00:27:30 - Anthony Campolo
Yeah, Theo should definitely do that. Do the tRPC 101 for people.
00:27:33 - Ishan Anand
Yeah, I don't even know what tRPC is, so let's start there.
00:27:38 - Theo
Oh boy, oh boy. tRPC is the solution to my backend-front-end problem. It lets me write a function on my backend and call it on my front end with type safety between the two without thinking about anything in between. If my backend is TypeScript and my front end is TypeScript, why do I keep inventing new things in the middle? tRPC questioned why we kept doing that and solved it with an RPC-like syntax. In React, it wraps React Query. You deploy it on top of things that are Express-compliant, and now you have a single endpoint you hit with strings and JSON blobs, and it responds with the thing that you expect.
00:28:15 - Ishan Anand
That makes sense. In fact, people are used to RPC. It's surprising we didn't have this already.
00:28:21 - Scott Steinlage
Hey.
00:28:22 - Alex
Yeah, so I'm Alex, I created tRPC. We actually just passed 6,000 stars on GitHub tonight, I think, like today. Thank you. I wish it had some correlation to some income, but it doesn't really do that for me. But yeah, RPC is just amazing. tRPC for me is scratching the itch Theo was talking about with PHP earlier. For me, tRPC is scratching my own itch from missing PHP and how I did things 15 years ago when I was just writing a database query inline in a sort of PHP file and just rendered some HTML from that. And it's not like Astro, but you can use tRPC in a React Native app or React app, and on your back end you write functions basically, and then on your front end you can use that logic. You can even
00:29:18 - Anthony Campolo
use tRPC and Redwood if you want to.
00:29:23 - Alex
Yeah, there's a bunch of people doing that.
00:29:25 - Anthony Campolo
That is actually similar to Blitz in a certain sense in terms of the philosophy behind it. And so there seems to be a fair amount of crossover there. And I'm curious what is the status of how tRPC is going to be
00:29:37 - Theo
worked into Blitz 2.0? I did a podcast with Alex and Brandon a while back. Brandon's also in Y Combinator with me. We just finished our batch. Judging by how much I struggle to even be part of these conversations, I have no idea how he has the time to re-architect the framework and run a company that's growing very quick. So I wouldn't personally expect too much from Blitz for a bit, just because Flightcontrol is so deep in running a company at the moment.
00:30:03 - Alex
Yeah, yeah, that's cool. But yeah, he has other people in the Flightcontrol project that's taking over Blitz now. I think he officially stepped down from coding a couple of weeks ago, so I don't think he will be the one pushing the needle on the next version of Blitz, but I know they're scheduled to do a lot of conference talking and stuff this year.
00:30:24 - Anthony Campolo
For stuff to continue together and to work off of each other and continue to exist. So Blitz is not... the idea is not for Blitz to slow down, it's for other people to take it on. Exactly what you're saying. Yeah. I've had Chris on my podcast four times, so I've talked to him many times about these things.
00:30:40 - Alex
Yeah. But yeah, so the question earlier was, how is the tRPC and Blitz collaboration going? And I think after that conversation together with Theo, we put a pin in that because we had some sort of fundamental disagreements on how the design of such a thing would look. We're going in two different directions there. One of the fundamental things for me with tRPC is that I don't want to be involved with any sort of build tooling. I don't want to be a Vite expert. So everything that you see in tRPC is TypeScript-first and doesn't require any build tooling whatsoever. All this magic in the client is just importing a type from the backend and not actually importing something from the backend and then letting the build tools somehow magically strip it away. And there were some disagreements with how such an approach would look and also how context propagation and stuff would work in the resolvers. So I think we're just going in two different directions there. And apart from Blitz, there's also a few other new contenders in this space. There's a new thing coming out called Gravity that looks pretty cool.
00:31:58 - Alex
I had a talk with the creator of that the other day, and then there was another one that looks pretty impressive too. There's a bunch of other projects in the space, and it's just cool to see this popping up and we all take inspiration from each other.
00:32:16 - Anthony Campolo
Yeah, no, it's great. It's an idea that a lot of people were able to latch onto, but yeah, it's a good idea. And so everyone now is giving their own take on it, and that's very cool.
00:32:25 - Theo
Awesome.
00:32:25 - Anthony Campolo
Good to hear.
00:32:26 - Theo
Alex, you're not bragging enough, so I'm going to do it for you quick. I want to emphasize how cool it is that there's no build or compiler stuff necessary to have a type-safe solution from your backend to your front end. Every other solution has some crazy heavy watcher that's waiting for files to change and then write the new type definition that you're using on your front end. This implementation is so good that you don't even have to save the file in your backend to start getting type errors in your front end. If I have a Prisma call where I'm grabbing users and I'm selecting their name and I switch from true to false, I get a type error on the component that's open in the other tab before I even hit save. And that's because it's fully living in the TypeScript compiler, because of some of the wizardry Alex has done there. As a result, you don't need to add anything to your build or to your framework really as a whole. You're consuming a package like you would any other. This package just gives you the best DX I've ever had between my backend and front end.
00:33:23 - Theo
No, can't say I'm familiar.
00:33:24 - Alex
Yeah, I'm not familiar with that. Can you explain what that is?
00:33:31 - Theo
Because Amazon just released, not that long ago, an open tool called Smithy, which is like an open API. They open-sourced it, and it's a really cool tool where it allows them to create APIs across all the different services. So I just wanted to know if this is similar to that tool.
00:33:57 - Alex
Is that a language-agnostic tool? Is that the whole premise?
00:34:01 - Theo
Yeah, it's. Yeah, it's like that. Yeah. Okay.
00:34:05 - Alex
No, it's not similar in that way. That probably relies on a spec in another language, similar to how GraphQL has its own language where you write in a second language that then compiles to TypeScript or whatever language you're using, and then use the generated types from that to do your logic.
00:34:26 - Theo
I've looked into it a bit. It's actually even further. It doesn't have opinions about how you should implement it on the other side. It is literally just the language for making your own new imaginary schema type.
00:34:37 - Alex
All right, so it's like protobuf-ish.
00:34:41 - Theo
Yeah. It's like in between protobuf and GraphQL, and I don't personally see any reason to use this right now.
00:34:47 - Alex
Yeah, I don't see why it exists when we have protobufs and GraphQL already.
00:34:54 - Theo
AWS has struggled getting GraphQL adoption for a bit. They've tried three or four GraphQL tools and even when they made good ones nobody wanted them, so they're trying to figure out what to do instead. I have no idea what's going on at AWS. I used to have some friends there, but I've lost all contact on my internal comms there, so I have no idea what's going on anymore.
00:35:09 - Anthony Campolo
A decent amount of people use AppSync, but they use it through the guise of usually an AWS meta-framework where it kind of packages it up for them in a simpler manner.
00:35:18 - Theo
Yeah, to Paul's question before, are these things similar? I would say tRPC is almost like the inverse, where rather than having no opinion on the language or being its own language, or having no opinion on the other side, by having a strong opinion on the side, it's TypeScript on the back and the front. You skip all the meta bullshit and that's what it is. If Smithy is a new type of meta bullshit, tRPC is the absence of it.
00:35:41 - Alex
Yeah, so tRPC is useless unless you're using TypeScript everywhere right now. And that's the direction I decided to go in because I use TypeScript everywhere. But that to say, you could do a compiler that used the TypeScript definitions and generate a client in another language. It's just that I haven't cared about going in that direction.
00:36:03 - Theo
Would there be a performance issue with the TypeScript because you have to compile down to JavaScript?
00:36:08 - Alex
There's a few. I'm curious what you mean when you say performance issues. JavaScript and the V8 engine is pretty performant, so there's no real issue in scaling a Node.js service. There are, however, some pains with tRPC currently that I'm working on in the new major that Theo is starting to experience now that he's getting a really big backend, and that is the TypeScript inference at some point gets really heavy for the compiler and you end up having the TypeScript language server crash sometimes. You have to restart it. And also that the feedback loop is not as snappy as just updating a file and then seeing the output straight away in that file. It might take a few seconds if you have a big router, but that's still a much better experience than using GraphQL code generation or something like that.
00:37:04 - Theo
Yeah, when it breaks, very clearly, and it honestly doesn't happen too often, it's like once or twice in a long code session. Usually it happens when I leave my editor open for too long and haven't touched it. But that's just TypeScript doing the heavy lifting here, not JavaScript. And the actual compile times are still pretty fast. My build times on Vercel are still, like, under 2:15, I'd say two minutes fifteen seconds, which is fine for the size of our code base and what we're building. And again, the magic of I write a function and then I call it. I don't really think about it beyond that. The crazy moment I had: one of the engineers that I brought on at Ping, they were a ramen chef at the time and they were building game engines in Zig for fun. I didn't know how they would feel about doing web dev, so I sent them our stack. I was like, hey, if this is interesting to you, I don't want you having a job you're going to hate if you want to do low-code stuff or really deep low-level stuff.
00:38:02 - Theo
And they just fell in love with it super fast. Brought them on full time. They built a bunch of full-stack parts for our project, like admin panels or methods to activate, deactivate users, stuff like that. All backend, front-end queries, database changes, whatever. We then started spec'ing out another project that was going to be a different repo. So we built a whole project plan, schema, sat there for a few hours and chatted. At the end they were like, I feel so embarrassed asking this, but I really need to know, what's an endpoint? Up until that point they'd been building very successfully and productively full-stack solutions. And due to the way our system works with tRPC, Next.js, and just generally TypeScript everywhere, the concept of an endpoint hadn't mattered until that point. They just wrote functions and called them.
00:38:46 - Ishan Anand
Wow, that is the nirvana that Blitz and other folks are going for. That you don't even have to think about the endpoint. That's pretty amazing.
00:38:57 - Theo
Yeah, the appeal.
00:38:58 - Ishan Anand
That's awesome.
00:39:01 - Theo
The reason I chose tRPC over those solutions was I didn't want to buy all in on a huge framework to do this. tRPC was a package I could install on my existing solution, try it out for a few things, and if I liked it, adopt it more. I adopted it for two new APIs initially, ended up really liking it, and just went on a rampage over the weekend and moved everything over to it. Ended up deleting two-thirds of our code and had a way better experience. It's very easy to adopt, and in the end, since you're just writing functions, it would be trivial for me to make external APIs for our mobile app and things if we don't want to use tRPC for that. I just have functions. I could put functions anywhere.
00:39:39 - Ishan Anand
I've noticed your philosophy for adopting technology is you want very piecemeal things, so you're not buying a whole opinionated caboodle, like Rails style.
00:39:50 - Theo
Exactly. I've been burned too many times by like big projects, big solutions, bad decisions. I want the ability to opt in and out on a more granular level and replace things without everything falling apart.
00:40:01 - Ishan Anand
I was about to ask have you
00:40:02 - Scott Steinlage
been burned in the past?
00:40:03 - Ishan Anand
Do you have an example you can talk about?
00:40:06 - Theo
I helped push for, and then do, the rewrite where we moved Twitch over from Rails + Ember to GraphQL, Golang mostly on the back end, and React TypeScript on the front end because of how bad the Rails experience was. But we bought in too hard on GraphQL and Golang as a result. Iteration time on backend was not quite what it should have been, and the interplay between front-end and backend developers was nowhere near what it should have been. GraphQL became a wall between the two, and since it was so heavily adopted, as much better as it was, it didn't let us have the flexibility to keep improving. And that's what kills me. When a decision prevents growth even when the engineers are motivated to do it, that's when I feel you've made a bad decision.
00:40:53 - Ishan Anand
So there are people who consider GraphQL to be a replacement for the backend-front-end pattern, and the solution is having this really well-defined contract. But it sounds like what you're arguing is you want to not have to think about backend versus front end to a certain extent. That remark, "what's an endpoint?" Where do you fall in that philosophy in terms of architecture?
00:41:17 - Theo
I like to be able to change the decision when it makes the most sense too. And for right now, where we're at with a small team that's building quick, it has developers that kind of need to know everything. It helps so much to have solutions that let us do that, but in the future we would be able to break things up and split it if it makes more sense for owners to have different solutions for different pieces. My philosophy is do the thing that's best in the way that, to the best you can, doesn't block you from changing direction in the future.
00:41:56 - Ishan Anand
It preserves optionality as much as possible.
00:41:59 - Theo
Yeah, Alex is going to have way better input on this than me though. I want to hear what he has to say.
00:42:03 - Alex
Yeah, so the decision on tRPC versus GraphQL, I think that's a matter of scale in a way. And I don't think it's scale in terms of traffic. It's more because tRPC is actually easier to scale in terms of traffic than GraphQL. I think it's scale in terms of the number of people on your project. At a team of 1, 2, 5, 10, 20 people, having a hard-defined spec will only slow you down. However, at a certain scale, having well-defined contracts for things will actually help you move faster. So for me personally, I've been a GraphQL user for quite a few years before I started working on tRPC. And I've been a massive ambassador for GraphQL as well, and I still am, I still love it. However, it does slow me down a lot when I just want to do critical business logic for an MVP or work on product-market fit for a small startup or whatnot.
00:43:04 - Ishan Anand
Yeah, that makes a lot of sense, I think. Anthony, this reminds me of the conversation we had on, I don't know if it's been released yet, but on your podcast FSJam, and I made this analogy. It's like microservices. You don't want to break apart your monolith into microservices if your team doesn't make sense, like you want that Conway's Law, which is that idea: your org chart reflects your product. If you have a defined team that operates independently, then yeah, it might make sense to break that off. But if they're all over the place, then it makes more sense to have something across. And I should plug your podcast FSJam.
00:43:39 - Anthony Campolo
I appreciate that.
00:43:41 - Ishan Anand
Check out his podcast, FSJam.
00:43:43 - Anthony Campolo
Yeah, no, for me, I worked at a GraphQL company for over a year and then got my start working on a GraphQL framework, Redwood. So for me, I've pitched every possible person you could think of on GraphQL in every possible situation. So I certainly have found every possible way it breaks down. But there are definitely still things that I love about it and would recommend it in certain use cases because the fact that it can be molded to almost anything is because of the front-end/back-end split and because of making the endpoint explicit. It's the exact opposite of ignoring the endpoint because it's all about you have this one endpoint and everything gets shoved into the endpoint. Everyone interacts with that single endpoint. So you can't not think about the endpoint. So it's really just a matter of philosophy, whether you want to do that or you want to make it entirely invisible.
00:44:30 - Ishan Anand
Is there a dimension besides like scale in terms of team size or number of teams? I guess to summarize, you know what I said and Alex said besides that as why you might use GraphQL.
00:44:45 - Theo
Number of clients consuming, I would say, is the big one, like different types of clients. So if you have one website consuming versus a website and a mobile app that's written in Swift instead of TypeScript, then you might want to start looking into something like GraphQL. The way I like to frame this is through the dimension of time. It's if your company succeeds and the thing you're building succeeds, where do you expect it to go? Do you expect it to have additional clients? And at that point, are you willing to make a change? For us, tRPC is buying us a ton of time before we have to make the GraphQL decision. And when we do have to make the GraphQL decision, we have a bunch of functions we can plug into our GraphQL schema and hopefully from there resolve a good API. Because we have all the functions already written. I am not the most confident in that path, but we have that option once we get to a point where tRPC isn't solving for all of the clients we have and all of the problems we have, or the amount that our team is growing and the different types of products that we're shipping, but tRPC is delaying that decision.
00:45:47 - Theo
I would argue that Redwood... this was so interesting. I really need to get one of y'all on the podcast for it. I've been meaning to. I have it in my schedule. I'm so sorry, I owe you. Yeah, we'll do that ASAP. But my thought there is it's making the decision earlier with as little additional burden as possible. It's doing the thing that's correct for two to four years from now right now while minimizing the burden, whereas tRPC is delaying the decision for as long as possible, so we know if this company's going to work or not before we do the hard work.
00:46:22 - Anthony Campolo
So you want to have at least a little bit of forward-thinking engineering so you're going to be set up for something in the immediate future. Yes.
00:46:32 - Theo
Gotcha. Good stuff. It's like, how much runway does this decision buy me, is one of the ways I like to think of it. How much am I putting in and how much runway do I get from it? tRPC is like negative effort to add it and start using it, and it buys me a decent bit of runway. Redwood would be a decent bit harder for us to adopt atop the solution we have, but it would buy us even more runway. Going all in on GraphQL and setting up our own infra and stuff for it would be a huge investment, but would theoretically set us up with a lot of runway. But now that runway better be in the right direction because if we were wrong when we made that prediction, we're fucked. And that's the other reason I don't like investing heavily in runway, is you're committing to a direction.
00:47:13 - Anthony Campolo
Yeah. And that's why for me, buying into Redwood was a multifaceted decision, and having faith in both the team and the community and the now financial kind of safety involved because Tom is actually funding it publicly. There's a lot of things pointing in a good direction, but it's always going to be a risk. That's why you're partially buying into the team along with the technology, which I think can be a good pitch if the team's going to stick around. People have invested in the Next team and they've been pretty happy with that decision.
00:47:47 - Theo
Absolutely agree. Even with Next though, I try to use as little of it as possible so I can theoretically move off if I ever need to. I will probably try porting us to Remix at some point just for fun and see how it performs and what the experience is like as a developer on top, if I keep using tRPC but in a different environment. I even have a YouTube video where I port one of my Next.js React apps with tRPC over to SolidJS, and I wrote a quick Solid binding for it too. Super fun.
00:48:11 - Anthony Campolo
Yeah, definitely a big fan of Solid. We've had Ryan on FSJam. Super cool dude. But we should probably pass this back to the host because we're getting close to the end.
00:48:18 - Theo
We're here.
00:48:20 - Scott Steinlage
No worries. No, this has been awesome.
00:48:22 - Scott Steinlage
I went ahead and linked to one of your tweets on FSJam podcast. It was the latest FSJam tweet you put out and it looks like I'm in there. Hey, look at that.
00:48:30 - Anthony Campolo
What a coincidence.
00:48:32 - Scott Steinlage
Anyway, this is awesome. It's just such a great time hearing all these wonderful conversations. Actually, I do have someone joining me sitting on the couch, just listening as well. This is pretty awesome. It's been such a great experience here so far at RenderATL. For the next couple days it's just going to be that much more fun, and I'm going to document that process and share that with you all. I'm really excited about it. Anything else that you want to say here? I know we've got about five minutes left, so we do have a bit of time, but real quick, before we hand over to you, Ishan, I just want to say, hey, if you've gotten value from the speakers up here, please do follow them. Click on their image there and follow. And obviously follow JavaScript Jam as well, because we do this every Wednesday at 12 p.m. Pacific Standard Time, and lately it's been at a lot of different live events. So it's been fun being able to get other people in here that are
00:49:14 - Theo
part of the conversation.
00:49:15 - Scott Steinlage
It's been really great. Thank you all so much for being here today. And with that, I'll pass it on to Ishan to finish it up here.
00:49:22 - Ishan Anand
Yeah, we've only got a few minutes and I have a hard stop. If we've got anybody in the audience who is at RenderATL or planning to attend, raise your hand. I'd love to hear what people are interested in seeing at RenderATL. What's the talk you're most interested in seeing that's on the agenda, and you're like, oh, I want to hear this topic or I want to hear from this person? So go ahead and raise your hand if we've got anyone. Some Render... or if you're feeling shy, maybe I'll just add, I saw... let's see, did somebody just raise... nope, they disappeared. An interesting tweet from Ryan about Solid, and it reminded me of that old Oscar Wilde quote, which is something about the two tragedies: not getting what you want and then getting it. And it was about how Solid has this really nice paradigm that the function runs only once, but then it can trip you up because people coming from React don't seem to expect that, and they get confused. So I'm curious, Theo, in your experience, since you've played a little bit with Solid, if you could just tell us what that was like when you did that port in a few minutes.
00:50:20 - Theo
Yeah. For me, I've always been keeping an eye on Solid since I first saw it on HN four or so years ago, and have thought in observables for a long time just from playing with other frameworks that used it. For me, I always liked the difference where I felt like Solid was writing to the page rather than creating a dynamic update tree. And the thing for me, why I like going between Solid and React so much, is I feel like most of the work I do in bulk is in JSX. It's actually writing the stuff that goes on the client. By using things like React Query and tRPC and state management tools that are super simple like Zustand, for the React world, I've made it so I'm spending almost no time actually thinking about React. Rather, I'm thinking about what we're rendering and the states that trigger those different renders. And in Solid it's just a bit more literal when you do that.
00:51:24 - Ishan Anand
Yeah, he's made the changes to rendering effects more so than having a dynamic tree that gets reconciled and updated. Yeah, it's a really fascinating framework. The other one that I think is really fascinating, but a little more on the bleeding edge, especially because you can't use closures anymore with it... but it's another one for folks to check out. Looks like we're right at the top of the hour, so I will just thank everyone for joining us. We'd love to talk to you all next week. Maybe we can get some folks who did attend Render ATL to come back and tell us what it was like. But thank you everyone. We'll see you in a week.
00:51:56 - Scott Steinlage
Absolutely. And one last thing before y'all go, just a little shout-out here. Go to composability.dev to check out our up-and-coming summit that we have coming up. Really excited for that. We've got some amazing speakers lined up and are continuing to line up even more, so really excited about it and looking forward to the amazingness that comes from that too. Thank y'all so much. Greatly appreciate y'all hanging out today. I'll be here live at RenderATL. My name is Scott Steinlage. Feel free to say hello. You can see my picture and stuff on JavaScript Jam if you want to know what I look like, and just say hi. I'd be more than happy to chat, have a good conversation, and network a little bit. So with that, I think that's it. Thank you all so much.
00:52:36 - Ishan Anand
Appreciate you all. Have a good one.
00:52:40 - Scott Steinlage
We'll see you next week.