Paul (00:15):
Hi there and welcome to PodRocket. My name is Paul and today with us we have Drew Baker. So Drew is the technical director and the co-founder of Funkhaus. So we're going to be talking about Funkhaus a little bit, and how you got into that. Welcome to the podcast, Drew.

Drew Baker (00:33):
Thanks, Paul. Great to be here.

Paul (00:35):
Yeah. Thanks for taking the time to come on. Yeah, so just like I mentioned, you're the technical director and co-founder of Funkhaus. Before we get into that, how'd you get into this field? How long ago did you start your journey into creating your own products and solutions?

Drew Baker (00:51):
Oh, wow. So it probably... 15 years ago now I would say. I mean, I always was into computers and my first job when I was in high school was as an IT tech at different high schools. So I grew up around it for sure. And then growing up in Australia, computer science and computer as a career basically was not something that I was aware of as an option. And so I went to school for business and business law actually, and got offered a job through a friend doing what we would call cloud computing now on Wall Street for hedge funds and banks in New York. And so I dropped out a semester short of graduating and moved to New York to work on that.

Paul (01:44):
That's a happy accident.

Drew Baker (01:46):
Yeah. I figured that was the job I wanted so I might as well just do it now. And so I moved to New York for that and was mostly working in data centers and doing big cross connects and all kinds of server infrastructure and stuff like that for hedge funds and banks, which was crazy and a whole weird world that I didn't really know I was getting myself into. And then my twin brother, he's much more on the creative tip, started a surf skate snow magazine in Australia and where I'm from. And so he called me up one day and was like, hey, I'm starting this magazine, come work for me, we need all kinds of help.
And I was working in a room with no windows and humidity controlled and the only other things in there were computer servers. And I was like go for a surf skate snow magazine? That sounds way better. So I went and did that, and that was my first real drop in the deep end as terms of having to build websites because we needed a website and there was no one else that could do it. So I had to figure it out. And so that's how I got into building websites professionally, for sure.

Paul (02:56):
I mean, it's funny you came from the business oriented place because hooking up data centers, moving data, selling the data, that is the business of computers. When you're at that level, that's about business decisions. It's about enterprise offerings that you can support what you can't support. How are you going to get things? Even getting the data from place a to place B is a whole business decision. Taking something out of AWS could run you a few nice Ford Lariats.

Drew Baker (03:24):
You're totally right. I was blown away at just the way data centers connect to each other. Like that was a big part of what I was doing was just connecting a data center in Connecticut to one in New York these sorts of things and the whole business of cross connects and stuff was crazy. I didn't know any of that existed.

Paul (03:44):
The underworld.

Drew Baker (03:45):
Yeah, a whole other world. So not very software, none of it was really software. It was all hardware stuff. And just some crazy horror stories of 10 people on a phone call waiting for me to plug in a server and then I plug it in and it's set to the wrong power from 220 to one 10 volts.

Paul (04:05):
Oh, fun.

Drew Baker (04:06):
Like blowing up a whole power supply for a $10,000 computer server that 10 people are waiting on me to do. It was real high pressure for someone who really didn't know what they were doing.

Paul (04:17):
Well, everybody has their I destroyed this while I was doing my job story. So there's yours. That's a pretty good one.

Drew Baker (04:22):
Yeah. Yeah.

Paul (04:24):
Well, now you're doing stuff that's not plugging in cables as much. You're building, like you said, enterprise websites. It's like we're on a different continent now of computer land. So you got into this because of the magazines?

Drew Baker (04:41):
Well, yeah, so I built a website for Pop Magazine, which was my brother's magazine in Australia. And then from there I ended up back in LA eventually moved on to working in a software company in LA called IDrive. And so IDrive was an early version of almost a private YouTube, but really geared around Hollywood production space. So if you were sharing video clips around because you were working on this commercial and you wanted to talk about some timestamp you would use IDrive to do that. Or if you were sending around reels of some director's work pitching on jobs, you would use IDrive to do that. And so I worked there as a front end engineer. My role there was really to pull data out of the IDrive system, I mean this was before YouTube really, pulled data out of the IDrive system and display it on third-party website. And so through IDrive, I met my business partner, Dave Funkhouser, which is where the name Funkhaus comes from, David Funkhouser.

