Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier.

Chris Coyier: Hey! That's right. This is going to be a good one. We get a chance to just dive into the pool of JavaScript again with a super special guest. We have Sara Vieira.

Oh, I screwed it up again.

Hi!

Sara Vieira: No, you actually did not screw it up that much. You just left a huge space because you thought you were going to screw it up. [Laughter]

Chris: That's exactly what I did.

[Laughter]

Chris: Gosh, dangit!

Dave: We can fix that in post.

Sara: Yeah.

Chris: You know I have a friend who has been on the show, Lara Schenck, and her website is notlaura because she has the same problem. It's L-A-R-A. It's Sara, yeah?

Sara: Yep. Yep, that's perfect.

Chris: Ah!

[Applause]

Chris: And you're Portuguese, right, but living in Berlin. Did I get that right?

Sara: Yes, I am from Portugal. I moved to Berlin last year.

Chris: Nice!

Dave: Fun!

Chris: You're a year into Berlin land. Your Twitter bio is hilarious, "International Agent of JS BS." Yeah, I was just super excited to talk to you because you're just, I feel like, truly an international agent of JavaScript and just neck deep in all this modern JavaScript stuff, so let's talk about JavaScript. Are you cool with that?

Maybe just to back up a little, share a little bit about your journey to JavaScript. We don't have to have this whole thing be like an interview thing. I'd love to just dive into tech stuff, but I would like to know what your life is like.

Sara: What motivates you.

Chris: Yeah!

Sara: What makes you wake up in the morning?

[Laughter]

Dave: If you wanted to move a mountain, how would you do it? [Laughter] Yeah, how would you do the code?

Sara: Okay, so I started doing the codes because my dad said I couldn't do the code, so I've learned how to do the codes.

Chris: Oh, that's a great reason!

Sara: I know. Right? He tried to mansplain me at a very young age, and he failed - deeply.

Chris: Hmm.

Dave: [Laughter]

Sara: But on the other hand, he kind of won because I have zero other talents, so that's good. So, then I started working and I got hired by a company because I knew how to do CSS stuff, but I don't mean really fancy. I could flex things and they were like, "This is incredible."

Chris: Yeah.

Sara: "You sure you want the job? We'll give you the job."

Chris: Yeah.

Sara: I was like, "I want the job." They were like, "That's cool." Then I learned JavaScript there. [Laughter]

Chris: Nice.

Sara: Then I got out. [Laughter] It was very, very, very productive. But now, I actually don't use the CSS-Tricks Flexbox thing because I transferred all of their things from floats to flexbox.

Chris: Nice.

Sara: [Laughter]

Chris: Yeah. Flexbox is a wonderful tool.

Dave: Flexbox master. [Laughter]

Sara: I guess, which I mean there are worse things.

Chris: Something about JavaScript took for you, though, right? Do you use it because you have to? Do you love it? I guess I'm interested in that flow a little bit.

If you look at your Medium blog, for example, it's all about super fancy, "Deploy your React app with Docker to--" you know.

Sara: Yeah, because I still don't know how to use Docker. I use that as a thing of, like, I can go back and copy and paste it.

No, no, I really like JavaScript, but I never had the chance to learn it until I basically joined that company because I mostly did WordPress up until that point or PHP.

Chris: Ah, right.

Sara: Then when I learned that I could do anything with JavaScript, it was mind-blowing to me. [Laughter] It was insane, and it was Angular 1.

Chris: Oh, that was your first, like--

Sara: And I was still happy. Yeah, and I was still happy, so you've got to give it to that. No, my first was jQuery. We used jQuery, but I didn't fully understand that you could build entire applications with JavaScript because we've only used jQuery and then the actual application was built with PHP. I assumed that I've always lived on that thing of JavaScript is that thing that you add for the clicky things.

Chris: [Laughter]

Sara: You can make entire apps with it, and I find that incredible. That's how I got into JavaScript. I wanted to see what could I actually build that it didn't need a weird server language. Does this make any sense?

Chris: No, it absolutely does. It has an empowering nature it. You learned it a little bit and then, all of a sudden, JavaScript grows up as this language and starts putting itself everywhere from the backend to our build processes to everything.

Sara: Yeah.

Chris: Your little bit of knowledge turns into a truly empowering chunk of knowledge.

Sara: That's pretty much it. I used it for the clicky things and, all of a sudden, I was making entire apps connecting to the PayPal and making people pay for stuff with JavaScript, and I was like, "This is incredible."

Chris: Yeah.

Sara: Why do people use other things?

[Laughter]

Chris: Sure, so your website, iamsaravieira. [Laughter]

Sara: That was not close anymore.

Chris: Oh, it's getting worse and worse.

Sara: Yeah, it happens.

Chris: The link will be in the show notes, anyway. [Laughter] It's awesome because it's basically a stylized version of GraphiQL, which is like, write the query on the left. See what the query returns on the right. A little tool that kind of ships with GraphQL, generally. I end up using it every day because I work in GraphQL. I just thought it was an incredibly cool and clever thing to see you repurpose that as the homepage of your website. You're kind of a GraphQL fan as well, I take it.

Sara: Yeah. No, I'm a huge GraphQL fan as well. I did that, actually, when I was learning GraphQL, but I really enjoy GraphQL. I actually really enjoy writing servers in GraphQL, which is something that I thought I would never say, but here we are.

Chris: Tell us! Tell us about it.

Sara: Well, like, I'd never really enjoyed the backend very much, as in doing Node stuff. I don't know why but, when GraphQL came around, I was like, "This makes sense." [Laughter] For some reason, this made sense to me because I was just writing pure functions that return the thing.

There was a log of magic, but there wasn't that much magic and I really enjoyed because, also, there was a GraphiQL interface to it. I think that's what drove me into it as well is that I could actually see things.

Chris: Right.

Sara: Unlike when you make a post request and you get a JSON file. You get a JSON, but inside a UI. I was like, "Yes! This is -- yes!"

No, I've actually really enjoyed building GraphQL APIs. It's weirdly calming. It's like my cleaning process. It's like cleaning, but for your server.

Chris: Yeah, you have to be super organized about it, right?

Sara: Yeah.

Chris: I think there are probably people like me out there. I deal with GraphQL, but only as a consumer. I'd just be like, "Oh, I can use GraphiQL to kind of describe what I want," and then I copy the query over to my code. Now I have what I want.

I guess it's possible to use GraphQL, but not know it surely as deeply as you do where you're writing the schemas too and writing the server that accepts the requests and all that. I don't know where I'm going with that, necessarily, but it sounds like you enjoy all of it.

Sara: Yeah. No, I really do, and I don't think you actually need to know a lot of GraphQL to use GraphQL. I think that kind of the beauty of it. You need some days to understand that that's kind of JSON but not really JSON; kind of like a text but not really text.

