[00:00:01] MB: Welcome back to Software Engineering Daily. My name is Mike Bifulco. I'm one of your co-hosts. And today we're talking about a topic that's something that comes up quite often in the life of developers who are building products. Whether you're building something for yourself or integrating with someone else's tooling, something that we bump into left and right, whether we realize it or not, is documentation written by other people. 

In particular, putting together documentation that is meaningful and useful is a real challenge. And the structure by which docs are written and put out into the world is actually kind of something that's an unsung hero for a lot of us. If you've worked on a project where you integrated with a product or an API or a tool that instructions were not clear, it can be very, very frustrating. 

And for teams where you're trying to move quickly and deliver on something in a hurry, documentation can either make or break your experience. Just as well, if you're building something for yourself, keeping good documentation and keeping structure and high-quality written notes to yourselves about the way you're building your product is super important, too. And building this out with a modern developer experience is something that can take away quite a bit of stress for development teams and for product teams. 

Today I'm very lucky to be sitting down with Sébastien Lorber, who uh is a luminary of the React world. Is someone who I bump into on the internet all the time in a variety of ways. And we're going to talk a little bit today about Docusaurus and some of the things that Sébastien got going on there. As well as his career and many of the things that he's brought to the world along the way. 

Sébastien, thank you so much for joining me. I really appreciate it. How are you doing today? 

[00:01:44] SL: I'm fine. And thanks for having me. 

[00:01:45] MB: Yeah, of course. Of course. Very happy to have you. For folks who haven't met you before, why don't we start here? Why don't you tell me a little bit about yourself and your career leading up to where you're at now and sort of the journey you've been on as a developer and someone in the tech world? 

[00:02:01] SL: Yeah. I used to be a backend developer. And I didn't even like frontend development 10 years ago. But some other JavaScript quota that now is a pretty nice language. [inaudible 00:02:15] startup and I saw my team, frontend team, was struggling with frontend. I was not a frontend developer. And just at that time, React came out. So I thought that it was a great opportunity to become better at frontend. And since then, I do mostly frontend and mostly React. 

This is how I became a React developer. Six years ago, I started to become a freelancer and I started to produce content because I wanted to attract better customers and to do some consulting with IR rates. This led me to create a newsletter called This Week in React, which is now quite popular and written by 25,000 persons in the world and growing fast. 

This is a quite significant project for me now. And at the same time when I started the newsletter, I had the opportunity to work for Facebook as a freelancer on Docker service, which is a static site generator that we'll talk about. It was supposed to be a three months project. But now it still continues today. It's over three years now. And I still work with Facebook and it's planned that this continues. 

The thing is I kept my newsletter. I have two projects in parallel. I have the newsletter on one side. I have the Facebook project Docusaurus on the other side. And I try to arbitrate my time so that I can give enough time to each project, which is quite challenging. 

[00:03:56] MB: Yeah, I can imagine. They're two pretty tall projects. Both of them are pretty time-consuming. One of the things I'm interested in hearing about is kind of how you decide where to develop your time. Obviously, Docusaurus seems like the sort of thing that, during product development cycles, it probably takes more time away from your day. Sometimes it has a little more demand on your life. And I would imagine This Week in React has to go out every week. Is it something where you carve out roughly the same amount of time each week to work on This Week in React and the rest of the time is for Docusaurus? Or does it work in another way? 

[00:04:34] SL: Yes. Somehow, this is quite challenging because both projects would need more time. But I decided to split all in half. So now I spend half of my time on the newsletter and the other half on the source, which is not enough for both, unfortunately. But this is the only way to keep making both of them work. I try to do my best. 

[00:05:01] MB: It sounds like maybe This Week in React came alongside your freelance career, right? Like you started freelancing and started writing as a way to drum up an audience. Was that an intentional decision? Was this like something that you started doing because you had a hunch that it would work? Or were you going on advice from someone? Something like that? 

[00:05:20] SL: So my goal with the content production and the newsletter that came a bit later was mostly to rich French customers. Because I'm from Paris. And to be able to sell IR Consulting jigs. But the thing is I never benefited from this because I work for Facebook now. So I have a lot of visibility to get work. But I don't need work. So I decided to keep the newsletter. But it was – you know, somehow, I needed to figure out how to monetize it because it takes a lot of time and it's not profitable if you invest one or two days a week on a project and you don't get nearly return on investment. Now I'm able to make a living from the newsletter thanks to sponsors. 