Paul (05:44):
You would never have guessed.

Drew Baker (05:45):
Yes. And I met Dave and then I met my other business partner, Nick through that world and IDrive like a lot of digital agencies before they were IDrive, they were a digital website agency. And then they built this video tool that became a SaaS platform that was way more popular than the agency. So they're making more money doing that. And so they closed down the whole digital agency and just started focusing on the SaaS tool. And so me and Dave were sitting there in the wings being like, well, we can build those websites. And so we left IDrive together and started Funkhaus. And that was 11 years ago now.

Paul (06:25):
So if you were to describe Funkhaus really quick, I mean like a true elevator speech, your 30 seconds, how can we wrap this up for listeners?

Drew Baker (06:34):
Yeah. So we're a digital agency that focuses largely on we say demystifying the creative. So our whole process is very a blue collar approach with a high design polish to all of it. So yeah, that's what we do. So we largely build and design websites all in-house and we have a whole content marketing department as well.

Paul (06:57):
Great. So you're building very professional, very modern, finely tuned digital products for... Is it mostly for like creative customers?

Drew Baker (07:08):
Yeah, our sweet spot we say, we like to say our sweet spot is a high design need meets a specific business case. So a lot of B2B clients, we've done plenty of B2C stuff too, but the majority of work we do is for high creative companies and being in Hollywood, that's largely like user, I guess, customer, visual effects companies directors, but also moving into architecture firms and boutique hotels, anyone that is really competing on a high design need, like boutique hotels is a great one because they're looking to be look better than the next, but have to book rooms or same with high end architecture firms, things like that. And also recently a lot of other agencies actually. A lot of other marketing agencies or advertising agencies that don't have the digital first capability like we do. So we've been doing a lot of that too, which is always interesting.

Paul (08:06):
Gotcha. Okay. Thank you for that. I feel like this will just help people frame their mind as we start to dive into what we really want to get into the meat and potatoes of the podcast here, which is how do you use the... some technology stays particularly I want to talk about Vue and then talk about Storybook, how you organize these components and how you just make this machine run smoothly. Design is something I think a lot of people find abstract and difficult to grasp, especially coming from the developer side. And I mean, if you go to the Funkhaus website, I mean, it's a gorgeous piece that you guys put up there. If anybody wants an example of a fun website, definitely check out the Funkhaus website.
I mean, you go there and one thing that I was thinking about when I was just noodling around is you guys completely take things and rethink how they're used in the dom, for example, the scroll. So when you're scrolling on Funkhaus, you have the lateral scrolling, but then at some point you have the classic, oh, I'm on Apple's product page and there's a slide show playing, but then it switches again. And now we have a carousel that's going left and right. So you're taking this slider or the scroll functionality in the dom and you're just completely re-imagining, like it's an original design purpose in every way that you can possibly interact with it to present content in stimulating ways.
So I would like to kick off talking about the intricacies of how you make these products by asking, what is the team composition like? When you're tackling a new website, do you use the same technologies? Why do you use them? And would you say it's 50/50 designers and programmers or are you looking for people who are really talented programmers and/or designers and where do you find the balance there?

