Swyx on Remote Development Environments and the End of Localhost

Transcript

Welcome to the InfoQ podcast [00:04]

Daniel Bryant: Hello, and welcome to the InfoQ podcast. I'm Daniel Bryant, head of Developer Relations at Ambassador Labs and News Manager here at InfoQ. Today I have the pleasure of sitting down with Shawn Wang, Head of Developer Experience at Airbyte. Shawn also goes by the name Swyx on the internet, that's Swyx, and I've been following his work for a number of years. 

His recent blog post entitled "The End of Localhost, explored local development environments and the potential move to remote developments". And this caused quite a stir in the developer communities. I wanted to chat to him more and explore the topic in more depth.

In this episode of the podcast, we cover everything from the topic of local development environments to the exploration of hybrid and remote development. And of course, the future of IDEs.

Introductions [00:42]

Let's get started. Hello, Swyx, and welcome to the InfoQ podcast. Thanks for joining us today.

Shawn "Swyx" Wang: Thank you for having me. I'm excited to chat.

Daniel Bryant: Could you briefly introduce yourself for the listeners, please?

Shawn "Swyx" Wang: My name is Shawn, I also go by Swyx. I've done a number of roles since joining tech. I used to be a trader here in London actually, where I'm recording right now, but I pivoted to tech not too long ago.

And I've worked at Netlify, Two Sigma, AWS, Temporal, and I'm currently at Airbyte. Basically just working on developer relations and developer experience, always working for a developer tools company. And on the side, I do some blogging, which is why I'm here.

Could you set the scene for writing your recent blog post "The End of Localhost: All the Cloud's a Staging Environment, and All the Laptops Merely Clients?" [01:17]

Daniel Bryant: Perfect. Yes, that's why I've been following you for many years, for your blogs. And I think you and I have led similar paths. I mean, I haven't done the trading, but we've led similar paths in the software space. We could talk for hours on developer experience, developer relations, many things.

But in particular, I was really interested by your recent blog post, The End of Localhost. And that's what we're going to frame the podcast around today. I think so many great insights for folks from all different angles, whether you're a developer, an operator, or whatever your persona is. So for folks who haven't read the blog post, could you summarize perhaps the core premise of why you put together what was called, The End of Localhost: All the Cloud's a Staging Environment, and All the Laptops Merely Clients? Great title.

Shawn "Swyx" Wang: I have a little bit of pretend Shakespeare literature bent around me. So if I can see a reference, an opportunity to squeeze it in, I will.

The premise of this, let me just start at the inciting incidents. I have been basically skeptic of the cloud development environments for the past few years. I've seen the rise of CodeSandbox, I've seen the rise of GitHub Codespaces. And I'm like, Yes, good for small things like testing stuff out, but you'll never do anything serious in these. And then I started to see people like Guillermo Rauch from Vercel saying he no longer codes on a laptop, he just has an iPad. And that starts to really shift my gears.

But the inciting incident for this particular blog post where I was really starting to take it seriously, was Sam Lambert, who's the CEO of PlanetScale, saying that PlanetScale doesn't believe in localhost on a podcast. I don't remember which podcast it was, I think it was Cloudcast or something like that? I put a link in the blog post. But for a dev tools company to come out and say that they don't care about localhost is a bolder statement than I think most people realize, because for most people a proper development experience must include a local clone of whatever the cloud environment is doing so you can run things locally without network access.

And this is exactly what I worked on at Netlify. I worked on Netlify Dev, which is a local proxy that compiles Netlify's routing services down to the CLI. At AWS we spend a lot of time building the AWS Amplify CLI, which does clone a few things. It's not a complete clone because it's very hard to clone AWS down to the local environment and that's where you start to see the issues. And mostly what is Docker Compose, but a way to locally clone your production cluster onto your local desktop. And you can see it's not a very high fidelity local clone, particularly as you start to use more and more cloud services.

And so the assertion is that this is a temporary phenomenon. This is not the end state of things, because all that we have to do and where every single cloud environment is trending, is that you should have branches. It should be cheap to spin them up and spin them down. You should not treat them like pets. You should treat them like cattle, which means if you want to spin something up for a few seconds, go ahead. It doesn't cost much. You can do it without a second thought. And so why are you wasting any time maintaining the differences or debugging differences between dev and prod when you can just have multiple prods and just swap between them?