Like many encouraging newsletters that developers follow, I include the ads in the newsletter. Obviously, this time is to make the project sustainable. And over time in coupons. So maybe maybe in a few years it could become a full-time job. I don't know.

[00:06:26] MB: Yeah. I think it's an interesting thing. Honestly, from my perspective, like I think your name comes up so often when I search for things. Because this week in React, giving me lots of answers to questions I have because you're sharing information that's new in the React world from people writing about things or YouTube videos and things like that that are really impactful and influential. And as I bump into them, I'm learning from smart people. But also, like your name comes along with all of those. I think you're sort of building Sébastien, the brand, as well here, too. Which is probably valuable in itself? 

[00:06:57] SL: Happy to hear that. Yeah. 

[00:06:59] MB: Yeah. Let's talk a little bit about Docusaurus. Tell me about the product in a world where we have lots of choices for static site generators. What was the – I guess, the Genesis of Docusaurus. Where did it come from? 

[00:07:18] SL: I wasn't there at the time. But maybe seven years ago, there was a need at Facebook, which was to be able to document their projects. Not only the externally open source projects. But also, internal projects that they don't share. [inaudible 00:07:32] at that time was to create a [inaudible 00:07:35] template and copy-paste it from one side to another. And of course, it became quite difficult to maintain because you had to – every time you add a new feature to the template, you have to somehow backboard it to all the documentation sites manually and there are merge complex and things like that. This was quite complicated. 

And the idea of Docusaurus was to create a static site generator where you can just focus on writing the content and then it creates a static site. And you can deploy it easily on free like GitHub pages and things like that, like any static aesthetic website. 

This is where Docusaurus, one, was born. The idea is that all the dependencies to to make all this work are behind a single dependency that is Docusaurus. And you just run a command line and then you are able to start a dev server to work on your site. And then you can also run a build command that permits to generate the static site. 

The idea is that your project is just another project where you have [inaudible 00:08:39] and you will run a command and then you are able to deploy your site quite easily with the command line. 

And although it's based on node.js and the first version was using React. But as a server-side templating language, it was not using [inaudible 00:08:57] for interactivity. This is something that came later with version two of Docusaurus, which builds this time a real single-page application and as a modular architecture so that you can create plugins and things like that. 

The version one was somehow a proof of concept of how to make it a static cell generator with React based on [inaudible 00:09:24] files. And version 2 was the more polished version, which is also a real React application because you can bring interactivity. You have direct [inaudible 00:09:35] running. 

Also, the seat may be a bit easier because your load React on the client this time. Somehow I think this is something that not everybody agrees on. But I think React can be beneficial on the play inside too even for documentation website. But some people will not agree with this idea for sure. 

[00:10:02] MB: Yeah. I think it's hard to have an opinion in the React world that isn't at least a little bit controversial. Yeah. My understanding was that V2 added quite a bit of ability for people to customize things and to use a lot of the – oh, man. I hesitate to use the word typical. But like the things you think of when you're using React. Interactivity, writing with interactive markdown with MDX, right? You could embed react bits into markdown and whatnot. 

And seems like it added quite a bit of, also, tooling for SEO so that documentation was I guess crawlable by like the Google search crawler and things like that. What was the main goal of the release? Was it primarily to make it easier to develop on or were these all features that were sort of a little or – a little more – I don't know? In demand from your user base? 

[00:10:59] SL: The thing is version one of Docusaurus was quite successful but it was quite a monolithic. The code base was a bit messy. Not well-tested and not extensible. When you build a seat, you couldn't really customize it outside of providing some CSS selectors and changing colors. But the structure of the site was quite similar from one side to another. 

And I think one of the benefits of version 2 was mostly to give a lot of flexibility. You can override any right component that we create for you. If you don't agree with where we display things, you can swap our code for use and you can really adapt your site to your branding. 

And we have seen great companies adapt the version 2 of Docusaurus and customize their sites, for example, React Native. And also, other companies like Figma, Snapshot and LinkedIn and many of those. And if you look at their site, they customize it so well. But even me, when I come to the site, I'm not even sure that it's using Docusaurus and I have to use the dev tools to be sure that it's the case. 

