Widgets

Episode Description

Chris and Anthony explore the challenges of building and distributing third-party JavaScript scripts, then discuss documentation strategies and podcast direction.

Episode Summary

This episode takes a different format as Chris and Anthony dive into the often-undocumented world of building third-party JavaScript scripts, drawing from Chris's hands-on experience creating a script for Everfound. The conversation traces the journey from writing and bundling code to distributing it across different platforms, revealing surprising complexity at every step. They unpack the differences between module formats like CommonJS, ESM, and UMD, explaining why UMD remains necessary despite being largely unmaintained since 2017, and debate the tradeoffs of browser compatibility versus script size. The discussion moves into deployment strategies, comparing iframe-based injection versus building directly into a website's DOM, each with its own implications for CORS, CSS customization, and developer experience. A particularly illustrative struggle involved getting Everfound's donation widget to work reliably on WordPress, where identical sites behaved differently for mysterious reasons. The episode then shifts to documentation, where Anthony outlines a four-category system of tutorials, explanations, references, and how-to guides, before both hosts reflect on the podcast's future direction, including plans for sponsorships and more duo episodes exploring technical topics together.

Chapters

00:00:00 - Introduction to Third-Party Scripts

Chris sets the stage for a deep dive into the world of third-party JavaScript scripts, explaining that this is a subject area he's been working through while building Everfound's script. He describes the common scenario where websites load external scripts like Google Analytics, Fathom, or Intercom, and notes that the process of creating these scripts is surprisingly undocumented.

Anthony admits this is largely a black box to him, having only ever used plug-and-play integrations on his blog. Chris points out that because scripts are hosted externally and served as bundled files, they don't need to be open source, which adds to the mystery. This sets up the core question driving the episode: how do you actually build a script that runs on someone else's website?

00:02:41 - Bundling, Module Formats, and UMD

Chris explains the practical first steps of building a script, starting with a micro bundler that outputs JavaScript in various module formats. The conversation turns to the landscape of JavaScript module systems—CommonJS, AMD, ESM, and UMD—with Anthony providing historical context on how each emerged. They discuss why UMD, despite its repository being untouched since 2017, remains essential for scripts that need to load via traditional script tags on any website.

Chris shares his frustration that CommonJS modules simply error out when loaded via script injection, making UMD the necessary fallback. They debate ESM's 93% browser support and the business implications of dropping older formats, using Intercom as an example of a product that cannot afford to fail on any percentage of websites. The conversation highlights how polyfills add bloat and there are no easy answers for broad compatibility.

00:08:39 - Tooling Struggles and Distribution Strategies

Chris reveals the practical tooling headaches he encountered, including Micro Bundler failing to produce valid UMD output, which forced him to use Rollup specifically for UMD files while keeping Micro Bundler for CommonJS and ESM. He explains Everfound's need for a WordPress plugin and the challenges of making scripts work reliably across that ecosystem.

The discussion shifts to distribution methods: hosting scripts privately on cached S3 buckets as companies like Intercom do, versus using npm CDNs like Unpkg. They explore the tradeoffs between npm installing a package into a project versus loading it from a CDN, noting that the npm approach yields smaller bundles since it uses CommonJS rather than UMD. Anthony raises the question of why you can't just copy-paste the code directly, leading to a broader conversation about developer experience and the many paths to the same functionality.

00:13:24 - Framework Integration and Iframe vs DOM Injection

Chris explains how integrating scripts into different frameworks varies dramatically. React requires a dedicated SDK with virtual DOM considerations, resulting in a much larger package than the core JavaScript SDK, while frameworks like Vue and Svelte work almost like plain HTML. The conversation then tackles a fundamental architectural choice: whether to build UI elements directly into the host page's DOM or load them via iframes.

Each approach has significant tradeoffs. Iframes avoid CORS issues and keep the script bundle small since the actual UI lives on a separate hosted page, and updates don't require pushing new script versions. However, iframes prevent users from customizing CSS. Building into the DOM allows customization but introduces CORS complications and requires more JavaScript in the bundle. Chris notes that no matter which path you choose, providing a polished experience remains genuinely difficult.

00:17:33 - Why No Standard Solution Exists

Anthony asks why no startup has tried to solve the script-building problem holistically. Chris suggests it falls somewhere between web standards territory and the challenge of finding a correct abstraction, referencing a recent guest who is building a language that compiles to multiple frameworks. They agree that perhaps a well-maintained open-source starter template on GitHub would serve the community better than a SaaS product.