So that is the premise of the debate. That was a personal journey that took a few years. And I sort of wrote it up in a tweet. And I was like, I want to get people's opinions. I know this will be slightly controversial, but I was very taken aback by how strongly opinion was. Obviously devs have very strong feelings about their development environment. And obviously it's the main tool of our trade, so of course, but it really split ways in terms of whether or not people use significant cloud services or they don't use significant cloud services or they don't see much benefit, and whether or not people have experienced the pain with maintaining different environments.

So one of my favorite lines, I really love this phase from Bob Metcalfe, was quoted by Marc Andreessen. The browser reduced operating systems to a poorly debugged set of drivers. The browser is essentially a better operating system for apps than the operating system itself, because it's a much easier application delivery mechanism. So if the cloud is doing the same thing to dev environments, then the cloud will reduce the dev machine to a poorly maintained set of environment mocks. We'll never have full fidelity to the production environment just because we don't have secrets or we don't have the right networking setup. We don't have to write data in place. And so anytime spent debugging dev and prod differences is time wasted as long as you can get cloud good enough. So let's go get cloud good enough.

What's the benefit of a dev environment being able to travel with you? [05:29]

Daniel Bryant: Perfect. That's a great intro. And there's so much to break down. I encourage listeners to read the full blog post and I'll definitely link it in the show notes because it's a fantastic read, straight up. I read it about 10 times now and I take away different things every time. It is a monster blog post, it's fantastic.

But a few things caught my eye and I'd love to dive into them for the listeners in a bit more detail. You've touched on a little bit there, but the ultimate developer wishlist stood out for me, as in like, what do we want as developers? I think back to my days, many Java development, did a bit JavaScript, did do a bit GoNow. And three things really stood out to me and I'd like to work through them and get your opinion on them now. 

The first one, and you hinted at that with the iPad development, but you said your personal dev environment travels with you no matter which device you use. And obviously there's GitHub Codespaces, GitPod, doc and dev environments. There's a bunch of tools out there. I'd love for you to break that down for us. What's the benefit of that dev environment traveling with you, the stop/start maybe of the dev environments? I'd love to hear your thoughts of why that was a wishlist item.

Shawn "Swyx" Wang: Oh, preface this with why I like to start with the wishlist, why I started this blog post with a wishlist. So some people might go directly into what remote dev environment is. But I like to start from the problems rather than the solutions, because solutions will come and go, but the problems remain. And as long as we can set a long term goal of what we actually want in an ideal world, we can kind of work our way backwards, to how we get there. And so that's why I started with this wishlist. And I think the dev environment traveling with you is kind of a luxury, but also it's a productivity thing. Like all your bash aliases, all your CLIs that you always use. If you use a different version of, I don't know, like what is trendy these days? Like FZF or all these sort of command line utilities that you know of, but are not fully distributed yet, but you just want to use it everywhere you go with you.

Like my favorite is Z, the little command line called Z, that remembers every folder you've been in and does a sort of frequency matching so that you can just jump back and forth between folders, just by typing a partial match of the folder name. Like all those little utilities that increase your productivity, you want to have them everywhere that you code. And sometimes you don't have access to your machine, whether you're traveling or using a coworker's laptop or you're, quote unquote, SSH'ing into a remote environment. And you're trying to debug something and you just don't have the utilities that you're used to. So now you spend some time writing lower level scripts that you would have put together in a macro, in a previous environment. So it just takes so much time to set up and people have built all sorts of tooling for this.

I think Spotify's Backstage maybe comes to mind. Netflix also has a sort of boots shopping tool that they use internally, all sorts of companies have this company dev environment. But then there's also an element of personalization that makes your dev experience yours, rather than the one that's prescribed to you by some company or your employer. And I think that is an ideal that we try to reach. We may not ever reach that because it's hard to basically teleport the whole machine regardless of any hardware. But I think we have enough generic tools and interfaces that we could possibly do 90% of that to work. One device or one tool that has made significant progress, that you did mention, was actually, VS Code implemented Settings Sync. It actually used to be a user land plug in that would post your settings to a GIST and then you'd have to download the GIST and do all sorts of funky gymnastics, but VS Code just built it in and it just works. And it downloads the extensions that you always use so you get your intelligent suggestions and it just works.

And I think that is something that is improving developer productivity as they move machines. So I think it's a luxury, maybe on the scale of things it's not as important as the other stuff, but I just chucked it in there because there's some things that, if you pick the right solution, you get a bunch of these for free together.

Can you dive into the motivations and reality of being about to spin up a dev environment on-demand? [09:04]