Chris: Hmm.

Sara: You need to understand why it needs the weird tick things. But after that, you don't really need to know a lot about GraphQL, inside out, how it works for you to be able to use something like Gatsby, which is something that I appreciate. No one needs to care about the implementation details. You only need to get your thing and put your thing on the thing.

Chris: [Laughter]

Sara: It's the most important thing.

Dave: You know I've done the part where you kind of faux JSON and you just type all the properties you want or all the things you want back, but I've never done the Node part. What's involved in writing that? Do you have to handle every case or does GraphQL kind of know how to connect to your database to do that? I've never done that part. Can you describe how that all works on the backend?

Sara: Yeah, sure. From what I've done, there are two main ways that you can use GraphQL in the backend. One of them is to connect to a REST API. It's basically a middleware between your REST API and your client, so that back-end people can--

Chris: Right.

Dave: Okay, so Graph in the streets, REST in the sheets, sort of scenario.

Sara: Exactly.

[Laughter]

Sara: So that your back-end people can still write the normal REST APIs and you don't have to go around and refactor every single code that you've written. In that case, it's actually a helper from Apollo, so you need to define the schema of the things that you're going to get, and you need to call that endpoint and resolve that, basically.

Dave: Mm-hmm.

Sara: If you've got an endpoint of users, for example, like a user, you need to define what that endpoint will receive, like what is the exact schema of that endpoint. Then, actually, there's a helper that basically says, "On this, get the users," and it will return, by default, that JSON. It will do the automagical thing of, like, if you only request a name, it won't actually get you the REST.

Dave: Oh, I guess then, let's say a user has classes or something. That's probably a bad word for…. [Laughter] Let me use a different one. User has books.

Sara: Yes.

Dave: They have a bunch of books. Then do you write the promise kind of thing?

Sara: Yeah.

Dave: Like, okay, now that I have a user, I go find out where they're books are, right?

Sara: Yes. So, the thing is, that idea of that GraphQL makes you do less requests, basically just hides your requests if you are contacting REST endpoint because you still have to do those requests, but you're doing it somewhere else instead of doing it on the front-end, mostly.

Dave: Well, your front-end can be more expressive.

Sara: Yeah.

Dave: "I want these things. Give me these things." You have to have that written in the back-end to handle that.

Sara: Yeah.

Dave: Yeah, okay. This is making more sense to me. I just thought it was like magic, like NPM install GraphQL and, all of a sudden, [laughter] send it to my database and it works.

Chris: No, it's work, still. [Laughter]

Dave: Okay.

Sara: Yeah, I think it's actually more work because you have to define your entire schema and then everything just breaks if it's not correct.

[Laughter]

Sara: One thing that we're so used to is putting a type of "any" or putting a type "this is an object." Have fun. Uh-uh. Uh-uh. [Laughter] Not a thing.

Dave: Yeah, it just … hard.

Sara: Not a thing. Yeah, so if anything is a type of object, you basically have to say, "What is in the object?" Every single thing that's in the object. Then you cry.

Chris: Right. [Laughter]

Sara: Then it ends and you're like, "Oh, this is so nice."

Chris: It doesn't necessarily stop you from needing to understand complex data structures, in a way. If you can describe something with really simple, flatish JSON, that's cool.

I'm looking at your site, Sara. You have your name, your email address, and your GitHub and stuff, and then you have talks. Talks is a little bit more complicated because it's an array and it has the name of the talk, the date of the talk, and all that stuff.

That seems straightforward enough. I guess that's what I mean by flat, even though it's not really flat. Let's say talks had an owner, Sara, but talks could have multiple owners, let's say. You allowed that. Then in GraphQL, you could query for just talks, like return me a bunch of talks, or you could return talks by a particular user or a particular user's talk. It can flipflop either way and it confuses me on how.

[Laughter]

Sara: How things just work?

Chris: Yeah.

Sara: It's just a lot.

Chris: Like sometimes one is nested in one and sometimes it's nested the opposite direction. I guess that's where the schemas come in. I don't know.

Sara: Yeah. That's where schemas come in. Yeah. No, that is literally where schemas come in.

Chris: Good.

[Laughter]

Sara: For example, in this thing, I made a GraphQL API for the World Cup. I have no idea why. I think I was just bored. For each fixture, for example, like for each team, you can get the players. Basically, to get the players, you basically need to request a team first. Does that make sense?

Chris: Yeah.

Dave: Mm-hmm. I've got to go ask for the team, Portugal, and then got to get the players for that team.

Sara: Yep.

Dave: Yes. One step….

Sara: Yes.

Chris: Let's say you didn't want to. Let's say your API required that you also could ask for a player, too, regardless of that.

Sara: No, you can get a player, too.

Chris: Yeah.

Sara: But in this case, the "get players" only gets a team ID but, in this case, I don't think the actual API have them. If you can get the ID of that player you basically need to get the request and then respond, like do a filter of every player that you get, for example, and return only that one.

Chris: Ah! Yeah, right.

Sara: It's just normal JavaScript functions. That's the thing.

Chris: Mm-hmm.

Dave: That's how you write the Graph API.

Sara: Yeah.

Dave: That's cool. Then again, I think you do that little bit of work, or maybe it's a lot of bit of work. I would love to know what you thought. Is it a little bit or a lot of it?

Sara: I think it's a bit. I don't think it's that much work. I think if you're already making an API, it's not that much work. But if you've never seen a GraphQL API and you just want to make it simple, I cannot stress this enough. If you're making an API that just gets the weather or something, do not go with all of this stuff because, in this case, I also set the cache.

For example, if you get the players, I say players and the team IT. If it already exists, then just return it. If it doesn't exist, then get the thing and set the cache. If you ask for it again, then you don't have to.

Chris: Yeah, super-efficient.

Sara: Yeah, so it has things that actually help. If it's a simple thing, I don't think it's honestly worth it to do all of this stuff.

Chris: That cache part, you mentioned Apollo once. It seems to me almost that when people talk about GraphQL, 75% of the time they're talking about their usage of it through Apollo. At least that's what it seems to me. Maybe I'm wrong about that. If you're talking about Git, 75% of Git usage is probably through GitHub. There are plenty of alternatives, competitors, and stuff, but that's what it means. Is that true for you, too, when you use GraphQL stuff, or are you just like, it's Apollo town?

Sara: In this case, the cache is literally an object. That's it. Then you put things into the object and check it out. When I use it in the front-end, yeah, it's usually Apollo. I have never used Relay in my life.

Chris: Relay? I don't even know what you mean. Is that an Apollo alternative?

Sara: You know, technically, Apollo is the real alternative. [Laughter]

Dave: Oh.

Sara: Yeah, it really is a Facebook thing. It was released at the same time as GraphQL JS was, but pretty much everyone just uses Apollo.

