FSJam in 2021

Episode Description

Christopher Burns and Anthony Campolo close out 2020 by defining full-stack Jamstack and predicting which JavaScript technologies will shape 2021.

Episode Summary

In this final episode of 2020, Christopher Burns and Anthony Campolo reflect on the year in full-stack Jamstack development and lay out their predictions for 2021. They begin by attempting to define what makes a framework truly "full-stack Jamstack," landing on five pillars: database support, CLI generators, authentication, continuous deployment, and front-to-back integration—criteria that distinguish frameworks like Redwood, Blitz, and Bison from tools like Next and Gatsby. The conversation then shifts to React Server Components, Facebook's late-2020 proof of concept, with the hosts breaking down how server components differ from traditional SSR and how they depend on Concurrent Mode and Suspense. From there, they trade personal technology picks for the coming year: Christopher highlights Chrome Portals as a next-generation iframe replacement, React Native for Web and Expo as a path to true cross-platform development, Rome and Snowpack as toolchain upgrades, and even a Bootstrap 5 comeback prediction. Anthony makes the case for AWS AppSync and Amplify as architectures that mirror Redwood's design, the Begin deployment platform as an opinionated AWS layer, and frameworks in the Vue and Svelte ecosystems—Nuxt and Elder.js—as important projects to watch. Throughout, they connect these individual technologies back to the broader trajectory of full-stack JavaScript development.

Chapters

00:00:00 - Defining Full-Stack Jamstack

Christopher and Anthony open the last episode of 2020 with some lighthearted banter before diving into a question that emerged from their recent roundtable: what exactly qualifies as a full-stack Jamstack framework? Christopher proposes five key pillars—database support, CLI generators, authentication, continuous deployment, and front-to-back integration—arguing that these criteria are what separate frameworks like Redwood, Blitz, and Bison from tools like Next.js and Gatsby.

Anthony reinforces the importance of built-in authentication by referencing a Software Sessions podcast episode where the hosts described their ideal auth system, which closely resembled what Redwood and Blitz already offer. They also discuss how Prisma 2 serves as the primary database layer, with potential Fauna and MongoDB integrations on the horizon. The hosts emphasize that excluding Next and Gatsby from the full-stack Jamstack label isn't a criticism but rather a recognition of different project goals.

00:07:10 - React Server Components, Suspense, and Concurrent Mode

The discussion turns to Facebook's experimental React Server Components, released as a proof of concept over Christmas 2020. Christopher and Anthony attempt to explain the technology in accessible terms, distinguishing it from traditional client-side rendering and server-side rendering. They note that the React team insists server components are complementary to SSR rather than a replacement, reducing JavaScript bundle sizes by rendering certain components entirely on the server.

This leads into a breakdown of Concurrent Mode and Suspense—the underlying features that make server components possible. Anthony explains concurrency through Dan Abramov's classic chart visualization example and describes how Suspense manages loading states more intelligently. They draw parallels to Redwood's cell architecture, which already solves many of the same data-fetching problems that Suspense targets, and speculate about how the two approaches will eventually converge.

00:18:23 - Chrome Portals and AWS AppSync

Christopher introduces Chrome Portals, an experimental browser feature he sees as the next evolution of iframes. He explains how portals allow seamless navigation between different web contexts—such as opening a Facebook share dialog or a payment flow—without truly leaving the current page, and describes practical applications for his own project, Everfund. The hosts compare portals to iframes, noting improvements in navigation capability and simplified communication via post messages.

Anthony then shares his enthusiasm for AWS AppSync and Amplify. He draws a striking parallel between the AppSync architecture—with its GraphQL layer, Lambda functions, and DynamoDB—and Redwood's own structure. He highlights the Amplify CLI as offering similar generator functionality to Redwood's CLI and credits the AWS developer advocacy team for making these tools more accessible. Christopher admits his general discomfort with using AWS directly, which sets up the next discussion about abstraction layers.

00:27:09 - React Native, Expo, and Cross-Platform Dreams

Christopher makes his case for React Native for Web and Expo as technologies poised for a breakout year. He explains the fundamental difference between DOM-based React and view-based React Native, then highlights the work Microsoft is doing with React Native for Windows and macOS. The "write once, run anywhere" dream—where a single React Native codebase compiles to native Mac, Windows, iOS, Android, and web apps—is closer than most developers realize, largely thanks to Expo.

The hosts discuss Expo's role as an abstraction layer on top of React Native, comparing it to Create React App in its ability to simplify complex mobile APIs. Anthony notes that Redwood's Brandon has expressed interest in supporting both React Native and Expo. Christopher envisions a future where a full-stack Jamstack framework like Redwood adopts Expo, enabling truly universal application development from a single codebase.

00:33:25 - Begin, AWS Abstraction, and Developer Experience

Anthony introduces Begin, a deployment platform built on top of the Architect framework by Brian LeRoux, the creator of PhoneGap/Cordova. He explains how Begin provides an opinionated AWS stack using roughly eight core services—DynamoDB, Lambda, API Gateway, and others—with the ability to deploy full-stack projects in seconds. Anthony sees Begin as doing for AWS what Redwood does for the React ecosystem: curating and integrating best-of-breed tools into a cohesive experience.

Christopher shares his philosophical discomfort with AWS directly while acknowledging its power, comparing the cloud provider to a utility company. Both hosts agree that the value of services like Begin and Amplify lies in abstracting away AWS complexity while preserving its capabilities. Anthony notes that the Amplify developer advocacy team has significantly improved documentation and examples, though Christopher points out that discoverability through the AWS console remains a challenge.

00:39:45 - Rome, Snowpack, and the Toolchain Future

Christopher presents his toolchain picks: Rome and Snowpack. Rome, created by Babel's original author Sebastian McKenzie, aims to replace the linter, compiler, and bundler in a single tool. Anthony notes that integrating Rome into an existing framework like Redwood would require a complete rewrite, but both agree the potential benefits are enormous. They then discuss Snowpack as a more immediately practical Webpack replacement.