Daniel Bryant: Let's dive into the second item I pulled up. It is any apps environmental dependencies, everything from an HTTPS certificate to a sanitized sandbox fork of production databases are immediately available to any teammate ramping up to contribute any feature - no docs, no runbook. And I can totally, I haven't done a bunch of microservice work, empathize with this. Not only is like TLS cert's an issue, but even other services, databases, this I think is a big one. I'd like to get your take on this wishlist item.

Shawn "Swyx" Wang: So first of all, I appreciate that you called it the TLS cert. Because I actually debated whether I should say TLS cert or HTTP cert and I settled on HTTPS because that's the thing that most people see. But it's always confusing to have two names for that process. I'm a guy who, I care about docs. I think it's a mark of a good developer to write docs and to write runbooks. At the same time I know that people ignore them, or people skip steps, or they are badly written and you just can't quite follow them. And that's also very frustrating. And ultimately the best docs is the docs you don't have to read. And that is a product level improvement that you kind of have to make there. But I do see that a lot of the cloud providers and cloud setups that are out there are trending towards this place, where again, this is an outcome of treating your environment like cattle, not pets.

All these should be commoditized things and immediately available. It should not be like one of these forks or one of these certs per developer or per organization or per team or per feature. You should have multiple of these. You should have 10 of these simultaneously running if you want to. And why not? So that's why I said any teammate ramping up to contribute any feature. You should be able to work on multiple features at the same time and not have any conflicts between them and to have a relatively high fidelity fork of whatever you have in production. And something I mentioned about the sanitized fork of the production database also matters a lot. There's just some companies are working on this, which is protecting PII information. And I think these are difficult problems, but they're not unsolvable problems. And there are companies working on this.

And it's easy to see a future in which some standardized version of this is essentially solved. It will never be solved forever because data is complex and heterogenous and difficult. But on some level we can probably have some version of this future where environments are truly disposable, truly ephemeral, truly just high fidelity as possible. And I don't think there's that much of a difference from doing that. I don't think whatever improvements we can make in Localhost cannot match that. Whatever we do in production, being able to thwart that is always going to be a superior alternative. I'm trying to express something, but I don't have the words for it. Like something to code gains. The word that comes to mind is a substrate. In environment to code against, you want to have a high validity environment to code against as much as possible to your production rather than making it easy to run locally. And that's, I think, what we achieve with this vision.

Daniel Bryant: Yes, I love it. And it brought back some memories. I remember IT did a bunch of Ruby on Rails and we had some really old services running on an old version of Ruby. And I had to use RBM locally to manage my machine of different versions of Ruby, different dependencies, like GEM. The bundles were a nightmare. And then the other day I fired up GITPod, just a name check GI Bob. And I was working on two branches in two different browser tabs of the same project. And I was like, whoa, that was a little bit of ... And I'm sure you can do this with other remote dev experiences, not just GITPod, but that blew my mind, to fiddling around with RBM, all my local tools, to having two environments in two separate tabs on the same machine. I was like, that's amazing, right?

Shawn "Swyx" Wang:  To me it's just really about all these things that can be commoditized, you should never have to worry about it. It should just be a part of the workflow as ubiquitous is GIT. GIT is forking code and whatever this cloud thing is, this cloud development is, it's just forking your environment. And I think that's a very expansive vision and that papers over a lot of infrastructural work that needs to be done, but it's going to be done because in terms of vision, that is the best way. The alternative is leave things as the status quo and it is not super productive.

Maybe one more thing I'll offer, and this is something I've been thinking about a lot, which is I've been talking to the Deno guys, Ryan Dahl, and the people working on Deno Deploy and also the Cloudflare people, CloudFlare workers and workers for platforms, and essentially there's an intermediate tier that's emerging between clients and server. And that is serverless, client server serverless. And the serverless functions are kind of an ephemeral tier of compute that are easily forkable, that are trusted, but Sandbox in a way that you can run untrusted code on it. It's just a very interesting environment where you can get very, very close to production-level infrastructure in a fork. 

So I feel like there's a very strong empathy in the service movement with this movement, which is, it should be able to spin up these environments easily. And obviously the easiest one to spin up is compute but then now that trend is moving to databases. And I think more and more of the infrastructure primitives should become serverless, air-quote serverless, in that way, where it's cheap and easy to spin things up.

What is your opinion on using local emulators of remote services for testing? [13:50]

Daniel Bryant: I remember, myself, I've played around with AWS Lamda and the SAM environment and I was using LocalStack to emulate some of the things. And for some use cases, it worked really well. And for other use cases, to your point, the emulators really showed they were emulators.

