Ben: Hey everyone, and welcome to PodRocket. Today I'm here with Nick Reese who's the creator of Elder.js and Elder Guide. How are you doing, Nick? Nick Reese: Good. Doing great. Thanks for having me. Ben: Really excited to have you on, and I've read a bit about Elder.js. Maybe before we even talk about what it does, maybe you can talk about what kind of the journey you took to building Elder.js and then we'll get into what it does and how it works. Nick Reese: Sure. For sure. Yeah. I have a kind of a non-traditional entry into the development space. I've always been a SEO/affiliate marketing guy. I've done that for, just came up on 15 years now. Basically I always joke that SEO has paid the bills since I've had bills to pay, and that's pretty true. Nick Reese: After selling my last company in 2018, essentially on that company, I had a technical co-founder, that was one of my best friends, but he kind of decided he's going to retire. I was like, "I still got more left in me, but I want to be able to develop everything." Before I could do CSS, JavaScript, some front-end stuff, but nothing fancy. So, I taught myself JavaScript and essentially ended up setting out to build my own static site generator because I had played with all the other players out there, like all the other static site generators that existed and nothing really scratched the itch that I was looking for. The ultimate manifestation of that is Elder.js. Ben: A bit more tangibly, I guess, what does Elder.js do? How does it work? How does it help with SEO and all those great things? Nick Reese: For sure, for sure. Essentially I set out to build a WordPress alternative in the JavaScript ecosystem. Essentially Elder.js handles partial hydration. WordPress doesn't do that, but the main reason why I wanted to build it was partial hydration. Which if you're not familiar with that, that's essentially, there's multiple different ways a page can be hydrated. One is fully on the client, partially on the clients, or just statically serving HTML. There's a pretty big conversation around that in the development space. I wouldn't be surprised that this isn't news to most people. Essentially when I started Elder.js, there was no one doing partial hydration. I decided I really wants to work with Svelte, and I want to find a way to do partial hydration. Initially when I started building, I wanted to build a major site. Nick Reese: What I mean by this is a site that has 10,000+ pages. In order to do that with a static site generator, you're generally looking at a several hour build time. I wanted to have something that was much shorter build time. Right now we build elderguide.com, that's like 18,000 pages and under two minutes. It's pretty fast and that's on a beefy server, but with the database locally, but it can go much faster than that. Elder.js can actually outperform Hugo in some user tests on like 20,000+ pages. Basically I know I'm not doing a great job of introducing it, but Elder.js is essentially my tool that I wanted to build in order to build my flagship SEO sites. So today, we have Elder Guide that runs on it, findenergy.com that runs on it. A few other sites that we don't really talk about on it. Elder.js powers all of them. Nick Reese: There's a few design philosophies that were in there that essentially underpin the entire reason why I built it. Is first it should be able to build fast. It should handle partial hydration. There should have SEO friendly defaults and the framework should never do anything that cause you SEO issues. Third, all the complexity should be isolated in the same places on every single project. We use hooks that are very similar to WordPress hooks, not similar to React hooks, but essentially these allow you to plug into any part of the build process, any step in it. Essentially really, inject your own code or edit what the static site generator's doing. Additionally, we have short codes. If you're not familiar with short codes, it's a fantastic way to essentially future-proof your content. Nick Reese: Those were all the big things I was looking for. No one really offered all of that in a single package, and so you kind of start scratching your own itch and say, "Hey, I should be able to build this in an afternoon. Like the start of this, let's prove this." Then you look and you've got like four months sunk into it, and it's become its own beast. I really think it's the best at specifically what it does. It's designed to power major SEO sites. Additionally, I didn't intend to do this when I started out, but I had built a preview system in order to preview your changes when you're developing locally. What that's evolved into is a perfect upgrade pathway from static site generator to server-side rendering. Elder.js does do server-side rendering as well. That's the overview. Ben: Yeah, no, that's super helpful. Maybe if we unpack that a bit. Starting with, you mentioned this concept of it has SEO by default. I feel like for a lot of people SEO, people have some basic ideas about what helps with SEO. Like the site has to be fast and your information architecture has to be a certain way. I feel like SEO is kind of a black box in some ways. A lot of people don't really know what are best practices. When you think about how Elder helps you have SEO best practices, like what are the most important items there? Nick Reese: Essentially this comes from my experience Gatsby and I converted a major WordPress site over to Gatsby back in 2018. And, it became a disaster because what ended up happening is Gatsby kept on pushing additional changes that were causing SEO issues. Like our canonical tags changed on the entire site, and we didn't even notice it until several days later. That's a major SEO issue. While I say essentially Elder.js is SEO first, what I'm trying to say is that it's not going to get in your way, and it's not going to cause problems, SEO specific problems. For instance, we do a lot of checking to make sure all the permanent links are unique, which is kind of obvious, but it's really easy to add canonical tags. It's easy to add breadcrumbs. It's easy to add a whole bunch of different items there. Then there's a built-in SEO check tool that goes with the Elder.js template that goes through and checks like 50 some different common mistakes to kind of prevent yourself from shooting yourself in the foot, like having an undefined in your title tag and stuff like that. Ben: I'm actually not familiar with breadcrumbs. What is that concept? Nick Reese: Breadcrumbs are essentially the navigation path throughout a site. You often see this when you enter a site deep into the site and you might have like the home icon and then it'll have like several different links up. You can essentially set that up. You can embed JSON-LD and Google will grab that and add that to the search results in some cases. Elder.js makes that easy. In fact, I should have a plugin out in the next couple of weeks that just does it automatically for you. Nick Reese: One of the main things about this hook system is I also designed it so that plugins are first class citizens. Essentially they have access to their own entire lexical scope. They also have access to set up their own templates, and then they can add their own hooks and short codes. They could essentially do everything that the user can do by just adding a plugin. And so, that makes it very easy to add a site map. It makes it easy to add live reloading. I have a whole group of plugins that I've developed and released, and there's some community plugins as well. Ben: You mentioned one of the other benefits is that with Elder.js, your build times are way faster than if you were having a multiple hour build with thousands of pages. Is that because you're doing partial hydration so you're not actually building the entire site statically, or are you doing some kind of optimization to statically build very fast? Nick Reese: Before building Elder.js, I built a high-frequency cryptocurrency trading bot. I was moving tons of crypto in milliseconds, basically four milliseconds between trades as fast as we could liquidate it on Binance. I learned a lot there about hot loops and all that other stuff about how to optimize and code and a lot of how Elder.js is structured is it's designed to always be running the hot loop. Then it also builds across all the processes across all the threads that it can possibly expand to, so it's fully parallelized. That's mainly what's making it fast. Nick Reese: Essentially partial hydration actually slows us down quite a bit, but what partial hydration does is it fully renders the HTML and then wraps a div with whatever component that you want to be mounted and then remounts it specifically on that unique div. There's quite a bit of extra work that goes on to do partial hydration, but it's definitely... The build times are something that was really important to me because you'll see a lot of the other static site generators in the space talk quite a bit about incremental static generation or incremental builds. Solely change what's built. When I was looking at that problem, that's a very sexy engineering problem, but it's not a very practical business problem. It just isn't because computing resources are incredibly cheap. Nick Reese: We have a single, super beefy bare metal box that we pay $200 a month for and it just is our build server. It's got like 24 cores and it just goes. It's much easier to throw computing resources at something as long as it's fully parallelized than it is to calculate all the dependencies of the data that might be required to generate the pages. That's the reason why I chose to focus on that instead of incremental generation. Ben: From like a runtime, I guess my question is, you are building the full site statically, so you get all the benefits of performance in production at runtime, plus you get fast builds? Nick Reese: Yep. Ben: Right. How does this compare to what you can do with Next.js? I know Next has some of these similar concepts where you can do static site generation. You can do partial hydration, server-side rendering. I mean, I'm forgetting the name of the concept, but there's another intermediate concept they've coined. How do you kind of think about the paradigms of building with Elder.js versus using the Next stack? Nick Reese: I tested every single possible player before I decided to build my own. I test tested Next, but this was back in late 2019, early 2020, so it's a couple of years now. At the time, what I was finding is that most static site generation was kind of an afterthought. The main issue with that is that it's very easy to build a server-side rendered application, and then run a spider on it. Then now, you have your static site. I basically set out to just build a static site generator that could be as fast as possible because I mean, I was used to dealing with eight hours of Gatsby build times. Nick Reese: I hadn't built with Next anything more than like I built a single template with some basic content on there. At the time, it was taking 40 minutes to generate a couple thousand pages. And I was just like, there has to be a better way to solve it. Essentially I went static site generator first, and I think there's just a different approach to it when you're building a static site generator and then you kind of tack on server-side rendering versus when you start with server-side rendering, and you tack on static site generation. Nick Reese: I think what Next.js does is fantastic. I think it's a fantastic solution for the vast majority of people, but it doesn't support Svelte. I really think my preferred tech stack is Svelte with PostGraphile. I just think those two things together, you're building with cheat codes, and you can just do amazing user interface stuff that's very hard to do otherwise. A lot of what Elder.js has is custom built for what we need, but I know several very, very, very successful sites, In addition to ours, that are using it specifically for an SEO focused site where they don't want SEO issues. Ben: When you think about the average React site you see out there, what are the SEO mistakes people make? I'm curious, like you've mentioned Elder.js has the SEO check tool. What kinds of things does that detect? Just generally, what are common pitfalls to avoid? Nick Reese: Yeah. The SEO check tool, Luke Edwards and I are working on a revamp of it, but it's going to be way more pluggable than it currently is. To answer the first question, when I look at React sites out there, probably my biggest pet peeve, and one of the things that's incredibly hard to debug is anything that has to do with when you have a service worker. We had this obscure SEO issue with Gatsby that had to do with the service worker, and we couldn't seem to debug it no matter what we did. We had to rip out the service worker and finally the SEO issue went away. So, I'm very much against service workers, because I just think that they... If there's one thing you know about SEO is if you've been around that community at all, is they all wear tinfoil hats. They think like Google is spying on them and stuff like that. Nick Reese: For me, one of my quirks is that I don't like service workers at all, because I generally think that they make things a lot more complex to debug. And so, I'd be very careful with service workers. As far as the most common mistakes, it's things like undefined in the title tag or your meta description or undefineds your page that you're not checking for. It's having your H tags out of order. Nick Reese: But there's a lot of on-page stuff that you can get right by just kind of paying attention. This is a lot of what SEO check does for you. It's saying, "Hey, your title tags should probably have your primary keyword and your H1 should probably have primary keyword as well. At least one of those words from each of those should match." It's checking that sort of thing. Then similarly it checks all your H2 tags, H3 tags, H4 tags, at least make sure one of those has a word that matches your title. It's a lot of what you'll see is that, especially as you get into bigger companies, is that the SEO team is disjointed from the development team and even the marketing team often. They're part of the marketing team, but they're not part of the content team. They often give direction to the content team. Nick Reese: Having worked in that environment after selling my company, I consulted for a year with a company that was like that that acquired us. What I found is that everyone knows SEO is a priority, but often what you find is that if the developer isn't aware of SEO best practices, essentially you have this roadblock that comes up to where the SEO has to go to the marketing team and the marketing team has to go to the development team in order to get anything done. Kind of my hypothesis is, is that there should be the ability for an SEO tool to live in the CICB pipeline and essentially surface common issues. SEO check is the first iteration of that, and it's built right into Elder.js. But, the future iterations will work on any statically generated site or anything like that. Ben: What does your future roadmap look like? What are you most excited to build up the next year or so in Elder.js? Nick Reese: As far as the Elder.js, I'm pushing small changes, like bug fixes. Right now, I pushed one today. But, the vast majority of what Elder.js needs to do is done. It's very much in maintenance mode, and so I've had requests of like, "Hey, can you do what Astro is doing? And also offer React's partial hydration? Could you add view partial hydration?" Those sorts of things. While I'm open to those sorts of PRs, it's just not something that I can develop business resources to do right now. But essentially, I mean, I have five major sites that run on this now. I talk about two of them, but I have five major sites that run on this and with close to 20 data collectors and a large content team and all. It's serving us incredibly well. I'm not seeing anything that's really missing. Nick Reese: Knowing the system inside out and knowing what our, what we need from an SEO perspective, I think we're at a good viewpoint to essentially say there are some things that I would like to develop. Specifically, I'd like to move away from Rollup and go towards Esbuild, and I would like to be able to do hot module reloading. But, right now, because of some of the design choices on the way we set up Elder.js early on, hot module reloading just isn't super viable. We have pretty fast refreshes as far as hot module, well, hot page refresh or whatever it's called, where the page reloads every time you save, it's pretty fast. I would like to make those improvements, but the juice just isn't worth the squeeze often. Nick Reese: Essentially, that's not a great answer to that question, because the people like to hear things are moving forward, but I would say that Elder.js is essentially incredibly stable. I'm very happy with where it's at. And like I've said on the GitHub and on the documentation, we'll make sure that it's maintained at least for the next two to three years minimum because we're not moving our sites off of them. It can be maintained much longer than that. Nick Reese: We're only adding features that are really major requirement features. I imagine mid next year we might do another sprint to kind of focus on having, because we're going to be building out some dashboards where on Find Energy where the providers can log in and manage their own profiles. We're going to be, dogfooding more heavily Elder.js and using auth and all those different things. There might be a flurry of changes that they come out then, but in general it's pretty stable. Something I would like to figure out how to do is how to get it to run on Cloudflare Workers or any sort of like Edge Lambda, but due to the way that it bootstraps and their shared memory across all of the plugins, it's just kind of not feasible. I have a wishlist, but there's things that I would require a major rearchitecture and the juice isn't worth the squeeze right now. Essentially I say Elder.js Is in a very stable place right now. Ben: I'm curious to learn about some of your sites. Would it be accurate to say to Elder Guide is kind of your flagship site or ...? Nick Reese: Currently, no. It's not. It's the site that I built in order to prove Elder.js and I still have really large ambitions for it. Essentially there's a few business issues. I don't believe the marketplace the way I want to monetize, I don't want to be charging nursing homes. I feel bad about that because nursing homes have incredibly thin margins. Right now, when they sell, they work with two major reseller or two major companies that are like Elder Guide that rank for all sorts of keywords. Then they send those customers to a call center and those call centers squeeze these people into the nursing home that pays them the most. Nick Reese: I don't want to be a part of that. While I do think there's a lot of opportunity in that space, essentially, I see Elder Guide kind of sitting and cooking and it'll get incremental data refreshes, but not a ton of new features. Specifically because I don't like the monetization options, and I don't want to be a part of the problem, which is essentially pushing people to the nursing home that pays the most. Essentially it's cooking is the way I think about it. It's just kind of sitting there. It'll be there. It'll continue to be updated, but it's not going to be the main focus. The main focus these days is in findenergy.com and Find Energy takes billions of data points, just like Elder Guide, but does lots of calculations to figure out essentially where are the dirtiest power plants in the United States? Who are the owners of those? What electricity companies serve what areas? If you're in a deregulated state, what are your other options? Nick Reese: Then additionally, we've imported a whole bunch of data from Google Sunroof and several other data sources that allow us to do calculations to estimate at what point would you break even if you installed solar? Doing quite a bit more there, because I think that there's that famous saying, I forget who said it, but the smartest people of the generation we're focused on figuring out how to get people to click ads. My co-founders and I are all very passionate about kind of changing the energy situation and bringing, at least surfacing, awareness that anytime that you type on your keyboard or that you have a light on in your office that that represents a fire burning off and a long distance away from you, or it's the wind blowing, or it's water falling off a cliff. Nick Reese: Something has to be done in order to produce this energy. We're so far removed from that, that it's hard to realize kind of the consequences of our actions. I want to be a part of the energy transition. That's where we're focusing our efforts right now the most. Ben: For Find Energy, I can go to that site and it will help me determine, can I switch to renewables for a percentage of my power, or does it make sense for me to install solar? Is that kind of how it helps consumers? Nick Reese: Yep. We're going to be rolling out the solar calculator page in the next probably two weeks, but currently what we've done is we've... Believe it or not, the US government doesn't seem to know what power companies operate in what areas. Believe that or not, it's pretty wild. Nick Reese: We built our own user interface in order to actually visit outage pages of every single provider in the United States and draw their coverage shapes because that's about as good as you can get because the US government doesn't seem to know. Like we've asked them, "How do you know who has coverage on what?" They're like, "Oh, you know, Department of Homeland Security has this map." But then it shows that, like I'm from Florida, that Florida Power and Light covers the vast majority of the state, but then it really does. It does cover a large part of the state, but because Florida is a regulated state, there's monopolies everywhere. Of course, you can't have two providers offering a service. We're really trying to figure out that problem first, because we think that it's really hard for policy makers to make policy decisions if they don't actually understand who offers coverage. Nick Reese: Then we're really focused on kind of surfacing the reality that the top 50 power plants in the United States produce the vast majority of all the pollution. Surfacing information around that as we move into solar. We're kind of facing a chicken and egg problem where we need to get solar installers in order to buy solar leads. It's an interesting spot to be in. It's a fun business spot to be in. Yeah, we're super bullish on the market in general and just the ability to influence change in a market. What I found with my prior company was called Broadband Now, and what we did is we essentially did the same thing we're doing in the energy space. We took government data and we did all sorts of complex calculations to figure out what internet providers offer service in what areas. We were the biggest third party retailer affiliate in the space. Nick Reese: We generated like 30,000 visitors a day with two million minutes of talk time a month to call centers. We were the huge whale in the space. During that time, what we found is that we were able to help bootstrap a huge amount of fixed wireless providers by just allowing them to list themselves for free. I think that not three years from now, maybe five years from now, I think there's going to be a major movement towards more deregulated electricity, which should allow consumers to put solar panels on the roof and sell it back into the grid with net generation. In general, I just want to be a part of that movement. It seems that I'm finding more and more smart people that have come from affiliate spaces that are essentially looking at how do we use business in order to influence change in the world? This is kind of my approach to it is Find Energy. I would say that's a hundred percent of my effort is going to there now. Ben: If folks out there are interested in checking out either, I guess, Find Energy is just findenergy.com, so that one's pretty straightforward. For Elder.js, do you take open source contributions or PRs? I think you mentioned earlier, you would accept PRs. If folks are interested in contributing, what's the best way to think about that or just learn more? Nick Reese: Yeah. Elder.js organization on GitHub is of course we accept code contributions, community plugins. Really, I get excited when I find that that people are using it. I love it when people reach out to me. It's funny, in affiliate marketing and SEO, people generally keep to themselves about what they do because they don't want competition. Nick Reese: I often joke that being vague is about as good as that other thing, because almost all affiliates and SEOs, essentially, don't talk about it. But, there's a growing amount of sites that are moving to Elder.js, and I'm hearing about it. That makes me excited. As far as things that where they could check us out, I would say, check out findenergy.com. Feel free to check out Elder Guide, but I don't really have too many other irons in the fire that I talk about. I would love contributions or anyone that's interested in Elder.js to check it out. I'm super active on the Svelte Discord. If you decide to check it out, make sure to join the Svelte Discord and look at the Elder.js channel. If you have questions, I'm in there helping generally most days. Ben: Well, Nick, thanks so much for joining us today. Nick Reese: Awesome. Thank you so much for having me. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me even though that's not a popular option. It's Brian at LogRocket.