Drew Baker (09:55):
Yeah. Yeah. I mean, it's been a whole evolution for us to figure out how to do those things and how to do them well. When we started, it would start with Nick, my partner, Nick would sell the websites. Dave would design them and then I would build them, that was the original trio. And then it's grown from there and we've had to learn all the lessons along the way of how to scale a team and scale a production effort. And all of the stuff that comes into building websites at scale and professionally, but I think maybe I'll start by just talking a little bit about our process and how we get to a website and that could inform the team competition.
Yeah. So a lot of the times it'll begin a customer will come to Funkhaus and a lot of the times it's outreach to us wanting a website of some sort. And we will start that conversation with my business partner Nick who's really partnerships director sales lead guy, but way more than that and way higher level of thinking about just what is it that you want? And try and really distill down what the customer wants. There's a lot of disconnects between what they say they want versus what you're hearing and being like, well, I think actually really what you want is this and doing a little bit of business therapy and hearing what their chip business challenges are and how our website may or may not be a good idea for them.
We try and be devil's advocates and not upsell them on you should have an app or something like this. We try and hear what their problems are and then propose solutions around that. And so then we'll go from that into a wire framing kickoff meeting where we want to hear what it is that they have done in the past and all of the different business concerns that they might have. And from that, we'll produce a wire frame of what we think the website should look like. And there's a lot more strategy that goes into it than just like here's a PDF, but it's a lot of thinking and everything that distills down what they need into a way that we can start pointing at things and talking about it.
And from there once wire frames have been decided on and signed off on by, the client will go into a prototyping design prototyping phase where the design team, which at Funkhaus is four people headed up by my partner, Dave, and generally they'll produce a total one-to-one prototype in Adobe XD, which for people out there it's pretty similar to Figma or any of these other high website prototyping software, but we use the Adobe XD. And then from there, the client will see a one-to-one of what the website's going to look like. And the prototyping has come a long way now, like the fidelity is pretty close. It falls down when it comes to animations and things like that. You have to fill in the gaps there with a bit of explanation or some examples of like, oh, it's going to be like this other website that we built or whatever.
And then once there'll be revisions to that, obviously you go through three rounds of revisions with the client and try and get it to a point where they like it and sign off on it. And then it comes over to my team, which is the programming team and that's me and five/six other people headed up by me. And so what we do is we can talk, we can go very deep in what our process is on the technical side.

Paul (13:26):
Yeah, for sure.

Drew Baker (13:30):
We'll get there because I know we want to talk about Storybook and everything that we do there, but then my team, we have over the years really put a lot of effort into trying to figure out what makes a good front end developer for the work that we do, which is this high design, like you said about Funkhaus website, high animation, lots of different things I would say. So we've found that what you want to do is look for, and we've coined, we use a phrase "design driven developer". You want to find a developer that cares about design and has a bit of a design eye, because ideally you want the developer filling in the gaps that might have been missed in the design process or just not having to get real hung up on like, oh, this is pixel perfect to what the designers did. More like the design intent was this.
So therefore I know that really what they want to do here is this and fill in the gaps and hopefully add a level of thinking to it that maybe wasn't even thought about in terms of, especially when it comes to animation and things like that.

Paul (14:33):
Kind of more vibe driven, less spec driven.

Drew Baker (14:36):
Exactly. Yeah, yeah, exactly. And it's a delicate balance where you don't want people going rogue and building a whole thing, but you definitely want them to be thinking about, like you said, the vibe. So what I've found there is really CSS is the problem. Getting someone who is really good at CSS is really hard to find. A lot of people think they're good at CSS and then get into the work we do and realize they don't really know nearly enough.

Paul (15:06):
I'm really curious of, I mean, I feel like I'm handy with CSS, like yeah. But then when you get into the weeds, I don't know, there's some crazy stuff out there. So what's an example of something that people get in tune and they're like, oh my God?

Drew Baker (15:17):
Well, we used to have this programming test that we would screen applicants with and it was like a multi-choice questionnaire. It was like 10 questions, I think even less and you'd be surprised at what's the difference between position absolute, position fix, position sticky, and everyone thinks, oh, I get it, but do you really get it? Or tell me the five different properties of flex box. These kinds of things. And then those are basic ones in my mind, but it gets deeper. Like when was the last time you used object fit or object position? These sorts of things. And then just all the overlapping stuff that comes with it. I mean, that's the problem with CSS, it's like you can know the property, but how do they all interact together is the real question. And there's no real logic to any of it. You have to have used it all and understand all the quirks of it all. So it's a hard language to learn because you can't figure it out. I think you just have to do it.