Anthony connects Snowpack to the broader ES modules movement, explaining how native browser module support has enabled tools like Snowpack and Vite to eliminate traditional bundling. He notes that SvelteKit has already adopted Snowpack, replacing Rollup. Christopher emphasizes the long-running joke about Webpack configuration complexity and suggests that Snowpack's developer-friendly approach could yield significant performance gains if adopted by full-stack frameworks.

00:44:22 - Bootstrap 5, Svelte Frameworks, and 2021 Predictions

Christopher delivers his self-described hot take: Bootstrap 5, now free of its jQuery dependency and in beta, will challenge Tailwind's dominance among frontend developers. Anthony pushes back gently, arguing that Bootstrap never truly lost its crown despite Tailwind's popularity among trendsetters. The exchange captures the ongoing tension between established tools and newer alternatives in the CSS utility space.

Anthony closes with his picks from the Vue and Svelte ecosystems: Nuxt as a Vue meta-framework ripe for full-stack experimentation, and Elder.js as a high-performance Svelte static site generator capable of building thousands of pages per minute. He frames these three frameworks—Redwood for React, Nuxt for Vue, Elder for Svelte—as representing different layers of the framework spectrum. The episode wraps with the hosts thanking listeners, previewing upcoming guests, and encouraging referrals to grow the FSJam community in 2021.

Transcript

00:00:00 - Christopher Burns

Welcome back. Why did I say welcome?

00:00:04 - Anthony Campolo

End of the year. If there's any way to start the last episode of 2020, that might be the way.

00:00:20 - Christopher Burns

Welcome back to the FSJam podcast, recording on December 29th, just between me and Anthony today. We're going to be speaking about where we think JavaScript and FSJam frameworks are going to go in 2021. How are you, Anthony?

00:00:42 - Anthony Campolo

Doing great. Did you have a good holiday?

00:00:44 - Christopher Burns

Super. We don't really call it holidays over here. We just call it Christmas, and it's quite an American thing to say "happy holidays."

00:00:51 - Anthony Campolo

People will argue with you about that, but I'm cool with making it agnostic. I don't have a problem with it.

00:00:56 - Christopher Burns

So much has happened in 2020. We just released our roundtable episode, episode eight, with Brandon Byers, Chris Ball, and David Price talking about where we'd like to see certain things go in the year and reflecting on the current year. We brought up so many topics. One of the main ones that came up between the group was, "What is FSJam?" I've been thinking about this ever since we did that podcast. We left it really up in the air, but maybe we should almost define it in 2021.

One, full application database support. Two, generating commands and CLI support to help out. And three, I think we forgot, but it's so critical: auth included. One of the things we obviously brought up was, should Gatsby be here? Should Next be here? And one of the things I forgot about in that conversation is one of the best things about Blitz, Bison, and Redwood: they have auth packages that are ready to go. It's super easy to get a logged-in user.

[00:02:15] That's not quite there, and it's not quite as easy without using third-party solutions. So I definitely think that's one of the biggest points of what makes FSJam: database support, CLI generators, authentication, and CD. We mention acronyms a lot. If you didn't know what CD stood for, it's continuous deployment. When you upload to GitHub, it's automatically going to run all your tests, run the build, generate the code, and upload it to a live service.

00:02:51 - Anthony Campolo

To kind of break that term down, you also frequently hear it along with CI. CI/CD is something you'll frequently hear, with CI being continuous integration. I usually think of it as the deployment part is what actually gets it onto the website, and why something like Netlify or Vercel is really nice, because they're set up where you can push a change to your GitHub and that triggers the build. So to me, that is like continuous deployment because you're not actually deploying; just pushing your Git repo is what gets you to that step.

00:03:25 - Christopher Burns

Do you agree with the auth layer being an important part?

00:03:29 - Anthony Campolo

That's exactly what I was about to go into, because I was listening to a really great conversation, Software Sessions, which is a podcast by Jeremy Young, and he had Ryan Jenky on. We're talking to him about getting him on as well, and he is someone who's really specialized in auth. He used to work at Auth0, and even now that he's at Prisma, this is still a topic he's really interested in. It was so funny listening to their conversation because they were talking about how hard auth was and all the ways to do it, and how to set it up with third-party services.

Then they described their dream auth system, and what they were describing sounded exactly like what we do for auth in Redwood and Blitz: how we've got it set up in the library, how we're able to use hooks, and how those hooks are able to manage most of what we do. So I think what we're doing with auth is really on the forefront of how to integrate auth into a framework.

[00:04:20] And I'm glad that you want to highlight it as a key piece of FSJam, because I think it's something that other people are looking to and trying to find a solution for, and we potentially have one.

00:04:29 - Christopher Burns

I agree, and it's one of the things that you can so easily forget, but it's super important and it can take a lot of developer hours. Using a framework takes away all of that layer for you and says, "Use our standardized set of hooks and you're ready to go."

The next one: front-to-back database support. Right now our main method is Prisma 2. As we go forward, other options will start appearing. I think one of them will be more integrations into Fauna, maybe even through Prisma. With Mongo and Fauna, document database support may come along. That is also super important. A lot of developers waste time. It's not wasting, but it's, "Which ORM do I pick? Which database do I pick?" These are all things that you can pick an opinionated option for and never need to look at that ORM again.

I think that's roughly the five main pillars of FSJam and why Gatsby and Next don't quite fall into that right now.

00:05:45 - Anthony Campolo

Well, as Brandon was saying, they're not trying to be. And I think not categorizing them as FSJam should not be seen as a slight or as exclusionary. So much as we're defining the actual goals that these different projects have, and the ability to, as Brandon was saying, build on top of Gatsby and Next to enable FSJam projects is more so what we're going to see.

Some of the things I actually wanted to talk about today aren't going to be projects that I would consider FSJam projects, but I would consider them projects that could be used as pieces of FSJam projects. We've talked a lot about some interesting stuff that could be happening in Svelte or Nuxt. So I kind of want to dive into some of those projects that I've been learning about over the last couple of months, and where I see them in their development cycle. And also what you're talking about in terms of integration with the database and generators, there's also some stuff on the provider level that I think is coming up that could be really interesting in that area.

00:07:10 - Christopher Burns

Facebook released a proof of concept over Christmas that allowed components to be rendered by a server and sent to the frontend with zero runtime. Is that correct? I believe that's correct. I've not fully read into it or watched the tutorial.

