The Nuanced Power of Headless Browsers with Joel Griffith

Episode Summary

On this week’s episode of Screaming in the Cloud, Corey Quinn is joined by Joel Griffith. Joel is  the CEO of Browserless.io, a company focused on providing headless browser automation without the pains of hosting. Corey and Joel discuss the most common use cases for headless browsers, the spectrum of web scraping ethics over the last decade, and why it’s so important to always do what you are passionate about no matter how high you climb on the corporate ladder. Joel also gives us his insight into why so many engineers come from creative backgrounds and shares his story of moving from jazz trumpet player to CEO.

Episode Video

Episode Show Notes & Transcript


Full Description / Show Notes
  • (00:00) - Intro
  • (00:53) - Guest Introduction: Joel Griffith
  • (02:51) - The Genesis of Browserless.io
  • (05:21) - Use Cases of Browserless.io
  • (07:19) -The Potential for Abuse of Web Scraping
  • (08:37) - The Legitimate Use Cases of Web Scraping
  • (11:17) - The Power of the Right License Type
  • (13:55) - The Value of Open Source and Charging for Software
  • (14:13) - The Journey to Starting a Business
  • (24:00) - Joel’s Emphasis on Quality of Life
  • (27:43) - Staying Focused on the Work You’re Passionate About
  • (30:00) - Conclusion and Final Thoughts
About Joel
Master of puppets and the browsers they run! I'm Joel Griffith, and for over a decade I've helped run, destroy, and make manageable things related to browser automation. I've had the pleasure of working on this in big companies and small, and more recently started Browserless to bring the power of automation to teams of all sizes.

Links:

Transcript

Joel: There absolutely are like legitimate use cases and obviously like those are the ones that I like to align with, of course. But you know, the web scraping is, it's the skeleton in everyone's closet. Every corporation I've ever been at, every company I've ever worked at has that at some level in their stack, and it's always the one, like, people don't look at it in the eyes, it'll turn you to stone, so just leave it alone and it'll all be okay.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by someone I encountered during my last couple of months of building a Kubernetes at home. One thing leads to another thing, leads to another thing, and I discover some fun tools along the way, and they have dependencies, some of which don't work as well as one might hope on raspberries pie.

I start talking to still more people and my guest today is sort of the end of one of those deep dive chains. Joel Griffith is the CEO of Browserless.io. Joel, thank you for joining me.

Joel: Yeah, thank you so much for having me. Appreciate, appreciate being on the show.

Corey: One thing I've always sort of wanted is something that'll just sit around and keep an eye on various web pages and alert me when they change.

Not everything supports RSS notifications, or doesn't prune or prunes appropriately. Terms of services on websites are a terrific one for this. Show me a diff and I found a project that's open source, but they also have a hosted version called Change Detection.io, and it works super well. If you upgrade the connection type, it will instead of using curl, it'll instead wind up using Playwright as a driver and hook out to Browserless, which is where I first encountered you. And oh, it's, it's a sep, it's effectively a separate container that runs a headless version of I, in my case, Chrome. But I don't know if that winds up working globally or if that's just a one-off here and it's basically magic in a box.

That's my weak fumbling in the dark explanation. What's the better one?

Joel: Yeah. So I mean, you're right on. That's pretty much exactly what it is. We. I, we have, you know, over the years, used headless chrome for a variety of things. The one you just described is a very good example. Web Scraping is another very popular one.

AI is a big one right now. So we get a lot of the AI, uh, gold rush as well. But the thing that we've, you know, noticed over time is like, first off, it's hard to get from running in a Docker container. And the second thing is, is when you start Chrome it, it binds to a random port and a random interface almost, and a random, uh, like URL to connect to.

So in order to get that whole thing working, you have to build all this like command line interface tooling to like get the right stuff out so you can connect to it and tell it what you wanna do. And I was like, oh, there's just this missing like web services layer around headless browsers and a way to like isolate them from your infrastructure.

'cause as we all know that they update and they have security vulnerabilities and so on and so forth. So yeah, the genesis of the company was really just behind what can we do to make that experience a lot easier and a lot more secure, to be honest. Just to have it like kind of off in the dark doing what you need to do it, but not have it be accessible to anything else.

