Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Chris Biscardi. Hey, Chris.

Chris Biscardi: Hey.

Brian: I've wanted to chat with you for a while about specifically MDX, but before we jump into that, do you want to just give us an intro of who you are?

No one can see your awesome tank top, but also if you want to mention that as well.

Chris: Sure. My tank top has a bunch of corgis on it, and that is because I run the Party Corgi Network, and that is a Discord of content creators and people who stream and write blog posts and things like that.

It's a supportive, "We help each other out" kind of thing.

As for me, I am an independent consultant. I specialize in JAMstack and Serverless stuff.

Work people may have known me from is Gatsby Themes, and I did work at Docker in the past. Yeah, that's me.

Brian: Awesome. So, specifically we want to talk about MDX because your name shows up if you Google anything about MDX. I'm curious, how are you involved in the open source project as well as writing content?

Chris: I'm a maintainer of MDX, and John Otander is the creator of MDX.

The way that I got involved was I saw John talk about MDX one day on Twitter, because half my life happens on Twitter apparently, and then I built Gatsby plugin MDX because I knew that MDX was the thing I was looking for after the past couple years of building design systems and whatnot.

I built Gatsby plugin MDX because I was into Gatsby, I was in MDX, and I thought that they were a great match. It went from there and then I became a maintainer as a result of that work.

Brian: I guess we should zoom out too, like "What is MDX?" I guess will be the question that a lot of people are wondering.

Chris: MDX is Markdown plus JSX, so that's a very simple way to phrase it that doesn't really convey all the things you can do with it, but it's Markdown and JSX.

Brian: Did I read somewhere--? Maybe the creator or somebody was talking about their creator's vision, that they wanted to embed stuff into Markdown.

Things like embedding a YouTube video is pretty janky and doesn't actually work in a lot of places where Markdown lives. So, does that also help out the description as well?

Chris: Yeah, for sure. MDX has a number of different effects, and o ne of them is that you can now use a React component or a Vue component or something like that.

If you ever want to render a YouTube video, you can use the YouTube video component and just pass in the ID. It just renders when you render your MDX.

You can replace any renderable element, so if you want to replace an anchor tag or a paragraph tag or how their headings render and things like that.

Stuff like that can be hard to do if you're rendering out a bunch of Markdown content that you don't control.

But MDX gives you a provider where you can actually take control of the actual rendering and change how the structure of the thing renders, and things like that.

That gives you access to short codes, so you can have that YouTube video component that I talked about before or whatever.

You can provide that to all MDX content, and then people who are writing the content don't need to import React YouTube video player from wherever the fuck.

That means that you can render an MDX doc that uses a YouTube player in a Vue site or React site and it doesn't really matter.

Brian: Excellent. I'm familiar with MDX because I took a tour through the code base and there's a parser that does all the hard work for you.

So everything's built on this parser that makes the MDX and the Markdown work with other styles of embeddable things?

I imagine there's an Ecosystem of MDX plugins that you can source and figure out how they work with?

Chris: There's a whole stack of things when you look under the covers on MDX.

There's the AST's that are used for the Markdown, HTML and JSX transformations.

So you get Rehype, Remark which are HAST and MDASD.

The naming there is a little confusing, but it's a Markdown AST and an HTML AST that you get to process with plugins.

Then you can get the JSX out the other side and process that as well, and MDX will run Babble on it for you so you can write a Babble plugin and apply it to your JSX output, or whatnot.

Brian: OK, so you mentioned JSX in your description too, as well as Markdown plus JSX.

Is this a React-only thing, or how do I even approach playing around with it?

Chris: It's a JSX thing. Vue has support for JSX, React has support for JSX, other frameworks have support for it.

Really all you need is a JSX compiles to a function call, and that function call is the thing that you need to implement if you want to support JSX.

Because MDX targets JSX instead of React specifically, it becomes much easier to port a document from one to another.

Brian: Excellent. I'm curious, what was the catalyst of making MDX as popular as it is and the solution for this ? Were there solutions prior to this to make this thing work?