00:07:30 - Anthony Campolo

It's a very experimental way to, as you say, render. Basically throw your components straight into the server and render them and even pull data straight out of the database. So it's really incredible for us to kind of see this at the end of the year, because it's very much validating all these full-stack ideas that we've been talking about the entire year. This is the only thing tech Twitter talked about for like a whole week, so it was a pretty big deal.

00:07:55 - Christopher Burns

Yes, we should explain it as simply as possible. I also think SSR is kind of this, you know, it's questionable. Is this SSR or not?

00:08:07 - Anthony Campolo

They're insisting it's not. They will insist very strongly that it is not. This is entirely different, and they have lots of good reasons for why that I don't yet understand.

00:08:14 - Christopher Burns

So let's explain what these concepts are as high level as possible. As you understand, React adds and retracts elements into a DOM tree. So that's adding divs, HTML, removing and adding them, and adding functionality to them in the most basic aspects. How that is done is using client JavaScript when the page gets loaded. JavaScript bundles start to get executed. And what comes with that is that it says, okay, now I need you to append all of this HTML DOM structure to the tree. It renders the HTML. That is client-side rendering, right, Anthony?

00:09:03 - Anthony Campolo

I was pulling up, because I know we were talking about this, so I'm pulling up the GitHub to the React Server Components so we can actually talk intelligently about it.

00:09:11 - Christopher Burns

That's fine. We're going to talk about SSR next.

So the client gets given a blank HTML document, and then the client JavaScript builds a whole HTML DOM structure. SSR: when you call a request, you're not actually calling an HTML file. You're actually calling a server endpoint that then builds a whole HTML document with the DOM structure already injected into it and then sent to your client. Is that right? I believe that's right.

00:09:53 - Anthony Campolo

Sounds right. Yeah. There's a really great RFC on this from the team that we'll link to in the very first. They have a super long FAQ section. The very first one is "Does this replace SSR?" So they call them React Server Components. They see them as complementary because they say that SSR is for non-interactive client components, but that you still have to pay the cost of downloading, parsing, and executing them after the initial HTML is loaded. But if you combine them, then the server components render first and the client components render into HTML while the components are getting hydrated. When you combine them, you get a fast startup while also reducing the amount of JS that needs to be downloaded.

00:10:43 - Christopher Burns

It's almost like part SSR. For example, your tree is half compiled by default. The server compiles the component, say your navbar, and then sends that fully compiled navbar to the client.

00:11:03 - Anthony Campolo

This to me makes sense because a lot of the stuff that Next has been talking about, and the type of work that all of this has been about, hasn't been about finding the correct way to render and where to render. It's about rendering where it's most effective for each individual place in the lifecycle. So this kind of finds the places where it's most optimized and splits the difference between a lot of those different areas.

Yeah, it's really interesting. And I definitely recommend checking out this FAQ section because then it also talks about how this relates to GraphQL, how this relates to things like Apollo and Relay, how it relates to things like service workers. There's a lot going on here.

00:11:46 - Christopher Burns

What about Suspense and Concurrent Mode?

00:11:50 - Anthony Campolo

So this is actually something that I do know a little bit about. This is possible because of Suspense and Concurrent Mode. So if you didn't have Suspense and Concurrent Mode enabled, you wouldn't be able to do this.

00:11:59 - Christopher Burns

Explain what they are first. I don't even know.

00:12:02 - Anthony Campolo

It's a way to make React asynchronous. So concurrent is like concurrency: having multiple things running at once. You can think of it like parallelization, even though it's not the same. It's basically multiple things happening at once in time. That's what concurrency is.

00:12:15 - Christopher Burns

Explain it in a use case. Why would I need parallelization of my UI?

00:12:21 - Anthony Campolo

Imagine you have a chart that is displaying a lot of data points and you're sliding over time. You want to increase the chart or shrink the chart because you want to see more data points or fewer data points. The more data points you have, each of those data points has to render individually, so all of those will be slowed down. So you want to render all the data points concurrently so that you could create your visualizations in a way that is smooth and doesn't have jank.

This is Dan Abramov's classic example. He has a talk that he gave like two years ago where he demonstrated this with a chart graph kind of thing. We'll link to that as well. It's so you can get a really smooth, buttery experience in your UI while you're doing a million things because we're computer hackers and we always want to have a billion things on our screen at all times. Think about 50 tabs versus two tabs. There's another good example.

00:13:11 - Christopher Burns

Does concurrency and Suspense come before this? If you wanted to enable this feature when it's potentially released, is it a rewrite or just add concurrency and Suspense?

00:13:26 - Anthony Campolo

If you look at the package.json of the example app, you can see that they're using what's called the experimental build of React. And so this is what you need to do to enable Concurrent Mode and Suspense. It's basically kind of like how most projects will have a Canary release or a next release. It's the same kind of idea. This is what a lot of Facebook has been running on for like over a year. It's what Blitz has been running on this whole time, because a lot of projects have been using Suspense and Concurrent Mode this entire year. It's like Redwood. People use something in production even though it's not considered in production, because people feel safe doing it because they understand it well enough.

It's work that has been done to enable things like server-side components. You can't have server-side components if you're not on the experimental build.

00:14:14 - Christopher Burns

Do I understand that Suspense is basically, in its simplest form, splitting up your bundle and then lazy loading when you need the bits?

00:14:24 - Anthony Campolo

So Suspense is another downstream effect of Concurrent Mode. Concurrent Mode is a whole rewrite to make React async, and then Suspense is, now that we have it working, we can use Suspense to be careful in terms of where we're reloading our DOM.

So like you said, it's about splitting up your bundle and lazy loading, and also about being more intelligent about when things have been loaded so that you don't have a flash of loading screen for a quick amount of milliseconds. So it's partly about having a nicer, smoother experience and being more aware of what's being loaded and how long it's going to take to load.

00:15:02 - Christopher Burns

So does this mean I'm going to be writing more JavaScript to write less JavaScript?

00:15:09 - Anthony Campolo

Yes, exactly. The point is that you're going to be able to rewrite your React components in a way that allows you to take out a lot of conditional logic of figuring out what's happening with all the loading. That's why this is really interesting for something like cells, because this is in the same kind of area of data fetching and how all this data fetching stuff works.