So that's it. It's the missing management layer for headless Chrome, headless Firefox, and have the Safari.

Corey: I've used a bunch of headless things over the years. Um, Selenium, Puppeteer, etc. I worked at a company over a decade ago where Plaid wasn't really a pro, uh, thinking about startups yet, so their pricing was absurd.

So we wound up building scrapers to log in with stored credentials to various customer bank accounts to pull transaction logs and having to, and finding a way to set that up as every time they change the interface a little bit, how do we wind up having, uh, a team of contractors being able to reasonably update how that works?

We had to build it from scratch, at the time. It was not terrific. So it seems like that's really come a long way. And also if you're working in the banking world, please don't, please don't do that. That is the wrong way, that is the wrong axe to tackle the, uh, intricate wiring problem with.

Joel: Yeah, I- for sure has come a long, long way.

What's funny to me is like the basic problems are still there, like what you just described. And, and with, with change detection too, being able to like Intelligently know what changed on a website or why it broke is really important. And there's a lot of good tools. Like playwrights really good at this.

Anybody's got first-hand experience using playwright for test automation. It's amazing. Like they, the diffing, the visual diffing, all that stuff is just kind of like built in and, and it just works. But fundamentally, yeah, it's like, the DOM changes, you know, your selectors or whatever you were trying to do change and now things stop working, which is not very ideal.

There has been some pretty cool innovation and things that are happening in that space, like around like visual computer vision. And so like instead of doing like DOM scraping, you do a picture and then you feed that to an ML thing of some kind and it'll say, oh, the price is this if you're interested in pricing.

So I think there's like some newer applications that even make it more compelling and fun. But yeah, at the end of the day it's still just a struggle sometimes to get it off the ground and, and running like well and continuously. So definitely

Corey: you have some fascinating, uh, reference logos on your website of companies who will attest to working with you, Heroku, Webflow, Microsoft, you know, a small company some folks might have heard of. It's, this is clearly something that's working at scale. It's not just, uh, someone with my use case with a couple dozen websites of, let me know when these things change from time to time.

What sort of use cases are do your customers wind up doing at scale with browserless?

Joel: Yeah. The funny thing we see at scale a lot is load testing. That probably is because there's lack of good load testing tools that like parse and run JavaScript, but everybody's building single page applications. You know, they're building react, view, you know, whatever the next thing is.

And they, there's this thing that has to run in, fetch more data and then assemble the page and like load testing tools. Obviously majority of them just don't do that. Like you'd have to run, run a headless browser to do all of that. So a lot of our use cases around that is like, you know, making sure, you know, they instrument code to make sure like certain API calls happen or that the page renders, you know, things of that nature that are hard to like do, you know, in full production.

But the other part is like, you know, we sort of have innovated at like the infrastructure level to a degree, like you can multiplex clients through Chrome, which it's a mouthful. I'm sorry, it's not jargon, I promise. But like having a couple different like puppeteer scripts running at the same time that talk to the same underlying browser process, you could get a little more performance doing it that way.

So just novel stuff like that, that's like hard to implement yourself, but we, since we kind of manage Chrome for you and manage incoming connections, we can take care of that in a pretty intelligent way. And so things like that just make it much more scalable and you get more throughput and benefit and it's just like another thing you don't have to worry about, you know?

'cause, does anybody like write and run their own databases anymore? Or do they, you know, use a managed database or do they at least, you know, run it separate from their own like web services? So anyways, bad, bad comparison on my part, but that's the one I tend to go to 'cause I think everybody's pretty familiar with, like, oh, you need to hook up to a database.

Don't run one yourself. Like, just pay the money and use the managed service 'cause they do the backups, they do everything, you know, they take care of all the stuff that you don't wanna waste your time on. And so this is very similar, I think in, in a lot of capacity to that.

Corey: The potential for abuse of a service like this is also almost certainly non-trivial.

It's, oh, great, I'm going to have a bunch of things that'll log in and do things for me. I mean, I brushed against the edge of that myself when I started down this project. 'cause I was running it on my Dev EC-II box, and some sites, including AWS's own terms of service, refused to accept the connection coming from their data center IP space.