[00:12:11] MB: Sure. Yeah. That is a very successful brandable product. I feel like there was an ERA for devtools online where doc sites all looked the same. And I think some of that was that tooling didn't support it and some of that was just that there wasn't much focus on the value of branding docs and the value of making docs feel like they're a part of your company's brand wholesale. I guess that all then brings us to version three of Docusaurus. And so, tell us a little bit about that. 

[00:12:45] SL: Yeah. Version 3 actually is mostly a dependency upgrade. We are familiar adopting React 18, which is released I think over a year ago now. But we didn't make [inaudible 00:13:00] so far. And catching up on this release. And hopefully, we'll be available on version 3 to take advantage of some new features like the transition API and things like that. 

And also, we have MDX2, which has also released quite a while ago but it was quite a challenging migration. And it's more powerful and cleaner version of MDX, which is [inaudible 00:13:29] which allows to embed React components inside of it to bring interactivity. 

The web version one of MDX was implemented, there was a bit actually relying on string concatenations and things like that. And now there is a better IST for the version two. And it's easier to write, pin MDX2 plugins to extend the way markdown is passed and how you can create some custom syntax and things like that. It's better for all these things. 

I think it's a nice upgrade. But it's quite challenging because there are some breaking change and we have to explain to all the users that have some documentations that they will need to do some tweaks to their documentation to be able to adapt it. 

And there's also something that I think is quite interesting that comes with MDX2, is there is the ability to have a common mark model, which was not supported before. Now if you already have an existing documentation in common mark, you can disable the MDX mode. Instead of using React inside your markdown files, you will be able to use regular HTML elements in your markdown file. And if you already have a common mark documentation in place, you can adopt Docusaurus without modifying too much the documentation because your existing common mark files will be compatible with the new version. 

[00:15:11] MB: Yeah. And so, I only recently learned about common mark. Common mark is I guess you would call it a superset of markdown, right? Can you give a little more details about what common mark exactly is? 

[00:15:23] SL: Common mark, yes, it is kind of the standout for markdown. I don't know if it's officially the standard or whatever. But the idea is that this is a subset of all the things that we can do on markdown that many people agreed on and many try to respect the specification. 

It's not a super broad specification. So you can't do a lot of things. And there are some people that are trying to extend it with new features like – and particularly excited for remark directives, which is a syntax that we use for Docusaurus to create admonitions and cutouts and things like that. 

This is not part of the markdown, the common mark specification. But I think it would be a great addition. And MDX supports it well. You can do many things with markdown. And thanks to MDX, you can do even more things. And thanks to extensions like the markdown directives that eventually will come to the common mark specification. 

You can do even more things. This is a nice upgrade to be able to support both MDX and support common mark so that people can easily adopt the more compliant version of markdown. Because MDX is not compatible with common mark. It's different. It's quite similar but there are some difference in terms of syntax.

[00:16:54] MB: Certainly. Yeah. My layman's take on it perhaps that MDX allows you to do much deeper customization but is far less cross-compatible. It's unlikely you'll be able to copy and paste your MDX to a GitHub issue or GitHub read me and have it work because there's a lot more that goes into the specification. Like you essentially have to tell markdown which React components you want to render and how the rules work for all that. And common mark is more about giving a spec that hopefully everyone will adopt over time. 

Docusaurus is an interesting case I think, too, because under the covers it's a static site generator. And so, this is just a nice way to build a highly performant, searchable, navigable web page in a single-page app. Do you find that there are folks who use Docusaurus for things that are not like traditional documentation for other uses? 

[00:17:54] SL: Yeah. Actually, there are a lot of developers that are using Docusaurus site for their portfolio. [inaudible 00:18:01]. You can have a landing page in a blog for example and that's nice. [inaudible 00:18:08] is running on Docusaurus. Also, this is something I thought it would be a good idea to be able to use my own tool for the job server. 

[inaudible 00:18:18] also notice things that are missing so that I can Implement them for my own need. And the thing is you can have multiple blogs on Docusaurus. What I have is one blog for the newsletter and one blog for the newsletter articles, which is a different blog. It's not the same pagination somehow. You go from one issue to another, from one week to another on one feed. And from the articles, it's the last article and then the previous one and things like that. I wanted to have two things about it. And Docusaurus works great if you want multiple blogs. 

Also, if you want to create some combinatory blog, it's possible because we support multiple [inaudible 00:19:05] and things like that. You can create a team that creates a lot of blog posts and assign each blog post to many others. And it's quite easy to set up. 