00:15:29 - Christopher Burns

Let's take the most simple example of a component in React. When I'm logged in, it says "Hi, Chris," and when I'm logged out it says, "Please log in. Click the button to log in." That's two different states. So we're saying when server components come out, what that's going to do is use your code to work out if they're logged in or not, and then just give the built component.

00:16:00 - Anthony Campolo

I'm not sure how it's going to interact with auth and that sort of stuff because this is more about loading data and data fetching. The auth layer is, I think, a separate component from this. So that's why that wouldn't be an example that I would go to. It'd be more like if you're loading your blog posts, you'll be able to specify bringing in the blog posts as separate from your outer UI.

When your blog posts are loading, you'd have those inside your kind of async components. So think about your component tree and think about your cell that's loading your blog posts. You would just put inside tags that would allow them to become suspended. That's all you have to do. You're just adding tags around the things that you want to make async. Those become enabled to then do all the async stuff, and they'll be able to tell whether the data has been loaded or not. It will basically handle when to show the loading spinners and things like that, much like how a cell does.

[00:16:59] So this is solving a lot of the same issues that cells do, but it's doing it within React without having to build a framework to handle those things.

00:17:07 - Christopher Burns

I think I got it.

00:17:08 - Anthony Campolo

That explanation will only make sense to probably Redwood people, because I'm using all the cell terminology to explain it, but it's the best I got.

00:17:15 - Christopher Burns

I think right now React is thinking three steps ahead. They've put an RFC out for three steps ahead from where most developers are. How many developers have Concurrent Mode and Suspense in production? Do any Redwood apps have it? I don't think so.

00:17:35 - Anthony Campolo

Well, that's the thing, though. Because of how your cell is architected, Redwood has solved a lot of the problems that Suspense was going to. So this is something I've been thinking about all year and always wondering, when Suspense gets here, how we're going to deal with all of this in Redwood. So we get to find out soon.

00:18:16 - Christopher Burns

Soon. 2021, the Year of Suspense.

00:18:19 - Anthony Campolo

Yep.

00:18:20 - Christopher Burns

Little pun.

00:18:20 - Anthony Campolo

First one to make it, I'm sure.

00:18:22 - Christopher Burns

Yeah.

00:18:23 - Christopher Burns

Something me and Anthony did want to talk about is technologies that we're interested in that we could see in 2021 that are not necessarily just about FSJam. The first technology: portals. Have you heard about portals?

00:18:41 - Anthony Campolo

I do not, but I do know how to think in portals.

00:18:44 - Christopher Burns

Google Chrome Portals, it's called. It's the only one with the code right now.

00:18:49 - Anthony Campolo

Seamless navigation on the web.

00:18:52 - Christopher Burns

But isn't that what it's going to be compared to? It's a new kind of iframe, basically.

00:19:00 - Anthony Campolo

That's the worst sales pitch I've ever heard right there.

00:19:03 - Christopher Burns

Okay, let me explain it. It is like iframes. iFrames are the closest technology that you could refer to.

00:19:11 - Anthony Campolo

That's what the main blog post says. It says think of them like an iframe. They allow for embedding, but unlike an iframe, they come with features to navigate to their content.

00:19:20 - Christopher Burns

Exactly. I'm going to put it in the simplest explanation for you. You're on a blog and you click, "I want to share to Facebook." As soon as you click open, you're going to open a portal. The portal is then going to open Facebook over the page you're currently on in your browser. Then it says, "I've navigated to Facebook." Now you then share it and then the portal gets closed, leaving you back on the page you were on. Technically, you never navigated away from that page, but you did. You navigated through a portal to Facebook and then back away from Facebook.

00:20:07 - Anthony Campolo

Jake Archibald, yeah, I know Jake Archibald. He's a Google Developer Expert. He's a great advocate.

00:20:13 - Christopher Burns

He currently did the talk about this. I see great uses for this in Everfund. Most developers can click their hands together and understand it. How many times do you need to run someone else's UI code on your website? For example, PayPal. PayPal opens a box. You click login through the box, the box closes. That can all be replaced with portals.

00:20:42 - Anthony Campolo

So it will be really useful to integrate with something like OAuth. That's kind of what it sounds like.

00:20:46 - Christopher Burns

Yes, or to have the shareability functionality. One of the things we want to do with Everfund is build a suite of tools that allow you to integrate your current website into Everfund. You would get one of our donation portals. Right now you would download our JavaScript script, add it to the page, add it to the DOM, and then the JavaScript executes when you click that DOM button. But if we had a portal, you could just say, navigate to this portal, allow the user to donate, and then close the portal in hopefully five lines of code. That's very universal.

Portals are currently behind a flag in Chrome, but they've been developing it since 2018, so maybe 2021 will be the year we will get portals.

00:21:49 - Anthony Campolo

Sounds like it's a really low-level primitive in the sense that what you're describing sounds super general and like it could be used for a lot of stuff. I'm still trying to wrap my mind around it.

00:22:01 - Christopher Burns

Think of how you would create an iframe and you replace iframe src with portal src.

00:22:08 - Anthony Campolo

I don't create iframes.

00:22:10 - Christopher Burns

Exactly, but a lot of people do. I use them in my business. Every single auth provider you use uses iframes to navigate and keep auth states. Stripe does it. Portals can be navigated to and from, so you can navigate into the portal and then out of the portal. An iframe cannot. You're literally looking through the iframe box. Everybody hates iframes, but nobody wants to see what iframes can become, and that's kind of what portals are. It's like the next generation of iframes.

00:22:51 - Anthony Campolo

Yeah, iframes is one of those things. I got a whole list of these as things that you run into all the time that are super important, and that no boot camp or video tutorial I've ever seen has ever felt the need to teach. It's really weird. Iframes are completely absent from the curriculum.

00:23:08 - Christopher Burns

Super hard thing is communication between an iframe and the web page. For example, you have to do it through the window's proxy of the browser API. Portals use post messages only, so it's super straightforward. I'm hoping 2021 will be the year for mass support. What's next?

00:23:31 - Anthony Campolo