So that was something I had to wind up- I looked at, okay, how do I proxy this through my home connection? However that I'm building a Kubernetes, put it over there and suddenly those prob, the entire class of problem went away. Do you find that that's a problem for, I guess, legitimate use cases? I mean, if people are hitting their own, their own environments, yes, they can, they can allow list anything that they want.

But when I'm just trying to keep an eye on a variety of websites around the internet, I, I look like normal traffic. But as soon as I start looking like a bot, people get very blocky.

Joel: Yeah. And to be clear, like I agree with m- most of the reasons, but it's never black and white. That's the thing. Like I keep finding with, you know, web scraping is, like you say the term web scraping a lot of the times and people will automatically like flinch up a little bit.

'cause just like you described with, you know, your banking before Plaid thing is like, it's painful to do for one, but also it's like, it's kind of an illegal gray area at the same time. But there's cases where it's not and we see a lot of those. So like for instance, there's a user of ours in I think the Nordic territories that by law goes through and has to review like shopping sites to make sure they're legit. They're not scams.

So it's like, uh, you know, for their citizens, they wanna make sure that you know the sites that they're going to aren't fake or you know, I guess fake is the only way to describe it. But those sites have bot blocking technology too, and they say you can't automate our sites.

But I'm like, well, this is a government body trying to do something the right way, but they, they run into the same problems that, you know, web scrapers run. So, uh, there absolutely are like legitimate use cases and obviously, like those are the ones that I like to align with, of course. But, you know, the web scraping is, is like the, it's the skeleton in everyone's closet.

Every corporation I've ever been at, every company I've ever worked at has that at some level in their stack. And it's always the one, like, people like, don't look at it in the eyes, it'll turn you to stone. So just leave it alone and it'll all be okay.

Corey: Yeah, in my case, it's often, oh, I, I wanna buy this thing. You are out of stock. I want to get an alert the next time it comes back in stock because in your infinite eCommerce wisdom, you didn't put a click sign up here to be notified when we have this again. It's, it's one of those things where it's, yeah, you want me doing this, I promise, but it's tricky to, like, you can't ever have a conversation with policy, so it's great you just have to work around some of the limitations that are out there.

Joel: Yeah, it's, it's almost an arms race to be honest, because yeah, PlayStation five is a great example. Like I remember during Covid that was like an impossible console to get, 'cause all those bots were out there buying them as stock came out.

And you know me, I wanted one, so I wrote a script on browser listing to like get one in a cart and inform me when it was time to check out. And, you know, I wasn't reselling it. I still have it, it's actually right over there. But, um. The thing is, is like I had to like rise up to that level that all these bots are and like, is this the way forward?

Absolutely not like they this, not everybody should be having to program a headless browser just to get a pair of shoes or to get a console, but like, I don't know when the ante gets raised like that and you need something, and of course if you're an engineer that's bored during covid, like why not just-

Corey: Yeah, and the problem is you're doing the same thing as a bunch of scalpers are doing the same technology, same approaches with, with a lot less pure of an aim. It's honestly, it feels like robot wars back and forth. I am curious about the direction you took the company in. Uh. I believe you're bootstrapped not taking outside investment.

Everything you do to my understanding is open source. So great. We're going to wind up, uh, giving all of the, uh, all the IP making that public. Anyone can use it. And then we're also going to charge money for the thing sounds historically like, ooh, that, that sounds like a great way to starve the death, but clearly it's working for you folks.

How'd you get there?

Joel: Well the right license type is absolutely the thing to get right at the beginning. If you go with a very like permissible license and then you relicense to something more constrained, you're gonna die after news is gonna kill you. Like, it's better to start off more constrictive with a license and then get maybe more permissive over time.

That's way better. It's like starting off with a, a pricing thing like that too. But you know, starting off with a low price and then just. Gradually, and of course we did that, start with a low price and then, you know, go higher. Nobody's gonna be a fan of yours. But, um, so fundamentally I think it's licensing, you know, making very clear, like we were GPL three, I believe, uh, originally.

And it was the idea was like, yeah, if you're using this for commercial purposes, like please pay us and get a license. And any legitimate business that sees that license type pretty much kinda like, it triggers them to be like, yeah, we need a license. 'cause we don't wanna deal with like all the nuances of that.