Chris: Yeah.

Sara: Which is very nice. I like Apollo.

Chris: Can you describe it? What does Apollo give you, with all the stuff we've talked about?

Sara: For any GraphQL request in the front-end, it's basically a fetch, but as a post, and the body is your GraphQL request.

Chris: Yeah.

Sara: You can see how that gets ugly very, very fast. What Apollo gives you, I'm going to use the example that you're using it with either React or Vue is that, first of all, it gives you components that automatically do a lot of stuff for you. You have a query component, for example. That query component, you basically just pass the query that you want to give it and it handles the loading for you and it handles the error for you.

Chris: Mm-hmm.

Sara: It can just return the data and the error and the loading, and you can just check if it's loading or not. It handles a lot of, like, the really annoying stuff that you have to deliver every time.

It already has cache by itself, which is usually good, but sometimes it's really hard to invalidate your cache. But for example, if you go to the homepage of something and it lists a bunch of stuff, it saves it in the cache. Then when you come back to the homepage, that's already there. It's not going to try and fetch it again.

Chris: Yeah, super-efficient.

Sara: Yeah, it's super-efficient, basically. It helps a lot with that kind of stuff, and it also cleans up a lot of boilerplate. Imagine that you had to get every single one of those things in a post request, in a fetch, and then you have to set the loading for every one of them. Your state would just get huge. It's all handled in the render, basically.

One that I always did is that I created my own query components because the errors would always be the same notification, for example, and the loading would always be the same loading, so I would just get the data. Get a query component and a render function or something. I don't know what people call it these days.

Chris: I think that's right.

Sara: You just get the data and you just map all over stuff because every website is basically a glorified map.

[Laughter]

Chris: Isn't that the truth?

Sara: It is.

Chris: [Laughter]

Sara: Some of them are also just forms. [Laughter]

Chris: Yeah, forms and maps. That's it.

Sara: Yeah.

Chris: That could be a talk, I think.

Sara: If you think about it, all of CodePen and CodeSandbox are just a form.

[Laughter]

Chris: Yeah, that's where you're at now, right? It's been a little bit, but you're a developer at CodeSandbox, right?

Sara: Yes. I started last month.

Chris: Last month, so it is pretty fresh.

Sara: Yes! Still very good.

Chris: Yeah.

Sara: I'm still in the honeymoon phase, so I can only tell you good things.

Chris: [Laughter] Well--

Sara: Come back in a year. I may be able to tell you bad things. I don't know.

Chris: No.

Sara: Yeah, I've only been there since the 1st of March. I mean I was helping with the open source project before but, technically, I've only been there since the 1st of March.

Chris: Yeah, right on. That's cool. Congrats on the new gig.

Sara: Thank you.

[Banjo music]

Chris Enns: This episode is brought to you in part by WooCommerce. Today, I want to tell you about three exciting updates to WooCommerce. The first one is that WooCommerce version 3.6 shipped recently and added product blocks, so you can build rich pages with blocks in sites running WordPress version 5 or higher that show products by category, best-selling products, handpicked products, newest products, and products with specific attributes, and more. Super handy if you're using the new Guttenberg WordPress editor.

The second cool WooCommerce update is the new WooCommerce mobile app for iOS and Android. You can track your store to see which products are performing best, check revenue, view and manage orders, and get real time alerts notifying you about store activity like new orders or reviews. Be sure to search for WooCommerce mobile app on the iOS app store or Google Play today.

Finally, if you're running a WooCommerce site right now, you should check out the new dashboard for WooCommerce admin that the team released as a feature plugin. It's what's going to eventually be the default dashboard in WooCommerce, but you can check it out right now. You get all sorts of data and analytics on your WooCommerce store with a completely customizable dashboard, new reports, and a new activity panel to alert you to what's happening right now in your WooCommerce store.

If you'd like to see a WooCommerce store in operation, go check out the CodePen shop at blog.codepen.io/shop and try ordering yourself a shirt. The CodePen shop is running on WooCommerce and the shirt is one of my favorite shirts that I wear each week.

Our thanks to WooCommerce for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: You've done a ton of traveling all around the world and stuff. You've written about it. There is one of your kind of viral posts, I'm sure of many, was about that, in a way, and about how it's so cool at first and then it kind of becomes less cool. [Laughter] Over time, perhaps.

Is that a past phase now? Have you found a way to balance that? Do you want to talk about that in any way?

Sara: Yeah, the main issue at the time was that, first of all, I've never had a lot of money growing up. I wasn't poor, but I wasn't rich, so I didn't travel much as a kid. We just camped.

The first time I went on an airplane was to go to a conference, actually. It was from Porto to Warsaw. It was the first ever time that I got on a plane, so my brain associated conferences with free travel and vacations.

Chris: Yeah.

Sara: Because I didn't have money for actual vacations. [Laughter] The thing is that I was also living in Porto, which is either the butt or the face of Europe; I'm not sure which one, but it's on the edge of Europe.

Dave: That's on the sign outside of the town?

[Laughter]

Sara: But all of Portugal is the butt of Europe or the face of Europe. We need to figure this one out, but it's the edge of Europe. There is only the ocean and then the U.S. That's it.

Chris: Yep.

Dave: Mm-hmm.

Sara: The Porto airport is like, no one cares, so it doesn't have any flights to anywhere except France because all Portuguese people immigrated to France in the '80s, so now we have flights like Nantes. I don't even know where Nantes is, but there's a flight there.

The problem was, I always had to stop in airports. Since I always had to stop in airports, I had this brilliant idea. You need to understand that I'm a very, very smart human being.

Dave: Mm-hmm.

Sara: I was just like, "I'm just going to do a bunch of conferences without going home because, if I don't go home, I don't have to stop in Amsterdam again." [Laughter]

Chris: Yeah.

Sara: It's not a good idea. [Laughter]

Chris: Yeah, I mean it looks like you have 50 one year, you said, right? That's in this post. Which is one a week, which is… Wow!

Sara: I got a little bit overly excited about that.

Chris: [Laughter]

Sara: I also have some problem saying no to things, mainly when they're free. [Laughter]

Dave: Hmm. Yeah. I feel that. As a result, trying to focus on the positive, that sounds like a hell of a lot of travel. You did mostly JavaScript conferences in that year, right?

Sara: Yeah, I did a lot of JavaScript and React, mostly React and JavaScript, yeah.

Dave: React and I think you were at Vue Amsterdam. Is that right?

Sara: Yeah.

Dave: Or MC-ing that.

Sara: That was….

Dave: I guess, do you feel like you have a pretty good perspective of the JavaScript ecosystem from all of that?