Paul (16:21):
I wonder if that's a telltale sign of a well designed intentful product though of... 95% of people can use CSS and not know the syntax, just like most people can speak English and not understand the tense of a single verb they're using.

Drew Baker (16:36):
Yeah. But I would say CSS is, I mean, it's not even a language.

Paul (16:42):
It's not, yeah.

Drew Baker (16:43):
It's a collection of settings.

Paul (16:47):
I don't think you could write a turn, complete anything and no, I mean for you. No, I don't think you can. I don't think that's possible.

Drew Baker (16:53):
Yeah. So anyway, so CSS is the one that is the steep learning curve and one we always struggle with. But then so it's definitely Vue by the way. So for anyone listening out there that... Vue is you've probably heard of React, which is a website. Well, technically, these are web component libraries. So React would be the most popular one. And thats largely backed by Facebook. But Vue is an alternative to React that I would say is the second most popular one. In my opinion, there is an argument for some things like Anglo, which is Google's version of this, but view is a web component building library. It's really good for building front end components. Yeah. So we're deep into view. And so we use Vue on everything. It's fantastic for building components for front end websites like what we do.

Paul (17:51):
And how does Nuxt tie into this?

Drew Baker (17:54):
Yeah. So Nuxt, I mean our whole business runs on it. It's incredible what you can do with it. So Nuxt, so if you have a component library like React, great for building an individual component, not so great for building an entire website, especially when you get into service side rendered and you want different routes and all these kinds of things. Okay, if you're just building a single page app where you don't really want to update the URL or anything like that, then you can use React or Vue. But there's another layer on top of all this, which is more of like a website library, which in the React world, there's one called Next, which a lot of people are probably familiar with. In the Vue world of this Nuxt. So that is, in my mind, the best way to think of that Nuxt is a great library for building a website and it uses view for the components in that website.

Paul (18:47):
Gotcha. Okay. That's interesting. The first time I ever saw Nuxt, I was angry that somebody misspelled Next. So yeah. So Nuxt like the view port of being able to assemble this into a nice package to create a service side rendered, like routable easy interface. I mean, I think a lot of people I've interacted with one-on-one are familiar with Next and it just has raving reviews, not just from me, but from a lot of people. So Nuxt is up the same alley, it must really appeal to a large audience.

Drew Baker (19:23):
Very much, very close. You know, a lot of what's going on in Next trickles down into Nuxt. We get the same Next features a year later in the Vue world. It's an exciting time for Nuxt right now because the new version of Nuxt, Nuxt 3.0 is now in release candidate and is probably going to be out in September this year and is going to be awesome. It's going to do a lot of really, really useful things that we are really excited for.

Emily (19:50):
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great doves like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show.

Paul (20:27):
So we have these three products you mentioned so far, Nuxt, Vue and-

Drew Baker (20:34):
No that's it really. We're using well Vue, Nuxt then Storybook is the other one that we're going to talk about a little bit.

Paul (20:39):
I wanted to include Storybook that first one in here because how would you frame the way your pipeline works internally? How do these three teams that we talked about earlier come together and use these tools to really streamline this pipeline of development and make it easy for everybody to just create?