I talked about this briefly on an episode that I now realize has not aired yet. When we talked to Jason from Prisma, I asked him about AWS AppSync. I'm really interested in AWS AppSync. It's a managed API gateway for GraphQL APIs. It's something that sits in the middle between a lot of your different services at AWS. So if you were to build something and you have your functions using AWS Lambda and you've got a database which is DynamoDB, you could use AppSync to be the thing that glues those together.

So when you go to your UI and you create a blog post, it is using a GraphQL schema that is being created by AppSync. And then that schema is what's used for your functions to then save to your database.

I find it interesting because it's the only thing that I look at and I very clearly see the Redwood architecture reflected in it to me, because everyone compares Redwood and Blitz, and we've spent the whole year kind of talking about how they're actually super different.

[00:24:41] But to me, when I look at the types of things people like Nader or Dabit are building with AWS AppSync and Lambdas and things like that, it looks almost identical to Redwood. So that's what makes it really interesting to me. I have a lot of respect for Nader, and this also goes along with the entire Amplify suite of tools, which is a CLI that allows you to create basically this architecture that I'm talking about in a way that allows you to generate a lot of stuff as if you're using, say, the Redwood CLI. So I think what you add in the Amplify CLI mirrors a lot of the CLI functionality you get from Redwood, and then the AppSync GraphQL layer is very similar to the Redwood API.

Yeah, this is something that I've already been digging into a little bit and started building out little proof-of-concepts, and I'm going to be doing at least two talks about this in January.

00:25:29 - Christopher Burns

Just so I understand, AppSync and Amplify?

00:25:33 - Anthony Campolo

Yeah. So AppSync is GraphQL API. It's the more lower-level building block, and then Amplify is a larger suite of tools that combines a lot of stuff with AppSync.

00:25:44 - Christopher Burns

Just like you have Google Cloud and Google saying, "You don't like Google Cloud? Well, Firebase is everything specifically designed in certain ways so that you don't know it's Google Cloud." Amplify is basically saying, "You don't like the AWS dashboard? We'll do all that bit for you."

00:26:03 - Anthony Campolo

This is a really interesting comparison because you're partly right. The connection here is this all came out of mobile: Firebase and the Amplify/AppSync. These were all the backends that mobile developers were using. This is your whole React Native mobile people taking over the world thesis partly coming into play here, that this is all the mobile infrastructure that is now eating into web.

00:26:51 - Christopher Burns

It's a big area. AWS can be super scary. If something can sit on top of AWS, like, I guess, Amplify, I could be behind that. I don't want to use AWS where I don't need to.

00:27:06 - Anthony Campolo

As for my second pick, we'll get to that one after you do another one.

00:27:09 - Christopher Burns

I'm sure we'll get into my next pick. The classic React Native for Web. React Native for Web has been plodding along in the background, slightly behind React. What it's focused on is bringing all the lessons from React Native to the web. React is DOM-based, but React Native for Web is... there's a term.

00:27:39 - Anthony Campolo

I usually hear "view-based" because you have a View tag, right?

00:27:42 - Christopher Burns

View-based, yeah, that's it. You don't use DOMs; you use views and you embed views into each other.

00:27:48 - Anthony Campolo

For anyone who hasn't seen it, just a tag that says View inside of it.

00:27:52 - Christopher Burns

Yes.

00:27:52 - Christopher Burns

You build the interfaces slightly differently. React Native still uses JSX, but instead of using core HTML abstractions like the DOM, you use specific React Native abstractions like View and Text.

00:28:11 - Anthony Campolo

Do you use iframes?

00:28:12 - Christopher Burns

No.

00:28:13 - Christopher Burns

Well, you can. But the abstractions React Native has made make you think less about your DOM structure and more about your view structure. You think about your application like a tree, as in your DOM tree. You've got your nav bar at the top and then it trickles down. When you think more about a React Native application, you're thinking on a view basis. You've got your tab bar, you've got your top bar, and how they combine. Two different ways of looking at technically the same stuff: React and React Native.

There's so much work going on right now that's very secretive because it's not hit mass adoption yet. React Native for Windows. Microsoft started React Native for Windows, a Windows-based application that would run on 365, UW, Xbox, Windows Mobile. Then they also extended that to React Native for Windows plus macOS, React Native code, JavaScript controlling native modules. The dream. If you could say the one thing I could just have over everything else.

00:29:36 - Anthony Campolo

Write once, run anywhere. Write.

00:29:38 - Christopher Burns

Write once, run anywhere. Write React Native and that would run compiled native Mac app, compiled native Windows app, compiled web app, compiled native iOS app, and compiled native Android app. You would be surprised how close you can get to that today using Expo. Not many people know what Expo is, but it's a service that sits on top of React Native.

00:30:08 - Anthony Campolo

Anyone who knows anything about mobile development knows who Expo is.

00:30:11 - Christopher Burns

Yeah, but nobody knows about them in the React ecosystem. They use React Native for Web. I think it's backed by, I'm going to say, Kevin Bacon.

00:30:25 - Anthony Campolo

It's Evan Bacon, but that's hilarious. Everyone makes the Kevin Bacon jokes to him all the time.

00:30:30 - Christopher Burns

I thought it was Kevin or Evan, but I was just going to go with Kevin. I would love to see an FSJam framework adopt something like Expo when they hit their native side. The dream of write once in terms of a client and run anywhere is completely possible as soon as someone like Redwood would adopt something like Expo.

00:30:57 - Anthony Campolo

Yeah. You asked Brandon about it, if it would support React Native or Expo, and his response is ideally it would support both. So he's got Expo on his brain.

00:31:06 - Christopher Burns

It's almost this thing: if you support React Native Expo, you support React Native.

00:31:12 - Anthony Campolo

It's like you can't support Next without supporting React.

00:31:15 - Anthony Campolo

Yeah.

00:31:15 - Christopher Burns

In all essence, Expo is Create React App. You can eject out of Expo and then it will compile your app down to pure React Native. They're just a wrapper that sits on top and do a lot of abstractions for you.

00:31:29 - Anthony Campolo

The way that Evan has described it in his podcast that I've listened to is that they're doing a lot of the really complicated APIs with mobile things that you don't necessarily have in just a browser.