Chris then outlines Everfound's roadmap, explaining the move from a simple iframe-based donation widget to a headless donation system with a full SDK. This involves extending class functions to handle REST calls and giving developers the ability to build custom UIs on top of Everfound's core functionality. He recommends Everfound's open-source JavaScript SDK as a starting point for anyone wanting to learn script development, sharing the WordPress debugging story as a cautionary tale.

00:21:42 - Documentation Deep Dive

The conversation pivots to documentation, with Chris asking how you properly document an SDK after building one. Anthony introduces the four-category documentation system: references for pure API information, explanations for prose-based conceptual content, how-to guides for specific tasks, and tutorials for guided learning experiences. He uses Redwood's documentation as an example of the tutorial approach.

Chris shares Everfound's documentation journey, having tried Docusaurus, a custom solution, and ultimately settling on Readme.io for its ability to present REST API documentation alongside regular docs. Both agree that Stripe represents the gold standard of documentation but acknowledge the significant investment required to reach that level. The segment underscores that documentation is its own complex discipline, not an afterthought.

00:25:13 - Podcast Direction, Sponsorships, and Advocacy Ethics

Chris and Anthony shift to discussing the podcast's future, including their upcoming trip to Remix Conference in Utah. Anthony expresses enthusiasm for more duo episodes without guests, suggesting a cadence of roughly once every other month to balance personal discussions with guest exposure.

Anthony then addresses the topic of sponsorships, explaining that they're considering ads for the first time to make the podcast more sustainable given the hours invested each week. Chris raises a thoughtful question about developer advocacy and whether guest episodes risk becoming product pitches. Anthony pushes back, emphasizing responsible advocacy and the distinction between helping listeners understand a product versus pressuring them to adopt it. The episode closes with this open reflection on balancing authenticity with the realities of running a podcast.

Transcript

00:00:10 - Christopher Burns

Today is going to be a slightly different episode. I've been, you could say, noodling away on a lot of things in the background on Everfound. One of these subject areas that always comes up, that I'm always interested to try and share more about, is scripts. When you build a website, if it's a standard blog or even a SaaS app, you're probably going to be installing loads of scripts by a marketing department, if you have one, or just by your customers. Maybe that's Google Analytics, Fathom, or maybe something more interactive like Intercom.

I've been building a script at Everfound, and it has been one hell of a journey. This is something that I wanted to explore in an episode with Anthony and just really talk over: the biggest pitfalls that I've found, the biggest head-scratchers. Why do we do it this way? How do you even make a script for your company? It's kind of this black magic that I think nobody's really described a best way of doing, and we've all just kind of made it up along the way, and it all just works because obviously it's JavaScript. But I think it's a really interesting subject area that I wanted to sit down with you and explore.

00:01:11 - Anthony Campolo

Yeah, this is something I definitely don't know much about. I've never had to write a third-party script or really integrate a third-party script too much. I've definitely done things with my dev blog or my Hashnode blog. That would be stuff like that, but they kind of give you the ability to just plug and play things. I have something that can track reads and then I get micropayments or something, and I get like $3 a year for my blog posts or something. So I know that there's a lot of these things, and they're basically black boxes to me.

00:01:42 - Christopher Burns

And the thing is, this is actually what makes it more interesting. The way they can kind of be hosted means that they technically don't have to be open source. They can keep all the source code, obviously how they make the scripts behind that, in private repositories, and then only give you a bundled version. I've actually seen that with a few others. Like, for example, version controlling is another one. There's so many questions here.

So I think the best place to start is: how do you make a script? How do you make a script that can run on the internet, outside of your own domain, outside your own website, and it runs some JavaScript on someone else's website? The first step to do that is you've got to work out what you want to write. If you want to write TypeScript or JavaScript, you can bundle further libraries into it, like Svelte and even React, if you want to make a really quite heavy script. But if you want something really light, you tend to be using just plain JavaScript.

[00:02:41] And this is actually really interesting because I found it really hard to just use plain vanilla JavaScript to build this script, because you're so used to abstracted libraries on how to build these things that when you actually have to use the core JavaScript, it really is empowering at the same time. So the biggest thing is you have to start somewhere, and some people have open-source scripts. I have mine open source, so you can always look at the source code to what I have built.