We have a few of our case. Yeah, it's a great place – yeah, we have a seat showcase on Docusaurus where you can see a lot of different sites that are using Docusaurus. There are many also product sites that are built with Docusaurus. Because you can create your running page with React, you have the ability to do whatever you want. 

There are some projects that implement their landing page with Docusaurus. For example, quest [inaudible 00:19:51], which is a database I think you add on the podcast I think. I don't remember exactly. But I think you had them on the podcast someday. And they implement their landing page on Docusaurus. And when you click on the docs, you stay on the same side somehow. 

[00:20:09] MB: It ends up being a really nice place to author and collaborate in particular for teams that are like very familiar with the Git flow who tend to rate naturally in markdown, which for developer teams is probably a fairly native thing to be able to do. 

Tell me a little bit about the launch of version three and what's coming there. What's the timeline? What are you working on in the alphas here? 

[00:20:34] SL: So for, the idea of launching the version 3 is to – first, we already merged the pull request that we wanted to merge for this version. This was a React [inaudible 00:20:43] and MDX2. 

Now for me the goal is to upgrade some Facebook sites like Jest and React Native to the version 3 alpha. And if it's successful, I will pass the release as a beta. And if it's not successful, I will try to make additional fixes so that it's not difficult to upgrade. 

And in the process, I'm taking a lot of notes so that I can get a material to be able to write the upgrade bead. Because we will need to write a git to the users do the upgrade for their own site. So the goal for me is that when these two sites are upgraded, I am more confident that we can move to the better stage. 

And once we are in the beta stage and we have some upgrade material, we will get some additional feedback from the community that will try to upgrade their own sites. And from there, if many sites are able to upgrade to the beta, we are able to release the first release candidate. And later on, the general availability of the version 3. So that’s our plan. 

[00:21:59] MB: Sure. Yeah. I think that's a good plan. It sounds like you're pretty close with the alpha here. And definitely, encouraging to see that this is something that you're using and Facebook is using a long way to really experience the product there, too. 

I'm also interested in hearing a little bit about the open source community that surrounds Docusaurus. Docusaurus, I believe, can be found on GitHub at github.com/facebook/docusaurus. And I'll make sure we drop a link in the notes here, of course. What is your open source process like? [inaudible 00:22:34] third-party. Like non-facebook employees able to contribute to the product via pull requests or issues preferred? What does your process look like there? 

[00:22:43] SL: Small issues, I think you can open a pull request directly. If it requires some breaking chance and API design, I think it's better to open an issue because we want to work on this together before you assume into a pull request. And I close it immediately because it's bad if you put some time to work on this and then I tell you that this is not the direction that we want to take. 

For small issues, I try to create also good first issues for external contributors that want to give a try to contribute to the project so they can easily pick one issue that is not too hard. And that we already gave the direction for how the program should be solved. They just can't swim into a pull request right now. 

Something I do more recently is that I prefer to receive a pull request immediately rather than people getting into issues and claiming the issue. Because very often, people claim an issue and they go silent for two weeks and we don't get any news. So it's a bit complicated that I prefer to not assign issues until there is already a direct pull request because a wise people claim the issue and then they don't work on it. This is not good. 

[00:24:05] MB: That might deter other people from working on the issue when that happens, too. Yeah, it looks like from a brief glance at the repo, there's a lot of activity, which is always really encouraging to see, too. The process of working with a large community when you're building an open source product is really an interesting thing because you need to find a way to be collaborative but also set some roles that give everyone a better chance of success. 

That sounds like a really nice way to sort of apply some – I don't know that you'd call it governance. But community guidelines around the product that – rather the project that helps everyone to collaborate in a way that doesn't waste anyone's time either, which is really nice. 

Okay. Let's talk next then about the – so with the release of Docusaurus V3 coming, I think there's a lot of opportunity here for people to get in and use it for the first time if they haven't given it a shot before. What does Hello World look like for Docusaurus? Just getting started, how does that process – what does it look like? Yeah. 

[00:25:11] SL: Oh. Okay. So this is something I'm quite proud of actually because I try to create the shortest tutorial ever. The idea is that first you don't have to install anything to be able to try Docusaurus first. You just have to go to the domain Docusaurus.net. And it takes maybe one minute to load the things like dependencies in a web browser. 