Drew Baker (20:57):
Yeah. So we have developed this process that we call factory. So this is an internal Funkhaus terminology here, but we have the factory process. And so the factory process for us is this, we get the design prototypes that have been approved and we're going to start building them. And so what we do is we do a design read in with the design team and so it'll be the lead programmer on a side and then one or two of other programmers that are really only going to be focused on building components. So we structure it like that, where we have one person who is basically putting together the jigsaw puzzle. And then we have an unknown amount of team members that are building the little pieces of the jigsaw. And so in our world, those are components.
So depending on how big the project is and how fast we need to get it done, we might have four or five people building the components. It depends on how fast we want to go, but we can scale those out so that we can build them as fast as we want, because what we do is we'll break down the designs of a website into components. So you've got a header component, you've got a little hamburger button component, you've got a slide show component, which is made up of a slide component. And then you might have an animation component inside the slideshow so you start to think of it like a dig jigsaw puzzle. So building out all the little pieces. And so we'll end up with a big list of all of these components that we need defined with some spec for each component.
So if you're familiar with React and Vue, you have this idea of props. So a component has some inputs and it might admit some events. So inputs would be like it has an image, it has a title, maybe text and then a URL. When I click the button, it goes to this other place. Those that might be some props examples. And so we build out this big spec of each component and we might end up average website will have about 50 components on it for us. And so what we do then is right as soon as we finish that, we can start building those components. We don't have to have any context of the whole website or anything like that, and we'll start building those in Storybook. And so Storybook is originally it was designed as kind of like a living style guide for your website.
So Airbnb is a classic example of using this. You can go and look up the Airbnb Storybook and it's like an interactive website that's auto generated of all the components used on a website and all the variants of components. You might have a button and then you might have a button hover state, a button deactivated, a button missing field input or something and show all the variance of it. These are stories. So you have the top level component and then all the stories that go kind of with it. And so you can build out these components in Storybook in an isolated environment. So you don't have to have it living in a website. You don't have to worry about like, oh, this is going to go on the homepage. You don't have to know any of that.
You just have to know the button looks like this and it's supposed to look like that and it's supposed to do this. And here's the props that needs to have. And if I click on it should admit some event. So we can then go from there, just building out those components. You know, there's some shared stuff that you need to set up like fonts and colors and some, some common variables that you might need to use, but you can get all that done in 20 minutes really. So from then the team building out the components can just run and build them as fast as they can. And we can put five, 10 people on that if we need to. And so that's the way we take it. And then each component gets built and we can QA each component individually and so we can pass the component over to the design team.
We run all this through Netlify. So we get builds every time a component gets completed. And so we can pass over URL to the design team and say, hey, this was the slideshow component, did we do this correctly? And a lot of the times we don't even need to show the design team because we're so in sync with them now, but we have a question so we can get ahead of it. They don't need to wait until the website is finished or we've built this one page, they can look at it individually. And so then once the components start getting finished, then whoever's up project lead will start assembling them into each page. And so at that point, they're just assembling a jigsaw and handling the data layer, fetching data from our whatever backend we might be using.
And we tend to use GraphQL to do that. So you really can build websites now in parallel and it's been huge for us. And that was a process that I have put a lot of energy into at front house. And recently we were hired by UCLA to teach their engineering team how to build websites this way, which was exciting. It was a crazy project to do and a lot of fun. So yeah, so that's how we do it. And then yeah, it works really well. We can get most of our websites done now in about three to four weeks, this way, fully custom, like we have some shared component libraries that we as a slideshow or a video player, for example. But most of the work we do is fully custom. We're starting from scratch on every component pretty much just because of the nature of the work we do, it's all custom designed. So, yeah, three to four weeks with a couple of people on it. Yeah. It's pretty quick.

Paul (26:28):
That's insane. I mean, so you pull you the designers and the component builders are organizing this custom component library. Does that go into its own Storybook?

Drew Baker (26:40):
Yep.

Paul (26:40):
Okay. Gotcha. And then so when you pull the component, can you explain the GraphQL part a little bit? That's very intriguing.