Sara: I think I have some perspective from the JavaScript ecosystem. I've not met a lot of people from the Angular community. I know some, but I think I gained a lot of perspective from the React, the JavaScript, and the Vue community. I just want to say that God blessed the Vue people. They have karaoke in their parties and I am just in love with that. [Laughter] Yeah, I feel like I got this weird, random bits of knowledge about either conferences or human beings or just a JavaScript community. Honestly, I feel like the best thing that I've realized is that all of the people that we look up to are also idiots, usually.

[Laughter]

Dave: Uh-oh.

Sara: We're all idiots, and that makes it so much better. [Laughter]

Chris: Oh, that's great.

Sara: It's true. It's true.

Chris: Everybody is an idiot.

Sara: But it's great.

Chris: I'll own up to that, for sure.

Dave: That's in my speaking arrangements. No one stand too close to me because, if you find out I'm an idiot, this is a huge problem.

[Laughter]

Sara: I'm very self-conscious about my idiot-ness.

Chris: What is it like?! You burned out a little bit on the conference thing. Hopefully, you can find a way to settle that. I'm still trying to figure it out.

Sara: Oh, yeah. No, I'm way better now. I've only accepted conferences that I really want to go to and I've learned to say no and I've moved to a city that has direct flights, so I figured this one out. [Laughter]

Chris: Nice. Good.

Sara: All flights take an hour and 30 minutes now. It's great. [Laughter]

Chris: Yeah, you're pretty central.

Dave: Sorry. You can say, "I don't want to answer this question," but was the move to Berlin purely for kind of--?

Sara: Oh, God, no. No, no, no, but it helped.

Dave: Okay. Okay.

Sara: Both airports in Berlin are really, really bad, so no. My move to Berlin was mostly because I wanted to move out of Portugal. It had nothing to do with the flights. But then when I got here, because I didn't even know the second airport existed, so I thought there weren't a lot of flights here, but then I found out there was a second one, which is the bad one, but goes everywhere.

Chris: Hmm.

Dave: Oh, wow.

Sara: I'm like, this is great. I won and I didn't even know.

Dave: I don't even remember which one I went to. It was small.

Sara: The Neues Tegel. That's the good one.

Dave: Mm-hmm.

Sara: You were like, "That's the good one," yeah, so now imagine the bad one.

Dave: Whoa!

Sara: Exactly.

Dave: Whoa!

Sara: It's Schonefeld, or as I call it, Schonefell, as in hell, Schonefell.

Dave: [Laughter]

Sara: I just remembered today, which is completely unrelated, which was, today I remember that when I went to Helsinki, their airport code is HEL, so like hell but with only one L. There's a huge sign when you get in from the bus that says, "Welcome to HEL." I'm like, "Wait, what?"

[Laughter]

Chris: Whoops! That's cool. I'm sure it's intentional. Nobody would put that there.

Sara: I know it is intentional. If you've ever been to Finland, you realize that it's very, very intentional. I appreciate it.

Chris: You've had tons of experience flying all over the world going to all these conferences, gaining some kind of perspective over the JavaScript ecosystem, in a way. What's going on? I've been to a couple conferences, but rarely are they as JavaScript focused as the ones that you're attending. Tell us about what's going on. Who is winning? What's a big topic? What is this ecosystem like? Is React as winning as it seems like it is?

Sara: No, React is winning.

[Laughter]

Sara: Okay, so the thing about the JavaScript ecosystem is that people really want to build things. They're really happy about building things, so that's why we sometimes have JavaScript fatigue. It's mostly because there are a lot of passionate people about building stuff. They just want to build stuff, and that's what sometimes causes the fact that React itself has five form libraries, but I diverse.

I think React is winning. I think there are so many people using React. It doesn't mean that the other ones are losing. That means that React is more widely used, which may mean it's a good thing or it may mean it's the next Angular 1. We don't know.

Chris: Hmm.

Sara: Angular 1 was also used everywhere.

Chris: What do you mean by that? Oh, because it was so ubiquitous and then all of a sudden it dropped off the map?

Sara: Yeah. Everyone just stopped using it and realized that it wasn't scalable and stuff like that. The fact that you're winning now, that's also a thing that I've learned. The fact that everyone is using your thing now doesn't mean that they're going to be using it in a week.

Dave: Mm-hmm.

Sara: Everything just happens so fast, which is something that I've heard a lot of people that came from the backend being very confused. Why is, every six months, there a new JavaScript framework? [Laughter] Why is there, every six months, cool, new stuff? Who is making this stuff?

Chris: Yeah.

Sara: What is going on? I don't know.

Chris: My data tends to stay the same, though, so it's kind of nice that way. If you make smart data choices, that stuff can stick around. Sure, if I got a rebuild a little bit of the front-end, that's kind of a lesser big deal.

Sara: Yeah.

Dave: Your client-side data store has been through four or five different NPM patches in the last 12 months.

Sara: It started with Flux. Then it went to Redux. Now I have no idea what the cool kids use.

Chris: It's fascinating watching little stuff like this, like Svelte come. We had Rich Harris on the show not long ago, and he was talking about the upcoming release. What is it, Svelte 3, I think? It got released and people are pretty stoked about it. I think you all have a special sandbox for it on CodeSandbox now, right? Pretty cool.

When something comes out like that, it feels fundamentally different than how React handles things or even Vue handles things. I'd be interested just to hear what you think about it, generally. But if you're a big player like React and you see ideas that evolve like that, what do you do? Do you admit, "Huh, maybe that just straight up is better. Maybe we should go in that direction," or are you so bought into how you do things that you just can't change?

Sara: I think the main thing that sometimes we forget is that React is built for the community but, first, it's built for Facebook. The way that Svelte is built is that it has a compiler, so Svelte does not--

The reason why it was so fast for us to implement it in CodeSandbox is because we have to compile it in the browser, but Svelte already has a compiler to compile it in the browser. That's why it took like two days and that was it. Yeah, now it looks like I didn't do anything. Crap.

[Laughter]

Dave: I'm in two weeks; I'm in two months.

Sara: Yeah, it was so hard. I didn't sleep for three days. The fundamentals that I think we keep forgetting about these frameworks is that, in the end, they're kind of all the same. They're all the component model. None of them work as an MVC. Angular kind of does but, by the end, it's still a component model, so everything is just built with components. People just find different ways of doing it.

Chris: I love that! It seems like that's what's happened in the Web industry. If there's one thing that's been decided, it's that.

Sara: Yeah.

Chris: It's that components are the way to go.

Sara: Yeah, we are going to use components.

Chris: It happened on the JavaScript side and whatever, like front-end development and that, but it also happened on the design side. People were like, "Design systems are great. Let's build them in various sized nested components.

Sara: That was also, I think, because of the JavaScript community and the whole people that are doing the front-end started doing things in components. Instead of needing big ass sketch files or -- I don't know what people use. We use Figma.

Chris: Mm-hmm.