Chris: There was a bunch of solutions that had various drawbacks.

MDX isn't a totally new idea. There are people who have approached it in the past, and I think a bunch of them are mentioned in docs and stuff like that.

But they all were like, "You have to ship the entire parser to the browser," or something like that which can be heavy weight, can be not exactly what you need.

Then you still have to work with HTML and you can't work with JSX or a structured output format.

If you wanted to do something that was complex, like a YouTube component or even a card, you want to render a card inside of a Markdown doc, you would have to write all of the HTML out and apply all of the classes in the right order and then you would get your card. But MDX allows you to just write a card component and you can provide it to that doc, so somebody writing in some CMS somewhere doesn't need to know how to import something or whatnot.

The JSX syntax is the short code syntax for them and they just write it.

Brian: I love that. I love this obscuring all the complication, because I've spent some time--

As we discussed earlier you mentioned that you are part of the Party Corgi Network as well and run that.

I spend a lot of time trying to make my Twitch embeds work and the difference between.

Because my site, I started with a template so I have server-side rendering running on it, but I'm using Razzle.

Which is super awesome, but also because I made that decision I can't use any React component off the shelf, it has to render to a string.

I say all that because I've got other things that are rendering Markdown, and then when I had some Markdown issues on my site and I was considering going down this MDX route.

Then I was like "I should actually just have someone come on and chat about this and give me the rundown on how this actually works."

Understanding that, actually, I didn't know that JSX was actually leveraged in things like Vue and other frameworks, but I get that it's a library.

But I'm curious as to how the adoption works in, it sounds pretty straightforward and pretty easy especially if you're familiar how to React components work.

If I'm using Markdown on GitHub pretty heavily, can I leverage MDX in my GitHub project?

Chris: It depends on what you mean by that. GitHub doesn't render MDX. It will think it's an HTML tag and it'll just take the tag out for you when you go to look at it.

Brian: Gotcha.

Chris: But that's somebody else's Markdown preview on their site, so if you're going to take MDX docs that you shipped to GitHub in a git repo, and then take them out and render them somewhere with even something like Gatsby or Jekyll, or whatever.

Then you could do that but GitHub Inc Markdown preview is not going to necessarily show your card component or your YouTube embed, or whatever.

Brian: I wonder if you could do some clever things with Chrome extensions or something to render it for anybody who has it enabled, but we can talk to GitHub later on figuring out how that works.

But the other thing that comes up a lot of time when I deal with Markdown is the GitHub-flavored Markdown.

You mentioned "Remark" in passing, and that's probably the most success I've had with Markdown compilers and working on projects, because that project just happened to have a lot more of the bells and whistles.

But also they're using the GitHub-flavored Markdown, so I don't know if everybody in the developer world has been trained to know how tables and how things work on GitHub and translate that to their other projects. But that's another thing that I've also fallen over, is that the consistency of how Markdown is used, it seems like mostly people get it.

But I'm curious, with things like MDX is that can you also provide your flavor of Markdown too as well? Is that a part of the whole plugin architecture?

Chris: You get access to all of the ASTs, so like I said before you get Remark plugins and Rehype Plugins and whatever, and in MDX too we're taking it actually a step further.

We're saying that "If you have an MDX plugin it can control adding a couple of different plugins, like Remark and Rehype, and whatnot."

So you get to control your own pipeline through the entire process through an MDX plugin, instead of just doing one-off Remark/Rehype, whatever.

Brian: OK.

Chris: You can add support for GitHub tables or anything that you want, emoji replacements, all of the entire Remark ecosystem works, the Rehype system works, etc.

Brian: Cool. I'm curious-- Actually, before I ask my next question, I'm curious what is the craziest thing you've seen done in MDX?

Chris: There's somebody that wrote a blog post and created a code surfing environment, so as you scroll down the code blocks on the page change right next to all of the content that fades up and does stuff like that.

That was pretty intense. I wouldn't necessarily call that "Craziest," but one of the cooler and more understandable applications of it.

Brian: Very cool. I'm curious, you mentioned your--