Drew Baker (26:47):
Yeah. So you build a website, you need content for it and there's a bunch of different ways you can supply content to a website. It just occurred to me that there might be a lot of users or listeners out there that aren't fully aware of this idea of a decoupled front end and back end. You know, it used to be that when Funkhaus started, we would build traditional sort of WordPress templates. So you would have PHP, WordPress, CMS, building out PHP templates. And that was it. So you had these server side rendered, use servers out, putting your server is out outputting HTML. And that's what the user sees. You know, that's a very traditional way of building websites. The new way of doing that is you would have these decoupled front end and back ends.
You might've heard the word jams stack, that's kind of what they're describing here. So you would have a back end CMS of some sort that's only output is via an API. You know, Jason object, essentially and you used to have a rest API, which would just output these giant Jason objects of data that you need, but the new newness is GraphQL. And so that was pioneered by Facebook and is a way to request only the data you need. So if you need just the title, you just ask for the title, if you need title and an image, you would ask for title and an image and so it's much more efficient way of moving data around. You don't have to just with a rest API, you just get what they give you here. You can tell them what you want.
So that's a GraphQL endpoint. And so we now use a headless CMS. And so headless CMS headless means there's no templating built into the CMS. It's only the data model really. And so generally we'll use a headless CMS and funny enough, most of what we use is headless WordPress. So we have a WordPress CMS running, using the WP GraphQL plugin to make it. So the only output from WordPress is GraphQL. So it gets around a lot of the kind of legacy problems and issues with WordPress and plugins and templates and yeah, PHP and all that stuff. And we don't deal with any of that. Basically it's a no code CMS now where it just outputs GraphQL by one endpoint and then we just call that on the front end as needed, and then use those in passing down into the components as we need.
And so the great thing about Nuxt and it's the same with Next is you can run those frameworks in different modes. And so you have a server side rendered mode, which would live on a node server. So for us, we would use Heroku, not really out of love for Heroku actually, more just legacy we've been using it for a long time, but yeah, we would use Heroku for a service side rendered site. And you do that on a website where you want a lot of instantaneous time from publish to the user, seeing it needs to be instant and that's service side rendered. And that's basically a node server building out the HTL and just giving it to the user on request. And so for a big website, like for us, it was floodmagazine.com.
That is a giant music magazine, and obviously, they need their stuff, it needs to be instant, but most of what we do now, nine out of 10 websites would be static site generated sites. And so what that means is when content is published, you trigger a front end build process, which basically like your back end and builds out static HTML of every URL it can find. And so then that takes about 10 minutes generally and then you just ended up with basically a folder of HTML that then just gets pushed out onto a CDN. And so those websites are insanely fast because really it's just static HTML given out over a CDN. There's no connection to the back end. There're no servers involved, that's very serverless thing. And so that's now what we do and we'll use on the front end to run that build and handle that deploy on the CDN and everything like that.
So that's our stack and then the what'll be coming out with Nuxt 3.0 Eventually. And it was already in the Nuxt world, which is kind of a hybrid of both called incremental static rendering. And that's where you have the benefits of both where there's a static site given, but anytime new content is published, it incrementally like update the parts that just updated or they'll just slowly update the whole website as each route gets built, they just push them individually rather than waiting till it's all finished and pushing all of it at once.

Paul (31:24):
I feel like that's the end state, right? Because 80% of the bundle is boiler plate and your nav bar and all that sort of stuff. The updating content is small in terms of the bundle.

Drew Baker (31:39):
Yeah. I know. And it gets really annoying once your site gets big enough that those build times take anything over 10 minutes. I mean, it is already annoying after a minute, but what we found is, especially for the work that we do, which are these high end marketing portfolio brand websites, it's fine and having the speed, here's a great example actually. This big website for a big music video advertising video production company called London Alley. And so really check it out London Alley, great website, super high design, amazing work. Just because we built that website 2019, I think originally that was a service side rendered website that would score about a 50 on Google page speed on the lighthouse scores.
And recently just converted that, didn't change anything about the website other than just updating the code to work in a static site generated friendly way and now gets like 90. So I just got a 40 point bump just from doing nothing really just from static site versus service I rendered. So yeah, static site is just incredible once it gets all working.

Paul (32:54):
It's good that's the direction that we're all moving in these days, anyways in the web world. So one thing that I love about the way you've described everything, but the way your company works, it reminds me a lot of how a cloud engineer or architect or data center person like yourself, like back in the day would organize a distributed system. You're thinking about, where are my bottle necks? How can I parallelize these things going on and come to the same output? It sounds like with these tools with storybook, with Nuxt, with Vue, you're really able to take some people and have them do this at the same time and other people do that and parallelize it. And then also scale up and scale down these teams in their own isolated silos that allow everything to come together on siloed beautifully at the end.
Where do you think the bottleneck is right now in the stack and the org? And I say the stack and the org, because your stack is your org and your org is your stack. It sounds like you're very well integrated. So is there a bottleneck you're trying to tackle now? Is there an improvement that's coming down the pipeline maybe in Nuxt 3.0 or something that you're excited about?