You know, like, when is it free and when is it not? But that one, I just kind of luckily got right from the start as, you know, engineer but not versed in software law like, it was kind of a shot in the dark to be honest. And I'm kind of glad I made the decision I did then just to make it work. But, um, I don't know.

The other thing is, is like I just see all these people struggle at the same time with like the sponsorship model. And it's like, why don't you just charge money for your software. Like that's, that's the easiest way to do it like this- this is commerce that predates like written history is like you have a service, you trade services for a another thing, or you, you buy them with something and versus like, please pay me if you think I'm doing well.

Like, I don't know, it just, I don't wanna say it comes across as like hand handling, but I kind of feel like it does to a degree rub me the wrong way. Like just charge.

Corey: I know I'm gonna get pushback on this, but it always feels weird to me when you see someone building something incredibly valuable and useful and then they have the Patreon link or whatnot there it's, it feels like when you wind up going to a professional, like you go to an attorney's office, for example, or a doctor's office, and then there's a tip jar sitting there. It's that that doesn't, that the, the model doesn't seem commensurate with the environment and the way I'm using this thing. Again, I, I'm, I'm not trying to crap on creators who decide to go down that path, but it always struck me as-

Yeah, a little it- it felt relatively down market and for a lot of these things that are solving enterprise solutions, it feels like it'd be driving away some of your perspective customer base.

Joel: I agree a hundred percent. It almost like you're broadcasting insecurities or unsureness of your thing. You're selling software, let's say in this case, like asking for a sponsor is like, this is kind of, anytime I hear that, I just, I just feel like it's pre-beta or a beta alpha thing. Like it's not quite there yet. 'cause if it was, why aren't they just charging you money for it? And so yeah, it's kind of like sending the signal or you know, you know, telegramming out that like, I don't have enough value in this to ask for money, so I'm just asking for whatever you have to spare.

Corey: You also don't want to equate the value of what you're doing to well, okay. If you buy me a cup of coffee, we're square. It's, look, if, if I help someone with a problem for half an hour, I'm like, thanks. Can I buy you a beer? Sure. That's that's fair. That's awesome. Hey, you wrote some stuff that's transformational to my business and we're making significant revenue off of it.

Can I buy you dinner? Doesn't quite cut it.

Joel: Yeah, exactly. You gotta, there's a value being traded here, right? I think as engineers in particular, many times I've like bought lunch for people just to like probe them with questions on like, I dunno, infrastructure or load balancing or something. You know, just like, “Hey, can I buy you lunch? And just like ask you some open-ended questions?”

And, and they were more than, but they didn't like come in and architect everything until, you know, they didn't solve the problem fundamentally. At that level, it's like you should be compensated well for it 'cause it's not only knowledge that that person didn't have to know about, but like you fundamentally fix something for them that you know, turn into revenue increase or whatever it is.

Corey: I mean, and the way that I fix it with the consulting stuff that I do on AWS bills is pretty straightforward. If I can fix your entire problem in a half-hour conversation, I'm not going to charge you for that because I wanna stay the hell away from, ah, I know the answer to your problem, but I'm not gonna tell you unless you pay me, which does not present super well.

But I'm also not gonna start doing multiple days of work and diving into, into, into a thoughtful analysis for funsies. I mean, that is there, there's a clear boundary at some point. I used to worry about that where, well, if I sit down with someone for half an hour, am I gonna give the value of the engagement away?

And what I realized pretty early on was if the value of the engagement fits in half an hour, I'm not really, I don't, I'm not selling anything of particular note. Like the generic advice is all out there. It's, it's, how do you think about it? How do you address the problems that you have in, in the context of your business?

Joel: Yeah, that is a very good point. I mean, there's a lot of nuance to this and I think again, as like engineers practically, like you don't really ever get told- I mean, you get told the value by a paycheck for sure, and then you kind of get an under a very small glimpse of the value you provide based upon like that kind of compensation.

But the value you have and the ability you have is literally magic to a lot of people. And so I think because we know it and it's like, known quantities is like we under undervalue it almost on purpose just because it's like, well, I know how to do that, so it really can't be worth that much, you know?

And other people know how to do it, so it probably isn't worth a lot. But I dunno, time and time again, I've seen engineers just undervalue to an incredible extent what they can do and maybe what they're doing.