I want to shift gears a little bit and learn more about your role as consultant and working at JAMstack and the Serverless space, because I know that you've been an engineer for quite a bit.

You've seen the transition and now people are using the term "JAMstack," so I think at the time of this podcast-- Since the first episode that wasn't a thing, and I'm seeing more and more the term "JAMstack" being applied to different products and technologies.

I'm curious of your outlook, because now your paycheck is aligned with people actually adopting these technologies.

What's your outlook on the landscape, and as far as companies adopting things like the JAMstack and these architecture decisions?

Chris: I think that giving a name to What JAMstack is, which is basically shipping static files to a CDN or whatnot, is useful because for some reason people had a mental block around why that was different than just shipping a server.

In my opinion, JAMstack and Serverless are basically the same thing and they're ways of developing applications with minimal DevOps necessity and maintenance and things like that.

Not that there's no DevOps involved at all, but it's much simpler and easier and a little bit more automated and things like that.

Everything pushes through git and then goes out through CI and then gets deployed all the time, and you get these incremental rollbacks and things like that.

Why people are adopting JAMstack is because there's a simpler architecture, it can apply to the vast majority of sites out there and the ones that are having trouble applying to are the ones with 1,000+ pages or dynamically updating e-commerce stores that want to render specific user data on every single page.

But most other things can be done in a JAMstack style, and that means that if your build process breaks your production doesn't break, which is super nice. I don't know about you, but I've shipped WordPress stuff before and that's always a bit scary to click a checkbox and just be like "I don't know if it's going to break everything or not."

Brian: Yeah, that's a good perspective too.

The simplicity I think for the majority of the sites, because I'm rolling out a bunch of side projects and ideas and these fever dreams that I woke up one day and I bought a domain name and then applied a website to it .

Being able to go from idea to dream to actual production, it's insane for me, because I feel like at the first time in my career in the last couple of years that I have the ability to actually push a product out and not be stuck on some of the more minute things of deciding what language I want to write in.

That's a decision that you don't actually have to make, and I just saw a repo that said "Static Rails" on it.

I would love to talk to Justin about that because I saw Justin Searles, he's been in the JavaScript and Ruby space for a while, but he shipped it out and now you can bundle your Rails app into static assets and host them in Netlify, which is pretty insane.

So I've seen that, I've also seen-- We are all watching Vercel as they have transitioned to the newer version of what they are today, but next JS is now fully optimized, runs in Static.

That's something we have watched for the last couple of years.

You're seeing all these-- That's what the one company I was thinking of when I was thinking "Now we're all using the word JAMstack," because now you don't have to make the hard decisions up front.

You can get something stood up really quickly and then things like MDX and going back to that conversation, you can actually--

If you haven't figured it out, and I'm thinking of rendering Markdown in the same sense of I think of iFrames.

If you haven't figured out that part of the app and just want to render, going back to the YouTube component thing, just pass in the YouTube ID and then you'll get the video there.

If there's a decision that has to be made around moving that video to another hosting provider or something different for whatever reason, just swap out the component with whatever your new version is.

That's where I'm seeing the power and the beauty of things like this and having these sandbox environments for your websites.

Chris: The programmatic access that you get to MDX components as they render, and the whole pipeline, makes it extremely powerful for things like that.

Where if I just want to have a suite of videos, let's say I have a video hosting platform like an Egghead or something like that.

Every page is an MDX doc and they all have video IDs for specific IDs.

We want to move our infrastructure from YouTube, because we-- I don't know, we bootstrapped it or something to our own infrastructure or a Vimeo Pro or something like that.

You can just swap out the video component, and now you have the IDs and you can just translate the ID when you render the component and send it somewhere else.

You don't have to go out and change every single page and every single URL and whatnot, the programmatic access is something that is very powerful for people that know how to use it.

Brian: I think you just sparked an idea in my head where I'm trying to migrate my main website, which is BrianDouglas.me

I built it probably seven years ago and it just-- It just works. It's built on Middleman. There's nothing that really needs to be updated.

The design could use some help, but I don't want to add design to it when I know I don't like the infrastructure. I want to do something shiny and new.