We are using either Codesandbox or StackBlitz to be able to run the non-Docusaurus project inside your browser so you don't have to install anything to give it a try. And once you initialize the new project locally or in your browser, what you get first is a tutorial that maybe last five minutes. And the thing is it's really playful. The idea is that should be able to understand the value proposition of Docusaurus by really giving it a try. Not just reading boring documentation. But we tell you exactly what to do. We tell you create this file and then create this over file. And you understand through for this way the value proposition of Docusaurus. 

Basically, the ideas that you just can write markdown files and get a good result from that because we are using third-system conventions. If you write the right side at the good place, you will see it appear in your UI. And we try to make this quite intuitive with a good default so that you understand out of the box how it works. 

[00:26:55] MB: Yeah. That's really nice. That is a very, very tidy onboarding. Literally, zero local install is something that is enviable definitely. And I have gone through it myself. And I think one of the nice things about it is that the onboarding is really gentle. Like it tells you what's happening and tells you what to do. But also, kind of does a nice job of balancing here's what you do next with this is why you're doing this. Or this is like the reason that you need to know that these files exist. And I think that's something that provides an easy on-ramp for folks who want to get to use this. 

And I'm pretty sure with both Codesandbox and StackBlitz, you can download your source code afterwards. So the outcome of the Docusaurus.net onboarding step is that you then have code that you can put into your own repo or download locally, whatever your process is, and use what you've done in the tutorial to then turn into something more meaningful if that's what you'd like to do. 

[00:27:52] SL: I don't know if you can download the code. Maybe. But I think the tutorial is really too short and very, very small. You just finish it in under five minutes even if you never use Docusaurus before. I'm not sure that it's worth downloading the end result because it's ready for educational purpose. And the files that you created, you maybe don't want to keep them. You just want to understand how it works but you are not progressing towards your goal of creating a real documentation. You are just giving it to try somehow. 

[00:28:28] MB: That's also fair. Yeah, definitely. 

[00:28:31] SL: Yeah. Once you understand that, you can easily do the same locally. And this time, try to create a more meaningful documentation. 

[00:28:42] MB: Yeah. I really appreciate that. And I think that this gets out of the way of teams pretty quickly. It makes the product easy to use. It lets them obviously get to the goal of making their tooling, their API, whatever it is that they're making, the documentation more easy for the team to build. More easy for end users to consume and do all the other good things that we talked about like branding and interactivity and whatnot. 

It's really an interesting product. And I think that the nice thing about it is that it's so self-contained and so compact and easy to use. And it comes with all the performance that you would expect, which is super nice to see. 

Actually, one of the things that I forgot to mention before, one of my favorite things about it is there's a plug-in for open API as well. It's smart about that. Do you mind talking about that a little bit as well? 

[00:29:35] SL: Yeah. Actually, we don't have just one plugin for open API. We have three. And they are third-parties. This is not something that I work on personally. But I know that there are multiple companies that decided to create plugin for open API. 

And actually, you don't even need an open API plugin to use open API inside Docusaurus because of MDX. Thanks to MDX, you can just write React components inside your markdown files and you are able to create an open API client from the – I think it's a JSON definition or something like that. And if you write some clients for open API, you can install it inside your documentation as an embedded direct component and it also works. 

What I wanted to say is that you can do this by embedding React components inside your MDX documentation. But you can also use, for example, the Redocusaurus plugin, which use Redoc. And I think it's an open API client. And this time it will generate – for each endpoint, it will generate you one Docusaurus page or something like that. You have two options. You can integrate it more manually and more customizable. Or you can just use a fully-fledged plugin that will create everything for you for free but is a bit less flexible to customize. 

[00:31:06] MB: The Docusaurus codebase itself, can you tell me a little bit about how that's built? Obviously, it's probably a safe bet that it's built on top of React or built with React. Is this a project that uses – I don't know. Typical standards or structure that React developers might have run into in the wild before? Or is it something that's a little more custom? 

[00:31:29] SL: [inaudible 00:31:30] monorepo using learner.js for handling the monorepo. We use React for the frontend and we use node.js for passing the markdown files and creating the data structures and things like that. The idea is that we have two sides. We have node.js and there's the data layer. Somehow, we read markdown files, generate props and trigger the static site generation from the node.js process. 