Drew Baker (34:08):
Yeah. So the bottlenecks totally what you said, we've approached this like a cloud engineer, distributed systems is a great way to describe what we've done here. So there's two sides to, this is the human part of it and the people bottleneck and that's just organizing your company in a way that's more efficient. So we can talk about some bottlenecks I see there. But then on the technical side, the bottleneck for us totally is the build times. And the like I said, DDoSing your back end. And there's not a lot of CMSs right now that are really set up for that. There's a couple of really smart new ones, anyone out there looking like there's one out of France called Prismic that is really, really set up for this, headless CMS doing some really advanced stuff where they're like API is also static generated, it's pretty incredible what they're doing there.
So that's really good, but what we are doing with WordPress and a lot of other CMSs that are mainstream enough to stand behind, there's plenty of bootstrapping new ones out there that are not something that we could sell onto our enterprise clients, but WordPress as a CMS, no one quantity as a CMS, the headless part of it is all new. That's a real bottleneck and there's only one WordPress host out there really, WP engine is the one, that is trying to handle this in a modern headless friendly way and getting those two to work together really well.
Because like I said, most hosts are going to look at a build process as a giant ddos attack. And so they don't know how to handle that. They don't know how to bill for it. They don't know how to scale the traffic. Here's a great example on the math that works out here. If you request an average website like we build, we might have one graph QR request to build out a menu, one graph QR request to build out some open graph tags, one graph QR request to build out the page data, and then maybe another one or two to handle a secondary menu in the footer or something like this. Now you could go to a lot of effort and combine all of those into one graph through our request, but it's much easier if you kind of just have like the menu FES, its own data, the foot of FES, its own data.
So we ended up with about five to eight requests per page. So we have a thousand pages, that's a thousand times five. And so you're going to have 5,000 requests just for a thousand page website, best case scenario, maybe that's 8,000 if you've got an extra couple of requests in there for every page. So what's going to happen is going to trigger a build. Andy is going to go, okay, build this website as fast as it can. So it's going to hit your back end eight in eight for 8,000 requests as fast as it can. So a lot of our hosts are like, why are you getting 8,000 requests a minute? You know, it's like, well, for that one minute we are. But after that, it's zero for maybe the whole day. And so the hosting environments really have haven't caught up yet.

Paul (37:31):
It's like the dirtiest of workloads possible.

Drew Baker (37:34):
Yeah, yeah, yeah. So the hosting companies really haven't caught up. And so that's been a huge pain point and WP engine are trying and certainly really engaged with that. And so that's been good for us, but that's been a big bottleneck is just the back end stuff catching up with this front end because the front end world has gone so fast now, like what is going on in JavaScript is just insane.

Paul (37:58):
It's insane, right? It's changing extremely fast and it's also not just language ads, it's a complete development paradigm shift that have happened. I guess that's the nature of JavaScript though. It's an unruly landscape of development.

Drew Baker (38:15):
And the infrastructure going on like Microsoft buying GitHub and MPM and like the MPM stuff has been crazy. So it's really interesting what's going on in JavaScript and the front end world and the back end world, I don't think has kept pace really. And so there's a big bottleneck going on right now for us, especially. So that's one. And then on the people side, it's not so much as a bottleneck, but it's just a huge pain point I suppose, is just animations. Just the need and the want for our clients for just high end animation and doing really weird things that seem, I guess I blame apps because everyone's gotten used to using an app on their phone and thinking that when I click on this image in a grid, that image might expand to the top of the page and now I've got the detail page, but doing that in a website is actually really complicated, animating a component across a page route transition or something, easy enough to do one or two examples of that, like a menu opening and closing or something.
But if you want the whole website to work that way, it gets really crazy. And so that kind of stuff is really something we put a lot of energy into, it's just better animations. And like you talked about the homepage of the Funkhaus website. Messing with scroll position and all these kinds of things and doing that in a way that isn't just annoying. You know, it's easy enough to animate everything on a website and it just be totally unusable. The trick is doing that and having the website still be usable and actually add to it, not be a giant distraction.