My thought is I want to build some sort of portfolio site where I can render different processes of my life.

Like my Twitch streaming, I just want to render that stream there.

You could do that with RSS, but then you've got to do a lot of handholding with HTML and rendering that.

I would love to be able to just pass in IDs for my blogs and IDs for my Twitch vods, and just have that render magically on the page and not have to worry about making design decisions or infrastructure decisions on how I can get the stuff working in-house on the one project.

I love this and I feel like there's so much I could dive into as I figure out how to work with MDX.

I'm curious, if someone wants to get started on MDX today or maybe they think MDX is a solution, what's the first step?

Is there the golden path of the MDX plugin that everybody uses first to get their feet wet?

Chris: It probably depends on what ecosystem you're in.

But there's a getting started on the MDX page, there is a Gatsby plugin MDX, which is something that I wrote.

So if you're in the Gatsby ecosystem that's the one you use.

I believe there's a next plugin or a couple of next plugins at this point, and those are all pointed to from the MDX documentation page.

If you go to the "Getting started," it'll have getting started for "Here's the framework that I want to use and the plugin that is associated with that."

Brian: Excellent. I love that it sounds so versatile.

I guess it works with a lot of different frameworks, a lot of different flavors of the way you want to write code.

Even going back to our JAMstack conversation, I love the fact that I don't have to make the hard decisions now.

If I decide that Fauna is my decision for hosting my data and that doesn't work out and I want to move to something else, or I want to opt-in to whatever the new technology is.

I can just effectively find and replace and hot swap stuff in, and make different decisions.

My personal site-- Well, I say "My personal project," but it's one of my many side projects.

I started this one project, which is Open Sauce, and I built it on a technology which was at the time it was GraphCool.

Now it's Prisma, and I actually was able to migrate through all the flavors of Prisma and I have since actually migrated off of Prisma because it didn't solve the problem that I needed to solve anymore. I've then switched to OneGraph.

But that entire process, I've always had a React app standing up on it and I've always had a log in, so making the app work, no one even knows unless I call it out in the repo that I've switched how my back end is being handled. I love the fact that we're able to do that.

I've also changed my authentication choices quite a few times, where I had my own.

I did Netlify Auth and then I also did Auth0 for a short amount of time. I am able to cycle through the way I want to handle authentication for my app and handle the back end, and then it sounds like with MDX if you wanted to handle different flavors of rendering, like if you just want to get it on the page for your blog or your different marketing sites, it sounds like a really cool path to walk down.

Chris: It's really cool, and the Vue support is new, so if anybody wants to use it please use it. Let us know if there are bugs.

But it's super exciting that you can just write an MDX file and then decide that you don't want to use React anymore, and maybe React isn't where you want to go.

So maybe you want to try Vue, and now you can, and you can just take your content with you and you get all the same features and the provider and the replacements and all that programmatic access.

Brian: Awesome. Is there anything else you want to let the listeners know before we transition to Picks?

Chris: Actually, MDX 2.0 is going to drop soon. If you're interested in that there's an issue open, and a PR, and get in touch.

Brian: Awesome. The second half of this-- Or, the last third of our conversation really, is Jam Picks.

These are things that we're jamming on, things that we're excited about, and it could be a movie or food or programming-related.

I failed to prep you on this, so if you don't mind I will go first.

Chris: Sure.

Brian: I guess my first pick actually will be remote conferences.

I'm on the fence as a non-pick, but also is a pick because I know each conference has been different.

I just got done with a really cool conference which was Open Source 101, and I feel like they did a really good job of having the engagement.

I think everybody is trying to figure out that we're all moving remote, but the engagement of getting attendees comfortable but also still provide content, but also in a world that we're all going to be sitting in front of our computers.

They used this tool called Hopin. They do have a site and I think you could check it out, I think it's pretty new, but they give you a nice little platform where you have different rooms.

It is all in browser as well, so it wasn't in something like a Zoom or anything like that.

Which I think Zoom is not conducive to doing large attendee events, it seems like Zoom's being used for everything else now.