Corey: It's easy to devalue your own efforts and your own stuff because if I know how to do something that everyone must know that.

And if I don't know something, that must be the hard stuff. That is never true, but it's a lie we love to tell ourselves.

Joel: Well, I think a lot of us too just suffer from imposter syndrome. Like I'm definitely victim of that for sure. I wasn't an engineer to start with and I kind of taught myself out everything I needed to know to get started and do it.

And so like I have this like intrinsic sense that, you know, I, I didn't go to school, I don't have a CS degree. Like I can't tell you all day about algorithms and inversing binary trees and whatnot. So like, I'm probably just not worth a lot. 'cause there's other people are that do that, you know? Anyways, I, I think that's another dimension at play here is, you know, just the amount of, uh, imposter syndrome feelings that we all have.

Corey: I'm with you on that. I mean, I, I don't have a college degree myself, and I know that I can't pass a lot of the big tech company interviews that are effectively hazing because I can't, off the top of my head, spout computer science algorithmic trivia that has no bearing to ninety-nine percent of any work I will ever do professionally.

But that's okay. I, I found that that's not the gate I necessarily wanted to go through. What was your path, if you don't mind the question, how did you get to where you are of running a bootstrap company that provides a- arcane and very valuable service.

Joel: I was a jazz trumpet player, actually, to be honest, uh, originally and then went down the path of having kids and, you know, I had some, had some small life tragedies happen at the same time where it was like, man, getting by on a musician's salary right now just isn't gonna cut it longer term.

And then, uh, was working at a music store and they got a website quote for redoing their website and having had a background in computers and hearing this quote, I was like, dude, they're way overcharging you for this. Let me, give me two months and lemme see if I can build something better. And that was the start.

It's just been ever since then, just like continuously learning stuff and like playing with new things and I don't know, trying to understand things better. And the, the trick is getting started. I would absolutely say that is the hard part is like the, you know, the, the Big Bang event or whatever for your career is like getting that first job, getting, you know, the first client or whatever.

But after that, like it's just keeping up with the pace, which is, is staggering. It's, it's hard. There's a lot of changes, things continuously change, especially front end. Yeah, that was kind of my intro to it and I just loved it. It's fun. It's tinkering. There's not always an answer, which I kind of like about it and I kind of hate it at the same time too, but there's a lot of creative freedom and so I think, I don't know, a lot of programmers have like this art background or some sort of like creative background painting, music, something.

And they kind of fall into this because I feel like there's like a lot of similarities between the two. But yeah, I just drive with my personality and I enjoy the work and you know, most of the people are pretty awesome to be around and work with and they're smart and you know, are well aligned to what we're trying to all do.

So yeah, that's kind of the broad strokes of how it happened.

Corey: You spent some time as an engineer at a number of places of significant scale. Was there a moment where you were effectively trying to find a good way to do something with a headless browser and kept beating your head off the wall. And was that the spark? Or did it happen completely in a vacuum of, you know, “I bet this is an expensive problem people would pay money to make go away.

I'll go build a business around that.” I, I have a sneaking suspicion it is the former rather than the latter, but I've been wrong before.

Joel: No, it's mostly the former, but I will say, you know, there was a lot of ammunition in to, to that effect. So like, you know, the first company is like, we had a Jenkins cluster that ran, uh, Selenium tests and it was always falling over.

It was never working. It was garbage. Uh, yeah. I see you nodding your head and I'm sure there's much people like Mm-hmm. Been there, done that.

Corey: Ooh, some white space change. Time to fire off all the alerts.

Joel: Yeah, and just even trying to read any sort of like diagnostic information from Jenkins is like, I don't even know if I'm in the right part of the app for this or what it's trying to tell me.

It's all this Java stuff everywhere and you know, no point of references. But, um, so that was a big part of it. But honestly, the thing was I was working on another business trying to get it off the ground and ran into this problem of SPAs loading JavaScript, and it was making my life a living hell to try to get this thing off the ground and I was like, this has been a problem every company I've ever been at.

And I'm facing it again with just this really simple thing. Just like we with change detection, like it was, I just wanna monitor a change on this website for pricing information. And anyways, I started working around, this is right around the time Puppeteer came out, which is starting to show our date, our age a little bit.