Sara: They just needed that tiny component and people started seeing how much it was actually -- because the thing is, designers pretty much have always done this. They just didn't know we wanted them. [Laughter]

Chris: Right.

Dave: Mm-hmm.

Chris: That's why they're so into it. I think there is some synergy happening in the industry now.

Sara: Yeah, that's the thing.

Chris: Even Figma, the app.

Sara: People are like, "Oh, you want this?"

Chris: Yeah. Yeah.

Sara: "This is important to you? Oh, that's great. Here you go. This is great," because that's how, for example, Sketch works. You add components in Sketch. That's how Figma works.

Chris: It does.

Sara: Yeah, you have a library and then you have your components. But the JavaScript word didn't work like that. Then it started working like that and it slowly came together a bit more. There are also good things in Figma and Sketch, at least, that lets you just copy the CSS. It's not perfect, but it's a huge help. Just remember going on PhotoShop and just seeing, oh, that's 14 pixels.

Chris: It seems like there are some things that we're deciding upon, like this component model is great and all that. Let's build websites. No matter what we do, let's do it like that.

What's less shaked out is the best way to--I don't know-get HTML to the browser, essentially, where the website should be rendered at all. They're so different that it can be as extreme as the single div, nothing ships, your bundle arrives, and rendering happens, or something more JAMstack-y where the whole thing just arrives and it's rendered later, or maybe there doesn't need to be JavaScript at all. It depends on the site. Those things seem so different from each other. I wonder how you think about that. Is there a good answer? Is that going to shake out?

Sara: I think the thing is, Gatsby actually, I think, helped so much, mostly because it's not a good idea to just send the div. It's not. It's just done.

Chris: [Laughter]

Sara: It's not the best thing you can do, and it's not even because it's a div. You can put it as a main. It's still bad. Server side rendering is painful, to say the least. [Laughter]

Chris: Why is that? Isn't that unfortunate? Isn't there an alternate future in which we did all this smart stuff, but we made SSR a first class citizen from day one? Wouldn't that have been nice?

Sara: That would have been great. But we're very lazy human beings, and that's why I think a lot of the websites -- a lot of the websites that I make, the small ones, are all just like, "When you get the page, here's a bunch of JavaScript!"

Chris: [Laughter]

Sara: Yeah. Here's the JavaScript! You don't have any JavaScript? Oh, no!

Chris: [Laughter]

Sara: Now, I feel like I do everything in Gatsby. [Laughter]

Chris: Yeah.

Sara: Mostly because it took away a lot of the pain. There are still a bunch of ifs that I've got to put, like if the type of window is different than undefined, but that's about it.

Chris: Oh, I see, because it's a compile, it doesn't have .DOM access or whatever.

Sara: Yeah, yeah, yeah, yeah. But I've done other websites that were on SSR, and that was painful. But also, I think Gatsby is not as painful because it has a very big plugin system.

Chris: Mm-hmm.

Sara: For example, one of the things that you always need to do in SSR is, if you use CSS and JavaScript, I use style components; you always need to render them on the server. Otherwise, that kind of looks like crap because you basically only get the HTML and then your browser is like, "Oh, there we go. Here's some CSS." Not pretty.

Chris: Yeah, you've kind of skipped the normal rendering path, right? Normally, the browser knows how to deal with styling very efficiently but, in this case, it just has to load some JavaScript and that JavaScript then finds the elements that needs to apply the styles to later or whatever. You've kind of invented your own rendering path instead.

Sara: Basically, because what the styled components in Emotion do is that they give you style tags that they basically just paste on your head, and so your HTML is like, "Wait. What's that?" Then they say, "Oh, that's CSS." Then it has to render the CSS, so you get the first pane, which may have some default CSS that you put in and then you get the JavaScript. Then you get the CSS again and your browser is just like, "I have no idea what's going on, but I hope you love this."

Chris: [Laughter]

Sara: In Gatsby, there's a plugin, and that's it.

Chris: Yeah.

Sara: You don't have to cry about it anymore. No one can say that because you use CSS and JS, you're evil, because they don't know that you're using CSS and JS because it's already there.

Chris: Yeah, it's server side render. It's already there in the HTML.

Sara: Yep.

Chris: Yeah, I'm building a little Gatsby site, so I'm figuring this stuff out for the first time for me. It's kind of interesting to think in that way. Most of the time, you can kind of just ignore that you're in an SSR environment and you're just building it like you would no matter what in React, which is nice. Then, once in a while, something comes up that you're like, "Oh, crap. That's right."

Sara: Yeah.

Chris: "This is recompiled, so I can't do that." Yeah, it's pretty weird. I'm finding the learning curve a little heavy, but it's only because I'm not--

Sara: No, it is. It is. It is. It is, but that's something that the Gatsby team has already corrected. They used to use the tagline of, "The easiest way to build…" No. [Laughter]

Chris: Eh, not really, but it is cool because it means that I get to work in components, unlike if I were to pick something like WordPress. I love WordPress. I'm a big fan. I built my career around sites and WordPress sites. I get it. I still like it. I think there's a lot of advantage to it. It does not help you at all with a component built structure, not at all.

Sara: No. No.

Chris: Unless you get really weird and bring it on your own. I feel like that's a little strong because there are ways to bring that to WordPress if you really wanted to, but it does not deliver them to you.

Sara: Yeah, I feel like the most common way is to just use WordPress as an API and you build your own front-end call it the WordPress….

Chris: Even Gatsby can do that if you wanted to use WordPress as the CMS.

Sara: Yeah, yeah, yeah, yeah, yeah. Before Gatsby, I think this is how people used to do it if they really wanted a Vue or a React front-end. They would have to get that WordPress API plugin and then hook it up themselves - pretty much, I think.

Chris: Yeah, right.

Dave: Hey. Hey. Hey, WordPress has at least three components: get_header, get_footer, and get_sidebar. I don't see why y'all are complaining. [Laughter]

Sara: And also, get_head. You forget get_head.

Dave: Oh, yeah, just the top. That's basically a helmet, right?

Chris: There is stuff like Timber, you know, Timber for whatever that's like a twig thing for WordPress that kind of brings this world to it.

Sara: That's cool.

Chris: I think it's cool. I think I'd probably tend to go that way, but I'm not sure. If I were tasked with making an entirely component-based WordPress site, I don't know what I would pick. It would either be something like Gatsby using the WordPress API or just do it in PHP and find some templating thing to help me. I don't know.

Sara: The good thing about Gatsby is that they're building a thing. I think it only works in Content. I'm not sure, so I'm going to shut up, but they're building the preview thing, which you know when you preview stuff, the "bad thing" when you're actually making a blog, if it's a huge blog with Gatsby, is that you can't preview stuff because it's on build time.

Chris: Right. Right.

Sara: It's connected to Netlify, you need to wait for Netlify to build and then preview, which is something they're fixing now. They're building preview stuff.