Shawn "Swyx" Wang: They're always going to trail behind. These guys have put a lot of work into it, but it's kind of a losing battle or a Sisyphean battle is the Greek metaphor I would use. That you're always going to trail behind and maybe you should just stop trying.

Do you think it is currently possible to scale from coding an MVP app in your bedroom to a Unicorn within a matter of weeks? [14:14]

Daniel Bryant: I think that it's great. We can first dive into that a bit more in a minute because Yes, I totally get it. I totally get it. The final wishlist item I wanted to pick up on, because I think it frames the rest of the discussion perfectly. Because I think this is maybe a bit controversial, but I think it's great. 

You said, you can scale up MVP to Unicorn in weeks using one of the serverless or new Heroku-like platforms with off payments, databases, communication handled by world class SAS teams. And that's the vision, going from one person in their bedroom to a multi Unicorn, right? Do you really think that's possible?

Shawn "Swyx" Wang: I think that's possible. I think that should be possible, that there's something that we want to get infrastructure to a point of doing, but I respect that not everyone will want this actually. I think you should have the option to have it. You should have the technologies available to you if you want it. But at the same time, large companies will always want to have their own platform by which you run everything through. So I view the world of SAS and all these sort of infrastructure as a service companies, I view them as net additions.

You could roll it yourself. You would take a long while, you would rediscover all the foot guns that everyone else has discovered ahead of you and you would take a lot more time, but you would have full control of it. So there is some level at which it makes sense to make that bargain of, I will give over control to someone who knows more than me, I'll pay them money, I'll exchange fixed costs up front for variable costs that I know is higher in the long run, but total cost of ownership is lower. I'll do all those trade offs for my size and until such time as I need to bring it in-house, I will bring it in-house. But I think these are net additions. I think that is a positive. We just have to be very clear about what actual primitives are additive to us and what are just really very thin combinations of other primitives that we should probably just bring in-house anyway, because they don't add that much value.

It's one of those difficult things to really make a judgment of because as someone who's not a domain expert, it's always very easy to under appreciate like, oh, you're just a crond service, why do I need you? And then figure out how unreliable crond skill can be. So I think it does take some experience. I don't necessarily think that this is the biggest point for me, but I do think that this is a litmus test of how good cloud services are and if we're not there yet, maybe we should go build what's missing. And to me, as someone who's into dev tools in the startups, I'm always looking for the negative space where the existing set of solutions are not well addressed yet.

Can you walk us through some local development environments and developer experiences that you’ve encountered? [16:31]

Daniel Bryant:  I love it. I'm the same, working in tools face as well. That totally makes sense, looking for the gaps, looking for the things to join it all together. Love that, love that.

Let's move on a little bit now because you've got some great points I wanted to look into there. I was really curious to dive into existing solutions already out there. The next bit of the blog, you said, hey, Google, FAANGs, already do a bunch of this stuff and you and I were talking off mic. We know not everyone's in Netflix, we know not everyone's in Google, but often they can show us where the future might be, or there's something interesting there. So my general experience, when I chat to people, when I chat to a lot of folks in this space, they don't know how other companies develop.

It's not a thing developers talk about. They talk about architecture, but they don't necessarily talk about local dev setup. So I'd love for you to give us a bit of insight into what have you seen as you've looked around at dev environments, you looked at Google, you mentioned Slack, you mentioned a bunch of other folks in the blog post. I'd love to get your take on where is the vanguard, if you like? Where are they in terms of local or not local dev experience?

Shawn "Swyx" Wang: I want to preface this with, I haven't actually worked at any of these companies that I'm about to mention. The only big co I worked at is Amazon. And Amazon did not have a, we had one but we didn't really use it internally. I think it was, I forget the name of it. Cloud Nine?

Daniel Bryant: Oh Yes, I know it. It got acquired, right?

Shawn "Swyx" Wang: But we didn't really use it internally for anything development wise. But anyway, so the list I had and by the way, this is one part of how I blog, which is, I'll tweet out the rough direction I want it to go. And then if you have enough of a relationship with your readers, they'll contribute examples to you. So I didn't know all this when I started out, but Google, Facebook, Etsy, Tesla, Palantir, Shopify, Slack and GitHub, all chimed in with their versions of whatever the FM or workspace cloud development environment is. And at some point in their lifespan, and some of them have talked about it publicly and some of them have not. Like Tesla was not public about this, but apparently, I got one tweet that said for vehicle OS development, they moved from local to cloud because it was too expensive to run locally.