But there was just no way to run those things effectively in the cloud. And you know, after looking at that and thinking about my history and all these other things, I was like- I feel like there's something here that's better in this dimension than just another, you know, kind of like business to consumer thing.

Corey: The web used to be usable without JavaScript enabled on your web browser. Those days have passed.

Joel: Yeah, it's funny 'cause even when you mentioned AWS, like blocking themselves their own data IPs, data center IPs from visiting their own properties of just like, you gotta like pull your head outta the sand at some point and be like, how did we get here?

This is not right. This is. Not how it was supposed to be, but even simple sites that are pure HTML, like server-side rendered, it's weird to say that 'cause it's, it, it's just the way things were. But anyway, server-side render pages, even those have cloud front or cloud flare in front of them. And so it's like.

You still have to bring a browser into the picture just to get past that. And then you can finally get to the content underneath it, which didn't need JavaScript to begin with.

Corey: And they do the fingerprinting and they look at user agents and all the other stuff. And it feels like it's a game of cat and mouse.

Joel: It is. And it's another escalation like war, you know, like you'll implement a fix or something and then they'll, you know, work around it. And I don't know. But you know, again, like everybody relies on open data on the internet to do business. Like literally every single company. I've worked at did, and I've talked to many, many others that do and like data and tell it like, I guess fundamentally it's access to data.

Like it's almost, it should be almost a human right, I guess. I don't know, I dunno how to like put that into more like political terminology that makes more sense, but like access to clean water, you know, access to data is, I think, one thing, and this kind of is working against it, in my opinion, but yeah, it's, it's incredibly nuanced too, at the same time.

So when is it right? When is it wrong? Yeah, it's up. It's up for debate.

Corey: It’s been a fantastic journey so far. Some of the flags you can pass to these things that just seem to work are wild. You can specify resolution of the display. I've, uh, done on developer mode and been able to basically program navigating through a website when I was kicking the tires on it.

It's stuff that, for my use case is, this is completely pointless and I have no use for it today. I love going on those little journeys because six months from now I'm gonna have a problem and it's gonna be, oh wait, I remember a thing. And that's how we learn. I mean, this is a bit off the beaten path for the things I normally spend my time on, but man, has it been an improved quality of life.

Joel: Yeah. Uh, thanks. I mean that's, quality of life is very important. I think. Full stop, like that's probably the thing that I would say is the most. That's the dimension that's the most important for us is like improving quality of life for developers that have to deal with these kind of problems. And we have a live debugger and that's like super, I use it multiple times a day to kinda like dive into a site without having to like fire up everything locally and get all the tooling set up and yada yada.

And it's just nice to have access to those kind of tools. 'cause like you said, like may not be today, may not be tomorrow, but you know, six months from now, a year from now, you're probably gonna run into it at some point in your career. And just like. Knowing that it's there and being able to reach for it and just keep moving forward is good.

'cause anytime you lose momentum on something, it's really demoralizing. So yeah, just keeping the trajectory up really is the, is the goal there.

Corey: How do you tend

to divide your time between working on the open source parts of it or source available? 'cause I know you're under the, uh, MongoDB server-side license now, so someone is going to complain your dual license.

Right. But the, how do you divide your time between the open stuff and the parts of your business that are the secret sauce that makes your platform work? Plus, of course, running a business, which is a whole bunch of things that people don't think about when they're starting a business of. Oh, right.

Accounting, taxes, payroll, the things that you, you, your wheels fall off your company real quickly without those things.

Joel: Yeah, exactly. Yeah, man. Whew. Uh, if anything else, like getting skills in that area have been huge and it took a long time to get there. To be honest, I, everybody I've talked to does it a little differently.

You know, some people are just very good, like just keeping it in their head, but I'm kind of like a set it and forget it person, so I just abuse the hell outta my calendar and it's like blocks everywhere for different things. It also helps me just keep me honest and on track. The other thing is I'm a big inbox zero person, which if you've never done that, that's like you go to your inbox and if there's nothing to do, you have no emails in there and it is pure zen.

Um, and so my email inbox is literally just like a running to-do list. And so I usually just first thing do, go email, start from the oldest one, and kind of work my way up. Um, but yeah, like deciding open versus closed source, that is tricky. I've had this stance that anything that, like puppeteer and playwright and all these libraries just kind of support out of the box, we should just have that in open source.