And it starts with a bundler, and that needs to output whatever that JavaScript is. So say we're going to go really simple and all it is is a function that says "hello world." You've tested it and it runs, so then you need to bundle it. How the internet actually works is, as you know, JavaScript can be bundled into multiple different variants, from CommonJS to ESM to AMD. But the biggest one, and this is how weird the internet is, is UMD.

[00:03:43] And this has caused so many problems. So Anthony, do you know what UMD is?

00:03:48 - Anthony Campolo

I've heard of UMD and I've heard of all of these module things because I've listened to podcasts and read blog posts about the history of it. It's actually a really good one by Tyler McGinnis that we'll link to in the show notes. But I know that the main thing is that you had a module definition for Node, which was CommonJS. And so that's the one that most people were using because so many people were writing Node, and it was just extremely common to have that kind of syntax. So everything that could work on npm could work everywhere else.

But then you also had things that were meant to work in the browser, which I believe was originally AMD, which was asynchronous module definition. And then that eventually kind of morphed into ESM, which is ECMAScript. And I've heard of UMD, but I thought that ECMAScript is what the browsers were supposed to be implementing. And this UMD repo that we'll also link to, that you sent me, no one's ever done anything with it since 2017, so I don't really understand how UMD is the standard that's being used.

00:04:42 - Christopher Burns

It's really weird because you build your script if you're using something like TSX, which is what we originally built with. It would spit out two versions, your CommonJS and your ESM, and you're like, that's it, done. We're done here. We have the script. And then you actually try to load it into a website using one of these interesting loader functions where you basically have the script on a URL, and the JavaScript is basically to inject the script onto the page asynchronously, load it, and then call it to initialize it.

These load scripts all tend to look the same. If you did that with a CommonJS module, it would just error and say, I don't know what to do. This isn't working. This reference isn't there. That's why you have to actually bundle down to UMD currently.

00:05:27 - Anthony Campolo

So what would happen if you just did regular ECMAScript modules? Where would it error there?

00:05:32 - Christopher Burns

So CommonJS errored. That's ESM, right?

00:05:35 - Anthony Campolo

ESM, no. So CommonJS is the require one, the one that you do const, declare a variable, and then you do require and you require the dependency. Whereas ESM, you do import, use the import keyword, and then from, and then whatever you want to import from. So I'll be curious what would happen if you just tried to write it like you would React when you're just importing stuff like that. That is ECMAScript modules. So what happens if you try and do that?

00:06:01 - Christopher Burns

Well, I think the simplest answer is that I don't really know because I don't think I compile to ECMAScript.

00:06:07 - Anthony Campolo

We don't need to compile ECMAScript because the browser just... it's built into the browser.

00:06:11 - Christopher Burns

It's built into the browser. Yeah. So maybe my big problem here was that I was using TypeScript first, is that you've obviously got to bundle out TypeScript and compile it down.

This is actually quite an interesting question because this is the thing: ECMAScript, I didn't actually try. All my headaches and all my problems all came off of bundling extra modules into the code. UMD obviously works for all browsers, but it is also not deprecated. But we're now leaning more to ESM modules.

What you tend to find with a tool like Micro Bundler is that when it bundles the code, it will bundle it to UMD, CommonJS, and ESM. They're the three that it bundles down to, and I don't know why it doesn't bundle down to ECMAScript.

00:07:00 - Anthony Campolo

No, ESM is ECMAScript. ESM is ECMAScript modules.

00:07:04 - Christopher Burns

So it is. So that should work on everyday browsers. And it does. It does. But this is actually a really interesting question as well, which is support. We did a Can I Use on ESM modules, and it says to me 93% of the users of the internet can use ESM.

00:07:22 - Anthony Campolo

Because IE11 doesn't support it, and then Opera Mini doesn't support it, and that's pretty much it.

00:07:30 - Christopher Burns

And then obviously earlier versions of Chrome. We're now on Chrome 100, and Chrome 60 was the last one that didn't. So this is also another big question when it comes down to business, is when is it okay to deprecate the older version? Because we have a bundled version of ESM and UMD, and the UMD version is actually bigger in terms of script size because it's using older JavaScript terms. When is the right time to define that you're going to only use ESM? Because this is a script that you need to work every time, 100% of the time. You need to load your function or your business can't work. Imagine if Intercom only worked on ESM. Well, that's 92% of the websites; it's 8% of websites that are not loading. Okay. And that's a really good question.

00:08:19 - Anthony Campolo