Chris: That's really good.

Sara: Yeah.

Chris: I work in the same office as Craft CMS, so Craft is like a WordPress competitor, sort of. It's PHP-based, but it's really good at content modeling and it has lots of great plugins and stuff as well. They are very aware that that's one of the big reasons that you'd pick a CMS like Craft is they're preview tool is so good that you enter some data or whatever and you can see exactly what you did on the rendered front-end of that. You do give up some of that, and it's not just in Gatsby. It's in anything, really.

Sara: Oh, yeah, yeah, yeah, and anything that's static.

Chris: Yeah.

Sara: It's not a Gatsby thing. It is anything. Okay. There we go. Gatsby site hosted its source on GitHub and then you can use, I think, Contentful, Sanity, or GitHub to add a preview site.

Chris: Right. Contentful and Sanity are just little CMS heads.

Sara: Yeah, yeah, yeah.

Chris: So, that could probably be flopped out with whatever, you know, Forestry or Netlify CMS, or whatever.

Sara: Yeah, yeah, yeah. Netlify CMS uses GitHub as its source of truth, actually. Am I mansplaining?

Chris: No! No, no, no, not at all. Well, no, because I don't think it's GitHub. It's like a Git -- it connects to Git something. [Laughter]

Sara: Yeah, it's a Git thing. It's a Git thing.

Chris: Yeah.

Sara: It just saves it to Git. I don't know if it actually uses the GitHub. It's like a Git thing. Who knows?

Chris: Yeah, it's fancy, though. I have it on a site, and I think it's definitely the fanciest. It's outside of my comfort zone. It's like, "Add the CMS to your site. Add this index.html file to a folder called admin, or whatever, and it just works," because it's a SPA React app, and everything it does is JavaScript magic, including the Git stuff. It blows my mind. It's amazing.

Sara: Also, I think I've only realized the actual power of Netlify when someone was like, "We want a form." I was like, "Oh, crap!" Then I went on Netlify and it said Netlify forms, and it literally was just some tags in your HTML. I had forms, and I was like, what is going on?

Chris: Yeah.

Sara: This is amazing.

Chris: That's a nice way to do it, and it works without JavaScript if it needs to.

Sara: Yeah.

Chris: You know?

Sara: Yeah. Yeah, yeah, it uses a fetch like a normal fetch if there's no JavaScript. It's incredible. I love it.

Chris: Yeah, it's really well done.

Sara: They're making it so easy now. They're making it so much easier than it used to be and it's so good.

[Laughter]

Chris: It's funny with this forms thing. It must have been in the water, right? Well, it always has been. In fact, my first start-up job that I ever got was Wufoo, which is still around.

Sara: Oh, yeah.

Chris: Wufoo was a form builder thing that you go to their site, and you drag and drop and build the form that you want. Then you paste it on there. I think it's more relevant than ever, really, because there was a time when maybe things were, like--I don't know--if WordPress takes over the world. Well, WordPress has its own form building plugins and stuff. You might be more suited to use those because then all the data from the forms lives in the WordPress database.

Sara: Yeah, it makes sense.

Chris: Maybe that's nice to keep in house. But now that the world is moving more and more JAMstack-y, I don't know if you'd agree with that, but it seems like a phenomenon that's happening.

Sara: No, I think it is. Yeah.

Chris: Wufoo is super relevant again. I mean, sure, you use Netlify forms, but just in case you didn't, couldn't, or you needed more power than that, like custom logic or whatever.

Sara: Yeah, you'd use something like Wufoo.

Chris: Yeah. You drop it on there and you're ready to rock.

Sara: The biggest thing that I remembered about Wufoo is that they had this HTML 5 input thing that I kept looking up.

Chris: Oh, that was me! I did that.

Dave: Mm-hmm.

Sara: Oh, that was awesome!

[Laughter]

Sara: I used that so much on the input form.

Chris: You know what? I think there's a better story here because I was invited to or I built that thing while I was at Wufoo and we submitted to talk at South by Southwest like 2010 or something. We got admitted to it. I went to Austin, Texas, and that's where I met Dave. Hey, Dave.

Sara: Oh, nice!

Dave: Hey!

Chris: Yeah.

Sara: It all came from Wuffoo and HTML platforms.

Dave: There you go.

Chris: Yeah. Yeah.

Dave: Inputs.

Sara: Inputs. They were great.

Dave: Thanks, inputs. [Laughter] Yeah, I'm just thinking. We're very close, Paravel, my company, is to never recommending a CMS ever again.

[Laughter]

Dave: Just because these static sites, these JAMstack kind of things are so powerful.

Chris: I would say JAMstack plus Paravel is a good match.

Dave: It's just that they're so, like, you can do so much, you know. But eventually, you hit somebody who needs an editor, like a visual editor. Eventually, you have to release control but, man, if companies could hire as crew of junior developers to take Word docs and put them on the website, it would be so much better and probably save you a lot of headaches. I don't know. I'm talking all over the board. Even giant enterprise sites could probably just be mowed down and made into a JAMstack site. [Laughter] I don't know.

Then you just change it and it deploys through GitHub and, suddenly, done. Did you break something? You just change it again and deploy it again.

Sara: One of the health providers here in Germany is called TK. TK, apparently, is the most used health provider, like health insurance thing. We have health insurance … I don't really understand it. In Portugal, you just got a number when you were born and that's it. That was just it. I'm just very confused right now.

The point is, they use what they use for forms. If you say, "I want to sign up for TK," they redirect you to Typeform.

Dave: Hmm.

Sara: So… [Laughter]

Chris: Yeah.

Dave: Wow.

Sara: Anything can be JAMstack. Even the biggest health provider of health insurance in Germany. If you want to make a call, they use Zoom. I'm weirdly proud of this company.

Chris: Yeah.

Dave: Wow.

Chris: That's great.

Sara: Yeah. Yeah.

Dave: That's smart.

Sara: Yeah.

Dave: They're just like, "You know what? Forms aren't exactly our thing. We've had some bad experiences."

Chris: Yeah.

Dave: "We'll just use Typeform."

Chris: It would be awesome if all their email addresses for their employees were just name spaced like [email protected].

[Laughter]

Sara: No, they're not. They have actual emails. Oh, no, they don't use emails.

[Laughter]

Sara: They don't believe in emails in Germany. Sorry about that.

Chris: Oh, okay. That's new to me.

Dave: You can't give out your email in Germany.

Sara: No, man.

Dave: It's a privacy law.

Sara: You need a house. [Laughter]

Dave: Yeah. GDPR.

Chris: I wonder if makefrontendshitagain.party is a JAMstack thing. Is that React?

Sara: No, it's Nuxt.

[Laughter]

Chris: No, way! Really?! It's Nuxt?