00:31:41 - Christopher Burns

You looked into it.

00:31:42 - Anthony Campolo

This is a podcast I listened to back in, like, April, and I just relistened to recently. Yeah, dude, I'm aware of everything. Listen, all these podcasts, that's just how I get my awareness of what's happening in the scene. And that's why the stuff you're always into and nerding out about is stuff I've heard about. I just haven't dove into it yet because I had to actually learn web first.

00:32:00 - Christopher Burns

I've not dove into it.

00:32:01 - Anthony Campolo

Well, next year I want to spend some time on mobile for sure, especially as it starts to bleed into some of these projects.

00:32:08 - Christopher Burns

If Redwood supports Expo when they do their React Native side, we're going to see it. We are going to see it, and it's going to be glorious.

00:32:19 - Anthony Campolo

That's what everyone says about their Tower of Babel.

00:32:21 - Christopher Burns

Don't even ask me what Babel does. Just too much.

00:32:25 - Anthony Campolo

It depends. Do you know what an AST is? Because that's going to depend on whether it's going to take you a day or a year to understand Babel.

00:32:32 - Christopher Burns

I roughly know what AST is. I've got what the words are now.

00:32:37 - Anthony Campolo

Abstract syntax tree.

00:32:39 - Christopher Burns

That's it.

00:32:40 - Anthony Campolo

Yeah. It's the way that your program understands the grammar of your language. If you think of when you have a sentence and it has verbs and nouns, you can create a tree that shows you where the verbs and nouns are and how the nouns relate to the verbs and all that goodness.

Let's move on to our next thing. So you're talking about how you want to do all this AWS stuff. You don't like the AWS console? This is, to me, the whole reason for these, what we call layer two clouds, which has traditionally been things like Netlify or Vercel. And we spent a decent amount of time talking about Render. Now one that I'm really interested in is Begin. Begin is from Brian LeRoux, who, funny enough, actually was the PhoneGap guy and Cordova, or the Cordova guy which used PhoneGap, which we don't need to talk about because he doesn't like it when people talk about it and talk crap about it.

00:34:00 - Christopher Burns

When I did university, one of my modules was PhoneGap or Cordova. I think it was Cordova.

00:34:09 - Anthony Campolo

Yeah. It's confusing.

00:34:10 - Christopher Burns

I literally said, "React Native is stable. Facebook uses it. Teach us React Native." And they went, "I can't do that in Dreamweaver."

00:34:23 - Anthony Campolo

I learned Dreamweaver in like 2007 when I took a web design class in high school.

00:34:28 - Christopher Burns

This was in, like, 2016 when I went to university, somewhere around there.

00:34:36 - Anthony Campolo

That's funny. Anyway, so he was also big into Node. So what Begin is, Begin is built on top of a framework called Architect, which is a bit like the Serverless Framework. Actually, it's like the Serverless Framework or it's like SAM, the Serverless Application Model. All of these things are just CloudFormation. It's a really easy way to write CloudFormation and to have a simple syntax that compiles down to CloudFormation.

If you don't know what CloudFormation is, CloudFormation is a way to define your AWS stack. Going back to what you're talking about, you can have DynamoDB, you can have your Lambdas, you can have an S3 bucket, you can have an EC2 server. You can have all this stuff, and you can have it all wired up. CloudFormation is a way to define that architecture in code. That's why they call it infrastructure as code. If you've ever heard of Terraform, Terraform is another kind of version of this.

Begin, to me, sits at this middle ground between all of these things: the infrastructure as code and the AWS services and the frontend developers being us who want to use this stuff and want to have an easy interface. You can deploy an entire project, a full-stack project, on Begin in 10 seconds.

[00:35:47] It is literally the simplest way to deploy anything I've ever seen in terms of the power it gets you. But that then comes along with the opinionatedness of what you're getting. He is a firm believer that there's only eight services you need in AWS, and that you can build your entire stack with just those eight services.

Basically DynamoDB, Lambda, API Gateway, and then you have your eventing, SQS and SNS, which are for your events, and then CloudWatch and then CloudFront. Yeah, I almost got all of them. EventBridge, possibly, and then maybe Step Functions.

But yeah. Anyway, the point being that it's giving you the ultimate opinionated AWS stack, which to me is just really interesting because I see it as the Redwood for AWS, because Redwood was this whole idea of how do we pick all these best-of-breed solutions from the React ecosystem and package them and integrate them all together? It was about curation, it was about integration. And to me, that is what I see Begin doing.

[00:36:51] So I want to figure out how to get Redwood deployed to Begin with a single click. That is my goal for 2021.

00:36:58 - Christopher Burns

I'm a hypocrite with this. I don't like AWS. I don't really like the concept of Amazon.

00:37:06 - Anthony Campolo

You know, like that every product in the world is now easier to get and cheaper?

00:37:10 - Christopher Burns

Not necessarily. But for example, when you build a service, say you build magic links that uses Cognito underneath it. That's using a service that uses AWS. I'm cool with that. But me personally, using AWS, it just makes me feel icky. I prefer to support someone smaller in the chain.

00:37:34 - Anthony Campolo

That's like the exact reason why you would support a company like Begin.

00:37:37 - Christopher Burns

Exactly. At the end of the day, AWS is great. It does everything, but it kind of loses a level of support, a level of care. What turns me off of AWS? You can just log in and do anything, but it doesn't really teach you. It doesn't really make it easy.

00:37:56 - Anthony Campolo

To me, the way I think about it, I think of it like a utility, like I think of it like it's power coming out of my wall. So yeah, you're right, it's extremely impersonal in that respect. I wouldn't expect to be able to call my power company and have a long conversation with them.

00:38:09 - Christopher Burns

So I know how to plug in a plug.

00:38:13 - Anthony Campolo

Yeah, exactly. I think that's totally true. And I think that's where the value of services like Begin comes in, because they simplify it. They give you really quick ways to get spun up, and they allow you to leverage these really powerful utilities in a way where you don't have to figure out how you would wire your own power in your house, kind of thing.

00:38:32 - Christopher Burns

Exactly. I don't have a problem with using AWS through a third-party service. I know loads of services that I use that use AWS. I just don't like that it doesn't handhold you to a certain extent. Google Cloud is the same.