Well, it depends. Would you have the ability to show a message saying this requires Chrome to work?

00:08:24 - Christopher Burns

No, I think it would just error and be like, I can't even compile this JavaScript in the browser.

00:08:29 - Anthony Campolo

Couldn't you do a polyfill, though?

00:08:30 - Christopher Burns

Hmm, probably. But the problem with polyfills is that you also have to bundle that with the script, unless you bundle it outside the script.

00:08:37 - Anthony Campolo

Yeah, no, the polyfills add bloat for sure.

00:08:39 - Christopher Burns

Yeah, this is actually a super interesting thing as we're debating all this. When you search how to build a widget, there's hardly any articles out there. Compiling it down like this was actually really interesting. When I used Micro Bundler and set output files, it couldn't even do it. It would give you a file that wasn't valid. So then I had to use Rollup to specifically make UMD files. I have Micro Bundler creating the bundle for CommonJS and ESM, and then I have Rollup creating the bundle for UMD.

Why is this really important in the world of Everfound? We make a WordPress plugin, and that's scary. No, I'm joking, but we need this plugin to work on every website. And this was also a massive problem, actually getting it working on WordPress, because WordPress did some funky things with it as well around hosting. So we went with the UMD option. We also chose the option to have it open source, so the source code is open. And then we also hosted it on npm.

[00:09:41] So what you tend to see in the industry is that some people will host the script privately, say on an S3 bucket that's cached. You see that with Canny, Intercom. And then you have the other route that is basically using a CDN, an npm CDN. And have you ever used one of these npm CDNs?

00:10:01 - Anthony Campolo

Yeah, just a couple times, like Unpkg. There's actually an ECMAScript one in particular. I think they're good for really simple demos where you want to do something like a CodeSandbox and you want to pull something without having to build stuff.

00:10:15 - Christopher Burns

Yeah. And this is actually really weird because I feel like we're in between multiple ways of doing JavaScript. You could just npm install, or you could just load the script in the browser. What is the better way? This is actually a really interesting one because as somebody building a script, you could do either one. You could install it as an npm package and import it, or you could just run it from the cloud using the UMD file.

And actually, you'd be better to import it into your JavaScript bundle because it would be smaller, because it's using the CommonJS bundle, not the UMD bundle.

00:10:52 - Anthony Campolo

So what's stopping you from just taking all of the code and just, like, literally copy-pasting it into the script tag on your website?

00:10:58 - Christopher Burns

That's an interesting one. What's stopping you? I don't think there is anything stopping you, because if it's in UMD, it should technically all run because it's in a format. It should work, but you'll then have a really big script that you've got to share to people and be like, hey, install this 200-line, 300-line script into your website. It's fine.

And that's actually the hardest point. What we're doing with all this is trying to create the best developer experience. I want to plug and play. I want to get a chat widget onto my website. What is, in your eyes, the easiest way to get it onto the website? Is that npm-installing it into your React package, into your React website, and then doing a JSX component? Is that loading it with a hook? Is that importing it through HTML and a script tag?

This is a really weird thing because there's so many ways to get the same functionality. The next really big thing about it, all that I think is actually quite confusing, is why do we do it this way?

[00:11:54] So what I mean by that is we spoke about the problems. I want it to be like a verbal tutorial at the same time. You know what I mean? Like, how do you do all these things?

00:12:03 - Anthony Campolo

Sure. You really want to?

00:12:05 - Christopher Burns

I want to give a compelling episode that talks about this area of darkness that I've actually struggled with. But how do you actually make it compelling? You know what I mean?

00:12:15 - Anthony Campolo

Oh, I'm already compelled.

00:12:16 - Christopher Burns

You're compelled. Okay, okay. This is actually something worth saying. So this is actually a really interesting moment to also talk about. You've made your script; now how do you demonstrate that? Are you just going to give your customers an HTML version, saying install it from the CDN and go? That's one way.

And then how about installing it into React? React is also totally different in every way that it works with everything. And what we've found with Everfound is that we've created two SDKs. We've created a JavaScript SDK that is core JS, and then we've created a React SDK that hooks into React. We speak so much about the differences in frameworks, about a virtual DOM. Yep, React does everything differently, so we have to use a virtual DOM.

And what we actually find is the CommonJS library. The JavaScript SDK is only about, I think, 2000 kB. The React version is like four, five, six megabytes, I think. So much, much bigger. Off the top of my head, I'm terrible with numbers, as we all know, but this is actually where I've been talking about in the past about learning experiences with other frameworks.