So if they have this like, fun, novel way of dealing with like, I dunno, downloads, let's say, like we should just support that in open source and kind of make it source available. But anything else outside of that? Like if you want bot detection, if you want, I don't know, multiplexing through Chrome with multiple clients, all these other kind of like novel things, those tend to go into like the proprietary side of things.

Um, and then, you know, we do have sort of like a very non-programmatic recipe for like how to like boil the bubble those back up into open source again. So I wish I could tell more details about, but I can't articulate it by any means of the imagination. So it's, it's a lot of it just like internal compass and internal sense to a degree.

But, um. More generally, it's, yeah, if other libraries and stuff have it, we will try to have it and support it as well just to kind of keep, keep equal footing.

Corey: Yeah. It's worth pointing out, you still have maintained being the number two most prolific contributor to the browser list repo on GitHub.

Number one, of course, as is always the case, is depend bot because it is- if I don't have good things to say, I'm just going to bedazzle everyone with nonsense.

Joel: Yeah, good old depend bot man. It does the job. It's the hero that we need, but don't deserve, really, to be honest, it is the Batman of the open source world.

Um, yeah, I know I, at the end of the day, I love writing code, man. Like, that's just my big thing is I love programming, the creative part of it. Um, you know, if I could, that's all I would do and I'm always trying to work towards that direction. I'm just always, you know, building stuff. I, I just think, I dunno.

Another, another point of reference is like, I just see a lot of engineers go to management or go to other, you know, disciplines inside their companies and it never gets a program anymore and like, well that was the thing that you liked and made you special. You know, and you kind of, you know, sacrificed it for, I dunno, maybe a raise or title or whatever, but like, maybe that's not always the best idea.

Maybe, you know, things, things should be a little different. Like maybe, I don't know. Yeah, it could be better, I guess. I, I dunno else to put that, but don't lose what you love, man. And I, I feel like if, you know, programming is what you like and it's. And it's there and you wanna do it. Like, just find a way to make that always happen, even if you're, you know, the CEO of a company, let's say.

But yeah,

Corey: Yeah. You, you, you find time for the things that matter. I think that that is something that people don't fully grasp when it comes to, oh, I should run a business or how I'm going to do this. It's a, it's a consistent challenge, but people make time for the things that matter to them. And everything else is prioritization.

Joel: Exactly. I mean, yeah, kids are a great example. After having kids, it's like. You put so much time and effort into them, it's almost like running a business and then you forget about like what you liked or what you've done before or what makes you happy to a degree and you can't lose sight of that. So I think yeah, always keeping that as like your North Star or your compass is a hundred percent the way to go.

Corey: I really wanna thank you for taking the time to speak with me. If people wanna learn more, where's the best place for them to go?

Joel: I mean, like GitHub is great. I do a lot of stuff on GitHub. I mean, you could open an issue and say hi if you wanted to. We've actually had issues before where people have like, complimented this service, which I thought was great.

Like, well, it's not technically an issue. So there's a bit of a semantic problem here, but, um,

Corey: Close. Won't fix.

Joel: Yeah, close Won't fix. Yeah, it's a good one. Um. So, yeah, GitHub. We're on, you know, Twitter and X as well, less so on those platforms it seems like as time goes on. But we're there if you wanna, you know, say hi or ask questions.

Slack too. There is an open source Slack channel that we're on. So yeah, if you want to come and see what's going on and say hi, always open there. But yeah, those are the big ones.

Corey: And we'll put links to that in the show notes. Thank you so much for taking the time to speak with me. I appreciate it.

Joel: Yeah, thank you so much for having me.

Appreciate it as well.

Corey: Joel Griffith, CEO of browserless.io. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment.

Heck, leave that comment on all of the podcast platforms out there using Browserless to do it.

Newsletter Footer

Get the Newsletter

Reach over 30,000 discerning engineers, managers, enthusiasts who actually care about the state of Amazon’s cloud ecosystems.

"*" indicates required fields

This field is for validation purposes and should be left unchanged.
Sponsor Icon Footer

Sponsor an Episode

Get your message in front of people who care enough to keep current about the cloud phenomenon and its business impacts.