Show Notes
Full Transcript:
Josh:
You're looking chipper, Ben.
Ben:
I'm feeling chipper, Josh.
Josh:
I'm glad.
Starr:
Yeah, there's kind of like ... you have kind of like a glow. Is this the new product glow?
Ben:
I think it is the new product glow, yes, yes.
Starr:
Okay.
Ben:
I pushed out a new feature this morning.
Josh:
Congratulations.
Ben:
Thank you, thank you. So, yeah, feeling pretty good. Had a good week, got some stuff built and deployed and things are working. I learned some things along the way, so yes, it's good.
Starr:
Awesome.
Josh:
You know, I had a pretty good week too, sleep aside. I even got enough sleep one day.
Starr:
Oh really? That's good.
Josh:
Yeah, yeah, that was a good day.
Starr:
Thank goodness, that's always terrible.
Josh:
I've been making progress on the JavaScript stuff so that's always good.
Starr:
On redoing our node client library?
Josh:
Yeah. Yeah, the universal rewrite. So it's combining the client side and the server side so that they can both function basically the same code running on the front-end and back-end with a few minor differences in how the platforms handle all the important things. So, it's a bit of a can of worms but it's what the kids demand these days, so got to give them what they want.
Starr:
Like your kids? Kids are pretty-
Josh:
Yes, all my kids are demanding universal NPM packages.
Starr:
My kid just demands pizza.
Josh:
Yeah. We've been making pizza lately and it's been pretty good.
Starr:
Oh, yeah, yeah. I've been doing it too. Have you been doing the dough where you let it rise for a day and all that?
Josh:
Yeah. Caitlyn does the dough and then I do the ... We got that ... Did I tell you? I told you all about the smoker with the ... It's a pellet smoker with the ... It has a pizza oven attachment that sits right directly in whatever the furnace part of the smoker, and so you get this ... It's like a wood fire pizza oven, and it can cook your pizza at 800 degrees or higher, so it's pretty intense.
Starr:
That would be really handy. We've scaled back our pizzas just because it's really hot and nobody has AC in Seattle and neither do we. We've got a unit that we can drag up from the basement and it's ridiculously obtrusive and everything, but yeah, we just try and avoid running the oven in this weather.
Josh:
That is one nice thing about this is that it's on the porch. I spend my time out there sweating on the porch baking pizzas, but everyone else doesn't have to be bothered by it.
Starr:
Yeah, we've been grilling a lot too and we've been trying to eat less meat, and so we've got this CSA farm box thing and they give us these weird ass vegetables, so I've just been grilling them all and it turns out pretty much every vegetable is good if you just put oil on it and you grill it.
Josh:
Nice.
Starr:
Did you know there's such a thing called garlic scapes? I didn't know this. Do y'all know what garlic scapes are?
Ben:
Nope.
Starr:
If you've ever seen a garlic plant growing, there's a garlic part that's in ... it's under the ground, right? But then there's the stem part that sticks out and it's kind of round. It has a little onion bulb on top and that is called the garlic scape. I guess you can cut them and grill them, and they're delicious. They're delicious.
Josh:
Have people always been eating these? What have we done with these for the last however long that we've been eating garlic? Because I've never heard of this before.
Starr:
I imagine that people who grow garlic have always eaten these.
Josh:
They must eat them all? Like they save the good part ... That's the good stuff probably and then we just get the-
Starr:
Yeah, it must be.
Josh:
... Yeah.
Starr:
We get the dregs.
Starr:
Yeah. I had a pretty good week too. I worked a bit on the static site for ... or the sales site for Hook Relay which is the new sort of product that Ben has been working on with Kevin, and Josh, have you been working on it too? I don't want to leave you out.
Josh:
No.
Starr:
Okay, okay.
Josh:
I've been rooting for them though.
Starr:
Okay, that's good. Everybody needs a cheerleader.
Josh:
I'm cheering hard over here.
Starr:
So yeah. Today we're going to be talking a little bit about sort of sales sites, the static site that you sort of put out into the world so people can see your app, and that's not necessarily the actual sort of app itself. So I guess we currently for this, we have our sales site hosted on a separate domain, but it wasn't always this way. When we first launched Honey Badger we had our main Rails app and the sales site was just some pages served by that app. We eventually changed that. So why did we eventually change that and move it into its own domain?
Ben:
There were a few reasons there. One of them was we got kind of tired of having to deploy the app every time we wanted to make a constant change to the website.
Starr:
I forgot about that.
Ben:
You know, because it has to go through all the test suite and everything. It's like, oh, five minutes to deploy a one word change to the site.
Starr:
It's like it made a typo, it's going to take 10 minutes to deploy.
Ben:
Yep, yep. Another thing was, as I recall, we just had customers who were getting ... Some got confused about which ... I remember we had customers who were submitting traffic to www.HoneyBadger.io. Like, API traffic instead of ... I don't know how that happened, but instead of using our API domain, they use our dub-dub domain, and because the app also responded on dub-dub, then it just worked. They're like, "Okay, cool," and we didn't notice, and then, I don't know, three years later when we were moving stuff around and changing how the hosting was going, it's like all of a sudden we broke that client because they were still sending traffic to our main domain instead of the API.
Josh:
Yeah, probably an oversight on our part. To the allow the traffic to that domain if we were hosting different roles like that, but that's just kind of how we do it.
Ben:
Yeah, but when we first launched, the Rails app did everything, right?
Josh:
Yeah.
Ben:
It was the site, it was the app, it was the API.
Josh:
Which, to be fair, I like that a little bit. There's something about just having one thing that was nice and-
Ben:
Yeah, it's simple.
Josh:
... There's some other benefits, like you can do weird things with the sales site that integrates. Well, you can display a ... It's easy to show a logged in link or something because you have the cookies and everything right there, the session, because it's all just your app, but yeah, it presents other issues once you ... down the road.
Starr:
So Ben, were you telling me that somebody was discussing this? Was that in the discourse?
Ben:
Yeah, yeah. So a few weeks ago on Twitter ... I think Tyler Tringas brought this up. I think he was just throwing out some advice for people who are starting up, and he's like, "Here's a piece of advice that you'll like down the road. Separate your app from your sales site," and a lot of people were like, "Huh? Why?" And other people were like, "Yes, totally." And all the "yes, totally's" are people like us who had been there and done that, and like, "Yep, it's less painful that way if you just start that way."
Starr:
Yeah, also there's just a number of little things you don't think about when you're just a developer making your app by yourself and doing everything. It's like eventually you may want to have marketing own your sales site and not be able to deploy changes to your application. That may not be something you want them to be able to do, not because they have any malice in their hearts or anything, but just because you want to ... You don't want to have to train everybody on proper procedure for not destroying the profit making entity in your life.
Ben:
True, true.
Starr:
Yes.
Josh:
Are we primarily talking about the sub-domain that you use, separating that? Or are we also talking about physically from the app? You could use an app and a WWW sub-domain still pointed at the same app. Maybe restrict certain things to each.
Starr:
That's a good point.
Josh:
That sounds complicated but that would put ... If we're talking about specifically sub-domain-related issues, because there are ... There's SEO and other concerns about having everything on the same domain, I think. Do you have any feel for that?
Starr:
Yeah. We've kind of been conflating those two, right? In this discussion so far?
Ben:
Yeah.
Starr:
Do you have separate WWW versus app sub-domains and do you have separate, I don't know, sites? Separate repos with separate things in them for your app and your site?
Josh:
There are benefits. When you're just starting out, it is nice just to be able to deploy one thing and just ship it, especially back then I guess. These days it seems to be easier to spin up a really quick static site or something and push it to Netlify single ... It's basically like the Heroku experience for static web hosting, whereas back then ... I mean, the alternative was, what, build an HTML page that you manage yourself for a static site or use something like WordPress. Who wants to also deploy a WordPress site in addition to their Rails app?
Starr:
Yeah, that's a really good.
Josh:
Or whatever, so ... I mean, that's why I always opted to start with the in-app sales site and then as the needs became apparent, then move it if it became an issue, but that's where I come back to the sub-domain thing because that's more difficult. To me, that's where the difficulty is. It's like you don't want to have to migrate either from ... Yeah, you don't want to have to migrate either way. In our case I think we had to migrate ... We started out everything on WWW or whatever and then had to migrate our app users to a different sub-domain which was kind of a weird process as I recall.
Starr:
It was a huge pain the ass.
Josh:
Yeah, it was a pain.
Ben:
I agree that the sub-domain part is more important than the actual infrastructure part, whether it's an app or a separate aside or whatever, especially if your app is going to have URLs that your users are going to share. Like for example in Honeybadger you can share a public URL for your error if you want to share it with the world and get some feedback or whatever, and you don't want to have to migrate those URLs at some point in the future. That's just painful, right?
Josh:
Right, because if you end up with hundreds or thousands of those all over Stack Overflow or something, or Reddit or wherever, those are sticky. Yeah, they'll have redirects apply to them but you still have to maintain those redirects forever and-
Josh:
Yeah.
Ben:
This is why our Netlify site has a whole lot of redirects.
Josh:
We've got a lot of redirects in our ... yeah.
Starr:
Exactly. I think we still have some left over from our original ... like when we ported from WWW to app-
Josh:
We also have some left over from when we used WordPress because at one point we'd had ... I don't think for our sales site but for our blog, which is probably a related discussion, do you host your blog ... This is like an SEO argument usually, like hosting your blog on a sub-domain versus on your sales site. I think we started out, we made that mistake early on too and moved it to a sub-domain I think specifically so we could use WordPress for the blog or whatever, but then that came back to bite us a little bit.
Ben:
And then we moved it back.
Josh:
We ended up moving it back eventually.
Starr:
Oh, maybe I should step in and give everybody just a little bit of context around how we actually do things now.
Josh:
Do you to tell the story of our progression from start to finish?
Starr:
Gather 'round, children. Gather 'round the campfire.
Starr:
Our current setup, we've got a static site ... our sales site on WWW and that also hosts our blog, so if you want to go to our blog, it's www/blog, right? Our docs are currently on a separate domain. But if we had to do it again, maybe we would put them on the same domain with-
Josh:
I think I would.
Starr:
Yeah. With Hook Relay we're definitely putting the docs and the ... If we have a blog, we're putting the blog there and the main site all on the same domain, in the same repo, the same Middleman setup. In terms of the tech stack, we host all of our static sites on Netlify and we use Middleman to sort of generate them. If you're not familiar with that, Middleman is-
Ben:
And Jekyll.
Starr:
Oh, and Jekyll? We use that for the docs?
Josh:
We still use it for the docs, because we used to use Jekyll ... We used to use Jekyll for the blog as well at one point.
Starr:
Oh my gosh.
Josh:
We're standardizing on Middleman though, and I think if this work you're doing for Hook Relay goes well with the docs and everything, I might ... My goal is eventually to port our docs too, into our main repo, and then we'll just have one site again.
Starr:
Oh, that's good to know. I can keep that in mind when I sort of build that.
Josh:
Yeah, I'd love to do that.
Starr:
Yeah, so anyways, the new sort of approach that we want to take going forward with Hook Relay is we're using Middleman to do the static site generation. We're using it to do the static site, the docs and the blog, and that has a number of benefits as we've sort of, kind of discussed so far. But one other benefit that I want to mention is that by doing that, you can actually share CSS files, you can share your JavaScript and one thing that we discovered is that having ... If you have your blog and docs and static site hosted on different platforms and everything, it's a huge pain in the neck to make them all look similar and consistent. You end up having multiple versions of your style sheets you have to maintain. It's just a huge problem, and then you also have multiple ... It takes effort over time to maintain Middleman sites.
Starr:
It's not a huge amount, but maintaining three of them is more work than maintaining one of them.
Josh:
We had to upgrade Bootstrap because we use Bootstrap for a lot of things, so even though they're the same design, they're all separate ... I remember having to do multiple upgrades, or getting weird with sharing style sheets across domain. We definitely never did that, but if we did, it was a really bad idea.
Starr:
Yeah, so we're doing that. We've got Middleman set up with using Webpacker. About three or four times a year I remember how Webpack ... Not Webpacker, Webpack ... how Webpack works, so I recently got that all set up, and we're going to be using ... what is it? Tailwind CSS for this one. We kind of like that because it's this ... I don't know, it's a really nice sort of utility-based CSS framework that doesn't have a lot of built-in components but it's got a lot of utilities just to make writing CSS easy ... or writing code ... I don't know, do y'all want to describe why you like Tailwind?
Ben:
Well, I was playing around yesterday with the static site and I was trying to do some formatting stuff. What was really nice for me was I was in the HTML which was in this case pretty simple, because these are pretty boring pages. But I'm like, "I want this to have some more padding," so I just add a class, like PX2, and all of a sudden it has some padding and I don't have to go into the CSS file and say, "Oh, what's the class of this thing?" And, "Oh, do I have to worry about inheritance here because it's going to conflict with that or the other thing?" It's just like boom, that little change is done and I can move on.
Ben:
It's like, oh, well what if I want this section to have a different background color? Okay, well it's BG-gray-100. Okay, well that looks nice. I think I'll keep that. And then it's just ... move onto the next thing. To me it's very fast.
Josh:
You know what that reminds me of? It reminds me of ... I think it was Ryan Singer at Basecamp who ... Maybe a blog post or something or maybe it was a video I saw, but it was basically how he prototypes designs at Basecamp.
Josh:
Basically the thing was, basically you do your design in the HTML. Don't go to some wireframing tool or something. Do your wireframing in HTML, and the wild thing was he was just writing inline CSS using style attributes basically, just for speed. So, that reminds me of what you were saying. You can kind of do that but just do it all the time and it gives you the same benefit of basically designing in the same file as you go.
Ben:
Yeah.
Starr:
I just want to jump in and clarify, sort of the main philosophy of Tailwind in its approach is that instead of making some HTML and you say this div has a class of card and so then it ... you write some CSS somewhere else and it looks like a card. Instead of doing that, what you do is you don't have classes like card or whatever. Instead, you have classes like BG blue or P4 for padding four units, and you sort of use those in your HTML, and so basically by reading the HTML you know exactly sort of how it's being styled as opposed to having to go to a separate place and then look at the styles and then figure out if they inherit from anything or whatever. So, yeah. What were you going to say, Ben?
Ben:
Yeah, there's some other niceties in there, like you mentioned the P4, right? It's four units. I don't have to care whether it's four pixels or eight pixels or one rem or whatever. There's a set of predefined units that just ... they look nice, like they've been curated by someone who knows better than I do how things should look, and so then there's that. And then there's also the different colors. I mentioned the BG gray 100. Well the 100 is a lightness, right? It goes from 100 to 800 or maybe 900 but there's different levels of gray there that are coordinated. That's really nice too.
Josh:
Yeah, I like using 100, 200 versus for color variations than light, dark, lighter, lightest, because we have some of that going on for your utility classes.
Ben:
As I play with it, I've found, yes, there are some places where it gets repetitive, where you've got six or seven or eight different classes that are defining different aspects like the text color and the text size and et cetera, et cetera, and I do like how Tailwind also has this idea, I think they call it components, where you can pull out those classes and you use this keyword "apply" and basically you can say, "Replace all that with a custom class name like header or whatever," and then-
Josh:
Okay, so, yeah.
Ben:
And then in the CSS file you can say, "Okay, apply these seven or eight things and make that into header."
Josh:
Okay, because I was going to ask you, because Starr gave the example of the card component in Bootstrap and it's like, well yeah, it's nice when you're actually designing these things just to use the utility classes but it seems like if you're using cards all over the place ... We're back to just writing HTML across six different pages and when you want to change something, you have to go update every file, right?
Ben:
Yep, yep.
Josh:
That's what this solves basically?
Ben:
Yep, exactly. Yep.
Josh:
Okay.
Ben:
So that's really nice to work with.
Josh:
You can share it. Nice.
Starr:
It's kind of interesting to think that this approach has ... like Tailwind is a couple years old, right?
Josh:
Yeah, it's pretty new, yeah.
Starr:
I heard about it maybe a year or two ago and I think the reason that it's able to happen now is that we've got these more advanced build tool chain build systems like Webpack, because one thing that I learned sort of setting up Tailwind in this in our new sort of static site for Hook Relay is that if you just include all the Tailwind CSS, it's like two megabytes. Your CSS file is two megabytes, so then you have to have a tool that goes in and looks and sees which CSS classes are actually used by your HTML or your templates or whatever, and only include the CSS that is relevant to that and strip out everything else.
Josh:
That's PurgeCSS, right?
Starr:
It's PurgeCSS, yeah, and I originally ...
Starr:
I had set that up just as a separate tool or in the sort of Webpack sort of ... It's actually a post-CSS plugin which is like ... Anyway, it's in there, but then when I added Tailwind, it turns out Tailwind has its own ... It'll bring it to the party itself. You don't have to set it up yourself, so I removed the one where we manually added it and now it's like I'm using Tailwind's built in one. And the difference there is that Tailwind's will only ... It'll only strip out Tailwind stuff, because one thing I quickly found with sort of the general purpose PurgeCSS is that, okay, I added a bunch of ... I add a bunch of CSS for syntax highlighting and those syntax highlighting classes are never used in the HTML templates I write because that's all dynamically generated.
Starr:
And so then I have to go back and add sort of exceptions and rules and configuration to not strip those out, and so I was like, "Well, it's a decent compromise, is to just ... We'll just purge the Tailwind stuff," and then our own CSS that I manually import, I'm just going to assume that I actually want that imported and included.
Josh:
That makes sense.
Ben:
Yeah, sounds good.
Josh:
Yeah, I think you're right though. Tools like PurgeCSS are one reason you can do a lot more with CSS frameworks because you don't have to worry about the overhead of including it all because you know it's going to keep what your users use or whatever. So, I'm sure that Tailwind will eventually be 50 megabytes.
Starr:
I mean, probably.
Ben:
Josh, I wanted to get back to-
Josh:
I hope Adam listens to this by the way. He listens sometimes I think.
Ben:
I wanted to go back to a comment you made, Josh, and I have a question for you about it. So you were talking about how we split out the blog into a separate sub-domain because we wanted to use WordPress to host a blog and then we brought that back into our static site. So, there might be some people wondering, "Well, okay, how do you do this blog thing with a static site?" And, combining with Starr's comment, you might someday have a marketing person who wants to update the site and you don't want to be deploying it. So, how do we have our marketing person updating our static site so that he can post to the blog? You found the flaw. You found the critical flaw.
Josh:
We tried a few things first. First we tried just using GitHub because you can get pretty far with just using the GUI editor. You know, file editor and stuff on GitHub. You can teach most people how to create a file or et cetera. The thing that gets kind of tricky there is if you have a branching workflow or ... How are you actually submitting content? Because if you're auto-deploying your master branch, you don't want people just creating files at random. But that said, we've been using Netlify CMS which is a CMS on top of your static site that is deployed to Netlify and it's backed by your GitHub repository, so it doesn't have any kind of ... Basically it uses your Git repository as its database for your content.
Josh:
So, it's an editor, essentially, that gives you a little ... It gives you extra workflow so that you can create posts, you could submit ... There's a review process, so it has a branching workflow built in so that you ... Basically it opens up a pull request on GitHub when you create a blog post and then you can either approve it on Netlify in the CMS admin or you can just merge the PR on GitHub. I think it works both ways. So, it works okay. It seems like ... We've had a few ... We've struggled with it a little bit. I think it's still probably in development, is my guess, or hopefully anyway, because it needs some work.
Starr:
Okay, that's some shade there. "Still in development, or I hope it is."
Josh:
Well, I'm the one who has to drop everything and support this thing when it just stops working, which has happened a few times. I will say it hasn't happened lately, so I think ... Actually I don't know because I haven't ... Starr and Ben Findley are usually the ones that are using it these days, so you all maybe can fill me in on how it's working for you. I haven't heard anything, which I take to be good news, but I don't know.
Starr:
I don't know if Ben Findley uses it. I never use it.
Josh:
Is he using it?
Starr:
I never use it, and maybe it's changed but I'll tell you why. The reason why I haven't used it is because for images it just sort of adds this extra level of complexity. We have authors create articles for us and these articles are markdown files and whatever images they want to include in their article. So that's what I've got and then to get that into the Netlify CMS, at least last time I looked at it, which admittedly was maybe six months or a year ago, was really a pain in the neck. And not only ... It wasn't just a matter of, "Oh, I've got to pull this up and copy and paste it." It's like there was something about the images really wonky. I couldn't just give it my images. I had to go in and insert them in their WYSIWYG editor because it uploads them itself and then uses its own image paths.
Starr:
It was just such a pain, so for all the blog posts that we have commissioned and everything, I just manually do PRs for those or I manually just pull them in, and I've made my own tooling to make that a little bit easier.
Josh:
Yeah, to be honest I do the same thing and I'm guessing Ben does too, Ben Curtis, but I think that's also natural because we're the ones who decided to use a static site generator in the first place so that we could reap the benefits of doing stuff like that and writing scripts and using our own workflow or whatever.
Ben:
And not having to manage WordPress.
Josh:
Yeah, and not having to manage WordPress-
Starr:
Oh my God.
Josh:
... Which is basically like ... Netlify CMS seems to kind of give you ... I remember the media editor in WordPress still and always hating that thing. Why can't I just put a file on disk or something and then link to it? We prefer just to use the Git workflow that we're used to, but at the same time these tools like Netlify CMS are nice because you can have basically the best ... Well, you can have both worlds. I won't say the best of both worlds necessarily. I think there's a lot of promise in those kinds of tools. There are others out there. I don't know, off the top of my head I can't tell you which one is really nailing it.
Ben:
I think we should totally ask people to get back to us and let us know if there's something that we should use instead of Netlify CMS because I'm sure there's some other ones out there that are at least as good-
Josh:
Yeah, there are.
Ben:
... Maybe better, I would love to hear if there are better options out there.
Starr:
If we didn't have developers running the blog essentially, it would be not the best choice to have our blog ... It may have been worth going to an actual CMS as opposed to having everything Middleman, right?
Josh:
Yeah, no, I think if non-developers ... If you're non-technical and you want the benefits of a static site and a first-class CMS then probably you want to have a headless CMS static site developed, I hate to say. That's the more modern ... Like Gatsby JS for example is going ... That's an example of a headless CMS where basically it can generate a static site but it can generate it from any content source like WordPress, for example. So you could have everyone using WordPress still but you get the benefits of deploying a static site to wherever, S3 or Netlify or et cetera.
Starr:
That sounds like simultaneously both cool and hell.
Ben:
I think if I was-
Josh:
It doesn't have to be WordPress by the way. It could be Ghost or any number of things.
Ben:
Yeah, yeah. I think if I was non-technical and I wanted to have my site and blog separate from my app, I would go with Ghost or Squarespace and I don't think I would mess with-
Josh:
Just use something hosted still.
Ben:
Yeah, exactly.
Josh:
Old school. Yeah. Yeah, totally.
Ben:
And again, keep the app completely separate. Own the WWW and the blog and whatever else on that static CMS thingy, whatever you choose, and then have the app do its own thing on its own sub-domain.
Starr:
You know, I think we're discovering why so many commercial CMSs are consulting-ware.
Josh:
Yeah. Well yeah, and that is ... I was going to say, the whole headless CMS route, I think it really is the key is if you want the benefits of the static deployment, because, again, there are ... If you're anticipating being on the front page of Hacker News every day or something, or a few weeks out of the year, it would probably be better to host on a static site than hosting a WordPress installation or something. You still have to run PHP or whatever. I haven't hosted Ghost, but ...
Ben:
Yeah, just let somebody else host it.
Josh:
Let someone else host it.
Starr:
This is all really good points. Let's talk about hosting for a little while. One of the things in favor, I think, of not having all the stuff as a part of your main application is because the scaling stories for a static site are way different than for your application and, yeah, so having those two things coupled may not be the best solution and one thing you were saying, Josh, a little while ago was that ... You were talking about when we launched, and this is one thing that I always forget, right? I always forget things were different back then, and I've got a question for you all that will make you feel old but did S3 even let you have publicly accessible files when we launched like in ... What was it, was it 2011? 2012?
Josh:
I don't remember.
Ben:
Yeah.
Josh:
I mean, I remember the date. I don't remember if S3 ... your question, yeah.
Ben:
Yeah. I want to say no, it didn't exist at the time. I'm sure I'm going to be wrong when I say that, but I've got to look it up now that I'm curious, but yeah, I want to say that S3 static hosting was not a thing when we launched.
Starr:
I think for a while we would run a static site generator and then upload it to a publicly accessible ... We'd SFTP it to a public directory somewhere on a server that we owned. For sure we used S3 though for a while, and that worked. That was nice but also you had to sort of set it up yourself and it was kind of a pain in the neck. So now we are on Netlify which is sort of ... Netlify CMS is a little bit of a tangent from it. It's not really the main Netlify product. The main Netlify product, if you don't know about it, it essentially lets you ... It's like Heroku for static sites, right? You push your repo to GitHub and Netlify gets a web hook for it and builds you a static site and then publishes it for you.
Starr:
I kind of like Netlify. I think it's super convenient for standing up sites. It's super convenient ... I love the preview capabilities where you can set it up to build preview sites for all of your branches. That's just super handy, but I really haven't ... I know Josh, you've struggled with it a bit in certain aspects, so I may not have the most complete picture.
Josh:
No, I think overall it's still a positive. Yeah. Speaking of the whole preview thing, I remember back in the day working for a client that had this Rails app. It was basically a custom CMS. I forget the ... It was using one of the CMS gems that existed back then. You might remember some of them, Ben.
Ben:
I think I know the client you're talking about because I think I built that for them.
Josh:
Did you?
Ben:
Yeah, yeah.
Josh:
It was basically ... It had a preview deploy process but it deployed to a whole different server and so when you updated the content ... So you would make all your changes. It was actually kind of cool because you could edit all the things and basically live preview it because it's just a Rails app updating your server and then it had a deploy button in the CMS UI and when you clicked it, it would basically spawn and deploy to production.
Ben:
Yeah, that was-
Josh:
But the content editors are doing this, so-
Ben:
Yeah, that was a pretty wild ... Yeah, I built that for them. That was ... Wow.
Josh:
Maybe it was ahead of its time or something.
Ben:
You know where that inspiration came from though is Moveable Type.
Josh:
Was it?
Ben:
One of the granddaddies of CMSs built in Pearl and totally awesome but basically what it would do is, yeah, you could write a bunch of content and it would store that in in the database and then you'd push a button and it would deploy all that. It would render it all out to static HTML and then put that where it needed to be served. Super awesome, I loved it.
Josh:
Yeah, I used to use Moveable Type. Back in the day that was-
Starr:
Didn't Fog Creek have a product that was something like that too?
Ben:
Yeah they did. Yeah, good memory. I can't remember what it was named, but yep. It was like something city? I don't know. I'll have to look it up.
Josh:
Do either of you remember the ... I want to say it's Justin Searles who has a project that I saw recently that lets you build a static site using a static site generator in a Rails app. Does that ring any bells? I was trying to find it on ...
Ben:
It sounds vaguely familiar.
Josh:
I was trying to search for it and I can't remember what it was called if it exists, but then there's also another static site gem for Rails called High Voltage that thoughtbot created but that's different. That lets you do static pages in Rails.
Starr:
So I've got a question for you. What if the static site you generate is just all the files you need to have another Rails project that generates static sites? You'd have static-ception.
Josh:
Like a static site factory or something.
Starr:
That's our new product for exceptions on static sites, is static-ception. Pricing is very generous.
Ben:
Low traffic. So, the takeaway for today's conversation is host your main site on a separate sub-domain from your app. The end. I think that works. I mean, yeah-
Josh:
And host everything else, all the other content related to that app on the static site? That's the other thing?
Ben:
On the static site, yep. You know, the one thing that I will say, you mentioned this before, Josh, about it's nice when it's rendered from your app that you can do things like add a "you're logged in" header thing to the top banner even on the public site, and one of the things that also makes it easy is if you have documentation or you have API keys that you're displaying in your documentation, you can just put it right in there. I'm pretty sure this site does this, where they show you an example and there's your API key that you can use right there, and that is so nice for copy-pasting work.
Josh:
I really like that too.
Ben:
Which all developers do, right?
Josh:
Mm-hmm (affirmative). I've always wondered that.
Ben:
Yeah, that's one thing I miss about our doc site is we never took the time to ... Because you can work around it, right? You can do a cookie or something.
Josh:
Yeah, there are some hosted documentation services that provide that as a feature that you can insert user data, so there's got to be a way. I'm sure Starr can ... Starr probably has that on their branch.
Starr:
Oh yeah, totally, totally, guys. I've got the whole damn site done on a branch. I'm just spoon feeding it out, though, so I can, I don't know, go to the horse races all day.
Josh:
Well if you want to just deploy that thing that lets us put random sensitive user data into the docs at will, that'd be good.
Starr:
Yeah, I'll do that. I'm sure that there's no GDPR problems with that. Yeah, so, I don't know. I think maybe the reason I've had a good week is that ... I mean, let's be honest. Setting up a new static site generator is one of the most sort of pure, innocent activities that a programmer can do. There's a reason that people ... The programmers who want to make blogs spend six months setting up their static site generator and then they write one post about how they did it and then they never write another post. That's because you have all these sort of naïve dreams about how easy everything's going to be and how automated and wonderful it's going to be.
Starr:
You haven't had to come up against the reality of that as you actually try and do stuff with the tools. You get to goof around with the tool.
Josh:
Yeah, when it comes to blogging, as everything, the real challenge is with the writing, not the-
Starr:
Not the tool.
Josh:
... Thing you're using to generate the blog, which I think is why there's a lot of blogs that end up with just how we built this blog. I've definitely been guilty of that in the past. What was the Jekyll-based blog template that everyone used six, seven years ago?
Ben:
Something on Octopus.
Josh:
Octopress? Was that ...
Starr:
Oh yeah, Octopress or Octokit. Octopress, yeah, that's right.
Ben:
It was Octopress?
Josh:
Remember? Because it had a default theme and literally every developer blog on the planet.
Ben:
Yes.
Josh:
It was a little bit like dev two before dev came on the scene because everybody had their own blogs which were where they posted their learning experience and stuff, but no one changed the theme, so you could always tell who's writing a new developer blog because it was just an Octopress setup or whatever.
Starr:
Yeah, Octopress was very nice.
Josh:
And I used it. Yeah, it was. It was nice.
Starr:
I was impressed by it.
Ben:
It was great.
Starr:
I met the creator of that at a conference one time and he was super nice. He was a super nice guy.
Josh:
Yeah, it was cool. Now I just use Vanilla Jekyll migrated back.
Starr:
Well, this has been a great conversation. Do you guys have anything else to add on this topic?
Ben:
No.
Starr:
All right then, I guess we will sign off. Thank y'all for listening to us rant and rave about static sites and sales sites. It's so funny because we're FounderQuest and we're talking about business and all this stuff, and it's like we're going to talk about this business thing and we talk about that for five minutes and then we just sag into the technical aspects of it and talk about those for an hour, which is fun. It's good. So, yeah, this has been FounderQuest. Review us, please, and if you want to write for the Honey Badger blog, we still do that. We have people write tutorials in Ruby and Elixir and whatever, so just go to HoneyBadger.io/blog because it's on the same ... It's on our main domain, right? It's on www.HoneyBadger.io/blog.
Ben:
So easy.
Starr:
So easy, and yeah, look for the "write for us" link on the top header and that's it. So, I will talk to you guys next week I guess. Have a good one.