[00:13:24] How do you then get your script into another framework? So say Vue or Svelte. It's actually quite easy and it's surprisingly simple.

00:13:34 - Anthony Campolo

Yeah, because they just have script tags and they pretty much just function like HTML pages would, unlike React.

00:13:40 - Christopher Burns

Exactly. You just install it and then you bind it to a function and it's done.

This was actually kind of crazy. And it's speaking about the web as a whole, as in when you're building something for your customers. So it's not an experience that you control, let's say like a dashboard, but something to go on their website. You've got to kind of mold everything so it won't get overridden, i.e. encapsulate it: CSS functions, variables. You then need to make sure that it can be imported into frameworks of choice in the best way possible. You also then need to make sure you have a UMD version that could be imported into things like WordPress websites, websites that don't use a lot of JavaScript. And all this starts to look like a really big puzzle on how you actually do it.

The first step, how we did it in Everfound, is we wrote a class with new. So, new class. What that has is every single option that we wanted to run inside of it, such as watching an ID click.

[00:14:43] So for a button, say if you put an ID like "open popup," we'd watch that ID when it gets clicked. We would then hijack that click and run all of our custom functionality. That was necessarily quite easy, but actually the hard part that took longer was working out the CSS solution.

Before I speak about the CSS solution, if you were to inject, say, some code onto another website, how would you think about doing it? You're going to run, say, a form. We'll make it easy, a form. How would you inject a form onto a website?

00:15:15 - Anthony Campolo

Use Netlify forms.

00:15:16 - Christopher Burns

So you're going to use Netlify forms. So you're going to load an iframe. And this is actually really interesting. What is the better strategy? Do you build the form out of HTML on the web page, so you're actually building into the DOM, or do you iframe? Tharshan at User Vitals has done the opposite to me, I believe. So in my web app we use iframes; it loads our Next.js website. But Tharshan's User Vitals, I believe, builds the actual content into the web page. So you have multiple, more complex options.

00:15:52 - Anthony Campolo

Until portals comes out.

00:15:54 - Christopher Burns

Until portals. This is also the savior of everything: portals, whenever that will be.

00:15:59 - Anthony Campolo

And check out episode nine for more on portals.

00:16:02 - Christopher Burns

The biggest problem to this is communication to your server. So say if you're going to send an API call, it could be CORS-blocked if you use the method built into the website's DOM, because you are then sending a web call from that URL, if that makes sense. But if it's an iframe, it doesn't get CORS-blocked because it's working inside that website.

So what's the pros and cons to each? When it's an iframe, you tend to have a lot less of a JavaScript bundle, i.e. what you're building, because really what you're then building in your script is a way to put an iframe on the page, open it, and let the website inside render. And that's actually, you know, good enough for most use cases, and it was in Everfound's donation widget.

So what do you gain and what do you lose? What you gain is that you control the website. Every time the website changes, you don't have to push a new version of the script publicly. You just update the website because you know the loader doesn't change.

[00:17:02] But then if a user wants to customize, say, CSS on how that form was going to look, then it's going to be impossible because you can't edit CSS inside an iframe. That's when you would then have to put CSS, like a CSS import, into your website. That could then allow them to inject their own CSS. So you see that it's not an easy picture no matter what you pick. And providing a really good experience is really, really hard.

00:17:33 - Anthony Campolo

So why is there not a startup trying to fix this problem?

00:17:36 - Christopher Burns

Interesting. Why is there not a startup? Because it's kind of like half web standards, I think. But also, have we all found the correct abstraction? Is there a correct abstraction? We've also kind of maybe seen this in other people's work as well. We recently had a person on from Qwik yesterday, and he was saying that he is building a language that can compile to any language, i.e. to web and all these other things, depending on the framework.

There's all these aspects out there as multiple deployment targets, but actually doing it, maybe a SaaS startup is too much, and actually we should just have a really good starter that's really highly starred on GitHub that everybody just uses.

00:18:20 - Anthony Campolo

Sounds like something you can do after all this stuff you've done?

00:18:23 - Christopher Burns

Potentially, yes. Everfound's donation widget is not actually done. Our SDK, we're actually just starting our SDK. Our SDK today is just opening our donation widget in an iframe. But what we're moving to right now and what we're building on is extending that into a headless donation system. So that then will allow anybody to completely build their own UI on top of all of our functionality.