At some point it makes sense for those people, especially if they have a lot of proprietary infrastructure, if they want to restrict what their developers do or they want to provide tools that cannot be provided locally, all those things are worthwhile investments for them. And I just think it's really interesting. So I'm very much of the opinion that we should not cargo cult, which is, oh, Netflix did it. Netflix is successful therefore doing cloud development environments makes you successful. That's kind of not the way to think about this because that is the path to madness. But the way I look at technology innovation diffusion is that it usually starts at the big players and then it trickles down.

And so what I pay attention to is, when people leave, I have a few friends at Facebook, I have a few friends at Shopify, when people leave, what do they miss? And so the Facebookers talk about Facebook on Demand and Facebook, local dev doesn't exist. And that is just such a stark contrast that is immediately compelling. But that's one thing. The second thing that you want to look out for is, does it still make sense at the individual level? Is this something that you only do because you have a team of 10,000 people? Or does it make sense for three people? Does it make sense for one person? And I think this concept of cloud development environments or end of Localhost, I think it applies for one person as well because I want to work on multiple things at the same time.

So in other words, right now, there's a lot of investment in proprietary tooling at the big co's because they can afford it. Eventually, some of these people will leave. Actually some of them are, I have a list them at the end of the post, and then work on spreading this technology to everyone else. So that's kind of how innovation works. It starts proprietary and then it gets productized and commoditized. And I think that we're in the middle of seeing this happen.

Are you a fan of Wardley Maps? [19:58]

Daniel Bryant: Perfect. Are you a fan of Wardley Maps? Sorry, I'm just thinking of all the things you mentioned there.

Shawn "Swyx" Wang: Yes.

Daniel Bryant: I love Simon's work and you can literally see things going, there was that genesis to product, then commodity. Have you tried to map out, at all, the dev tooling space?

Shawn "Swyx" Wang: Oh dear. I have one. I actually have a separate post called, The Four and a Half Kinds of Developer Platforms. And my map looks very different from Wardley mapping. I think Wardley Maps do play a lot of significance in my thinking. The problem is they tend to look like conspiracy theory maps, the always sunny in Philadelphia meme. And I'm like, this is going to make people laugh at you rather than come along with you. 

So I tend to keep my dimensionality simple, two by two matrices or some kind of heroes' journey type of storytelling. But Yes, I look at things in terms of money spent, the way that industries move together or separately. So what I have is, four and half kinds of platforms would be application platforms, infrastructure platforms, developer platforms, which is the one we're talking about today, and then the fourth one would be data platforms.

Daniel Bryant: Oh, interesting.

Shawn "Swyx" Wang: So people working on data engineering. And I feel like web developers historically underestimate the amount of data engineering that is going on. And that has been the biggest blind side for me in just catching up in all of them. And the final half platform is the platform of platforms that eventually emerges at all of these companies. So particularly things like logging. You will need to log all the things and feed information from one place to the other, building off-end and obviously the singletons in the company that naturally emerge because they need to be the central store of all data, all information that is relevant to them. It's an open question. So I used to work at Temporal. It's an open question whether workflow engines count as a platform of platforms because they are used in both infrastructure and applications. And I think maybe that is something that should not be encouraged. Maybe we should have separate engines for those of them, because it's very tricky to commingle these resources together. But yes, I think it's an emerging area of debate for me, but I have mapped it out and that's the TL;DR.

What feedback have you received on your blog post? Are developers ready to give up localhost yet? [21:59]

Daniel Bryant: That's awesome. And that's another podcast we can bring you in for, is to cover those platforms because that sounds fascinating. I'll definitely be checking that blog later on. So I know we're sort of coming close-ish to time. I want to leave a bit of a gap here. You and I talked before about addressing the feedback you've got from this post, both the good feedback and the negative feedback. Because to your point earlier, that some folks really do love their local dev environments. They do treat them like pets and I've been there in the past, so I would love to get your take now on the feedback you've got when you put the tweets out there, you put the blog out there. Was it predominantly good feedback you got, predominantly bad? I'd love your take on it.

Shawn "Swyx" Wang: I think it's interesting. The thought leader types love it, and then the anonymous types don't. If I could sum up the reactions ...

Daniel Bryant: That's awesome.

