Introduction
Josh: Welcome to another episode of Static Bits, a podcast that focuses on building web sites with the JAMstack and generally learning web development. In this episode we have two special guests from Snipcart which is a drop-in shopping cart solution for static web sites. We talk about building e-commerce on a static site, selling the JAMstack to clients, and contributing to the JAMstack in general. Check this one out, guys, I know you'll love it.
Josh: How are you guys doing?
Franck: Yeah doing great.
Charles: Good too, yourself?
Josh: Very good. And if you guys can introduce yourself...
Franck: Yeah. So I'm Franck. I live in Quebec City, Canada. I'm a good friend of Charles, who's also on the podcast right now. And I've been working with Snipcart for something like five years. I was the first employee and became partner. I’m doing mostly content marketing, SEO, training new people, analytics on the product, trying to connect with developers... that kind of stuff.
Charles:And I'm Charles, one of the co-founders of Snipcart. So I've been with Snipcart since the beginning and I mostly write code.
Josh: Awesome. Well welcome on the show. This is this is such a pleasure!
Franck: Yeah, it's a pleasure to be here. Thanks for having us.
Josh: I kind of say this every time but I'm like besides myself with the way this podcast is going and it's totally organic. Like I had never heard of you guys until I think the second episode. I was talking to Leon Stafford and he said something about, you know, Snipcart and I'm like, "What is this?" And then two episodes later, here we are.
Franck: That's awesome. I mean you had some great guests who are all representing cool tools, you know, in the ecosystem. So it's an honor to be here, and it's cool to connect with someone who's making his own effort to contribute to the JAMstack and the static site generator space.
Josh: Right. Yeah, I think there is a lot of value in my kind of super newbie-ness... I'm just not afraid to say "I don't know that, what are you talking about?”
Franck: I think actually that's your USP. If I put on my annoying "marketing guy hat", it’s like your unique selling point with that podcast.
Josh: There you go. I'm gonna need to learn more and more about all this marketing stuff because that's technically my job now at this company. My day job that is.
Snipcart Origins
Josh: So anyway I guess we'll jump right into the questions here. I prepared a little bit for you guys. So what is Snipcart?
Franck: Charles you gonna do the classic one here?
Charles: Yeah yeah I will. Basically, Snipcart is an e-commerce solution for developers. So you can very easily add an e-commerce solution to any website, just with some HTML markup and JavaScript inclusion. So it's very easy to work with the static sites, especially.
Franck: Yes, it's very frontend centric. We rely mostly on HTML and JavaScript. The funny thing about Snipcart is that it has no JAMstack origins. Like we stumbled into the whole static site and JAMstack movement organically I'd like to say. "By accident" is the right way to say it.
Charles: The first two years of Snipcart we never really heard about JAMstack or anything related to static site generators. We knew that they existed but it wasn't, like, a thing, like it is today.
Josh: Right. What was the first site you guys supported... was it like WordPress at first or something?
Franck: That's a great story. I don't remember the exact stack but here’s what happened. So Snipcart was launched inside a web development agency in Quebec City called Spektrum. These guys have been running for like 10 years now. And there was this old school client who supported Spektrum from the beginning and he wanted to have us add e-commerce to his site. But it was a dusty code base and Charles didn't want to get his hands dirty. So he had to try to figure out a workaround and some kind of fix for that. That's the shaky origin story of Snipcart!
Charles: To give you an idea, it was classic ASP under the hood. So you don't want to touch that too much.
Josh: Oh God yeah. I just don't even really know what that is. Is that Microsoft?
Charles: Yeah. It's like an old Microsoft thing. It has nothing to do with what Microsoft is doing nowadays. It's like active server pages and it was not something very fun to work with. But at the time it was quite popular so that's why we wrote the initial website with that stack.
Josh: Right. Did you guys have anything else to add to the origin story at all?
Franck: We can expend just a little. Yeah. I mean that was 2013-ish. Maybe a little before Charles?
Charles: Yeah actually we launched our first version on August 2013.
Franck: So we didn't follow the traditional binary startup way you know, you either bootstrap or you get VC funding. We didn't do either. We really bootstrapped a product inside a web development agency that kind of acted as our first financier. That provided time, money and resources for Charles mostly to code on this project and encouraged him to basically quit his job, and stop being a developer at Spektrum but start being a founder and lead developer at Snipcart. So that's a cool hybrid part that I like to push a little bit...to realize there are more options to get your business off the ground.
Josh: Yeah I love that. So basically... alternatively they could have just kind of said, "No this is our software you're developing it on our dime." Right?
Charles: Yeah, they could have. But this was one of the values that the agency likes to promote: intrapreneurship.
Snipcart & Static Sites
Josh: So you didn't start with static sites. Was it hard to adapt Snipcart to a static site or...?
Franck: No not at all because... (Charles is going to correct me if I just say stupid development things because I'm not a developer per se. I know my way around some basic stuff). But yeah, that disclaimer being said: Snipcart from the get-go was hooked to the static part of any website. So regardless of your database, server, regardless of anything behind these static files, we didn't care. We could just plug into your HTML, add a JavaScript snippet, and then you were good to go.
Josh: Wow. So you didn’t even know you were developing for the JAMstack. I mean... that term didn't exist then.
Charles: No it didn't.
Franck: I remember when it didn't exist at all. It’s funny because the guys at Netlify, the founders Mathias and Chris... I remember having a call or a few emails with them saying that they were talking with Tom Preston-Werner from GitHub and Jekyll, and they were just annoyed with the whole static vocabulary. They came up with the JAMstack term and coined it. At that time I was like, "Hey I'm not sure but, you know, why not give it a go and try to do some content around that and push it and see if it sticks." I didn't know it would stick that well.
Josh: Yeah well JAM is pretty sticky stuff. So how does Snipcart solve the problem of having a shopping cart on a static site?
Charles: Actually Snipcart takes care of everything that you’d need a server for. In the JAMstack, it is the API part. We take care of ending the checkout process, keeping the cart in memory, we allow merchants to retarget their abandoned carts. Those are all things that you could not necessarily do only with a static site generator because you’d need a server... something to process that data.
Josh: I think it's just so interesting that for you guys it was almost trivial to enter the JAMstack space because you were already there.
Charles: Yes. On a static site, it's probably the most simple way to integrate Snipcart, because you just have some HTML and that's it.
Franck: Yeah the product definition is basically HTML markup. It's data attributes that say what's the price, the name of the item, where it’s at, what's the image and description. Then we crawl that and add that to your JavaScript shopping cart. The one we handle and make pop on top of your website.
Josh: Oh wow. That's so cool. So it's just like in a data tag or something like that?
Franck: Yeah.
Josh: I can't wait to mess with it. I plan on trying to do some sort of a little site for myself and just put a shopping cart in there. I don't know what I'm gonna sell yet. I'm just so excited to learn all this stuff and at the same time I'm not in a hurry, you know?
Franck: Well maybe you can sell podcasts ads.
Josh: There you go.
Discussing Jamstack Tools
Josh: I do have a loose plan of rebuilding the entire Static Bits site myself.
Franck: And what kind of JAM would you pick?
Josh: Well right now I'm still just working with Jekyll for the most part.
Franck: Cool.
Josh: And I think it's enough. I still have a lot to learn there. I think a lot of it. In the TakeShape episode they were talking about how, for the most part, if I can understand how to write my own Jekyll templates, I should be able to go into GraphQL without much difficulty.
Franck: The fun thing about Jekyll too is that it's the older brother, right? I mean it's got this more active community because it's been around longer. So all of the resources and the theming and the ecosystem around it. You've got Jekyll-specific CMSs that are very neat like CloudCannon. I think it's a super nice entry point into the static site generator space.
Josh: Yeah.
Charles: This is the first one that we tried at Snipcart, too.
Franck: No actually Chuck it was, remember, Middleman.
Charles: Yeah you're right.
Franck: We were just trying stuff out on the blog. To see if some would stick in terms of marketing. Charles was like, "Oh yeah I've seen this Middleman thing on XYZ forum." I was like, "Okay let's do it. We're in experimentation phase anyway.” And this post ended up ranking high on Google and driving traffic and even sign-ups. We were like, "Alright there's an appeal to this kind of tooling here, it’s evolving." That was 2015 if I'm not mistaken.
Josh: That seems kind of like the turning point, 2015—2016. It started getting a lot more powerful... or not powerful but popular AND powerful.
Franck: Yeah. And that's around the time BitBallon became Netlify, too, if I'm not mistaken. Or was it 2014? I.
Josh: I think you're right. It's close.
Franck: Yeah, anyway people can go listen to the Phil Hawksworth episode.
Josh: Yeah. Phil might have said that that episode.
Franck: And they can get, you know, his smooth British voice and accent instead of our violent French Canadian one.
Josh: Yeah it was a pleasure to talk to him. You know it's like... it's great. But that's how it is with podcasting because I'm talking to people from around the world.
Franck: And that's one of the beautiful things about development in general. There's just like... this cross-culture, cross-boundaries, cross-nationalities.
Franck: Actually we just released a case study about a guy from Paris that did Maison Futari, which is kind of an e-commerce shop built in Vue with Snipcart but he's selling developer t-shirts with the word developer in a whole bunch of languages. Just this idea of connecting devs all around the world and it's super dope.
Challenges of Building a Jamstack E-Commerce Solution
Josh: What was the main hurdle you overcame with developing Snipcart?
Charles: When we add buttons to the website, those are just HTML attributes. Anyone could alter those attributes with developer tools. So we needed to find a way to somehow validate the integrity of the order before processing the payment. So, yeah we ended up with a solution: when you create a product... when you and your “buy button” on your website, you have to specify the item URL with a specific attribute. And our servers would crawl back this URL and make sure that all the information about the product is all right so it has not been altered by someone with knowledge about how Chrome works.
Josh: Was there any other more minor hurdles other than that?
Franck: I guess, scale-wise we had some challenges.
Charles: Snipcart grew quite a bit and it's the largest application that I've been working on. We ended up having some issues with database scaling that I never really had to deal with before because I was mostly working on client projects at the agency Spektrum. Those were more small-scale applications than Snipcart. But, I mean, that's fun stuff to learn and to work with!
Franck: Yeah. And the good news is that if you're building with the JAMstack and some frontend centric project, you don't have to do that. We'll do it for you.
Jamstack vs. Full Stack, Frontend, Backend
Josh: That's kind of the beauty of it. I feel — I think I said it on another episode — but I feel like I almost don't even have to worry about any server stuff at least for quite a little while. You know, as far as backend goes.
Franck: Yeah, well it depends. Right? Because if you get into the whole serverless approach and stack a few functions then, depending on the tooling you're using there...there might be some issues. But generally speaking, I agree.
Josh: Right. I guess that leads to a side question. So there's the term "frontend," "backend" and then "full stack." Do you guys think that the JAMstack is like the antithesis of "full stack"? Like is it really drawing a line in the sand between the front and backend?
Franck: I'm going to try and answer and if I do massacre the paradigm or philosophy too much, Charles can interrupt me at any time. I think in a way it does draw a line in the sand. But the beauty of it is that... that line isn't hermetic or closed, meaning that you can do all of that... you generate all of your HTML, CSS, and JavaScript in the front and have your sweet hermetic JAMstack. But then if you decide that you want to play with data and play with servers or whatever, there's this door that's opening wider and wider, regarding serverless computing and these kinds of functions. There are all sorts of backend services, functions as a service platforms. So I'd say it depends. It is drawing a line but not that closed of a line. Am I making sense?
Josh: It's not a border wall.
Franck: If you're going to get political, sure!
Josh: Ah man, anyway. What do you think about that, Charles?
Charles: Yeah, I think Franck mostly had it right. I think that nowadays, no matter what you do on the web, the backend and frontend are getting closer and closer. When you work on an application, most of the time you're going to use a single page application framework such as React or Vue. And I think that it requires more development skills than it took a couple of years ago when you were working as a frontend developer on the web. I think that all those terms like "frontend," "backend," "full-stack" are coming together, especially in web development.
Jamstack, JavaScript Bloat & TypeScript
Josh: Yeah I guess it's just a heavy dose of "it depends," you know? It opens another question: do you think that the JAMstack leads to a lot of JavaScript bloat? Because this is what's kind of powering it.
Charles: Yeah I think it can. It can lead to a lot of JavaScript, of course, but I think that it's where most of the web development is going anyway. So I don't think it's a bad thing.
Franck: JavaScript is so open and so large as a language in itself and I feel like Javascript done right... it's all right if there's heaps and loads of JavaScript on your site. I know we have started experimenting with TypeScript which is way more secure, more rigid... like there's this uniformity and its scales better and there's less errors and whatnot. But yeah I think if you don't tread carefully you can have JS bloat in your app.
Charles: But I think that, in general, JavaScript development has improved a lot since the last couple of years. I remember the days where you included jQuery and added a function that JS would find in the website and it was doing all of the work, all the animation and everything. We've come a long way from that stage.
Josh: Yeah. So you're coding in TypeScript but it compiles into JavaScript in the end anyway. Right?
Charles: Yeah. TypeScript is a superset of JavaScript. So basically all it does is add in IDE tools for your VS code and the likes. So you get IntelliSense and all those cool things about type checking. You can write plain JavaScript even if you are working with TypeScript. But when you're a team working on a project you can use TypeScript to ensure that everything is written the same way and the typing and everything helps a lot with maintaining a large code base.
Josh: Yeah, I guess one of the thoughts behind my question is... it just seems like another piece of tooling that I don't need.
Franck: I think I heard you mention Wes Bos a few times on the podcast so I'm guessing you're a listener of Syntax, the show they're doing.
Josh: Yeah, I need to listen a little more. I haven't listened lately.
Franck: So Scott and Wes, they tackle that question very thoroughly in one episode. And the question is like “should I learn TypeScript?” And there's a lot of, "of course it depends" and nuance in their answer. Basically I think that if you're starting out with JavaScript, you shouldn't bother with TypeScript right now. But the situation that Charles mentioned paints a picture of where it comes into play. When you've got a bigger team and a larger code base and there needs to be uniformity and scalability and easy tracking of what went wrong, now it might have value.
Franck: But like you said there's—JavaScript bloat is one thing—but you mentioned on your show with Phil that there's tooling bloat also. There's just so, so many tools. And just trying to find, like, trying to find out how everything works is... well, can be intimidating in itself. Which kind of leads me to one of the coolest discussions I had in 2018 was with Ohad, one of the first investors in Netlify. Right now he's starting something called Stackbit and the whole idea is to simplify getting up and running with the JAMstack. To abstract all of that tooling stuff, and just give you some kind of a more beginner friendly UI and setup where you can say, "All right, I'm gonna go with this as a headless CMS, I'm going to go with the static site generator and hosting/deployment is going to be on Netlify." And then they kind of bundle that initial setup for you. So you can focus on customizing and building that project in itself. This is something we should be on the lookout for in 2019. It's going to help bring onboard new developers to the JAMstack who are a bit intimidated, and rightfully so, If I may.
E-Commerce Limitations on Static Sites
Josh: Yeah. I guess we could move on to the next question here. What is and/or what are the limitations of e-commerce on a static site?
Franck: Mm-hmm. Well, right off the bat there's the popular disclaimer that says limitations on static sites are disappearing by the minute because of the JAMstack. So the JAMstack comes in with all of these different APIs tools you can use. There's us for e-commerce, but there's a whole bunch of tools for search and what not. Any old school—not old school—but more traditional argument that went, "Well you can’t do dynamic stuff like comments, forms, reviews, user authentication, CMS..." This is all becoming false. You can do all of that right now because of the JAMstack tooling, not the static site in itself. If we were to go further in the question, the actual limits of e-commerce on a static site?
There's this: if you have a site with a very high number of pages, lots of data... the whole static build process can become huge and long. So building a huge e-commerce on a static basis might become problematic. But then again there's nuance like always. Gatsby made an announcement that said they were working on incremental builds for static sites so that might fix the problem.
Josh: Wow that's cool.
Charles: This is very exciting.
Franck: Yeah. These guys are full speed, one gear, go. Since they became a company. It's beautiful to see that happen. I remember when Gab, one of the engineers on our team, was helping us out with some blog content and I was like, "Yeah there's this guy, Kyle Matthews, that started this cool open source project," and he was like, "Yeah Gatsby I heard about it let's try it!" And it was just an open source repo on GitHub, basically. And that was it. There was not the whole organization and community and company around. And it's awesome to see businesses like that thrive in the JAMstack era.
Josh: Oh yeah. That actually is something I am a little intimidated by, Gatsby.
Franck: It's funny. Two weeks ago I tried installing Gatsby on my machine. It was a new reality check. I mean they've got awesome tutorials. Don't get me wrong. Their content team, in terms of documentation and recipes and tutorials... they're hand-holding you, a lot. But, even then, I had some NPM permissions issues and I had to go dig somewhere else for it, and I was swearing on my couch and my mom was like—I was visiting my mom—"Why are you working during the weekend?" I was like, "I'm not working... I'm working on a fun project for myself." She said, "It doesn't look like you're having fun at all!" I ended up putting this on pause and getting some help from the devs here at Spektrum and Snipcart.
Charles: I think that tools like Gatsby and Nuxt—it's like the equivalent but in Vue—are like that next step. Yeah... Gridsome, too. It's like the next step in terms of static site generators because you get all the benefits of having your websites statically generated so that hosting and SEO things work great. But you also have the feeling of having a single page application so the navigation for the end user is much more clean and everything works great and it's very nice when you need to add more custom features to your website. You have access to the whole React framework or Vue or whatever tool you are using but it really gives you much more power than the more simple static site generators like Jekyll or Middleman.
Josh: It almost makes me wonder if maybe in the next 5 years Jekyll will lose its popularity. I think it might be one of the more popular ones, but it might lose that, too.
Charles: Yeah, but Jekyll has its own purpose. If you need to have a blog or a static documentation, you might not need to go with Gatsby. I think that Jekyll will still do the job very well for a lot of years. But when you have to build something that feels more like an application but you still want to make something statically generated, I think the more advanced tools can become handy.
Franck: Yeah I'm on staticgen.com right now and Jekyll is still way first. That being said, some other cool projects have caught up.
Josh: The thing I really like about Jekyll is it's very un-intimidating for me because all I need is an HTML, CSS and maybe a JavaScript file and then I get a GitHub repo. And nothing else. I think that's important for my feedback loop of learning because I can just do it all locally and I still could just be using it like a file and then looking at it in the browser. A little bit of tooling is really cool. Just Jekyll... even though it's very dependency heavy, I feel like I can really understand what's going on, for the most part.
Franck: I guess you're not alone. If I look at not only the GitHub stars and downloads, but just in our own analytics. We haven't counted them recently but it's over two hundred tutorials on the Snipcart blog, mostly frontend-centric and JAMstack-ish. But if I look at the analytics, we've got a post on Jekyll e-commerce and it's driving heaps of traffic ever since we published it in 2015 or 2016. And we refactored that post a few times. It's driving conversions and stuff. So yeah we're seeing it also in our own ecosystem of content.
Josh: That's awesome. It's great to know.
Franck: Maybe we can expand a bit more on the e-commerce part for static sites. Before you use the dynamic argument and say, "well you cannot do e-commerce on a static site because there's lots of dynamic stuff you have to do like checkout and transactions and maybe even login and authentication.” Now, the cool thing is that you can do some of these yourself (maybe even all of them), but it would require lots of serverless functions. And I'm feeling like it might just become a whole dynamic app in itself, which could move you away from the simplicity of the static site.
So, it's always this balance of... should I be offloading most of that logic to an external API, like Snipcart and many others, or do I want to tackle all of this myself? That's an important question to ask yourself. But with the JAMstack it becomes not a sign of laziness to use an external AP, but a sign that you're able to bundle together the right tools. That bundling skill becomes valuable and respected in the community so you can focus on the stuff you want to focus on and offload the rest of the logic to other services. This is a very nice and modular approach and we've been preaching this for years now.
Charles: I think one of the core principles of the JAMstack is about composition. You have to pick your APIs and tools and you compose your application using all these tools.
Franck: Yeah I've gotten to saying, "The art of tying it all together" to sound fancy. But that feeds back into the Stackbit project where it becomes hard to pick the right tools because you've got the JavaScript, APIs and Markup. So how am I generating my site? Which content management system am I using? For these logins and comments and forms, what am I using? There are so many options. This is why it becomes really important to educate others and share your experience as a developer as much as you can, whether it's by guest posting, hopping on podcasts, starting a podcast like you did, or just writing about your experience in general and sharing. I think that's really key. You can do that with low friction, like participating in some cool slack communities, for instance.
Josh: For sure. It’s interesting when you're talking about, I was thinking about... well, for one, just cost. It's probably a lot cheaper sometimes to use an external API then develop it yourself. You have to really look at if it's worth putting the money into it or not.
Franck: Yeah definitely.
Josh: And then putting the money into maintaining it. So it's like, we’ll just let those guys do that. It's almost like building a house. You don't really see a construction company that does framing through, like, finished work. I mean they're out there but more and more there's just different contractors that do all the different things.
Franck: Yeah. And you've got the equivalent of a fully hosted WordPress instance also that comes in the pre-built house. I don’t want to go too analogy-ish.
Josh: Right. We're going to wax philosophical here.
Franck: Yeah, just to tie it up for the e-commerce part. Where we positioned ourself is: Okay, listen, you've got all of that logic and complex dynamic features in e-commerce. You can go Dunning-Kruger effect on that like, "Well it's simple... you just accept payments online" but when you start digging into it you realize, "Oh jeez there's this login and address and refunds and discounts and..." It's an endless well of features to handle. So we come in and we're handling that for you. Like we made it our day job to make a product that handles that for you. Now, you can use us for that but it doesn't mean you have to use a black box full on CMS that does everything—you just punch in your product and you point and click.
With JAMstack e-commerce you can do your own site and your own web app yourself. Then you offload that complex logic of e-commerce but you don't offload the theming and the styling and the performance that you want to work on, on your own site. So that really always was our positioning and I don't see it changing for a few years.
Josh: Yeah. If anything, it's just going to get more popular.
Josh: Anyway did you guys have anything else to add to the e-commerce part?
Franck: Yeah, that covers it. I don't want to be preaching too much for our own thing.
Josh: Yeah I know... I don't really have to say this but this podcast is not an ad, you know? I'm not getting paid by you guys or by anybody.
Franck: No, no one's getting paid here.
Josh: Right. I think Phil was actually able to bill his hours on my podcast.
Franck: Well I'll have to reach out to him and so he can explain his tricks.
Josh: But anyway, you know how people are, there are trolls on the Internet. Obviously... right? But this is not just one giant ad for.. well, I guess it is a giant ad for the JAMstack in general, but not for Snipcart.
Franck: Well, if you were to think this is an ad for Snipcart, just consider our track record. We've been putting out free tutorials, editorial pieces, GitHub repos, live demos... we've been putting out free stuff like this for years. Some of it talks about Snipcart. A lot of it doesn't even talk about Snipcart. For instance, how to build a Vue.js blog. This education of our users has always been a core part of our values, and of course it's marketing too, it's part of the whole thing.
Franck: But there's actual, factual value in you having that free stuff and that free content. So it's more than just pushing the product. It's pushing the paradigm that the product is part of, you know?
Selling the Jamstack to Non-Technical Clients
Josh: So I guess moving on here, next question. What are some ways to sell the JAMstack to non-technical clients?
Franck: Yeah, that's a good question. We struggle with that a bit. Charles you want to go ahead?
Charles: Yeah we could say that it's not really our problem since we are a service provider, but I think that, like Franck was talking about earlier, educating users about all those things is very important and for agencies and freelancers without...
Franck: Without client money, basically.
Charles: Yeah, I think that by educating our own users, agencies, and freelancers, this is how we're gonna end up selling the JAMstack to non-technical people.
Franck: Yeah, sure. It's more than just giving them the tools. It's also giving them the rhetorical arguments and the language tooling around it. And that's super important because like Charlie was saying, if you don't have client money as an agency or a freelancer, you don't eat. So if your clients aren't in and you're pushing the JAMstack, well the JAMstack is out and that's it. I mean there were a lot of instances where people were reaching out on Twitter, reaching out on Intercom, and they were saying, "Listen, I love this idea of dropping an e-commerce directly on my Jekyll site, for instance, but I don't know how to pitch it. I don't know how to pitch your model. I don't know how to convince my client to switch away from something like WordPress which we've been hearing about for years." So in that regard, as a developer you like the tooling, you understand the tooling, you know that there's more speed, it's a better user experience and whatnot, but this doesn't resonate necessarily with the client. The people that are paying you money to do that.
You need to turn these technical features into business benefits. You need to talk their lingo. Like we were saying, a static site is faster. So it's got a better UX... content appears almost instantly. And that kind of speed is now rewarded by Google, immensely. So you might have better Google rankings. And if you do that, well there's more traffic and more money in the bank because you know that you can convert that traffic into clients. So these kinds of trains of thoughts and equations that go from something technical to something business and tangible, that's very important.
Josh: Just the money thing is where is you got to speak the lingo and I mean, the world doesn't run on happiness, unfortunately. So you know we all need to eat and we all need to pay for it. And for a client, if it is cheaper, in the long run, then it just makes sense and I guess it's just the developers job and/or the salesman's job at that point to explain how it's cheaper, right? Or how it makes you more money...
Franck: Exactly. Sometimes you're going to have the history of the client playing in your favor. So clients have been around who have seen XYZ version of WordPress attacked with vulnerabilities and, I don't know which bugs... whatever, they know that they've gotta turn around and ask a developer to patch things up and “Oh there's this... I cannot upgrade because it's messing up my theme and this plugin and whatever…” So, maybe some of your clients have already lived through some of the pains of the traditional approach.
Josh: Or Gutenberg.
Franck: Maybe you can just go, "You know what, with that static approach, you're still gonna be able to manage your content with that app. It's pretty neat. Looks like WordPress, you're not gonna be at a loss but the site in itself would be way simpler, way lighter, and I don't need to handle a bunch of different plugins and databases, so this reduces the number of attack vectors. So it's gonna be more secure, more reliable, and that means more peace of mind for you and less unpredicted expenses and late-night phone calls where you're panicking because your site is down or being hacked or I don't know what." There's all these business and emotional triggers that you can pull. They're gonna convince the client to say, "okay, you know, let's try that JAMstack of yours."
Josh: How much say does a developer have over it? Like a lot of times, in my experience, when I worked for Linda.com, I started in shipping there but then I ended up working as one of the runners in hospitality. So I was like everywhere and I would go down and kind of take care of developers. I would go shopping for them and stuff. I ended up making friends with them and that's kind of the genesis of my interest in web development. There was this guy named David Higby that was the lead developer there and he showed me Chrome dev tools and that I could go change the wording on a website and stuff. And that just was that little bit of a seed that then took root about a year ago. But it felt like the developers were kind of... they literally were, actually, they were in a separate building, in a separate city, sequestered away on their own, you know?
But I guess the question I'm trying to fish for is does it seem like that's changing more? Like developers have more of a say?
Franck: Oh yeah, definitely. There is this old blog post. A woman that wrote this really cool piece, The Developer Renaissance.
Josh: Oh wow.
Franck: It's great, I'll send it to you. This is something we've been seeing, not only as a developer-first business, but as the mother agency, Spektrum, behind it. Business-wise, if you want to stay competitive, if you want to please your customers, you got to embrace technology. There's no two ways around it. Marc Andreessen said it, software is eating the world and there's nothing you can do about it. You got to get with the flow, at one point. That being said, the importance of providing experiences and products and services that are catering to the Internet, the mobile era, the smartphone era...
This is already becoming evidence for business people. Right? But smart business people will recognize that they do not necessarily have the skills to create such experiences. So very very smart business people will always surround themselves with people who are either smarter than them or very very good at stuff they're not. And in that sense if you mix the whole macro-economy of business moving towards the web and technology and better experiences, digitally speaking, you mix that with people like developers in businesses, they're getting way more share of voice and way more recognition. And when they speak up, people tend to listen more. Like the days of the old geek in his basement coding in I don't know what dead language... these are gone. Right? There's actually market and human value to technology. There's whole sorts of very helpful apps for mental health, for social accountability, for activism... there's not just businesses. As a species, we're doing digital stuff way more. So who can enable these experiences is developers. There's no two ways around it.
Josh: Right.
Franck: OK. There might be a shift, at some point, where lots of tools are making it easy for dumb people like me who don't know how to code to create digital experiences, sure. But at some point if you want a real edge and you want something custom and that's tailored to your audience, in terms of building an app, you're going to have to work with developers. So, yeah I think that these stereotypes or lack of empathy and listening towards developers, they might be around in some places. But if you're inside good, modern businesses with smart people in it, it's definitely not going to be the case.
Josh: Yeah, for sure. That was a great answer. I'm glad I was able to fish for that.
Franck: Yeah I got cosmic.
Josh: I liked it. I really want to check out that "Developer Renaissance" article.
Franck: Yeah sure. The last little thing I had is... people in general like to learn visually and see things for themselves. This has more impact psychologically speaking. So when you're trying to sell the JAMstack (to get back to that point just a little), you can just show clients. If you just use PageSpeed Insights, maybe if you've built some mockups of a more traditional site and the equivalent in JAMstack or just a site that you know is running JAMstack versus a similar site that's not...and you put them in PageSpeed Insights and you compare speed and you're like, "Look at this. This is horrible in terms of performance. And this is awesome." This is one. And just, you know, name-drop... name-drop all of these big companies that have started using the JAMstack for XYZ project. I know MailChimp has been running a Middleman and I know Red Bull has some projects on the JAMstack. Yeah I'd have to dig more but there are heaps of examples.
Josh: Yeah, I mean even just on my last episode the JFK [airport].
Franck: Oh yeah, with the TakeShape guys? With Mark and...oh, that was awesome.
Josh: Oh it's so insane. It blew my mind.
Franck: Yeah I didn't even know that. Charles if you haven't listened to this one... it's that JFK airport, they have all of these screens that are showing data that's relevant to the passengers and stuff. And this is powered by the JAMstack behind it, basically.
Charles: That's crazy. I actually listened to the podcast, too, with Mark from TakeShape. I listened to it a couple of days after trying the tool for the first time. I was very glad to see that they were doing great and having such clients.
Franck: Yeah, we've published a post with TakeShape, recently and... it's a cool little demo, an online gratitude journal where you can punch in what you're grateful for and then we receive that data in the backend with TakeShape and then we can publish it or edit it and then it shows in the static fronted. That's cool.
Josh: Yeah, I'm very excited to check out TakeShape but it's still... I feel like I still have so much to learn with Jekyll.
Franck: Yeah, one thing at a time. I think Phil said that.
Static Site Generators Pros, Cons, Preferences
Josh: Exactly. So moving on here. What are your thoughts on static site generators in general and the benefits and limitations? It's almost a redundant question, so I might add: What are your guys' preferences for different use-cases?
Charles: Yeah I think my favorite static site generator, the one that I will use to build something would be Gridsome at the moment, since it's based on Vue and I'm a big fan of Vue.js in general. It’s very fun to use and it has all those features about GraphQL. It really makes it easy to build a very live application with static site rendering. But that will be for a use case where I have to build more of an application - not only like a blog. If I had to pick a more traditional static site generator to build my blog or something, I think that I'd go with that Middleman because this is the one that I’ve used the most. It supports things like multi-language, which we have to deal with a lot since we are based in Quebec and all our things must be in English and French.
Franck: So, Charles is going with his first love for Valentine's Day. Because we are recording this on Valentine's Day, people.
Josh: Yeah it is Valentine's day.
Franck: That's dedication to the JAMstack. Our girlfriends are not happy about this at all.
Josh: Yep yep. But that is some dedication, for sure.
Franck: Of course I'm not using most of these tools directly, so I don’t want to bullshit anyone and say, like, "oh yeah, this is the best one." But the kind of tools I'm using directly will be headless CMSs, right? Because I'm more of a content guy. So TakeShape has a neat UI. I enjoyed my experience with the CMS! But I have to say that in terms of who's making noise right now? Sanity...the guys at Sanity are just like... they're crazy good. And I was talking to Knut from Sanity, and he knows his stuff. Like he just pitched me a whole where and how Sanity shines in that ecosystem and for developers who want to really push things further headless CMS-wise, I think that one is definitely worth a mention.
Charles: Yeah and actually we're working on a new version of the cart and we will be rebuilding our documentation and we plan on using Sanity as a headless CMS. So people at marketing will be able to tweak the wording and all of those things in the documentation as well without having to Git push.
Franck: Yeah, all the typos that Chuck does when he writes the documentation.
Josh: So back to the questions here. What are some ways to contribute to the JAMstack community? I guess other than starting a podcast and, you know, being a guest on one.
Charles: Yeah. I think that for people like us at Snipcart, what we are doing is our own way to contribute to the community by writing tutorials, demos, having some open source code and participating to Slack communities. And I think that as a developer in the JAMstack community the biggest way to contribute is to do some open source thing... just play with the products and do some side projects using the JAMstack itself. And talk about this at your local dev MeetUp. I mean, it just needs to get talked about more. I'm going to quite a few dev MeetUps around Winnipeg where I live at the moment and I don't see a lot of people talking about it. So, I think that spreading the word is something that everybody can do.
Franck: Yeah, and you just, I mean, you open up MeetUp.com and you literally filter by geography and say "my area," you punch in "JAMstack" and if there's a JAMstack Meetup, just go to it. Just try to learn a thing or two, talk to a person or two, and then maybe it will get the ball rolling. But then again, if you do that and there's no JAMstack Meetup in your area, why not start one? Like I literally started a meetup a few weeks ago about online marketing, super small gathering for people in SaaS and building apps who wanted to get better. So it's just fun and it's easy. The onboarding is super simple and you can start that MeetUp anytime. And like you did with the podcast, you don't have to position yourself as an expert. You position yourself as a learner and a student. And that humility goes way way... it's just better.
So I really like that approach you did and I think people should try to see, "Hmm, let's see. Is there an in real life, physical space where I could reproduce that dynamic? Is there a blog I could contribute to? You know FreeCodeCamp on Medium? They're accepting good quality posts. Why not challenge yourself to write about something you learned or something you don't agree with regarding the JAMstack and whatnot. And if it's good, they'll help you edit and they'll get you published and that will get the conversation going and you can have some feedback from devs all over the world. So there's that. There are very cool Slack communities. I can't name all of them... I'm part of one that's called The New Dynamic. Josh, you and I spoke on there, and it's a brilliant community full of very talented people.
Josh: That's my favorite one that I've found.
Franck: Exactly. So I try to hang out and lurk a little bit in there and ask some questions and get heaps of inspiration like content-wise and just better understanding of how the real developers are living that JAMstack transition. So participating in these is great. Of course, I don't want to over promote Netlify stuff but they're doing lots of great stuff for the community and they're organizing the JAMstack conference. We missed the first one, unfortunately, last year because we were spending all of our budget at the Vue conference in Toronto (which was awesome by the way... Charles gave a talk there). But this year we're kind of hesitating between going to JAMstack New York or S.F. and we'll have to talk about this literally, like, tomorrow.
Just one last example I wanted to nudge in is... there was this guy who wrote about how he used Hugo with Git to create an editing and publishing workflow for some kind of online publication, online book, I don't remember. And it was just so in-depth and specific as a use case but at the same time really inspiring to see that "Oh yeah. If I can manage to plug this with this then editors can edit it and it's very simple and..." Like this is a good example of talking about your experiences and sharing them with the world, your JAMstack experiences. And it's one of the best ways to learn... to actually write about stuff.
Josh: Yeah for sure.
Franck: So I guess that's it. Yeah. And go subscribe to StaticBits and leave a review on iTunes...
Josh: It was so awesome having you guys on here and like I said, I kind of just geek out every time I am able to chat with new guests and stuff. And you guys are so smart.
Franck: Well we look smarter maybe than we are. Charles is very dumb. No! I love him to death and I can't wait for him to come back to Quebec and quit that cold city that is Winnipeg.
Charles: Six months left.
Franck: Yeah.
Josh: Nice.
Franck: Yeah it was a pleasure to be on. Josh, let's keep in touch and it's just a blast having this conversation.
Charles: Yeah. Thank you very much.
Josh: Yeah, thank you Charles. And so you guys' website is snipcart.com.
Franck: Yeah. snipcart.com/blog if you want to learn and read some cool stuff about the JAMstack and more.
Josh: And you guys can be found on Twitter.
Franck: Yeah @snipcart. And for all of the people who were asking on Twitter or via intercom if we're dropping jQuery in Snipcart's next version, YES we are dropping jQuery in the v3.0 that's gonna be coming out in the end of March-ish.
Josh: Oh nice
Franck: I hate ETAs.
Josh: Yeah. Don't ever give ETA's. All right. Well, thank you guys so much. It was a pleasure. You know I always extend the invite to be on again.
Franck: Yeah, and maybe we could have you on the blog.
Josh: Yeah. I'd love it...if I can find the time.
Franck: Yeah. No rush.
Josh: Awesome. Thank you guys so much.