00:38:48 - Anthony Campolo

I would say that this is where things like Amplify and AppSync, their docs are really good. Their examples are really fantastic. Nader Dabit and Swyx and Ali Spittel and there's a fourth person on the team now are the best dev advocacy team in the industry right now. They've done a lot of really great work on docs and stuff. So they recognize it. And there are pockets of AWS that are working on it.

00:39:12 - Christopher Burns

But do you navigate to Amplify through AWS?

00:39:17 - Anthony Campolo

It depends. You can use everything on the CLI and do everything through your code editor if you want to. You don't have to use any of their GUIs.

00:39:45 - Christopher Burns

My next technology. This is a doozy. It's two for the price of one, and this is more toolchain. One is Rome and two is Snowpack.

00:39:58 - Anthony Campolo

Great picks. I would pick those myself if I thought of them. Rome is the uber tool. It's meant to replace your linter and your compiler.

00:40:08 - Christopher Burns

And bundler.

00:40:09 - Anthony Campolo

And bundler. I'm sure it does minification. And it's by Sebastian McKenzie, who, as some people may know, was the original creator of Babel. So that's what I find to be pretty interesting, is that it kind of has this Deno-like story where it's like this creator who created this epic thing back in the day that has essentially become a standard, and then he's like, "Hey, I want to do it better."

00:40:32 - Christopher Burns

The reason I'm really interested in Rome is the trickle-down effect. When someone like Redwood or Blitz or Bison uses it, you don't have to integrate it yourself. I can't wait. It seems incredible.

00:40:47 - Anthony Campolo

Just the idea of how Redwood would have to. Redwood would have to do a complete rewrite to bring in Rome. It would require an entire rewrite of Redwood to get Rome integrated in the way that it would be useful. So, yeah, we'll see about that.

00:41:01 - Christopher Burns

But how much would it bring, you know?

00:41:03 - Anthony Campolo

No, I mean, I've thought about this too. I've definitely thought about this too. And it's just like, yeah, we'll see in a year if we have the bandwidth to entirely rewrite Redwood. We'll see.

00:41:14 - Christopher Burns

On the other hand, something smaller, but you could say almost as powerful in certain areas, is Snowpack. Snowpack's one job is to replace Webpack. What do you think of this?

00:41:28 - Anthony Campolo

It's already being used by SvelteKit. SvelteKit is the kind of new Svelte meta-framework that the whole team is working on, and they have taken Rollup out, which was what Svelte was using before, Rollup being created by Rich Harris, the creator of Svelte. And they have moved into Snowpack and this whole kind of no-bundling thing. And we should talk about ES modules and why this is all possible.

This is all possible because JavaScript finally has a native module system, which took many, many years and is incompatible with Node and has been this huge headache. And so now you have tools like Vite.

00:42:06 - Christopher Burns

As high level as possible. It's the deep issue.

00:42:09 - Anthony Campolo

Yeah. Now that we've slowly gotten everyone over to ES modules, at least in terms of modern browsers, evergreen browsers, I think you're good up to like IE11, which is like 3% of the internet. So it's at the point now where if you're cool supporting 97% of the internet, you can use ES modules. Basically, you can just do your import at the top of your page and you can import from URLs. My old-school developers are like, "You mean you can put a script tag in?"

00:42:37 - Christopher Burns

Yeah, it's literally full circle. Put the jQuery in your HTML DOM. You want Popper for Bootstrap? Stick that in your DOM as well. You want the Bootstrap script? Stick that in your DOM.

Snowpack would be really exciting for me as well if a framework was to integrate it. How much integration could they save? Something like Snowpack could be a lot easier for something like Redwood to integrate, because it's just the bundler at the end of the day, not the compiler. The Babel tower, as you said, 100%.

00:43:16 - Anthony Campolo

Yeah. Starting off with a thing like Snowpack, that would be a much more reasonable, piecemeal thing if we wanted to add in some sort of new tech to Redwood.

00:43:24 - Christopher Burns

The biggest benefits of Snowpack are when it's done for you, and it does a lot of it for you. For example, configuration of Webpack has been a running joke in the industry now for how many years? It's not changing, and that's life. Snowpack is really easy. It goes, "We'll just work a lot of it out for you. TypeScript, JavaScript, it doesn't matter to us. We'll work it out."

It's the trickle-down effect. If Redwood or Blitz or Bison were to implement that just by removing Webpack and replacing it with Snowpack, how much code speed and efficiency could be gained? I don't know, but from what I read on Snowpack, they seem to think that you can save a lot.

00:44:13 - Anthony Campolo

This will be a really good topic to ask Peter about, because Peter is low-level enough into the Redwood codebase that he would actually probably be able to give pretty good answers to these questions.

00:44:22 - Christopher Burns

This is going to be my ultra-small, ultra-maybe technology that I'm interested to see where it goes in 2021. Get ready.

00:44:32 - Anthony Campolo

Bootstrap 5 is already here, isn't it?

00:44:36 - Christopher Burns

It's not. It's beta. It's in beta. I love Tailwind, but sometimes I'd rather just write btn than 20 tags. No offense to Tailwind. I'm interested to see where it goes. Now it no longer relies on jQuery.

00:44:53 - Anthony Campolo

Something I saw throughout the course of the year: Brad Traversy, one of the YouTube channels I follow. He's a long-time Bootstrap developer, so he kind of keeps up on those and he'll put out some new videos as Bootstrap 5 has been coming out. That's funny. It's pretty rare that someone will say, "I'm excited for Bootstrap next year." But you're right, it's a great utility and it's something that served many web developers very well for a long time. And I'm not into the whole Bootstrap bashing thing.

00:45:19 - Christopher Burns

We're going to see it. It's going to be the Goliath. Bootstrap is going to try and take its crown back from Tailwind. I'm calling it now.

00:45:45 - Anthony Campolo

That's a good hot take. That's the kind of hot takes I like this podcast to have.

00:45:50 - Christopher Burns

I'm feeling it. I'm interested in Bootstrap 5, but we have to see where it goes.

00:45:55 - Anthony Campolo

Yeah, we'll see.