Shawn "Swyx" Wang: ... it does trend to that way because I notice that the people that were positive, Jonno Duggan, Erik Bernhardson, Kelsey Hightower, Danny Ramos, Simon Willison, Paul Biggar, Patrick McKenzie. I can say these names and I don't have to introduce them. They're thought leader types. All of them were positive. And then the people I would have to introduce, or I don't even know their bio, they were saying things like, you can pry my Localhost from my cold dead hands. This is the final step in the road to the inescapable surveillance dystopia. General purpose computation on your own machine is probably going to be illegal in 20 years. It will be our greatest accomplishment if we can liberate even 1% of humanity from this soul stifling metaverse. So really cutting, really brutal. But even that last comment was agreeing, saying, this is probably inevitable, we just don't like it.

And I think there's two questions. One is, should you like it? And two is, is it inevitable, whether or not you like it? So I think the two levels to debate, maybe the second level is just, who knows? Who knows if it's actually inevitable, only history can tell. All we're doing here is we're observing some trends. Everything is trending in one direction. Maybe it'll continue, maybe not. Should we like it? That is the bigger question. And I think it's reasonable to want more control. It's always reasonable to want privacy. And I think that's why this tweet or this post did well on Hacker News in terms of up votes, but the comments just tore it to shreds.

Daniel Bryant: Brutal. Yes.

Shawn "Swyx" Wang: Because Hacker News, out of all the communities, loves privacy, loves open source, hates proprietary services. So I think that is entirely reasonable. And then the other thing to point out is, if you are a thought leader type, you probably work for a large vendor or you are a founder. So you are trying to provide proprietary services. And so you have a vested interest in encouraging people that, hey, the cloud will not harm you or the cloud is a TCO win or whatever the choice of terminology you favor. It's really up to you what your value system is. I think that my north star is, am I more productive and how much time am I spending on things I don't really want to spend time on, it's just incidental complexity? And what kind of apps do I want to develop? And my universe of apps is increasingly more infrastructure centric, more data driven than other types of apps.

If you're just the front end dev, you take markdown, you transform into HTML and then, that's about it, then go ahead, be my guest. You can do everything Localhost. Go code on your planes, go code in your mountain cabins, I don't care. But if you use any sort of significant cloud services, you will not be able to mock some percentage of them. And even if you deploy significant cluster services, you can't run that on your local machine. And so there's just a lot of reasons where you're just running into issues with development. And I think for the vast majority of people trying to make money, doing big things with technology, that's what they'll be concerned about. So I'm focused there.

Is there anything else we haven't covered that you really want to point listeners to and focus on in the blog post [25:21]

Daniel Bryant: So we're getting to the end of our time here, but I wanted to ask if there is anything else we haven't covered that you really want to point listeners to and focus on in the blog post?

Shawn "Swyx" Wang: There is one more nuance between the inner loop and outer loop where the cloud has basically already eaten the dev outer loop. So now we're just talking about whether the cloud is eating the dev inner loop. So I encourage you to read more on the blog post there.

Daniel Bryant: So the inner and outer dev loop is super interesting and probably that's a whole podcast we can do in the future. So Yes, because I've done a lot of thinking in that space as well. And that's been a fantastic tour de force of the potential end of Localhost. Fantastic. If folks want to find out more, where's the best way to engage with you, Swyx? On Twitter, LinkedIn, via your DX Tips site? Let the folks know.

Shawn "Swyx" Wang: Actually, intentionally, I don't have a LinkedIn. This has been a sticking point for recruiters because they're like, we need to hire people onto your team and people want to look you up. So I said, basically, try not to do CRUD data entry for a $26 billion company that turns on and sells your information. Literally, that's all they do. You hate Google and Facebook doing that, so why are you doing it for free on LinkedIn? Anyway, so you can reach out to me on Twitter or DX Tips. DX Tip is the new, dedicated blog that I spun out for my writing. I'm hoping for it to be maybe a baby InfoQ.

Daniel Bryant: Ah, interesting, interesting competition.

Shawn "Swyx" Wang: I don't have inhibition. I needed to split out my personal reflections from my professional reflections. And I thought that there was enough of an audience that I could do a dedicated one. I was more inspired by CSS-Tricks. So Yes, sorry. To cut a long story short, you can reach out to me there.

Thank you for joining us today! [26:46]

Daniel Bryant: This has been awesome. It's been a great chat we've got in the can here. And thank you very much for your time.

Shawn "Swyx" Wang: Thanks so much, Daniel. It was a pleasure.

Mentioned

• The End of Localhost: All the Cloud's A Staging Env, and All the Laptops Merely Clients
• Scalable, Serverless Database Platforms (podcast)