And on the other side, we have the frontend, which is React components. And they react they receive the props that node.js layer provides them. And then we'll use React to rundown the frontend of the application. And this is a modular architecture. We have three core plugins. We have one for edges, which is basically longing pages. We have one for the blog, which is basically a list of blog posts. And we have features like the tags, pagination and things like that. And and archive. And maybe later we will have a page for each order of the blog posts and things like that. And we have the docs plugin, which is a set of documentation that can be versioned and for which we can add a sidebar on the left. And that's it. 

[00:33:02] MB: Yeah. I think it's an interesting thing for anyone who's interested in sort of how these things work to kind of go look at the underlying source code for the tooling that you're using. And one of the things that I admire about Docusaurus is that even though it's a fairly large code base because it's a really well-developed product, is the code is really well-organized. 

You can kind of dive in once you understand that you're in a learner package. Of course, there's the basics of mono repos. But plugins, utilities, all those things kind of fall into a nice place. And I think this ends up being a really good example of software engineering as well. 

If you're someone who's in the step in the journey of your career where you're sort of figuring out like what does it mean to write a code base that is something that can be maintained? And what does it mean to organize code in a way where I know where things are and consistent what not? The Docusaurus team has done a really, really great job of organizing things in there. And I think that's something to look up to and probably something that you don't hear much. But I think it's very, very valuable to experience and to see as an end user, too. 

Sébastien, I'd like to pivot a little bit and talk some more about This Week in React. Can you give the elevator pitch for your newsletter? 

[00:34:17] SL: Yeah. So about the newsletter. The idea behind it is that there are not a lot of newsletters for single developer. And there's not a lot of content for single developers. If you are a React beginner, you will find a ton of people that will provide you [inaudible 00:34:35] to get started and to learn how the best to learn React from scratch. 

But once you already know react, like me, I'm doing React for like nine years or something like that. I don't need to learn React anymore. I just need to get a content that is to my level something that I would be interested in. And it's surprisingly hard to find interesting content once you already experienced with the technology. 

The idea for me is that, with this newsletter, this is a curation newsletter where I pick links I found on the internet and I visited them in a weekly email. And the idea is that you don't – the idea is that you save time and you get the relevant news on the battle somehow. 

I spend a lot of time on videos and score a lot of Twitter so that you don't have to somehow because it's quite addictive to be on Twitter and try to find meaningful content there. And so, the idea is that keep you updated and everything React and you don't have to spend a lot of time on social network to find the great content that you are interested in. 

And this is mostly for senior developers that are not looking to learn from scratch. But instead, they just want to keep up to date with the latest news and eventually also including weak signals and pull requests being merged and things like that.

[00:36:14] MB: Yeah, I think one of the big values of this, too, is if you want to know how someone like Sébastien is thinking about learning react or the things that an experienced developer is finding useful, it's a great place to go for those sorts of things. 

And the pattern I've found with it in particular is that many of the things I read about in This Week in React aren't useful to me straight away. But they are something that I come back to often. I have a massive pile of bookmarks that are the results of reading the weekly newsletter and it's made it really easy to come back to developer patterns and tools and techniques that will come in handy for me or that I think something that I'll bump into before long. 

Whereas I think the beginner tutorial world is very much like zero-to-one Hello World and sort of the same thing over and over with maybe a different learning style or personality or language. I find the things that you put together to be extremely helpful for that reason and often are things that sort of float around in the back of my mind for a few weeks before I end up getting to use them. But really, really an interesting and valuable resource for me as well. 

That's something that obviously you mentioned before you're working on this about half of the time. This is something that also I think probably helps to build upon itself that you're able to make relationships with people who are producing great content and whatnot. Is this something that you think about as its own business? 

[00:37:45] SL: Yeah. It's totally something I'm considering as a business now. Because in the beginning, the goal has to attract customers. And I didn't need that because I was working for Facebook. And the thing is I thought should I stop the newsletter because I don't really benefit from it? Or should I continue it and grow it to a point where it will be sustainable and find a business model? 

And there were already existing newsletters that were profitable. For example, you probably heard of Cooperpress, which has newsletters like JavaScript weekly and things like that. There are a few newsletters that are already making good money from their work trying to find the most interesting links for developers. And I thought I could do the same but maybe with a different editorial line which is focused on more senior React developers also interested in React Native and particularly interested in also the cross-platform union of React and React Native. 

