Ep. #52, Open Sourcery with Tanner Linsley of Nozzle
In episode 52 of JAMstack Radio, Brian and Tanner Linsley discuss the enterprise keyword rank tracker Nozzle, how the open source ethos has shifted in recent years, and finding sponsors to elevate open source projects.
Tanner Linsley is the Co-Founder & VP of UI/UX at Nozzle. He has a rich history in web development, web consulting, and open source.
In episode 52 of JAMstack Radio, Brian and Tanner Linsley discuss the enterprise keyword rank tracker Nozzle, how the open source ethos has shifted in recent years, and finding sponsors to elevate open source projects.
transcript
Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Tanner Linsley.
Tanner Linsley: Hey, everybody.
Brian: Tell us what you do, and why you're here.
Tanner: As a non-tech person, I'm married, I've got a little boy and I live in Utah right now.
I'm a software engineer. I really like open source a lot, and I speak occasionally. I'm just really obsessed with React most of the time.
Sometimes I get a little loud on Twitter, probably. But I co-founded a business here in Salt Lake called Nozzle, and I spend most of my time just working on new features for Nozzle.
I'm over all of the UI and UX for Nozzle right now.
In the process of doing that, I've had an opportunity to make a lot of open source libraries and use a lot of open source libraries, so I'm very active in the open source community.
Brian: Are you able to zoom out and talk about more of what Nozzle is, and how open source is involved?
Tanner: Absolutely. Nozzle is an enterprise keyword rank tracker, which is a mouthful.
Brian: Sounds like a lot of business.
Tanner: Yeah, you can think of it like a SaaS or a DaaS company, so it's like software data.
It's an analytics tool that is more or less reverse engineering how Google search rankings work.
A lot of businesses have marketing teams that need to be able to track where they rank in Google and why, and where their competitors rank in Google.
We try and surface as much of that data as possible to them, to make them productive.
Brian: Awesome. It sounds like a very clear business need, because I know some people who before they start a new product or even name something they will actually go in the search and see if it's ranking.
If it's some weird-- I guess "Nozzle" is not a good one, but if you had the word "Google" before Google was a thing then you could see, "It's not even ranking, or it's non-existing. We can own that name."
So is it a bit of that too as well, or is it just all this--?
Tanner: Right, exactly. There's a bit of that, but most of the people that are using Nozzle are big businesses that rely on organic search for a lot of their traffic and a lot of their lead generation.
You'd be surprised, but there are companies who are tracking millions of these keyword phrases in Google, trying to get their website to rank in those keyword phrases.
If you can succeed in doing that, it's so much free, essentially free investment in getting traffic to your site and leads and stuff like that.
You've got to work for it, but organic search is very powerful, so it's valuable at every end of the spectrum.
For big businesses and for little ones, it's just the tools you use on that spectrum are different depending on where you are.
Brian: Speaking of value, what's the value of open sourcing all the stuff that you're building or supporting or bringing in?
Tanner: Nozzle itself has a ton of proprietary stuff on the back end and in pipelines and things that I don't even really work on directly.
But as far as the front end goes, I've always imagined, I don't know. The internet to me and front end, everything about UI and UX seems very open.
To me it's like, you can reverse engineer a website. You go to the website, you can see it. You can pretty much know how it's going to work.
I've always approached what I do as an engineer, not as something that's very proprietary .
I would rather share than try and be secretive about the tools that I'm using to be successful.
Clearly there's a secret sauce to our application, even on the front end.
That doesn't really apply to everybody, but there's so many things that all types of companies are worrying about and some of those are libraries that I've built.
React Table is one of the libraries I built, because everybody has tables. Everybody needs data tables.
Brian: So this is specifically a table library to add a spreadsheet looking-like thing into your--?
Tanner: Yeah, if you're going to build a table you're going to want sorting and filtering and grouping.
You might want pagination, you might want a lot of these features that don't come out of the box with HTML tables.
React Table is just a library that helps you build those tables with the least amount of work possible.
Brian: You mentioned it already, and the reason I knew of you originally was React Static back when React was pumping-- The community was pumping through a bunch of one-stop toolkits to get a React app up and going.
There was a bunch of them, we could spend at least 10 minutes listing them all, but--
Tanner: Absolutely.
Brian: I'm curious about the story behind React Static, did that also come from Nozzle and a need internally?
Tanner: A couple of years ago we weren't a big company, and we aren't even big now, but it still was just a few of us.
So I had to make a marketing site on top of building this SaaS application, and I just didn't like how the tools looked for doing that at the time.
I tried Hugo, and all these tools are great but I tried to Hugo, and I did try Gatsby.
I had some really long talks with Kyle Matthews about Gatsby in the early days, and all these tools were really great but they just didn't fit my style of how I wanted to build a marketing site.
Part of it is I just wanted to learn about it, so I started building React Static just so I could use it to build Nozzle's marketing site.
It turned into something bigger, and people wanted to-- Like you said, people were exploring so many ideas at the time of one-stop tools to build your applications.
It turned into that, and it got really big for a little while.
Honestly, I don't really have any sacred projects. I'm more just in it for the solution and whatever is going to be the best tool for the right job.
It wasn't too long after React Query had its heyday a little bit that Next.js came out some new versions that really nailed what I was looking for.
I just decided that I was going to pass the baton and let somebody else manage React Static, and just move on.
Brian: I guess that's a hard thing for a creator /maintainer to do. Actually, I don't really know many maintainers or creators that pass it on.
I've heard a lot of projects that walk people walk away, they just basically walk away and the thing flounders. But big ups to you for passing on the baton.
Tanner: It had a lot of users, people that really cared about it, and not just hobby users but there were businesses that were built on top of React Static.
I just couldn't, I didn't feel right about leaving them in a lurch.
I didn't just give it to anybody, I spent a good month or two looking for candidates of companies and organizations who would be able to foster the growth of React Static and keep it going, and even make it better than I could have.
Luckily, I did find some of those people and they're doing a great job of taking care of it now.
Brian: Excellent. Because I definitely still see it around, it still shows up in lists of things to use.
I'm assuming since companies are already involved, there's a good community of contributors and maintainers going forward?
Tanner: Recently they've moved to TypeScript, and there's plenty of TypeScript advocates out there now . People love that.
There's tons of plugins, people are building plugins left and right, so it seems really healthy.
It's definitely not this huge behemoth like Gatsby or Next, or something like that. But it doesn't need to be. It has its little corner of the market and it does a good job.
Brian: I'm curious about the React Query too as well, because that's one of the more recent projects that I've seen you ship. I even tinkered with one of my projects as well, so what's the story behind that?
Tanner: React Query is my love story right now. I am just really loving it.
React Hooks came out and I wrote an article way back when React Hooks came out, and I was exploring how Hooks are just going to change everything about how we do state management.
I didn't even know myself what was going to happen, I just knew that it was a game changer.
I've been exploring these ideas a lot over the last year and a half, and finally I found some patterns that were starting to make sense to me on how to pull asynchronous data into my app.
First it was moving away from Redux, and then trying to build little promise Hooks here and there. I tried Apollo, just feeling out all of the options out there.
I felt this gap in the ecosystem for a tool that would give you the productivity of something like Apollo, but just without all of the opinionated stuff about GraphQL. Just a Rest-oriented tool. So I started building it, and like it wasn't even V1 and it made me really productive.
I put it into Nozzle's app right away and it just simplified so much of what I do, and the one thing that I saw simplify the most is-- I've been talking so much about this with people, it makes me so excited.
When I moved to React Query, I noticed that my "Global state" is that it wasn't so global, and there wasn't a whole lot of it.
95% of my application was just this cache of data from the server, and after I moved to React Query I just took the rest of that global state and just put them into some Context and providers, and I was good to go.
Brian: Under the hood, are you using the React Hook Context API?
Tanner: Yeah. It uses Context to communicate.
It doesn't need to do this because it would work fine, but some people get skittish about using Context for global state.
It actually uses the same -- A similar paradigm as Redux, where it just has a pub/sub model that will re-render components specifically when they need to.
But it does use Context to pass that information down, and it uses Hooks throughout to subscribe to queries and make sure that everything is in sync.
In fact, the entire library is just basically a collection of Hooks like use_query and use_mutation.
Brian: I feel like with the Hooks, I feel like I have a better understanding and I have better context of the Context API at this point.
With Redux, I understood it because I did all the tutorials and built Redux from scratch, and all that other stuff.
But this was my opportunity to really start using it after everybody told you not to use it, so my exploration to basically having this global state and that caching.
What I really wanted was caching for my site, and I didn't want to build in something hefty, so I started using Context and using some light tokenage in local storage and stuff like that.
For the most part I got I got what I needed to get done and I didn't have to involve a very large library.
Tanner: Right. A good way I've been describing to people what React Query is technically, is it's basically a global store for your app, but it's just one that is specifically built to handle asynchronous cached resources.
All of the re-fetching and lifecycle logic is just cooked in, so by removing so much of all that server cache from your global state and putting it into a tool that's dedicated to it, it would be the same thing if you were to move to something like Apollo.
You realize that, "Most my state really isn't state, it's just server cache."
Brian: The thing I like about React Query, and I think there's a couple other people who are approaching this problem, is it actually looks a lot like Relay.
Where Relay is super GraphQL heavy, it was a nice approach to co-locate your fetch requests within your React application.
I know we went through this whole cycle of whether to do -- I forgot even the different styles. Like, class-based components but then we had these container components.
Tanner: All right.
Brian: That had extra work, and then we had-- Now we're up to Hooks, but I forgot all the other styles of components, function components. Everybody was trying to figure out the best way to--
Tanner: Render props were super hot right before Hooks came out. Render props were like, "You have to use render props."
Brian: It's funny, because I spent probably two years up until last year not really paying attention to React because I didn't have any daytime projects that needed me to ship fast or stay up to date on React.
I just kept doing the same thing I already knew how to do, and I missed all those.
When render props was first getting big that was the last thing I learned, and in between that I was like "I'll just do my own thing."
I came back and Hooks were done, they were talking about them for so long and then they were done. I was like, "I'm going to switch to this thing."
Today it feels great. I don't have any problems of trying to get data, or co-locating data, or that approach.
I think the pain was more of just converting a bunch of files to use Hooks.
Tanner: I hear that from so many people, that post-Hooks React is just so much more expressive and productive. It is for me, so.
Brian: One other thing I wanted to touch base on, and thanks for talking through some of these projects and getting the secret sauce behind these open source projects.
Because I think most people will think the magic happens one day, and someone has this beautiful read me and it's an open source project.
I think there's a lot of steps that you get to discover that, and I think you explained that with Nozzle.
You solved a problem and then it became an open source project. But I'm curious of how, is Nozzle basically your co-founder?
I don't know if Nozzle is actually paying for you to do all this open-source stuff, so what is the sustainability portion of this?
Tanner: It's interesting. We don't really know yet. Nozzle is still really small.
We're only about 12 or 13 employees as of today, but right now all I know is that if I were to-- I wouldn't do this right now, but if I were to leave Nozzle those projects would die.
Nozzle itself isn't really investing into those projects. They help Nozzle in a cross affiliation kind of a way, but I always list Nozzle as one of the sponsors on all of my projects that I build.
Because in a way I am sponsoring these projects with some of my Nozzle time, and that's fin e.
We're all serving the same purpose here, but very much so these projects would die without me.
At least, I hate that I say that because I would love for all these projects to become community maintained things.
But as of today, that's how most of them are. It's about finding that balance.
Brian: Yeah. If Nozzle is sponsoring you from-- Like, you're taking your Nozzle time or your day job time to contribute that.
Do you also, is it a thing for the engineers at Nozzle to also contribute to the projects? Or is this mainly contributors outside?
Tanner: There aren't a lot of front end engineers at Nozzle, actually. I have one intern right now and that's it.
I've been carrying a heavy load, but your question is extremely important to me and I think about it all the time.
The answer I can give you is that I want my employees, and my future employees, working in the front end world of Nozzle.
I want them to be contributing to open source libraries and thinking of how to give back to the community. I think it's a privilege and a good opportunity in the front end world to be able to do that, where in the back end world there is so much intellectual property and special sauce in the back end compared to the front end.
I think it's only fair to be a good citizen as a company, where if you're building something that's on the internet and open you might as well share it.
That helps with so many things, it's not just good for the employees but it's good for our company too, being able to say that we give back to open source and that we care about the front end community as a whole is really important to me.
Brian: It seems like there's a model that-- I don't know, from being involved in the React space specifically, it's very apparent that there was a lot of people who migrated from open source into doing engineering at Facebook, like the 2015 between 2017.
It seemed like everybody was jumping into there, but that model is real where open source has been a really good recruiting tactic.
It's been a really good value play, because there's only so many snacks that you can give your employees and gummy worms and everything like that.
Tanner: Right.
Brian: But when you can actually get real value into, "You are going to work on something that actually matters to the developer community as a whole," which nothing against Google search ranking and what Nozzle is doing in the day.
Tanner: Right.
Brian: But if you could also sell that as-- I'm not speaking to you specifically, but as a hiring manager they might be thinking of "How can we get people not to go to Facebook, but also just come to our company? What other value can we provide them?"
I think that is a real thing that people have been taking note of.
Tanner: Absolutely. One thing that we should not fail to mention is that open source is really fun. It's a blast, and sometimes it can be addicting.
I know it has been an addicting cycle for me in the past, and probably will be in the future occasionally, but it really is a lot of fun.
I think that it's fun because writing your own open source library is like building your own little micro business.
You get to build a product and market it and sell it and get feedback, and it's good practice for running a business.
It's difficult to make money on open source projects. Not impossible, but difficult in my opinion . I think that's why it's fun, though. It resembles that to me.
Brian: Yeah. I echo that too, as well. The open source I do tends to always never mirror my day job.
My interest or the things I want to try out, I think a lot of people -- You find us with a lot of junior engineers, they find something really cool and they want to implement it into the project at work when it really doesn't make sense to.
Because what we're doing today already makes sens e, so why introduce new tech debt?
But open source gives me an opportunity to try to things that I would want to work on every day, but outside the context of work and providing all that technical debt, and people shunning you for being the one that introduced some random non-Redux library into a project.
Tanner: Yeah, totally.
Brian: So going back to the "Hard to make money" thing that you just mentioned, I'm curious what's your thought on--?
Because I know you have projects, you have sponsor buttons on your projects. What do you think of this whole like movement into GitHub sponsors, obviously that's one of them.
Open Collective, Patreon, Tide Lift I think is the other one. I know Code Fund which you know Erik out in Salt Lake.
Tanner: Me and Erik go way back. Back before-- I think the only one that was out was, maybe Tide Lift and Open Collective.
But I remember going to GitHub Universe with Erika a few years ago.
Brian: That's actually the first time we met. I was actually at that same table.
Tanner: I remember that. Erik asked me to go out there and just be his wing man on his little passion project, which at the time was called "Code sponsor."
That was a lot of fun, and I'm really happy to see Code Fund being successful and becoming a thing.
I think all these tools and moves to these tools is fantastic, I've never felt like I deserved anything for my open source work but that's because I'm in a position of privilege, of having my own company.
I have these cows that I can slaughter to get me to do whatever I want in the open source world. Like, I have my-- I guess that was a bad way to put it.
But I have all these other things that are helping me succeed in my life that are allowing me extra time to be able to work on open source, so I've never felt like I needed or wanted a ton of support from the open source world.
But there are other people out there who definitely deserve it. These are people who are quitting their jobs and they're going full time, open source.
They're solving extremely difficult problems , and they're building really valuable tools.
I think it's great that we're trying to make a move to support open source as almost like a career path as a business.
It's not going to be perfect. I don't know if it ever will be, but it's good to see it growing.
Brian: Excellent. With that being said, I wouldn't mind leaving it right at that and transitioning us to the picks.
This was a great conversation, and hopefully this is going to be a good conversation on GitHub, and people can reach out and find us on various Slack channels or Twitter.
Tanner: Absolutely.
Brian: So, picks. These are jam picks, things that we're jamming on. Food, movie, tech. All of the above, or maybe not even on that list.
I know you already have a list, but if you don't mind I'll go first and then I'll let you go after me.
Tanner: Go for it.
Brian: My first pick is actually JAMstack London, this podcast is called JAMstack Radio and JAMstack London is about the JAMstack, and it's based in London.
It's pretty self-explanatory. It's happening at the end of May, so May 27th and 28th. Please check it out, grab a ticket or submit to the CFP if it's still open by the time this actually ships.
Definitely check it out, I've always had a good time at the JAMstack events. I tend to always learn something new and someone is pushing the JAM in a different--
Not a different direction, but spreading it outwards into covering more things and just-- Static site generators are React, and stuff like that.
I always come away learning tons from there.
My second pick, I was just in New Orleans last week, so we're actually recording the day of Mardi Gras.
Some sort of inside baseball, if you wanted to know when we record. I spent the week before Mardi Gras in New Orleans, which honestly is still kind of crazy.
The parties actually get going the weekend before or even the week befor e, so it was interesting to be there, but I was way more interested not in the parties but in the food.
If you are based in the US or if you've heard of the US, you've probably heard of Cajun food and that southern style cooking .
I don't know if it gets out to Utah, if you guys have got a bit of Cajun food out there?
Tanner: Yeah. You won't see very many Cajun places out here, but you'll see a lot of places that do a Cajun dish.
There is one place actually, downtown Salt Lake, that has some Cajun food. Actually, I ate there with a group at React rally last year and it was delicious.
There's a few spots that are really good, but I agree. It's so delicious.
Brian: New Orleans is an interesting place. Not only did they bring us jazz, which is the first American style music, but they also gave us the Cajun and the Creole cooking.
But what I did learn is that Cajun and Creole are different .
Normal people peg it as Louisiana style cooking, and the irony is my father in law is a chef who learned in Baton Rouge and cooked for LSU for the football team for quite a bit.
But so basically, this comes down to Cajun is a thicker roux. So if you have a gumbo, it's going to be a thicker stew, and then a Creole is going to be thinner but way more seasoned.
If I butchered that, feel free to hit me up and @ me on Twitter. But I found that New Orleans is way more Creole food than Cajun, which I super enjoyed.
So, definitely check that out. Then I had one more pick, which I just wanted to mention on having a list, which is I just did a blog post on Dev2.
Which is called A Path to Open Source, and it sums up what we were just talking about in sustainability and also just contributing back.
I personally found that I consume a lot of open source, but I'm always looking for places to contribute.
I recently started contributing-- Not really contributing, but I've been doing some reviews of the PRs for graphical helping out where I can. Like, some non-technical help.
Then when I start getting some more bandwidth, hopefully next week, I can start helping out at that project. But that project is actually getting a whole facelift.
Tanner: That's awesome.
Brian: It's hard to jump in some in-progress stuff, so I'm hoping just to keep an eye on it. But with that being said, I'll link that blog post into the show notes, and Tanner do you want to take it away?
Tanner: Sweet, yes. My first one on the list, we already talked about it but React Query, just today I was told that React Query was nominated for an open source award at React Summit.
Brian: Congrats.
Tanner: That's top of mind for me right now, I thought that was really cool.
I don't even know if there's a public way to vote on that, to be honest. But I looked it up, and it's OSAwards .com/React, or something like that.
Brian: Who's running the OS Awards? I've never even heard of that before.
Tanner: It was React Amsterdam, but now it's React Summit. It's called React Summit now. It's huge, it's like 1,500 people at this conference I think.
It's in Amsterdam, and fun fact I was actually nominated last year for an open source award for React Table. But I was going up against MDX deck. I was like, "No way."
Brian: MDX was huge last year.
Tanner: Yeah, it was. React Summit is really cool. I would love to go to React Summit. I don't know if I'm going to be able to justify that one this year, but--
Brian: Is it also in Amsterdam this year, as well?
Tanner: I think they pretty much have set up camp in Amsterdam. I think it's going to be there.
Brian: Excellent.
Tanner: My next pick, the other thing that's top of mind for me is I just actually got back from Hawaii from JS Conf Hawaii, which was such a cool experience.
I love Hawaii and I love JavaScript, so those two things together, it was awesome. I actually got to speak at that one, talking about custom Hooks in React.
I've actually linked my slides because I don't have the videos up yet, but it was a really fun conference and I had fun talking about that.
Brian: So, how much time did you spend inside the hotel at the conference versus being at the beach? Like, did they build that into the schedule?
Tanner: Absolutely. They have this gap day in the middle, so it's a two day conference but there's a day in the middle where you get to go and just hang out.
I got there a day early, so I took my wife with me because she wouldn't allow me to go without her.
Brian: Fair enough.
Tanner: The conference was inside during most of the day the first day, and then during the gap day we could go out and do whatever we want.
They even had activities that were sponsored for attendees and stuff, so we could go snorkeling or go to the beach and just hang out .
We did a luau that night that was so much fun. It had all these really cool activities like outdoorsy ones, they even had some service oriented ones too.
Like, "Let's go clean up the beach." It was really cool.
It was a little jarring to go to a conference and then come out of it , and then you come back in and do the conference thing again. But at the end of the day, it was a nice break.
Brian: Excellent. I've never heard of gap day at a conference. Normally it's before or after it's your time.
Tanner: I honestly don't think I would do it anywhere else, but Hawaii makes perfect sense.
Then the other thing, I couldn't really think of any other picks right now.
I'm just really invested in my startup right now, but I'd invite anybody listening if you guys have a marketing team at your company, you should go tell them about Nozzle.
I'm sure we can do some amazing things for them.
Brian: Excellent.
Tanner: That's all I got.
Brian: Awesome. Tanner, thanks for having a conversation with me about open source and sustainability stuff, and all the stories behind the projects you're working on.
Tanner: Absolutely.
Brian: Listeners, keep spreading the jam.
Subscribe to Heavybit Updates
You don’t have to build on your own. We help you stay ahead with the hottest resources, latest product updates, and top job opportunities from the community. Don’t miss out—subscribe now.
Content from the Library
Open Source Ready Ep. #3, The Open Source Pledge with Chad Whitacre of Sentry
In episode 3 of Open Source Ready, Brian and John sit down with Chad Whitacre from Sentry to discuss the Open Source Pledge, a...
Open Source Ready Ep. #2, Defining Open Source with Avi Press of Scarf
In episode 2 of Open Source Ready, Brian Douglas and John McBride speak with Avi Press, Founder & CEO of Scarf. Together they...
Open Source Ready Ep. #1, Introducing Open Source Ready
In this inaugural episode of Open Source Ready, Brian Douglas and John McBride embark on a technical and philosophical...