Sara: Yeah, it's Nuxt.

Chris: Oh, who would have ever guessed that. That's hilarious.

Sara: I have no idea why I used Nuxt at the time, but it is Nuxt. It's an SBA with Nuxt.

Chris: Yeah. What is Nuxt? Tell us. I don't even -- I mean, I kind of know, but I'd rather you tell me.

Sara: Oh, Nuxt. If you've never heard of Next, Next is an SSR thing for React and Nuxt -- oh, wait. No, it is JAMstack, technically, because Nuxt has to generate, so Nuxt is pretty much that, but they build on top of that and build a lot more stuff, but for Vue.

Nuxt actually has a generating thing, which basically generates the actual HTML files. It's technically JAMstack-y. Yeah, it's a JAMstack file, but it doesn't do any requests. It just shows a bunch of weird images and that's it.

Chris: It's great. I like the spirit of that site, for sure. Things have gotten a little boring lately. Maybe we're thinking in components too much. We need to start thinking in gifs again. Absolutely position gifs. [Laughter]

Sara: Yeah, they are. Some of them are.

Chris: [Laughter] I don't know. It looks like that.

Sara: No, some of them are. Pretty much likely. What I've also realized is that you shouldn't shame people for using Absolute Position if they know how they're using Absolute Position. I use a lot of Absolute Position. I feel like, over the time, I started using Absolute Position when I needed to know what I was doing. I mean I still don't know, but you know what I mean.

Chris: Yeah.

Sara: Then I stopped because I was told that that was wrong. But then, I was like, "Wait. If the parent is relative, I can do what I want."

Chris: Yes!

Sara: I am free.

Chris: See, there is always a learning curve like that, isn't there?

Sara: Yeah.

Chris: I used it, learned I was using it wrong, then my response was, "I guess I'll just never use that," and then it turns out that the answer is more baby bear. No, the porridge needs to be just the right temperature. Use it correctly and you're all good.

Sara: But I didn't know how to use it correctly. I just knew how to put things in the thing, but it never worked properly, but now it does because the parent is relative and it's great.

Chris: But what if all of a sudden you want to add a breakpoint? Then absolutely position something to the parent above that, you know. It's tricky then. I feel like just the other day I had that where I was just like, "This is nice right now but, ultimately, I want to stop the context of the position relative parent and be able to, all of a sudden, absolutely position on the parent of that."

Sara: Yeah, so my reasoning, my thing is that I only use Position Absolute if the immediate parent is relative.

Chris: Right.

Sara: If it's not, I'm like, "No. I'm going to cry."

Chris: Yeah, if you're three levels up, it's a little scary, isn't it? Yeah.

Sara: Yeah. That's about it. That's my threshold right there.

Chris: React is winning. Vue is doing pretty good too, you know. Angular is maybe the more segregated of the communities, although maybe that's not fair. I don't know, but I definitely hear less about it even though it's huge, still.

Sara: I feel like Angular is more used by enterprise. I think that's why we hear less about it. We don't really talk about enterprise.

Dave: I'm working on a project or two. [Laughter] But, yeah, no, I definitely. Like even for this show, it was like, "Who can we talk to about Angular?"

Sara: Simone. Get Simone Cotton. She's great. I love her.

Dave: All right. We'll get Simone on.

Sara: Yes!

Dave: Definitely, it was like the gears turned slower, if that makes sense.

Sara: Yeah, yeah, yeah.

Dave: You're just like, "Okay. Who is on the tip of my tongue?" We can do that, but yeah. I'm working on an Angular project, and it does have that enterprise-y feel.

Chris: Angular what? One is gone, right?

Dave: Seven.

Chris: Yeah, seven?

Sara: I think it's seven now.

Dave: Yeah. Angular 1 is bad news. Angular 2 was a bit of rough stuff, but they kind of just call it 2+, I think.

Chris: Yeah, right.

Sara: Yeah, it's AngularJS and Angular, I think.

Chris: Oh, I see.

Dave: Mm-hmm. Yep.

Chris: Angular is the new one. You don't say JS anymore; you just say Angular now.

Sara: Yeah, you just say Angular. Yeah, I think that's it.

Dave: There was some news that IO, I just kind of grifted, so this not really great reporting, but the big push is Angular 8. It's like Make Angular Great Again, just because it's going to be fast rendering. It kind of had the modules/no modules, sort of setup going on. Polyfills will be lower because right now, if you do Angular, it comes with 500 kilobytes of Polyfill and stuff like that. It's really….

Chris: Five hundred?!

Dave: It's a lot. It's maybe not that much, but it's a lot.

Sara: Yeah, it has a lot of Polyfills because it supports really older browsers. All of the events in React are actually synthetic events because of some older browsers that didn't support the normal event listeners. That's why React DOM is slightly bigger. That's why, actually, Web components don't work with React and they work with Vue, for example - I think.

Dave: Because they kind of have their own event structure.

Sara: Yeah, because they did their own synthetic event thing. Yeah.

Dave: I heard that was for React Native as well.

Chris: That's the first time I've actually understood why that's the case. Thank you.

Sara: You're welcome. Anytime. I got real mad, so I had to figure it out.

[Laughter]

Dave: They say Angular 8 has IV, which I think is more like almost kind of using this lit-html--

Sara: Yeah, that's nice.

Dave: --sort of API for writing DOM, I guess. I don't know. I don't believe it until it's out and I can play with it. Angular 8 is supposed to be a bit of a gamechanger for them.

Sara: I feel like most of the things that are running, like in Vue, you can already use Web components inside of Vue and they work. In React, they're also making strides to make that work because I think everyone is just realizing that there is a common language. If I create a component, the ideal world would be that I can plug it into Angular, React, or Vue. I think all the frameworks are actually working a bit together to try and figure out how this could work. Then you can just use whatever you want.

Chris: Wow!

Sara: Yeah, for state management and for forms.

Chris: That's your vibe. That's great.

Sara: Yeah, the JavaScript community has weird hates, but they always end up cohabitating together, which is nice.

Chris: I think we've discussed that a number of times. Web components are a platform, and the platform is pretty, pretty, generally good about evolving things, not deprecating things. The fact that Web components are in now and there are lots of browsers supporting them means they're probably, definitely not going away ever.

Are they solving all kinds of great problems right now? I'd argue that they're not. They're not compelling developers to reach for them. But it's now standardized, and they do deliver some interesting things that a framework never can. The Shadow DOM is a platform thing. It cannot be replicated practically. It's pretty cool that, now that they're here, maybe the rest of these frameworks can get onboard with it.

I think of it like ES6 imports. They're not a great idea to just ship in production because it's like they make their own requests. People are like, "Don't use that. Just bundle anyway." But now that they're standardized, all the bundlers understand that syntax and use it. It's like you've got to standardize it and then things evolve from that. It's nice that that seems to be the vibe.