I decided to try to monetize it. It took a really long time. But now I think it's on track to become a sustainable project. I'm not covering exactly the hourly rate I have from my work with Facebook. But slowly, it's increasing. And it compounds over time. So I think it's interesting. And I'm now quite known in the React ecosystem including from sponsors. 

Many sponsors contact me because they want to sponsor the newsletter. For example, today, the newsletter is full in terms of sponsorship until the end of the year. That's quite nice. 

[00:39:39] MB: Yeah. Wow. That's really exciting. I would love to know some of the things that you've learned while figuring out how to work with building your audience. I think there's two sides to that, is sponsorship is an interesting thing. Like has it been challenging to learn to work with sponsors? 

And I'm also kind of interested in has it been challenging to prioritize which content goes and which issue of your newsletter? Are you overwhelmed with things that you want to share? Or is it a little more work to go and find the right sort of things to share? 

[00:40:13] SL: Generally, first, I am quite overwhelmed with the things I want to share. Yes. Of course. The thing is I'm also filtering quite aggressively and try to keep mails not too long. They are already super long with lots of links. But the thing is if you send an email that is too long, Gmail will truncate it. And this is really bad because it gives no full experience to the reader. I can't include too many links. Otherwise, this happens. 

And so, I start off my editorial line. I try to not put the same content that overreact newsletters send. For example, all the step-by-step tutorials that you mentioned, this is something I don't like to include too much unless this is about something very, very cutting-edge technology that I want to show. 

Maybe the first tutorial on a new technology, I will include it. But the goal is not to be exhaustive and include every step-by-step tutorial that has been published out there. And also, I really focus on super time-sensitive content. The idea is that if a blog post hasn't been published in the last months, it's all for me somehow. 

I really focus on things that are new and considerable by readers. Already know the things and are reading me for a long time. So they don't need me to resurface all projects because they maybe already know them. For example, if a project that I discovered doesn't have a key event like a major new version and a blog post that explains why this version is great and what's the purpose of the project and things like that, I won't include a random GitHub link unless there is a key event about this project. 

[00:42:10] MB: Yeah. That makes a lot of sense. 

[00:42:12] SL: Regarding your sponsorship questions. Yes, it's quite complicated to work with sponsors. And actually, from all the time I spent on the newsletter, I think Alf is about managing sponsors, which is quite annoying because this is a necessary thing to do. But I'd prefer to improve the quality of the newsletter rather than discussing with sponsors. 

But the thing is you have to convince them to sponsor the newsletter. Some of them won't – some kind of reporting. You also have to explain what's the other format for the newsletter. You have to remind them to send the ad on time. And, yeah, there are a lot of things. And many times, also, you [inaudible 00:42:58] them to try to convince them to sponsor. That's a lot of emails to send. 

[00:43:06] MB: Yeah. Quite a bit of coordination. And I can understand how that would add up to most of the time, half the time, at least that you spend on things. Certainly. Well, it's a remarkable thing you've done I think one of the best things about it, too, is that like I'm sure you're benefiting from this. But it's a value to the community. And I think that's the sort of thing that community projects that help other people to grow their skills and to make themselves better, there's a clear value there. And certainly, for the right sponsors, that makes a lot of sense, too. 

Yeah. Yeah. Well, thank you, it's a very cool thing that we're on. Sébastien, thanks so much for joining me for the podcast today. I really appreciate it. It's been absolutely a blast chatting with you and kind of getting to know about you. 

Before I let you go, what's the best place to find you online? And how can I find This Week in React? 

[00:43:58] SL: So you can find me on Twitter @SébastienLorber. And on LinkedIn also. I don't think there is a handle, but Sébastien Lorber, too. And yeah, I'm on many communities. And the newsletter is thisweekinreact.com. It's quite easy to find it, too. 

[00:44:18] MB: Great. And Docusaurus as well, where's the URL for that? 

[00:44:24] SL: Docusaurus.io to get the documentation. And if you want to give it a try, it's just Docusaurus.new. 

[00:44:31] MB: That's great. Thanks so much. And of course, if you're listening to the show, you will have a whole pile of links for you in the show notes from things that Sébastien mentioned along the way. 

Sébastien Lorber, thank you so much for joining me. It's been a real pleasure. Have a great day. 

[00:44:44] SL: Thanks. Me, too.