But I mentioned this because they not only had the main stage where you watch the talks, they had a networking room where you're at random.

It's kind of like Chat Roulette, but at random you get matched with somebody else who wants to network with a new attendee.

Sort of like the hallway track if the hallway track was just you and one other person.

I'll admit, it was kind of awkward because I didn't know what to expect when I clicked the link.

But I did get matched with someone pretty cool. It was a student out in Raleigh, we answered a couple of questions and we connected with LinkedIn.

I only ended up connecting with one person, and also I was fumbling with my mic too as well. Because I was setting up for my talk later, so it was probably not the best time to start networking with people.

But that was an amazing experience, definitely check out Open Source 101 online. I think it's the same, Todd is the same person who runs All Things Open, so I'm sure All Things Open will have a very similar format.

That's like a 5,000 person conference in person in Raleigh, so if we end up not doing in-person conferences by the time we hit August or September I'm sure he's going to end up using this platform again.

So, definitely check out the Hopin platform and check out All Things Open, and check out Open Source 101.

Get all that content so that if you're interested in getting into open source for the first time or for the second time, I'd love for people to check that out. Did I ramble enough to give you time for picks?

Chris: Yes. I'm going to shout out to some technology that I've been working with recently that I've been building some more MDX-first approaches to building sites with, and one of the underlying technologies is SnowPack. Shout out to SnowPack.

Brian: Nice.

Chris: You should check it out, the unbundling. I think you have an episode a couple episodes ago on them.

Brian: Yeah, it was actually two episodes ago. We had Fred on.

Chris: Yeah, so I won't talk about it too much and I'll let people listen to that one. But there's also the Dynamo DB book by Alex DeBrie is really dope and would have saved me a lot of time.

So if you're interested in Serverless databases that's a great pick, and then Monica Lent just started a blogging for devs email newsletter that I would love to shout out.

If, as most people that I've talked to, you have not started your blog and not started writing yet, this is the place that you should check out.

Brian: I built a whole career on writing blogs. I wish I was actually way more consistent nowadays, because I've got so much to say but not enough time.

But I'd actually love to sign up for that too as well, because I think what really leans into success is "Don't over-index or over-optimize things, just sit down and write."

I'm actually-- I guess I'm a subscriber of your newsletter, so I'm a big fan of the content you put out there.

Actually for the most part it's pretty thought provoking, so I think you had a post or a newsletter, or an email that was about pagination.

Actually this broke my brain, like "Actually you're right. I don't need pagination, why am I trying to solve this problem when more than likely people aren't going to really scroll down or try to click through?" Pretty good article.

Chris: Yeah, that was a funny one because I think that it's just built into-- Like, if you started building something in the last 10 years it's just built into the way you do things.

It wasn't always the way we did things, and I don't think we need it for personal blogs, anyway.

Brian: It's the same thing as like, maybe it's like the hamburger menu discussion all over again.

Maybe we're going to blow up the internet by no longer doing pagination on sites and have infinite scroll forever, but also perhaps hiding stuff between some ambiguous icon was also a problem too as well.

But I am on board, like I'm done paginating anything. Let's just give me all the data when I need it and we'll figure it out later.

Chris: For sure. Speaking of hamburgers, is a hamburger a sandwich?

Brian: That's a hard question. But I think, what's the site? That should be a pick, the--

Chris: "Is This a Sandwich?"

Brian: IsThisASandwich.netlify.com. Sarah Drasner threw that out there for everybody to contemplate on Twitter, "IsThisASandwich. Netlify.app. I think actually--

Chris: It is .app now, I just checked it.

Brian: Yes. I still have some .coms, I think. Or maybe they switched over for me already. They had a cutoff date.

Chris: The cutoff passed, a couple of my stuff broke. I had to change it.

Brian: Yes. Luckily my side projects end up dying on their own in the corner, so anything that was still expected to be a .com is actually no longer around.

But, I digress. Chris, thanks so much for coming on and chatting about JAMstack and MDX. Listeners, keep spreading the jam.