Programming Cultures with Peter Cooper

Episode Description

Peter Cooper of Cooper Press discusses his programming journey, Ruby vs JavaScript ecosystems, Hotwire, WebAssembly's future, and open source sustainability.

Episode Summary

In this conversation, Peter Cooper, creator of Cooper Press and publisher of multiple developer newsletters, joins hosts Christopher Burns and Anthony Campolo to trace his path from childhood programming on microcomputers through Perl, Ruby, and Rails, explaining why Ruby remains his primary language despite the JavaScript ecosystem's dominance. The discussion moves into DHH's pragmatic philosophy around Rails and his continued use of screencasting to demonstrate new tools like Hotwire, which Peter frames as a "back-end first" approach to modern web development in contrast to "front-end first" frameworks like RedwoodJS. The hosts explore the cultural divide between developers who start from the front end versus the back end, touching on Node, Deno, and the identity of server-side JavaScript developers. Peter makes a strong case for WebAssembly as the next transformative technology, predicting that Rust-compiled tools and frameworks will reshape front-end development and bring together previously siloed developer communities. The episode's final act tackles open source sustainability, examining models from foundation-governed projects to company-backed efforts to paid products like Remix, with Peter arguing that healthy open source projects survive as long as maintainers remain benevolent and allow community succession.

Chapters

00:00:00 - Meet Peter Cooper: From Microcomputers to Newsletters

The episode opens with the hosts welcoming Peter Cooper, known for running Cooper Press and its portfolio of developer newsletters. Anthony expresses his long-time appreciation for Peter's work, while Chris notes that the two of them share a connection through their rural Lincolnshire community, which Peter humorously compares to Kansas.

Peter walks through his programming origin story, starting with tinkering on early-80s microcomputers as a child and progressing through demo coding and Turbo Pascal in his teenage years. Despite initially wanting to become a lawyer, the dot-com boom redirected him into web design, and he quickly moved to working for himself. He traces his language journey from Perl through Ruby and Rails, eventually building a business around blogging and email newsletters in a characteristically unplanned, organic fashion.

00:03:54 - Ruby, Rails, and the Polyglot Question

Anthony asks whether Peter has pivoted to JavaScript, prompting a nuanced answer: Peter still relies heavily on Ruby but uses it beyond Rails, building APIs with Sinatra and even serverless functions on AWS Lambda. He emphasizes Ruby's fast startup time and his deep familiarity with the language after more than 15 years.

The conversation broadens into a discussion of polyglot versus monoglot programming philosophies. Chris explains his preference for JavaScript's versatility, while Anthony champions the growing tooling support for multiple languages through WebAssembly and serverless runtimes. Peter then breaks down how Rails functions as an opinionated collection of libraries, drawing a parallel to JavaScript meta-frameworks like Next.js that bundle many tools into one cohesive package.

00:07:44 - DHH's Pragmatism and the Power of Screencasting

The hosts ask about David Heinemeier Hansson and the staying power of Ruby in a JavaScript-dominated landscape. Peter highlights DHH's pragmatic two-legged approach—making money and enjoying the work—noting that formal technical correctness takes a back seat when a technology delivers results, even recounting the infamous story of Rails apps needing hundreds of daily restarts due to memory leaks in the early days.

Anthony connects this to DHH's influential screencasting style, which debuted alongside YouTube's launch in early 2005 and essentially popularized live coding demonstrations. Peter points to Hotwire's recent launch as a continuation of that tradition, where DHH builds a sophisticated real-time chat application in a short video to showcase how much more efficient Rails tooling has become over the past fifteen years.

00:13:00 - Hotwire, Front-End First vs Back-End First

Peter offers his conceptual framework for understanding Hotwire: it extends traditional server-rendered Rails apps with JavaScript that enables partial page reloads and WebSocket-driven updates, all while keeping the server as the primary authority. He contrasts this "back-end first" model with "front-end first" approaches like RedwoodJS, where development begins on the client side and reaches back to the server as needed.

Anthony shares his personal tension as someone trained in front-end development who has always aspired to be a back-end developer. Peter reflects on how his own approach to building web apps hasn't fundamentally changed since writing Perl in the late 90s, and voices his bemusement at trends like CSS-in-JavaScript, which he sees as re-merging concerns that the industry spent years carefully separating. The group acknowledges the cultural dimension of choosing between these paradigms.

00:17:44 - Node, Deno, and Server-Side JavaScript Identity

Chris asks whether Ruby developers shoehorn their front end in the same way JavaScript developers shoehorn their back end. This sparks a lively exchange about the identity of "Node developers," with Peter arguing that Node's specific standard library and API justify the distinct label over simply being called a back-end JavaScript developer.

Anthony advocates enthusiastically for Deno and recommends frameworks like Oak and Drash for building APIs, which leads Peter to a delightful discovery that Oak is an anagram of Koa, mirroring Deno's anagram of Node. The segment also touches on the fun trivia that New Relic is an anagram of its founder's name, Lew Cirne, before the conversation shifts toward personal branding and how Peter has intentionally kept himself in the background of Cooper Press.

00:20:19 - Personal Branding and the Newsletter Renaissance

Peter discusses his conversation with Corey Quinn about personal branding, explaining that he has deliberately kept his personality out of his newsletters, preferring to be known for reliable weekly delivery rather than a larger-than-life persona. He contrasts his approach with Corey Quinn's heavily personality-driven Last Week in AWS brand and considers whether the current newsletter renaissance suggests he should inject more of himself into his publications.

Chris playfully suggests Peter put his face at the top of an issue and track the subscriber response. The group shares an anecdote about secretly hiding a friend's face in newsletter graphics, and a brief tangent about their mutual acquaintance Christian Roebuck—a JavaScript developer and pizza maker who is passionate about Elm, a functional language that compiles to JavaScript.

00:22:47 - WebAssembly, Rust, and the Future of Web Development

Peter makes his boldest prediction: WebAssembly will be the defining technology of the next five years in web development. He envisions a React-like framework written in Rust and compiled to WebAssembly, citing the growing trend of build tools like esbuild being written in compiled languages for dramatic speed gains. He also highlights Microsoft's Blazor as evidence that .NET developers will increasingly enter the front-end space.