00:45:56 - Anthony Campolo

All right, so for my last picks I'm going to take a page out of the Svelte and Vue worlds. This is something that we've danced around a little bit throughout the course of the show. I've really tried to invest some time into learning some of these projects. I gave a talk about both of these.

For Vue you have Nuxt, which if you're familiar with Next in React, you will be able to wrap your mind around Nuxt pretty quickly. It provides a lot of the same benefits in terms of structuring your Vue apps with pages and server-side rendering and all the niceties that you get from a thing like Next.

We have seen really incredible projects like Blitz and Bison built on top of Next. So I'm curious to see what sort of things people are going to be building on top of Nuxt. And if no one does it, I might mess around with it myself just to kind of see how far I get. I probably won't get very far, but it'll be fun to try.

[00:46:49] I've already got a repo called Blitz.js, so the other one would be Elder. Elder.js is a really fascinating Svelte project. It's a static site generator that can build 18,000 pages in a minute. So it's about how do you build a ton of pages really, really fast and then also have those pages be optimized for SEO because the creator, Nick Rice, was building a website for finding information about elderly care homes called Elder Guide. So that's why it's called Elder.js, and the docs are actually on the website, so it's pretty interesting.

I'm really into Svelte, and I just like static site generators in general. I think they're super cool tools and I really like blogging. This is a popular refrain from Swyx: Svelte is for sites, React is for apps. Redwood, in many ways, has encapsulated that idea of using React to build apps and really leaning into that. I am trying to figure out how to use these tools in the proper way. So to me, as someone who just wants a static site generator that can build a blog, Elder seems like a really good tool for that.

[00:47:58] That's also kind of cutting edge.

00:48:00 - Christopher Burns

I've still not looked into Svelte, but I hear it's good. The grass is greener on the other side effect. Everyone tells me you do. It's awesome, and it doesn't work with Redwood, so it's a no.

00:48:19 - Anthony Campolo

I do feel like you have to specialize and you have to, obviously, pick a tool to build something with, but you can still compartmentalize in the sense of you can spend a half hour or an hour a week reading about this other thing or building out a proof of concept with it on the side. So for me, I always have probably three or four projects that I'm building simultaneously, and I give each of them a couple hours each week. And then that allows me to continuously build in these different ecosystems and continue to learn with them. And that's why I picked a framework in each: you've got Redwood for React, Nuxt for Vue, and then Elder for Svelte. And I also think of those as being the different layers of frameworks: the static site generator being the simplest layer, then the server-side rendering being the next layer, and then the full stack with the database being the final layer.

[00:49:07] And then to me it also mirrors where they are in their development, because React has been around the longest, and then Vue, and then Svelte. So yeah, you can tell I'm a nerd.

00:49:15 - Christopher Burns

Do you still believe my hot take about Bootstrap 5?

00:49:20 - Anthony Campolo

I don't think Tailwind ever overtook Bootstrap. I think Bootstrap has been the king and continues to be the king.

00:49:26 - Christopher Burns

But the hipsters, the hipsters love it. And we do too.

00:49:31 - Anthony Campolo

So we're the Redwood users. We're the biggest hipsters there are here.

00:49:36 - Christopher Burns

I'm just looking at it and just like, why did I stop using Bootstrap? And then I remembered that it's super clunky, but then Bootstrap 5 looks pretty good. It's in beta right now. If you didn't know, their first beta, I'm sure we'll see the production version by the end of 2021.

00:49:56 - Anthony Campolo

All right, everyone, well, thanks for listening. Thanks for being with us for 2020. It's been a blast. We're really looking forward to 2021. We got lots of great guests coming up next month. We got Jason, Kurt, we got Britt, and we got Kim Adeline.

00:50:12 - Christopher Burns

Thank you everyone for coming on this journey with us. If you want to give us any feedback, there's multiple ways to do it. The first one is joining our Discord. The link is in the description of the podcast. The other one is Twitter, FSJamOrg. The final one that I'm trying to keep up to date, but I'm struggling, is Instagram, FSJamOrg. Or finally, if you really want to help us, review our podcast on your platform of choice. Tell us what you think. The other way that you can help FSJam grow in 2021: recommend it to a friend. The most powerful marketing channel is the referral marketing channel. If you recommend FSJam to one or two people, one of them will implement it and refer it to a friend and it will overtake Next before long in the prominent full-stack Jamstack application. That's it.

00:51:13 - Anthony Campolo

And then you can tell your friends you're a thoughtful influencer.

00:51:16 - Christopher Burns

Thoughtful answer. I might have to add that to my Twitter description, but.

00:51:22 - Anthony Campolo

It is my Twitter description. That's exactly my Twitter description: FSJam. Thoughtful answer.

00:51:27 - Christopher Burns

Wow. What does that even mean?

00:51:29 - Anthony Campolo

It's a thought leader and an influencer.

00:51:32 - Christopher Burns

Right. Final thing I would just like to say: this podcast has been growing. There's two people that have been instrumental to the growth. Anthony, who has been doing all of the editing throughout the first year and also guest management. So thankful to Anthony and also myself for organizing it, coining the term, and getting us rolling. But this wouldn't have been possible without you guys listening to us. So thank you. Good luck with 2021 and, if possible, launch with an FSJam framework.

00:52:13 - Anthony Campolo

We'll catch you guys next time.

00:52:18 - Outro

[inaudible singing]

00:54:11 - Outro

[inaudible singing]

00:55:08 - Anthony Campolo

It's what's called a dapp, a decentralized app, instead of a cryptocurrency. That's the whole point of Ethereum. You can pay to use it as a programmable computer. So it's still cryptocurrency because you're still paying to use the computer, but you're using it to build an app. Web3. Yes, exactly. I got very into this stuff back in, like, 2017, actually, so I'm pretty well versed in all of it. You can buy in and actually believe in the value prop, and that it's going to go up over time. And that's not just something that you want to trade for volatility. I think the people who are really into this actually think it's going to be the future currency. So they want to buy and hold essentially forever because they think they're just not going to need money.

You can still use the chains as your login because blockchain is also this... there's this big push to use it for identity. It's basically like people want to run the whole society on blockchain, is what people want to do.