And then what we've turned our SDK into is this script that, one, loads your script; two, initializes classes that will then allow you to create and take donations for charities in a headless way. And what that involves is extending the class functions to then do REST calls as well. Not too hard.

The big thing about all this is that they're very core functions. I might do a REST call, an API call, or load an iframe. But the way web standards is, it all can get really muddy really fast because there's so many ways of doing anything, if that makes sense. Like, what's the right way?

[00:19:26] What's the right way to create a script? This is a really good question. Where would I say start? I'd be nice and say probably go look at Everfound's JavaScript SDK because we actually open-source it. So you could bundle it yourself. And then second, we've made loads of examples that have it bundled in, so you can actually try it and then build one for yourself off it.

That's what I'd say would be a great first step, because I've gone through a lot of headaches getting that to this point, that it actually bundles and works on every single browser, every single web platform. We had problems where our donation widget just would not work on WordPress. The code would be there, the script tag would be in the page, and it just wouldn't work. And we were like, is this a JavaScript problem? Is this a WordPress problem? You know, you're looking at the code, and what made it weirder is that it worked on some WordPress websites, but not others.

[00:20:19] And you're like, why is it doing that?

00:20:21 - Anthony Campolo

Because there's different versions of WordPress, and some people let their WordPress sit forever and never update it, and other people are like, well, I need to update it because it has nine vulnerabilities in it now. And that's why you're going to have a huge spread of different types of WordPress sites.

00:20:35 - Christopher Burns

Yeah, this was the latest version of WordPress, so almost identical websites. The solution to this was actually not to call the JavaScript code, but to host the script inside the WordPress instance. It almost was like the WordPress instance was blocking the script from communicating with the web. It was a really weird edge case that we managed to solve by bundling the script inside the WordPress instance.

Really, you could say this was a real 20-25 minute ramble. There's also other subjects that I did want to talk about in this episode, for sure. Where do you go and how do you start and what to do? Because I think so far the evolution of FSJam has been we've been speaking to so many framework advocates, and we love doing all those things. But me and Anthony also love to chat to each other and just talk about technology.

I feel like we need another deep dive without a guest to talk about the blockchain again. Now that you work at a Web3 company, just really trying to explain it, really try to make it easy.

[00:21:42] Not necessarily every episode is gonna now just be me and Anthony, but I think it would be great once in a while to try and start exploring other subjects. Let other people maybe learn from these subjects. You know, if there's a subject you want us to talk about, potentially ask us about another good subject. I think another one to talk about, and this can be just ourselves or it could be someone else with us, is documentation. You've written a lot of documentation, but how do you write good documentation?

00:22:07 - Anthony Campolo

Oh, God. Yeah, that's a huge one.

00:22:09 - Christopher Burns

Exactly. Say you're a SaaS product. You wrote your SDK that we've just been speaking about, and now you need to document it. How do you document it?

Well, we've had Docusaurus on. We've had Tanner Linsley on. These two people build really good documentation separately. Docusaurus builds a website. Tanner Linsley built his own. But actually, how do you write really good documentation, and actually, how do you get people to understand it? That's one thing I want to sit down and really ask you one day.

00:22:38 - Anthony Campolo

I agree, and it's something that there's no docs specification, but there is a docs system, I think. They break it down to tutorials, explanation, reference, and how-tos. And I remember I came up with kind of my slightly different names for this because I think that tutorials and how-tos sound like the same thing to people, so that's a little confusing.

The main thing is that you'll have a reference, which would just be like an API reference. So you have every single method you can call and then everything that it takes, and it's just pure information. And then you have explanation, which would be like this, what we're doing here in a podcast, like explaining something just kind of in prose or normal language, maybe with or without some code examples.

And then a how-to guide would be how to do something specific. So like for Redwood, this would be like: how do you connect Redwood to file storage, or how do you make a third-party API call?

And then a tutorial is something that is meant to teach you something as you go throughout the process, like the Redwood tutorial. At the end, you don't really have a quote-unquote production app that really does anything that fancy, but it gets you to understand the entire framework along the way. So I think that's a pretty good way to separate the different types of documentation you can write. And then you want to make sure that those categories are then easily represented on your actual doc site, so people can then navigate and know how to find things.

00:24:04 - Christopher Burns

Yeah. Documentation is, as you just said, this really, really big thing. And I, at Everfound, we tried Docusaurus, we tried rolling our own solution, but now we're actually using Readme. Have you heard of Readme, Readme.io?