Paul (40:04):
Right. And I think one thing about the Funkhaus website, going back to what I said at the beginning, that is just so cool about that animation is it wasn't vanilla. You reinvented the way that I would think about using the scroll why variable. It was used in more ways than one that is traditionally used and that's the type of thing I'm guessing too, the reason why animations are difficult, you can't just reach the green sock to implement that. You can use their helper functions to grab the pointer and manipulate the Dom elements if you want or whatever library you use. But I'm guessing these animations are truly like you're crafting the animation.

Drew Baker (40:42):
Yeah, absolutely. How we built that is basically, you figure out how long that carousel is from left to right and then get a percentage of the scroll position and translate it.

Paul (40:57):
Right.

Drew Baker (40:58):
And so, yeah, there's a lot of weird math going on there and trying to understand how wide something is, but also make it responsive. And yeah, I wish it was way easier. And there really isn't, especially in the view like green sock for example, that was written originally when Jay crew was a thing.

Paul (41:14):
Right? Yeah. That's old.

Drew Baker (41:16):
It's old. It wasn't really written in these shadowed front end kind of things where when your app starts up, half those components aren't even in the dom yet. So it gets real tricky. And it's only recently that there's been some animation libraries coming out that are actually set up for this kind of stuff. Motion, check it out. Motion.

Paul (41:41):
It's not remotion, it's motion.

Drew Baker (41:42):
Motion.dev. Yeah. Motion.

Paul (41:44):
Okay, motion.dev.

Drew Baker (41:45):
Great. It's from the guys that did pop motion for React. So it's only starting to become a thing now, but yeah it's still hugely custom. So it's a real pain and it's a lot of effort that goes into it. And at the end of it, it should look easy, but behind the scenes, it's really difficult.

Paul (42:03):
Well, we're unfortunately coming up on time here, I have so many more questions I want to ask about this clean run smoking machine that you have over at Funkhaus and how you guys are using these tools to really win the race here and produce these amazing looking sites. But since we're wrapping up, I'm going to point viewers to go to the Funkhaus website, of course, check out what Drew and his team have built out. Is there any other things you'd like to point out to our viewers drew or socials of viewers, if you like to direct people over to follow?

Drew Baker (42:36):
Yeah. Yeah. Check out Funkhaus website obviously. And then I'm on Twitter, Drew Baker underscore, that's why I post just any of the interesting stuff that we're working on really. And then the Funkhaus Instagram account is really good. Just F-U-N-K-H-A-U-S. We just won a Webby, which is pretty exciting. We just won a Webby for a project we did for Adidas called songs from scratch. You want to see some weird stuff? You should check that website out. That's pretty cool.

Paul (43:05):
Sweet. Okay. I'm Googling it right now.

Drew Baker (43:08):
So we want to wear with that one, which was exciting and yeah, we're just chipping away and trying to make one cool website after the other.

Paul (43:19):
Heck yeah. I mean, that sounds like fun. You're really getting creative and pushing the envelope here, so. Well, thank you for your time Drew. It was great talking about your company and what you guys are doing. And hopefully, some listeners can check out some of these tools that you were mentioning, or if they're already using them, take inspiration about how you guys are keeping organized and proficient.

Drew Baker (43:42):
Yeah. On that note, Paul, I would love to say that if anyone's out there listening and they hear this and they think, ah, this sounds really fun and I'd like to do this kind of work. Send me an email drew@funkhaus.us, because we're always looking for talented people, actually looking for a technical, not a tech, a senior technical person right now. So send me an email if you're interested.

Paul (44:06):
Right on. All right. Well, thank you for your time Drew. Thanks for coming on.

Drew Baker (44:10):
My pleasure, Paul. Thanks man.

Kate (44:25):
Thanks for listening to PodRocket. You can find us at PodRocket Pod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.