Sara: I think, in my opinion of when I use Web components, I would use Web components but then put them in React or Vue so that I could get the whole thing of having the state management, having an actual framework behind it. The actual component could be used by anyone.

Chris: Right. There is this thing, Stencil. Have you seen Stencil? I've been talking with some people from them, but they're like an API for Web components, but their latest push is to be like, "Use us because it makes your Web components better in some way, but that doesn't mean don't use React, Vue, Ember, or whatever else. Use Web components and us and them altogether, which I don't quite get the vibe to it yet, but that's only my own ignorance. It's not because it's bad, but it's kind of like Web components don't give us enough, so give them some love first. But that doesn't mean, don't use React.

Sara: I think it's because Web components don't have any type of state management or anything, as in global state management.

Chris: Or re-rendering or anything.

Sara: Or re-rendering or help with any of that stuff.

Chris: Yeah.

Sara: You kind of need both things if you want to make an entire application. But the beautiful thing is that, for example, if you make a design system, they can be in Web components. If your team decides they want to switch from React to Vue, no one is going to cry because it gives you the same components.

Chris: That Stencil's whole rallying cry is that people think in design systems, build the design system with Web components, then sprinkle on your framework on top of that. Now, I'm a little nervous of that because that seems like a pretty thick stack for just something, but I don't know. Maybe not. Maybe it's fine. I don't know.

Sara: The thing is that it depends. If you have a huge company, if I have an example for a friend here that works at a huge company and they have a ton of products, and some of them are in Angular and some of them are in React, and some of them use CSS and JS, and some of them don't. If they had Web components, they didn't have to do all the hacky things they did to get everything to work together, and they don't have to refactor those components. I feel like it makes sense when you imagine several products, but you have to keep the consistency between the products.

Chris: Yeah. That's exactly right. That's why something like lightening design system, they didn't even go JavaScript at all. They said this is only in HTML and CSS framework because we know that it's going to be consumed by such a wide variety of things.

Sara: Yeah.

Chris: They even went deeper than that and said, "We're going to make design tokens," which is a fascinating concept. I think Gina Bolden (phonetic) was involved in the early thinking around that. That transcends even HTML and CSS. "We're just going to have JSON describe colors and padding in situations like that in case this design system also needs to be an iOS native thing or something.

Sara: Yeah.

Chris: Fascinating.

Sara: Yeah. Yeah. I think that's also the direction that design systems are going.

Chris: Yeah, it seems like it.

Sara: It's making it as agnostic as possible, which is good. No more fighting over frameworks. That's great.

Chris: [Laughter] Yeah.

Dave: Hopefully. It does seem like there's value. Everyone is doing components, but each is doing it a little different way, and I think it's kind of nice because I like the Vue way maybe more than the React way. It's all very similar, I think, when it gets munged down, but the authoring experience is just a little bit different, like V if statements and stuff like that is like, "Okay, I like this."

Sara: I really like that. I really like V if statements, actually.

Dave: Yeah.

Sara: I'm really into that.

Dave: Yeah, so it's just like minor things. Those minor nuances are actually fun or they're nice, I guess.

Sara: Yep, but those tiny nuances should be what drive you to the library, basically. I think that's what Web components are trying -- I think Web components are trying to take over the world, but that's what's not going to happen.

Dave: Right, or maybe the underpinnings.

Sara: I think it's the same idea of WASM. You should combine it with something else. You can build your entire website using Rust, but should you?

[Laughter]

Sara: Should you do that? I mean, maybe.

Dave: I think the answer is yes.

Sara: Obviously.

[Laughter]

Chris: It would just be interesting to see one of the frameworks or a new one or something say, "We're going to give you all that stuff that you want, but it's based on native Web components. But we're going to give you everything else, too: all the re-rendering, all the fancy syntax that you want, maybe a styling solution, a routing solution, a state management solution. All that, but your components are still Dave-slider," you know.

Sara: I really like the fact that Web components come with ShadowRoot CSS, which basically is like the scope thing in Vue.

Chris: Yeah.

Dave: Mm-hmm.

Sara: I'm like, that's great. Thank you for coming up with a CSS way of doing things because I feel like that's the thing that a lot of frameworks forgot when they built the frameworks. They were like, "How are people going to sell?" I don't know.

[Laughter]

Chris: Yeah.

Dave: Yeah.

Chris: Or they scope it, but they don't do it well enough, right? It's not a platform thing. It's fine to scope your selectors. That's a pretty good solution, really.

Sara: Yeah.

Chris: I think the styled components situation or CSS modules is awesome. I can't sing enough praises about it. It's super, dumb, little system that just scopes your selectors and that's all it does and it does a great job at that.

To do it at the platform level where it's kind of like almost like a little iframe, it's not quite, but you can't screw it up because you can't accidentally write some CSS elsewhere that penetrates in and starts screwing stuff up. It's an actual boundary. It's pretty cool.

Sara: You get global things anymore. [Laughter]

Dave: Not like you used to.

Chris: Not like you used to.

Sara: No escape hatches.

[Laughter]

Chris: Oh, well, this was the best conversation I could have hoped to have. Thanks so much, Sara, for coming on. Dave, do you have any things to say?

Dave: Yeah, Sara. Thank you so much. Yeah, thank you for sharing your perspective because it's cool to round out the view of what's going on in JS land, so appreciate that. For those who aren't following you and giving you money, how can they do that?

Sara: The best way to give me money is to give CodeSandbox money. You can become a Patreon of CodeSandbox. [Laughter]

I'm usually on Twitter, but I made it when I was about 21, so I thought I was really cool and my Twitter handle is @nikkitaftw with two K's, so it's like Nikkita for the win. My parents wanted to call me Nikkita, but for Portuguese law, you cannot call Portuguese people non-Portuguese names and that's why we all have the same name.

Chris: It's a law?!

Sara: It's the law. Yeah. You cannot.

Dave: Wow!

Sara: If I marry someone that's from America, I can call them Portuguese or American names, for example. It's an actual law. [Laughter]

Chris: That's new to me. That's incredible.

Sara: There's a list on the Internet.

Chris: Yeah.

Sara: It's just weird, but that's why everyone is called Maria and Joao in Portugal.

Chris: Hmm.

Dave: [Laughter] Those are the only two?

Sara: There's like five of them.

Dave: And Sara.

Sara: There are a lot of Saras as well.

Dave: Yeah.

Sara: There are a lot of us.

Dave: Yeah. Wonderful. Well, cool. Yeah, I definitely feel you on the "I picked a username in my 20s and now I'm stuck with it."

Sara: Yep.

Dave: So, on that note, thank you very much for coming by the show and thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

If you hate your job, head over to ShopTalkShop.com/jobs and get a brand new one because people want to hire people like you. Chris, do you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.