Anthony adds historical context, tracing WebAssembly's lineage from asm.js through its stabilization around 2017, and points to Rust's already significant role in tools like Deno and Prisma. Peter draws an analogy to the early days of XMLHTTPRequest before Ajax was even named, suggesting that today's developers are in a similar moment of untapped potential where combining WebRTC, WebAssembly, and Rust could produce applications no one has yet imagined.

00:28:36 - Open Source Models: Companies, Foundations, and Forks

Chris asks whether open source projects are better off backed by companies or communities. Peter outlines several models—company-driven, independent community, hybrid (like Basecamp's relationship with Rails), and foundation-governed (like Node.js and Rust)—and notes trade-offs for each, particularly around governance speed and the risk of forks.

Anthony provides valuable context on why Node was forked with io.js while Rails never was: DHH remained as Rails' benevolent dictator, whereas Ryan Dahl stepped away from Node, creating a power vacuum that Joyent, npm, and independent contributors struggled to fill. Peter argues that the key to healthy open source succession is a benevolent maintainer willing to hand over control, citing jQuery and Redis as examples of projects that thrived after their creators stepped back.

00:33:20 - Corporate Open Source, React, and Funding Software

The discussion turns to whether companies like Facebook could ever commercialize projects like React. Peter dismisses the concern, noting that Facebook has no apparent interest in entering the cloud space and that React's development budget is negligible relative to the company's scale. Chris raises a broader point about the sustainability challenge when frameworks are built by small groups of passionate individuals rather than corporations.

Anthony clarifies RedwoodJS's unique funding model as the passion project of billionaire Tom Preston-Werner's foundation, while the group examines Remix's approach of being an explicitly commercial, non-open-source product. Peter distinguishes this from the "open core" model and the GitHub Sponsors early-access strategy, ultimately concluding that software costs money to build and multiple funding approaches can coexist, each with legitimate trade-offs.

00:41:14 - Wrap-Up, Shout-Outs, and Lincolnshire Tech

Anthony thanks Peter and asks where listeners can follow his work. Peter points to his Twitter handle, mentions experimenting with Clubhouse as an emerging audio social platform, and highlights the Jamstack newsletter published under Cooper Press and written by Brian Rinaldi, whom Anthony notes will be a future guest on the show.

Peter closes with a shout-out to Lincoln Hack, the only hackathon in Lincolnshire, expressing hope that in-person events will resume after lockdowns. The hosts share a lighthearted post-show moment discussing the tiny Lincolnshire tech scene and a mutual acquaintance who avoids social media despite being active in the local developer community. The episode ends on a warm, informal note at approximately 00:44:39.

Transcript

00:00:00 - Christopher Burns

And he walks in and he's got a more expensive mic than both of us.

00:00:03 - Anthony Campolo

I mean, a man with his own name press has to have his own mic. Great to meet you, Peter. I was really excited when Chris said that he knew you and was like, "Yeah, we're gonna get Peter Cooper on." And I was like, "You mean that guy who does all those newsletters I've been reading for years?" It's such a fantastic resource.

00:00:29 - Christopher Burns

I met Peter a few times at our local hackathon, the only hackathon in our county. We're one of the biggest counties in the UK, but very rural and sparsely populated. If you're from the UK, we would say we're from farmers' country. And what we mean by that is if there's going to be a parade of vehicles, it's normally tractors.

00:00:54 - Peter Cooper

I often call it the Kansas of England, just to put it into context.

00:00:57 - Anthony Campolo

I went to school in the Central Valley, which is like an hour away from the actual Bay Area. When you see it from California, people think of San Francisco, so it's the same thing. I call it the South of California. What do you see as your zone as a programmer? How did you get into programming? What's your professional experience as a programmer? I'm curious. Can I get that background?

00:01:16 - Peter Cooper

So my background really just goes all the way back to the start, when I was given all sorts of toys and microcomputers in the early 80s, which is when I was born. I just messed around with them from day dot because my dad was heavily into that type of thing.

I was programming before I even remember. My memory can go back to, obviously, complete rubbish. It wasn't anything good. Ten PRINT hello world, twenty GOTO ten, and all that kind of stuff. But that's kind of where the seeds were sown.

I just got into programming all the way through my teenage years. I was doing demo coding and a lot of x86 Pascal, Turbo Pascal, stuff that's basically antiquated now. I kind of had a taste for it, but it wasn't what I wanted to do as a job. I actually wanted to become a lawyer. So that makes me an even worse person than people probably think I am.

[00:02:03] It didn't quite pan out. The whole dot-com side of the new media thing happened in the late 90s, and because I had the skills to do it, my parents said, "You're not going to sit around all summer holiday waiting to go to college. You're going to get a job next day." I was like, "I've got a job at a web design consultancy." They were like, "Okay, we thought you were going to get a job at Woolworths or somewhere, stacking shelves or something." I was like, "No, no, no, I'm gonna be a web designer now." I did that for a bit. It didn't really pan out too great because I'm ridiculously difficult to manage, and I ended up working for myself. I've pretty much done that ever since, kind of on and off.

I just moved from language to language. I was really into Perl for several years, building server-side stuff, which is kind of funny because a lot of the stuff from back then, some of the patterns, loop back around now with the whole serverless thing.

[00:02:47] But I moved from there to Ruby, saw Rails, and thought that was fantastic. I learned Ruby after trying to implement Rails in Perl first and completely failing at that. I just went from there building web apps, building stuff with RSS, and really getting into the whole web ecosystem of building apps and releasing them.

I went to blogging. I was heavily into Ruby and Rails, and not many people were blogging about it. From there I went into email, and it's kind of been weird random steps of like, "Oh, I like doing this. Now let's add this bit on. Now let's add this bit on." And then I've kind of ended up running 12 email newsletters. It all goes back to that initial just screwing around on a machine. No plan to this very non-deliberate free flow.

00:03:29 - Christopher Burns

You might want to say.

00:03:30 - Peter Cooper

Yeah, I'm terrible at planning.

00:03:32 - Christopher Burns

It's kind of like you just work on something until you find what's right. I found that with Ever Fund, we've gone through like five ideas, five iterations of working out what we want to do and what we're passionate about. That's the hardest thing, really. You still got to make money. You still got to learn, and you still got to be a member of society.

00:03:54 - Peter Cooper

So can we call those pivots? Then we're going to be trendy.

00:03:57 - Anthony Campolo

I'm actually curious to ask about that pivot, because it sounds like you got into Ruby on Rails back when it was just first coming out. I would imagine that was probably around 2005, right?

00:04:06 - Peter Cooper

Yeah. So it's like November or December 2004, but yeah, pretty much 2005.

00:04:10 - Anthony Campolo

Yeah. So have you, or will you, pivot to this whole JavaScript thing? Do you still kind of see yourself as just an old-school Rails developer, or have you moved more into the JavaScript ecosystem? This is an interesting theme that we see a lot in terms of some of the frameworks we talk about. A lot of old-school Ruby Rails developers who enjoyed it feel like they need to move beyond it. Both Tom and Brandon, I feel like, have this sort of opinion, so I'd be curious to get your thoughts there.

00:04:36 - Peter Cooper

I've moved beyond it, but not necessarily in the direction that you're talking about. I would say of my projects, perhaps like 20% of them involve Rails in some way or another. All the rest are either in different languages or they're still in Ruby predominantly, but they're not using Rails, so they're using Sinatra. I've built a service from scratch, that type of thing. Building more backend APIs and things like that, and even building serverless things.

Ruby is a first-class language on AWS Lambda now, has been for the last couple of years, and works very, very well for that type of environment. I know that's not the trendy thing to do and is not what things like RedwoodJS and whatever are taking that approach. But Ruby works really well in those contexts. It has fantastic startup time. It may not have the best raw performance, but in terms of just being able to get something up and running quickly and have it perform a reasonable standard, it's absolutely perfect.

[00:05:29] Because I've done the language for 15, 16 years, I've kind of become very au fait with it. So I can immediately turn to it and do something that maybe would take me a little bit longer to do with a more suitable language. I'm pretty much stuck in Ruby being my mother tongue, as it were. It's not my first language, but it has now become my main language. But I dabble with Python, JavaScript, and whatever as and when I need it. That works quite well.

00:05:57 - Anthony Campolo

Me and Chris talk about this a lot. Chris is very much a monoglot in that he loves writing JavaScript and TypeScript. I'm more of a polyglot. I like different languages, and I think it's really cool with both WebAssembly and all of these different runtimes in serverless. It seems like it's getting better and better for people who just want to write whatever language they want to write, and the tooling is slowly starting to accommodate a lot of these different languages and ecosystems. People now are implementing PHP runtimes. It's really cool for me because, like I said, I enjoy the polyglot type of programming.

00:06:40 - Christopher Burns

I don't have a problem with polyglot programming. There's just this thing in my mind: why do I need to go learn another language? JavaScript does it. It's messy and it's scrappy, but it works. And it works on everything, just about. Why do I need to go somewhere else? But in the conversation, Anthony said to me that if I started my career ten years earlier, I would be a Ruby developer, something that I don't understand. Ruby, the language, and Rails is the processor, the task processor.

00:07:14 - Peter Cooper

Rails is basically just a pile of libraries glommed together into a framework. ActiveRecord that you've probably heard of is the ORM. You've got ActionView and ActionCable, which do the WebSocket stuff. It's basically all these different things put together into one opinionated framework.

00:07:30 - Anthony Campolo

Which should sound very familiar to you, Chris.

00:07:32 - Peter Cooper

Yeah, exactly. So yeah, it's just bringing lots of different things together. And Ruby is just the underlying language that's a bit like JavaScript. You've got JavaScript, but then you've got other things on top of that, like Next.js, for example, which is built up of various pieces.

00:07:44 - Christopher Burns

What do you think of people like Dr.

00:07:48 - Peter Cooper

David Heinemeier Hansson.

00:07:49 - Christopher Burns

You know him? What do you think? Do you think the diehard Ruby is still a real, I would want to say, company presence?

00:07:58 - Peter Cooper

A thing? Yeah.

00:08:00 - Christopher Burns

Most companies tend to just be like, "We use MEAN, JavaScript, React, and Mongo, and everything else has gone out the window these days." But at Basecamp they've gone solely down Ruby, to my understanding.

00:08:16 - Peter Cooper

Yeah, and he owns lots of supercars and all that type of thing. So I guess I'm just making a little point that he might focus on one technology or another, but he's extremely successful at it.

At the end of the day, for him, it's about two things: the end result and his experience of having to work on these products. Sometimes he does seem to choose technologies that aren't necessarily the most ideal. I believe Basecamp uses MySQL very heavily, which isn't necessarily the best option nowadays for that type of thing. But the fact that it does what they need it to do, they can make it work, and he makes tons of money off doing it. So as long as he's kind of got those two legs of the stool, like, you might have three legs on this stool, which is one where you're using the exact correct tool and you're getting everything formally correct, making money, and having a good time.

[00:09:04] He's got the making the money and having a good time. So who cares about formal correctness? That seems to be very much his approach to a lot of things, which was kind of echoed when he began doing Rails. He was doing all these talks like "F you to Java" and this, that, and the other, when Java was seen as the way of building big enterprise web apps at the time. He's just chosen that approach.

But I think it resonates with a lot of people because a lot of people feel the same way, especially the most pragmatic among us. They see that, like, well, yeah, okay, you can be successful, you can have a good time, let's give it a go. So he very much emphasizes that and says, "Look, you can just throw CPU at a performance problem or you can throw more servers at a performance problem."

Perhaps the funniest example of that was many years ago. Ruby was really hard to deploy on a server. This was before things like Passenger existed and there were no serverless platforms or anything. This is like 2005. You'd have to use this thing called FastCGI on Apache, and I think Lighttpd was another HTTP server at the time.

What FastCGI would do was you'd run your Rails process as a server process, and FastCGI would connect to it and keep piping requests through it, like a CGI process. But that was running permanently, and it had so many memory leaks in it that there was a story going around that they had to restart their Rails app 400 times a day just to stop the memory accumulation going through the roof. There's been some argument as to how true that level was, but it was hundreds of times per day. And he's like, "But it worked." And we don't have that problem anymore, but it was a problem.

It's just pragmatism at the end of the day over all else, I think.

00:10:44 - Anthony Campolo

What I appreciate about the way he approached it, and this is me kind of looking back at this history, is he was really good at just demonstrating what working with the tool was actually like. I've had so many different podcast interviews where I've been talking about Redwood and explaining it to people, and everyone goes back to that Rails demo. It really was super pivotal in terms of showing people not only that you could do it that quickly, but how to do it that quickly, because you could just watch the video and then fire it up yourself.

You'd probably hit a bunch of roadblocks in the process, but you could still follow along and get to the same result. That's something that I've really taken and tried to run with, with Redwood, doing these meetup talks and going out and showing people, like, all right, here's how you fire up a blank application. Here's how you build it out, here's how you deploy it.

00:11:34 - Peter Cooper

You got to think, actually, it was a perfect storm back when Rails came out, because Rails came out in 2004 and started to become popular in January and February 2005. Something else happened at the start of 2005 that a lot of people forget, and that's when YouTube began.

There was suddenly this place where people could share videos. Screencasting almost became a thing in 2005. He was very early on with that whole "demonstrate something" approach. There were people who would record videos, but it wasn't a thing to do. You wouldn't necessarily think, "Oh, I've got this thing, let's record the screen." That was kind of an alien concept at the time.

So he was thinking ahead of the curve there and almost invented screencasting to a certain extent. He's carried on doing it, though, which is the cool thing. I don't know if you've heard about the Hotwire thing that he's been working on and has released over the last few weeks, but if you go to hotwire.dev, it's kind of like the Ruby on Rails approach to doing modern web front-end apps and everything on there.

[00:12:29] He's done yet another 12-minute video where instead of creating a blog in 15 minutes, which was the 2005 thing, it's now creating a chat application that has all those bells and whistles. It doesn't refresh the page, and you can have like ten different clients open. They all talk to each other. So he's basically just taken exactly the same model of like, "Oh, I made this work with this screencast. Now let's make a ten-times more complicated app in exactly the same amount of time."

It shows you the efficiency over time of the underlying processes, which I just thought was really cool when I watched it.

00:13:00 - Anthony Campolo

Yeah, that's something right now we're talking about in Redwood, trying to build out a larger, more complex example application for that exact reason, so that you have something you can demonstrate that's really sophisticated. Right now we do use a blog, and it's more because it's easy to understand and wrap your mind around. But at the same time, we always say that a blog is not a very good representation of what it's actually capable of doing.

I want to get back to talking about Hotwire, because this is obviously a big topic right now and sits in a lot of interesting intersections between things like server-rendered components and this tension between the front end and the back end, and how far we go into the server. I'd love to get your basic definition of what it is, how you would explain it to someone from ground zero who's never even heard of it.

00:13:46 - Peter Cooper

So I must admit I've not even used it yet. I've watched the videos or whatever. All my Rails apps are very old-fashioned Rails apps, where it just works in the very typical CRUD kind of fashion. You put together your Ruby code and it has views, and you click on a link and it renders a new view. That's that old-school server-side app.

What Hotwire does is it extends that in a variety of ways by basically keeping the server-first approach. You build everything server-side, but everything gets decorated with JavaScript that allows it to do certain things, like reload parts of the page without reloading the entire page, or hooking up to a WebSocket broker that then sends messages to you and can update things on the page in a dynamic way.

So just a term that I've kind of got in my head for this is what I would call front-end first and back-end first.

[00:14:38] I think if you take something like RedwoodJS, for example, it's almost front-end first because you're building something that's front-end, but then it can also run bits on the back end. You're looking at it from a front-end-down perspective. Whereas something like Hotwire has some of the same ideas, but it's the server pushing things into the front end that then suddenly work.

They take totally different approaches, but you can end up with similar outcomes. Developers have to pick between the two. I don't envy them because you could either pick based on your cultural allegiance. You could say, "Look, I'm a Ruby developer, I'm a Rails developer. This is what I understand, and I'm going to put my toes into the front end in a very timid fashion by sticking with the Rails approach to it." Or you could be someone who's really on the front end, doing existing Jamstack stuff, and say, "I'm not really a fan of the back end, but I need to do some back end stuff. Let's keep this front-end-first approach and approach it from that direction."

They're not super compatible. You can't really take your code from one and move it to the other very easily, even if they were the same language. If JavaScript had some equivalent of Rails and Hotwire and whatever, which you could rig up using Express and stuff like that, I guess. But the code doesn't really go across very well between those two mechanisms.

So I think there's going to be a bit of a, I don't want to say war or anything, but it's going to be a big cultural issue as to which approach you take over the next few years.

00:16:00 - Anthony Campolo

That's so interesting. I'm someone who spends a lot of time listening to podcasts from Laravel and Elixir and all these back-end frameworks, and I'm someone who is trained in front end. I feel like I was pushed into front end because that was the career path you get if you go to a boot camp today.

I've wanted to be a back-end developer this whole time. So I feel this tension so strongly within myself and my own career.

00:16:28 - Peter Cooper

Yeah. I guess one way of looking at it is just because I've been developing in some form or another for so long, I've almost just stuck with the default approach to doing something. People think of Ruby and Rails as being super progressive and super modern, and they are, but within an older-fashioned context of building from the server first.

The way I would build a Ruby app and think about building a Ruby app isn't substantially different to how I would think about building a Perl app in 1997, for example. It's very much thinking from that direction down. All this stuff that's come along in recent years, I got my head around it and experimented and stuff like that, but it's a whole new way of doing things.

Especially when you throw in things like CSS-in-JavaScript into the mix, it just makes me want to facepalm a lot of the time. I understand the benefits, but we spent so long not mixing these things together and deliberately pulling them apart. From the 90s when we had tables and bgcolor and all this kind of nonsense all jammed into HTML, we ripped all that stuff apart with CSS and JavaScript, and now it's like, "Oh, let's just mush it all together again."

[00:17:34] So yeah, there's definitely these funny cultural issues going on and stuff like that. I've kind of got my head around it, but it can be so exhausting to think about sometimes.

00:17:44 - Christopher Burns

Do you think that it also really depends on the developer at the same time? For example, most of the time you write JavaScript, you're probably writing it on a front-end-capable service, and then you go, "Now I need a back end." So then you go to a back end and add Express, for example. But do I understand, is Ruby more of a back-end language that then they go, "Now I need a front end," and then they shoehorn their front end in, and it's kind of like both of them are shoehorning the other end into the other?

00:18:17 - Anthony Campolo

There were, though, correct me if I'm wrong, Node developers who thought of themselves as specifically, "I am a JavaScript back-end person," and that was a thing for a while. I feel like it's almost kind of started to disappear a little bit just because the front end has eaten away so much.

00:18:30 - Peter Cooper

Yeah, and you got Deno as well, which is playing in that space.

00:18:33 - Christopher Burns

I don't even know what a Node developer is. Is it just someone that says, like, "I use the Node runtime"?

00:18:40 - Anthony Campolo

It's someone who writes servers in JavaScript. That's all it is.

00:18:44 - Christopher Burns

Wouldn't they just be a back-end JavaScript engineer then?

00:18:48 - Peter Cooper

That's how I would think about it.

00:18:49 - Anthony Campolo

Yeah, but you're just saying that because you're talking about how people who write JavaScript write the front end.

00:18:54 - Peter Cooper

But the thing is, Node has such a specific standard library and API that I think that's why you have to identify as being a Node developer rather than just a JavaScript developer, because you can't necessarily take those things that are in the Node world and apply them to another JavaScript back-end system like Rhino. I think that's probably an example, which to be fair, there aren't many of them. Node has basically taken over.

And that's part of the thing. It's become the brand now for server-side JavaScript, which alternative implementations like Deno, for example, are trying to do. You are correct, but I'm not quite sure whether they're going to achieve that.

00:19:28 - Anthony Campolo

I'm very big into Deno. I did a talk for Deno. I'm all in on Deno.

00:19:32 - Peter Cooper

Yeah, I've heard a lot of people using it to build tools and stuff, which is kind of cool. Not for necessarily building web apps, but for building, like, "Oh, I've got this file of whatever. I need to crunch it and move it here or there," that type of thing.

00:19:44 - Anthony Campolo

Yeah, you can do it with Oak. It's the closest equivalent to something like Express, even though it's based more on Koa. And then Drash has the best docs and the fastest performance I've examined, kind of like all the main web frameworks. So I'd say check out Oak and check out Drash if you're someone who wants to build an actual API with Deno.

00:20:02 - Peter Cooper

You just made me realize that Oak has to be an anagram of Koa, and then Deno's an anagram of Node. Yeah, okay. It never even occurred to me. It's like how New Relic is an anagram of the founder's name.

00:20:13 - Anthony Campolo

I didn't know that.

00:20:13 - Peter Cooper

Yeah, his name's Lew Cirne, and it's an anagram of New Relic. There you go. Another piece of trivia for you.

00:20:19 - Anthony Campolo

Something I was curious to talk to you about. I listened to an interview you did with Corey Quinn, and you guys had an interesting discussion about the nature of personal branding. What I got from the conversation is you feel like you've built a really powerful, kind of faceless empire, and you don't necessarily feel like Peter Cooper is a brand so much as Cooper Press is a brand.

00:20:41 - Peter Cooper

I think we just accidentally spoke about it. It's one of those topics that you don't really sit and think about too much until someone puts you on the spot. I've always tried to keep myself out of the work to a certain extent, other than my insights and opinion and where I think I can add value to something. But I try and keep me as a person out of it because I assume people aren't interested. I'm not sitting in the mirror looking at myself going, "Oh, you're so interesting." So I don't expect anyone else to be doing the same.

Maybe this whole renaissance of newsletters that we're seeing all over the place shows that personality is important. Even people like Corey Quinn, for example, Last Week in AWS, if anyone's listening and hasn't heard of him, he rounds up AWS news on Twitter and in email. He's super heavily, personally invested in his business as a personality, complete with all of his snark and jokes and this, that, and the other.

[00:21:30] And people just know him for that. Whereas I'm not really known for any of that. I'm just known for getting these things out every week, reliably, which isn't super exciting at all, but it has to be done.

So yeah, it's got me thinking about how I can inject more of myself into this. But then I sit and think, well, do I need to? So it's always a balancing act.

00:21:48 - Christopher Burns

Maybe what you should do first is the next time you publish a Ruby newsletter, just put your face at the top of it and see if you go down or up in subscribers.

00:21:58 - Peter Cooper

I know we were talking about Christian Roebuck earlier, just a random name to throw out there. The graphics that we put at the top of each issue, we've sometimes secretly hidden his face in certain issues. We sometimes do some fun stuff, but I need to put myself in there properly rather than just messing around.

This is one of the things about running your own business. You get to mess around a lot, which is quite fun, but sometimes you got to get a bit serious.

00:22:18 - Christopher Burns

Roebuck, now a professional pizza maker.

00:22:21 - Peter Cooper

He is a professional JavaScript developer and pizza maker. That's a combination that I don't think exists.

00:22:27 - Christopher Burns

He's a very special JavaScript developer. L, is it L?

00:22:31 - Peter Cooper

L?

00:22:31 - Christopher Burns

It's not JavaScript. It's like Elm.

00:22:33 - Anthony Campolo

Elm.

00:22:34 - Peter Cooper

Oh, Elm. Yeah. Oh, so that's something. Yeah.

00:22:36 - Anthony Campolo

Functional language that compiles down to JavaScript. It's very interesting. It's based on Haskell.

00:22:41 - Peter Cooper

Yeah. He's very, very keen on that. I looked at it and it just wasn't for me, but he's very bullish on that.

00:22:47 - Christopher Burns

What do you think the big thing will be in web development in the next five years, agnostic of language?

00:22:55 - Peter Cooper

WebAssembly, yeah, definitely. I've seen other people saying this as well. I don't think it's a particularly amazing thing to be saying right now, but I've seen people predicting that the next big thing in the JavaScript space will be something that's a bit like React, but probably written in Rust, compiled down with WebAssembly. Super fast, super light, super tiny, all that type of thing.

Now that pretty much every single internet device under the sun runs WebAssembly in some form or another, at least something that's being used to access the web in anger anyway, will generally support WebAssembly now. Like, why not?

And we're seeing this massive boom in front-end web development of tools not being written in JavaScript anymore. Things like esbuild. There's a load of tools linked to in JavaScript Weekly recently, but my memory is very poor with names of projects. There's a whole bunch of different projects, like linters and bundlers and things, that are written in Go and Rust, basically languages that are very, very fast once they're compiled.

[00:23:51] I can only see more of that occurring. Now, I don't reckon you're going to write all of your front-end, typical CRUD type stuff in Rust, for example. It's a little bit verbose. But to be the cogs in the front-end engine, it makes sense to use languages like Rust and Go, probably less so Go because of the garbage collection thing. But with Rust, I'm seeing so many people being won over by its benefits and its speed that there's going to be more of this. So watch this space: WebAssembly, Rust, building tools, building front-end frameworks, things like that. It's going to happen.

00:24:29 - Christopher Burns

I think I just had a shot-myself-in-the-foot moment. I decided to look up WebAssembly compilers, and I saw that Swift is a compiler. I listened to Apple Podcasts, and they're like, "Yeah, you could write a whole website in Swift these days." I was like, "How do you do that?" It's obviously compiled down to WebAssembly.

00:24:47 - Peter Cooper

Now you can do the same from the .NET world as well. So this will bring a lot of people in. I don't know what your connection with the .NET world is, but I feel like sometimes I see a lot of personalities in the .NET world who are massive, and I'm like, "I've never heard of you," just because we're in totally different spaces, and it's vice versa as well.

But I think we're going to see more people from those sorts of worlds. .NET people can come in with a tool called Blazor, which basically lets you use things like C#, for example, in the front end, and it all compiles down with WebAssembly. It's all supported by Microsoft. They're big on it. They're pushing it.

We're going to have lots of interesting extra names and faces and ideas coming into, I'm not going to say our space, but coming into this broader front-end church. It's going to be really fun, really interesting.

[00:25:36] It's not like when we had Flash, for example. People that did ActionScript, there was no ActionScript, JavaScript kind of thing. They're almost the same language, but there was no real integration between the two. We're going to see that a lot more. WebAssembly is going to be that thing. It's not just going to be a technology, it's going to be a cultural thing that brings together some of these tribes.

I think now I might be getting a little bit far off on that, but I can't see why it wouldn't happen. So yeah, I'm very bullish on that.

00:26:07 - Anthony Campolo

I've been tracking WebAssembly for at least two years now, and it first came out with asm.js, which goes back like six or seven years. Then what we think of as WebAssembly proper was around, like, I think 2017 is when it really got its act together. So at the point now where it's stabilizing, it's about developer tooling now.

It's like, can you make it nice enough to write that developers actually want to do it? The written-in-Rust kind of thing has been present in this conversation already. Deno is written in Rust, that's a perfect example. We talk about Prisma all the time. Prisma is written in Rust. We don't really think of that as this Rust tool that's enabling full-stack Jamstack, but it already is right there.

Toast is another one I'm interested in. This is Chris Biscardi. He's using Toast. I think it's just like a static site generator, but Rust is a great tool for that because you want to be able to generate tens of thousands of pages within minutes.

I think it's great.

00:26:58 - Peter Cooper

We've got all these moving parts now, which is really cool. I remember back in 2005 reading the documentation for XMLHTTPRequest, which Microsoft were the only people who had actually documented it at the time because they had invented it to act as a way of dynamically sending XML backwards and forwards from the browser.

I was looking at this and thought, this is really cool. I could use this for so many things. So I built a basic library to use it from Rails. This is before Ajax was even coined as a term.

I was playing with certain parts of it and I was like, "Well, I can kind of see how this is cool, but I can't really see the future of it." I wasn't thinking about what it has now become, where suddenly we had Google Maps turn up and Gmail and all these apps that then showed us what can happen if you don't have to keep changing the page whenever you're doing something. We didn't even call them apps online. They were just web pages. We could think about them as applications.

I feel that now we're at a similar spot where we can go and look up the specs for things like WebRTC and WebAssembly and look at what Rust is doing. But there's this massive gap of imagination, I think, where we can join this, to this, to this, and produce this really cool thing that we can't yet imagine.

So I think it's a really great time to be a developer in this space. Combining the front end and the back end, whether it is you go from the front end first or the back end first, whatever you're doing, I think this is a really exciting time because there's so much that could be built that we're not quite thinking about yet, just like no one was thinking about Google Maps or Gmail at some point. Yeah, that's the next thing.

So I don't know what it is, but I'm looking forward to whatever it is that everyone produces.

00:28:36 - Christopher Burns

What do you think is necessarily better for the open source community, when a project is backed by a company or a group of people?

00:28:49 - Peter Cooper

Yeah, that's kind of a tricky question. I'm not super opinionated on that, to be honest. I've seen both approaches work. You could also argue that there's a bit of a hybrid approach, which is like the Basecamp approach where they didn't start the company to just do Rails. They just extracted it from something and they support it as almost a charitable thing.

To be honest, I can't imagine the fact that they maintain Rails actually gains them any customers to Basecamp. It does to a certain extent, but it's not their business. It's not like MongoDB Inc., who deliberately make money from people signing up and playing with the community version and then needing support for the full thing. Basecamp don't make any money off Rails other than using it to build apps.

So there is that hybrid model where a company doesn't make money from their open source, but they do it as a byproduct of their main business.

[00:29:40] I've seen it work in every different way. There are places that just won't even go anywhere near commercialization. It's just a completely open source thing, more common in the Linux world in particular. You don't see companies springing up around certain technologies there.

If something gets big enough, you'll see a foundation pop up, which is perhaps a fourth model to put into that. So I think Rust is forming a foundation right now. Node.js has had a foundation around it for some time. Those sorts of projects gain a lot of governance, which can be good and bad for the project. It can make it reliable in a way that a company-backed project would be, but it makes it hard to add new features and all that type of thing.

People threaten to do forks and stuff, which has happened with Node in the past. That hasn't happened with Rails. That's an interesting thing. I've never even thought about that. But Rails is a project that no one has really threatened to fork, whereas Node has been forked twice, once with io.js, which, sorry, go.

00:30:37 - Anthony Campolo

There's a good reason for that. What's that? DHH never left Rails as the benevolent dictator, whereas Ryan did. Ryan, around 2012, basically said Node is finished. This is actually what he said. He said Node is done, so I'm gonna go on and do some other stuff.

Then you had npm become the thing, so npm became in charge of Node. But also you had Joyent, who had all the people who were working on Node. So you had this weird tension between Joyent and npm. And then you had people, often like Russians, who are just hackers and wanted to get their PRs merged. That's what triggered the initial fork with io.js. This Russian hacker who was mad that Joyent wasn't merging his pull requests, so he forked it. Everyone else rallied around that as the reason to then get all these new V8 improvements and stuff, and they ended up getting a lot out of it. And then that's what led to the two foundations merging back together.

But all of this happened because the guy who actually created it in the first place had peaced out years ago.

00:31:35 - Peter Cooper

I guess going back to the question about whether that's good or not, there are pros and cons of every different model I've just rattled through. So no, I don't have a specific answer to that question. I guess we've covered the options.

The one thing that I find kind of boring, just as a developer, is when a company builds a product and it's kind of open source or semi-open source. People say, look, this is definitely not open source because it doesn't have all the right things in the license, but whatever. I don't like it when a company opens something, but then you can tell it's a thin veneer for being commercial about the product.

At least with something like Redis, which is a common data structure server or cache server people use, someone built that independently and it became popular, and then a company kind of acquired it and now offers commercial services that add to Redis functionality. But they haven't taken over the actual underlying project as such.

[00:32:36] So I use Redis all over the place for all sorts of things, and I haven't paid anyone a cent for it. I like that approach. But I don't like it when a company is like, "Oh yeah, we've got this open source kind of community version of our product." Yeah, but you can't use it in anything unless you share every single piece of source code that you use. It's just kind of dull. If you want me to buy something, just make me pay for it. You're basically giving me a free trial.

So that's the only model I don't really like. But I can also see the reasons why people do it, because otherwise you end up with people like AWS coming along and saying, "Oh, here's the source code for a database service that we don't currently have. We're going to run a managed version of this and not give you a single cent." So there are so many issues like that to deal with in the open source world that it's confusing, it's complex, and I can't deem any one way to be better than the other.

00:33:20 - Christopher Burns

The main reason I asked the question was it's quite easy to look at things like Facebook and say Facebook made React, and React wouldn't be where it is now without Facebook. But then you look at Facebook's money. Exactly. And how long is it until Facebook commercializes React server-side components? Could they charge for them?

00:33:46 - Peter Cooper

I'm not convinced. I don't think.

00:33:48 - Unidentified Speaker

Hard no on that.

00:33:50 - Peter Cooper

I don't see Facebook. Facebook have never, at least in my eyes, really shown a big interest in entering the cloud space. They've clearly got a lot of infrastructure, but it's not like they've ever released any kind of products, not in the same way Amazon or Microsoft have. So I wouldn't be concerned about that.

But the fact is they now use React so heavily on the front end, which wasn't the case when React first came out. It was actually kind of more of an experimental thing for them. But now they're writing specifically about how they use React everywhere on the front end at Facebook. So they have a huge vested interest in keeping it going.

I don't think they necessarily have a vested interest in having the rest of the community keep it going. They just need it for themselves. But the fact is they benefit from everyone contributing components to it and whatever anyway. But they're so huge that any money they spend on React is basically a rounding error in their lunch bill.

[00:34:39] Like it's nothing to Facebook.

00:34:41 - Christopher Burns

I think it's really important that we don't talk about being the torchbearer as a company. The company's faceless. It could be around for 200 years and still be maintaining something. But when we look at these projects and these things that are not even built yet, who's going to build them? Who's going to maintain them? Who's going to keep them up to date?

That's such a big problem with open source that there's no one answer with FSJam. Every single framework so far has been a group of people choosing to say, "I want to do this better." None of them are backed by companies, as I understand.

00:35:24 - Peter Cooper

Yeah. I mean, you could argue that RedwoodJS is backed by a billionaire.

00:35:27 - Anthony Campolo

Okay, so RedwoodJS is backed by a foundation called Preston-Werner Ventures, which is Tom's foundation. So it is not backed necessarily by a company, but it's backed by a foundation by, yes, like you say, a dude who is a billionaire. So I tell people it's the passion project of an eccentric billionaire.

00:35:46 - Unidentified Speaker

It literally is. And that's okay.

00:35:48 - Peter Cooper

That's fine.

00:35:49 - Christopher Burns

It is, but it's this thing about being a torchbearer. And what you said about Node a minute ago, he peaced out. Who was the guy?

00:35:58 - Peter Cooper

What? Ryan.

00:35:58 - Unidentified Speaker

Ryan.

00:35:59 - Peter Cooper

Ryan.

00:35:59 - Unidentified Speaker

Yeah.

00:36:00 - Christopher Burns

Ryan Dahl. He peaced out and was like, "I'm done with it. See you later." It's this interesting thing of if you're the creator, should you be the maintainer? If we could separate those two things and just say, "I've created it, and then I no longer want to maintain it," would open source be better or worse? I don't know.

00:36:20 - Peter Cooper

It seems to have been better so far because obviously if you do something completely commercially, it depends upon someone acquiring the business or running it as a business, which is a completely different kettle of fish to running an open source project.

The good thing about an open source project is it only lives and survives if people are actively using it and actively interested in it. So it's a really good gauge of whether a project is any good or not, whether it's still alive or not. So like jQuery, for example, people moan about jQuery like it's everywhere, but the fact is it is everywhere. People are still working on it. It's not the most attractive thing to be working on, but it's used so heavily that it's living on anyway, and that really is a sign of just how good it is.

I'm not gonna make any bones about it. jQuery is fantastic, it's still heavily used, and a lot of people turn to it as their first thing to use in a project.

[00:37:07] So I think projects like that really prove that the open source model works, because if something's being used, it's going to get maintained. In fact, core-js is probably one counterexample recently that I can think of. I think that's more because the keys to the kingdom with that are in one person's hands, and there's been some arguments over should core-js be forked and so on.

But that's a rare counterexample to that, where something's heavily used and not many people are contributing to it, and that's because of the maintainer. As long as the maintainer has the right attitude and is happy for something to live on, then we've not got a problem.

That was true with Ryan Dahl. That's true of John Resig, who's not involved with jQuery anymore, as far as I understand it. These sort of people may have stepped back, but they've stepped back and not had a power vacuum. They've allowed people to come in. That's happened with Redis recently as well.

[00:37:54] The founder stepped back. So when you have benevolent, that's the benevolent dictator for life thing. If they chop the for life off the end, as long as they're benevolent and they give the project over to someone else or say, "Look, community, you can run this thing," great.

If they're like, "No, I'm going to keep the commit bits for this, and I'm not going to let anyone update anything because I built this and I don't want anyone getting the credit," that's when things get really, really bad. But we don't see a lot of that. So yeah, happy days.

00:38:22 - Christopher Burns

I guess my final question is, what do you think of closed open programs and things? I don't know if you know or you heard of Remix Run done by Michael Jackson and Brian Florence. Brian.

00:38:36 - Peter Cooper

Yes, yes.

00:38:37 - Christopher Burns

Is this like a closed-open thing?

00:38:40 - Peter Cooper

Yeah.

00:38:41 - Christopher Burns

What do you think of that?

00:38:42 - Peter Cooper

I guess there's two ways to look at it. So one is that some people refer to closed open as being things like I mentioned earlier with MongoDB where things now have licenses that aren't what you would call truly open source. So they restrict what you can do so that people like AWS can't just rip it off. So you've got that kind of closed open.

But then there's this other thing that has come along in recent years where I've actually seen people say, "I'm working on this cool open source thing, and I'm gonna only let my GitHub sponsors see it until I get 100 or 200 of them or whatever it is, and then I'll release it completely for free so everyone can access it." I mean, it's a growth hack. People who are really interested think, "Oh yeah, I'll spend $5 a month, $10 a month to have a look." But then secondly, the fact that when they get 100 sponsors on their GitHub profile, it makes them a lot easier to get the next hundred, the next hundred, and so on.

[00:39:31] It's really hard to get that first group, so you can almost use it to get people into that funnel and social proof and everything. Does it work as a business model? It seems to be working for the Remix guys because I keep seeing good stuff about what they're doing.

I've not paid a huge amount of attention to it, because I find that type of thing extremely hard to promote unless there's some super compelling video or something that says, "Look, here's what this magical thing does." I find it really hard to sell to a readership and say, "Oh yeah, there's this really cool thing. It's like $200, and I can't really tell you much about it because I've not used it yet." So it kind of self-limits itself.

But I don't know what their plan is about eventually making it a lot more open, a lot more freely available. Maybe you know more about that than me because I've not dug into it.

00:40:15 - Anthony Campolo

What you're talking about with MongoDB, the term people use for that is called open core. So there's the core and then you build services around it.

There isn't really a term for what Remix is doing, and I don't think they would use the term closed open because they're not claiming it to be open sourced in any respect whatsoever. They're saying, "We've done lots of open source work in our lives. We think it's great. This is not an open source project. This is a product we are selling."

00:40:41 - Peter Cooper

That's not even part of the plan.

00:40:42 - Anthony Campolo

Okay, exactly. Yeah. The idea is that it supports things like React Router, but Remix is a paid product, is not an open source project, and is not intended to be an open source project. They're saying, "This is a product we are selling." So for them, they're like, "We need to sell a certain amount and then that's going to cover the cost because that's how a business works." They're like, "We're a business. We're selling a thing."

00:41:04 - Christopher Burns

We need to fund people. At the end of the day, software costs money, and if they're not making it, then it's not being made. At the end of the day, I support it. Do you have any questions?

00:41:14 - Anthony Campolo

Anthony, I was gonna say thank you for being here. Peter, I really love getting people's perspectives who've been in the industry for a while and have seen a lot of these developments because I'm a huge history nerd and huge history buff about all this stuff.

I'm coming in so new and so fresh to all this compared to someone with a little more experience. Why don't you let us know where people can get ahold of you, and what's the best way to follow what you're doing?

00:41:41 - Peter Cooper

I'll have a couple of things to mention. The first thing is probably follow me on Twitter. That's the best place, the most consistent place. I'm just Peter C on there. That's P-E-T-E-R-C on Twitter.

I'm messing around with Clubhouse as well now, so I'm Peter Cooper on there, if anyone happens to be using Clubhouse. It's not very popular at the moment, but kind of cool to mess around with.

00:41:59 - Christopher Burns

What's his Clubhouse?

00:42:00 - Peter Cooper

Oh, it's like an audio social platform. It's a new social platform. It's kind of an American thing at the moment, but it's starting to take off. It's like an audio chat thing. You drop in on channels of people and they're talking about all sorts of whatever.

There's beginning to be developers moving on to there, but it's very busy at the moment. I'll talk to you about that after the show. Maybe I'll see if I can sort you out.

But one of our titles that we publish, and it's not written by me at all, is we have a Jamstack newsletter. You just go to Jamstack email. It's run by Brian Rinaldi. He's been in the Jamstack space for quite some time.

00:42:33 - Anthony Campolo

He will be on the show, and he has published a couple of my articles in this newsletter.

00:42:37 - Peter Cooper

Oh, well, I'll just do a little promotion for him in advance of that. So yeah, he's an interesting guy. I don't get involved with that newsletter at all. Basically, he writes it and it gets sent.

And I guess if anyone else is from Lincolnshire, like me and Chris here, and you ever come across the Lincoln Hack event, you should come on down. Hopefully when these lockdowns and everything have finished, we'll all get back to being able to hack in the same room together at some point.

So yeah, Lincoln Hack is the only thing in Lincolnshire for doing that. It's the only one I tend to go to because I don't like traveling around too much. So those are my shout-outs.

00:43:08 - Christopher Burns

Well, thank you for your time, Peter. It's been great.

00:43:12 - Peter Cooper

Yeah, it's been good.

00:43:13 - Christopher Burns

I can't wait to see what you build next time at one of these hacks.

00:43:16 - Peter Cooper

Who knows?

00:43:47 - Christopher Burns

I need to speak to Rob. It's funny because I'm still an admin on the Lincoln Hack Facebook page.

00:43:54 - Peter Cooper

Oh, okay.

00:43:55 - Christopher Burns

He never removed me. Anthony, you do not know Rob, but he's, I would say, a giant personality in the Lincoln tech scene. And by Lincoln tech scene, pretty much me, Rob, and Chris Roebuck are the only people that write JavaScript in this community.

00:44:14 - Unidentified Speaker

What's his Twitter? What's his Twitter handle?

00:44:16 - Peter Cooper

Does he tweet anymore?

00:44:18 - Christopher Burns

I don't know. It's probably something.

00:44:20 - Unidentified Speaker

That he doesn't exist in the tech scene if he's not tweeting.

00:44:22 - Unidentified Speaker

No, he's.

00:44:23 - Peter Cooper

He's protected.

00:44:25 - Unidentified Speaker

Yeah.

00:44:26 - Peter Cooper

His account's protected. He speaks a lot about how much he hates social media. He's one of those type of people.

00:44:33 - Unidentified Speaker

And it's funny about social media, too. I just spent all day on it.

00:44:39 - Peter Cooper

It sucked you in.