00:24:18 - Anthony Campolo

I've heard of it. I know there's GitBook. Also, there's a lot of these. I have not used Readme myself, but I think it's one that, if I saw it, I would recognize the look because I read so much documentation.

00:24:28 - Christopher Burns

Yes, well, we're using it with Everfound. This is actually something that I think is super, super important. With that, we're building an open REST API for Everfound as well. So that's built into the documentation, and finding a documentation platform that makes the REST API documentation look as good as the actual rest of the documentation is something by itself.

And I think the real top level of documentation is Stripe. We could all want to be like Stripe, but they obviously spend a lot of money being like that. There's so many subject areas that we always want to talk about, and getting around to them is a really big question.

Something that we have coming up, we're both going to Utah for Remix Conference. How are you feeling about that?

00:25:13 - Anthony Campolo

I'm stoked. Yeah, there's going to be a lot of people there that I know: Michael Chan, Ishan, both of which have been on the show, and then Austin Crim, who works at Prisma. We'll be hanging out with him for a bit. Some other people as well. Yeah. So I'm looking forward to it.

I am not going to be speaking. I won't be really doing much quote-unquote work stuff. It won't really be like a work conference for me. So yeah, I think it'll be fun. And then my girlfriend's going to be there as well. So Jen will get to meet a lot of my friends, which will be cool. We'll get to meet her.

00:25:45 - Christopher Burns

That'd be very cool. My partner is very jealous that I'm going to the United States. I'm sadly taking my business partner instead of my actual partner, but she's going away to a five-star resort in Greece instead, so I'm sure she's not missing out that much.

Something else that I quickly wanted to talk about on air is how we feel about the podcast, where it's going, and also how we feel about always having guests on. I've not broached this with you before, but I think it's actually quite cool to have it very open, very, you know, have your thoughts in the air.

00:26:22 - Anthony Campolo

Yeah, I mean, I enjoy these episodes. I was saying the last time we did this that I wish we did these more often. So yeah, I could see us doing this maybe like once every other month or something like that and then get a good cadence. Because the main thing is just like there's so many guests that we would like to have on, so we always want to keep space for them.

And then I think listeners will get value from our conversations, but they'll also get a lot of value from being exposed to new projects and new people and their ideas. Because if you've been listening to us for a while, you probably will know our opinions about a lot of things at this point. But there is still stuff that I think we could probably talk about that we haven't really dived into too much.

But yeah, and then I think something else that you're probably getting to hear is that we're considering sponsors for the first time. And so it's likely that we'll be bringing on some different companies and having just a short little ad read in the beginning of the show that you're welcome to skip if you want, but it's going to really make this a lot more sustainable for us because this is something that we've been doing as a labor of love, really.

[00:27:22] Myself especially, I put in quite a few hours each week on it to make it happen. So that is something that I have hesitated to do. But I think as long as there are companies that I feel confident promoting, then I think I won't feel too bad about it, and then listeners can skip it if they want. It's very easy to fast-forward commercials in podcasts.

So yeah, if people have any ideas of who we should sponsor or anything like that, feel free to shoot us a message on Twitter and let us know. Those will likely be coming in the next couple of weeks or a month.

00:27:53 - Christopher Burns

Yeah, and this is something that I wanted to ask. What's your opinion on having products or frameworks on the podcast that you could openly endorse? Are the episodes we have where one of us is so far deep in the area almost alienating, if that makes sense?

So what I mean is let's take an area, something that we're both really, really knowledgeable at, and say Redwood. So if you listen to our episodes about Redwood, we say it's the best thing ever. You're never gonna have a problem. And, you know, you should go out today and you should build in Redwood.

00:28:26 - Anthony Campolo

No, we don't say that. I specifically don't say that because I'm a responsible advocate. And I would never say that.

00:28:31 - Christopher Burns

Responsible advocacy, that's more what I'm trying to get at. When it comes to sponsorships, when it comes to people who are coming on to the podcast, a lot of the people we get on are in developer advocacy. And yes, they are trying to get you to understand their product, understand what they're doing, and also give some value.

So as a developer advocate yourself, we kind of sit on both ends. I'm a founder of a company. You're a developer advocate. How do you feel about almost having these episodes be pitches, all these guest episodes? Are they pitches in your eyes, or are they you want to learn something without necessarily buying the product?