In episode 65 of JAMstack Radio, Brian talks with Ohad Eder-Pressman of Stackbit. They explore the influence the JAMstack has had on developers from all walks of life, and how to bridge the communication gap between engineers who code and creators who don’t.
About the Guests
Ohad Eder-Pressman is the Co-Founder and CEO of Stackbit, the first open, complete platform for the JAMstack. He is also an early-stage investor in companies such as Netlify, Domestika, Sanity, Chroma, PeerSpace, Bottomless, and IFTTT.
Brian Douglas: Welcome to another installment of JAMstack Radio, on the line we've got Ohad Eder-Pressman.
Do you want to say hello and tell us why you're here?
Ohad Eder-Pressman: Hey Brian, thanks for having me here. Why am I here?
I guess I'm excited about the JAMstack and devoting or have been devoting a bunch of my time to productizing, evangelizing and promoting it.
Brian: Yeah, and like you're also founder, CEO of this company called Stackbit, which folks have probably, who've been paying attention to this podcast, are probably familiar with.
It comes up organically in conversation, but do you want to talk about that?
And sort of how that fits in the JAMstack?
Ohad: Yeah, so I'm indeed a cofounder and CEO of Stackbit.
We are a company building products and tools for the JAMstack.
And we're probably best known for our site builder, which seems to be the most popular JAMstack site builder out there with a lot of traction and a lot of people showing up everyday, building new websites whether it's for, you know, production needs or educational needs.
We support a variety of technologies within the world of the JAMstack, whether it's, you know, different choices for static site generators or headless CMSs.
And I'm really excited about that.
And we feel that that is, it's something that really helps promote the JAMstack from a paradigm that is mostly accessible to developers who are comfortable with the command line to a broader audience.
You know, not consumers because consumers are still going to, you know, most likely prefer tools like Wix or Squarespace, but tinkerers, people with technical tendencies who are curious about, you know, the new things coming around, people who are currently using WordPress and want something faster and more secure and so forth.
Definitely love to talk about our studio and some of the other things that we're doing, but I guess we'll get to that in a moment.
Brian: Yeah, can we unpack a bit on the site builder too? And what you mean by site builder like per se.
Because you mentioned Squarespace and Wix and I get that sort of the used case to model, maybe folks who might have a YouTube page and they might be technical enough to do editing and video and might be a prosumer or whatnot.
And they want to throw a site together. It sounds like that's might be the target audience for this.
Ohad: Yes, so the target audience is pretty broad, but the challenge that we were looking at when we got started was, hey, here's a great architecture for the future of the web.
We really believe that websites are going to be built this way because it offers so many benefits and a better developer experience.
I don't need to talk about the benefits of the JAMstack.
I'm just going to assume that listeners are familiar and they're listening to this podcast because they want faster and more secure sites and modern tooling and so forth.
But, just to create a functioning website, I'm not even talking about how do you edit this thing and publish this thing, but just to get started, kind of requires you to get into the weeds and learn about a lot of different tools and choose between a lot of different tools.
And every choice requires further education and configuration and you know, tweaking. And it's really a lot of work.
It's not like in the world of WordPress where I commend them for bringing the ecosystem to a point where you can just go and download a theme and create a WordPress droplet installation and drop the FIM in there, and it just works. It's still, I think, not as smooth as I would hope for it to be, but a lot of less technical people do that everyday and successfully create websites.
And let's just think of that as step one.
So it may be a little unfair because the term site builder, can encompass both the creation and kind of the day-to-day life cycle of I'm just working on this theme or on this website.
But in the world of the JAMstack, I tend to split these into two separate parts.
And our site builder is basically, here's a growing collection of themes and, you know, support for a variety of open source themes and pick your technology, click a button, and within 60 seconds we're going to do all this hard work of provisioning and creating and configuring and webhooks.
We're going to bring you to a point, where you have a live site. You have a GitHub repo with all of the code and everything wired up.
You have headless CMS, or you have your content in Git, whichever option you picked.
And you're kind of good to go and you can use this as a starting point for working on your website if you're a developer.
You can use this as a starting point for your journey in trying to better understand all the moving parts in the JAMstack. And what is a JAMstack website made of?
And how do these things connect? And Stackbit brings you to that point within approximately 60 seconds.
We like to say that the world record is pretty two seconds, but typically takes up to 60.
So that's kind of how we think about the site builders, like, who uses it, right?
So like a ton of people who are curious about the JAMstack, it's the easiest way for them to get started and get to a point where they can go to the GitHub repo, and look at the source code.
And it's not like just going and looking at a random Hugo feed because your repo is wired.
You make a change and hit commit, it's going to trigger a deploy in this case to nullify.
And you know, if you chose to store your content in Contentful, it provisioned the space.
You can go into Contentful, you can see what Contentful looks like.
You can change content, hit publish, it'll affect your website.
And so, you know, lot of the partners that we work with, whether those are static site generators or headless CMSs, we'll often send their users over, you know, coz it's the easiest way to experience Contentful or Sanity if you will.
In a more full-fledged JAMstack kind of experience.
Brian: Yeah, so like would you say that stack that would be the sort of starting point for folks making the decisions for starting a new website.
Was that where you fit in the sort of life cycle?
Ohad: Yeah, I think that we, you know, we'd like to be the create button for the JAMstack.
We'd also like to be the edit button for the JAMstack, but we can talk about that a little later.
And because we think the JAMstack is going to be the predominant way that people build websites, you know, like our vision is to be the create button for the web in the longer term, right?
This is what people go.
But it's not where it, you know, the difference between, and this is both like the difference between Stackbit and say Squarespace, but also the difference between say JAMstack and Squarespace is there's a lot of site builders out there and there's a lot of different ways to get content onto the web.
Most of those ways or methods are, you know, proprietary and very well guarded.
And I love the JAMstack because it, you know, keeps a lot of control in the hands of the developer or the person building the website.
And what we try to do through the Stackbit site builder, is maintain that freedom of choice and control.
And so, when you're done with those 60 seconds of creating a website, you're not stuck with some sort of proprietary Stackbit, SDK weird way of doing things, which may not be relevant in a few years.
If you pick Next.js and Sanity.io, and you know, one of our themes, it's like you have a repo, you have the code.
We try for it not to really be, you don't need Stackbit to continue working on your site, right?
We try to give you a fantastic starting point, right? So some people will use it for education.
Agencies will use it for a starting point for the, you know, the websites they built for their clients 'cause they get all the scaffolding and everything is hooked up and it's very convenient.
And there's a lot of downstream benefits, which we'll touch. The usage is very broad.
And I actually I'm very encouraged by it because I think that's the audience we want to serve.
We want to serve a super broad audience.
We're not competing for the people who, you know, their preference is to always be in the command line and hit create-react-app if you will.
Or like, you know, new project and everything is blank.
Like I'm often that kind of person, but I also love using tools when, you know, they let me run faster without locking me into something.
Brian: Yeah, and I like that sort of approach too as well.
Like being able to have, like I'm a big fan of the onboarding experience, big fan of this generally JAMstack onboarding experience.
Like if I could discover things like Stackbit or all the other tools that you mentioned, and in 60 seconds, I can have a functioning site that works on top of that technology.
And then I could sort of backtrack and read the docs later. Like that's the experience I'm looking for.
And I'm also very much in the vein of, because I can write code and because I can throw a site together real quick with that nice deploy to Netlify button.
I do want to go back. And once I have the template and go to massage it into what I need it to be.
So if the CSS or the UI or the animations aren't what I want, I want to be able to use my knowledge and not be sort of stuck.
Like when I see, so my brother who he's in the marketing space, UT marketing, and Shopify and stuff like that.
And he helps brands and he always presents me with a problem on a Wix or Squarespace.
And he's like, hey, how can I make this work this way?
And I'm like, well, here's a GitHub repo and here's me prototyping it for you.
He goes, well, how can I get this inside of Squarespace or Wix? And it's like, I don't know, I have no idea.
So let's open up the editor and their editors it leaves a lot to be desired.
So if I could just get, if I could jump into the repo or I can jump in a place where code makes sense to me, I can solve his problems.
But a lot of times his problems are obscured away because of some decisions made by a product manager at one of those companies or engineers or whatever the reason for that.
But I guess what I'm getting at is like having that sort of experience where you can just ship something really quickly, but not be bogged down.
Sounds like the experience that I would love to see.
Ohad: Yeah, and I couldn't agree more, you know.
What you experienced with your brother is basically the lack of a meeting place if you will, for your two disciplines, right?
You want to think about things from the perspective of code and CSS and templates and logic.
And your brother is thinking about these things from a perspective of, I have a job to be done.
I need to get this thing online, right? Like how do I do it?
You know, I don't care if the Google Analytics snippet is manually injected by me into just one page or if there's a nice configuration way to do it from Squarespace.
I just need to track my analytics.
You know, I really love thinking about these problems from these different disciplines, because it helps us build, helps us all build better products and more successful products.
And with the JAMstack, I think we're at a point where, you know, I think we're winning over developers.
Most of the audience are people who are technical.
The less technical people don't really care about the JAMstack, but they sure love faster and more secure websites, right?
So it's about how do we empower them and bring them into the flow and give them the tools that they need to be able to produce JAMstack websites or from their perspective, like modern or superior websites, but in a way that doesn't require them to get into GitHub and edit CSS or call you every time that they need something, right?
Brian: Yeah, so can we transition to that what you were calling the edit button for the web. And what that looked like for Stackbit.
Ohad: Yeah, yeah, and I'd love to give you just a little bit of background about what got me into, you know, being curious about these things.
Because I have been yearning for this sort of tooling for approximately 10 years ago.
You know, my journey if you will, I'm a developer mostly self-taught and very curious and have written code and built systems and a bunch of different disciplines and architectures.
And around 2010 or 2011, you know, I had the burden of having to maintain my own personal website, you know, out of choice.
But also maintaining, you know, the websites of every random family member who will say was able to get me to do it for them.
You know, you've been there, right? We've all, you know, gone through this journey of WordPress and cPanel and shared hosting and pain here and pain there.
And I remember being tired of a bunch of these WordPress websites that I was maintaining for family and friends, just constantly getting hacked.
You know, some of the main benefits of the JAMstack are speed and security.
I personally was bothered by security. 'Cause these things were just, and, you know, not like hacked in any kind of like super malicious and targeted kind of way.
But, you know, they find these vulnerabilities and they run them and they kind of get their script into 500,000 websites.
And that was happening way too often.
And one day I was thinking about like why do I even have a server generating my website every time?
And why do I have to maintain this thing? And like, who is it good for?
And I bumped into a blog post by Werner Vogels, the CTO of Amazon, who was talking about how you can now put website content on an S3 bucket and wire it up to a domain and have them post it, right?
And I was like, wow, you know, that's how I'd like my website to run and be hosted because, you know, it's basically zero maintenance.
You know, as a developer, I want to optimize for like zero maintenance.
And so I took a snapshot of my WordPress site and I put it on as free and I hooked up the domain and it was magic.
It was magic. It's like one less thing to worry about, you know.
I really love worrying about less and less things.
So that was fantastic until a couple of weeks later I wanted to write a new blog post, and what do you do then? I am not particularly a genius or anything. So I learned these things the hard way where I didn't really think a lot about this problem of if I want to work on my site later on.
I just thought about this, I was reacting to the site getting hacked.
And so I start to think about, well, these static sites, you know, static site it wasn't even the term then.
I'm not sure it was a term. And, you know, static site generators, generally weren't a big category or a popular category.
I think, you know, perhaps Jekyll existed or was on the way to exist to kind of get born.
But it took me on this journey of it's like most websites should really be static and hosted on something like S3 or CDN.
And well, you know what, like we should be able to generate them somehow and we should be able to pull content and then we should be able to edit them because we really sacrificed the editing experience and so forth and so forth.
So, you know, fast forward to Stackbit, we started with, you know, the site builder in 60 seconds and you have a website up and running, right?
But how do you edit these websites? You know, there's the status quo in the JAMstack for how do you work on a website is also extremely technical.
You know, a lot of people like to store their content and markdown and config files as part of their GitHub repo.
You know, I remember the first popular way to edit that content was a tool called ProseMirror or Prose.io, right?
Maybe ProseMirror was the WYSIWYG, that kind of open source library, which I'm not 100% sure of this, but I think it was created by a digital agency in the Washington, D.C. area that also created Mapbox the company, and span that out.
And so at any rate, you know, there was a, there was a time when those were the tools and you know, of course headless CMSs, kind of merged these two things together where, you know, here's a great way to create, you know, structured content and a schema for content.
And here's a basic interface for editing it, but it's almost like on purpose.
We don't want to deal with how does content gets presented, right?
Like we're separating that problem out. Here's where you edit strings and paragraphs and upload images, right?
This is about content and schema and then wonderful companies like Contentful and Data CMS, Sanity.io, and a bunch of other great headless CMS companies emerged.
And that became the status quo of how we edit the content.
Unless we're hardcore, you know, markdown people where we just go to GitHub and click edit and so forth, right?
But if people like your brother want to be able to work on a website, you know, they're really comparing this to Wix and Squarespace, right?
They've seen Webflow, they've seen WordPress, you know, they expect it to have let's call it a studio experience that has a couple of core capabilities, right?
The first one being a live preview of your work in progress, you know.
There's your live website and it's kind of out there, but like, I want to be able to work on something that isn't published yet.
And obviously I want to be able to see it, you know, while I'm working on it.
And as a product feature that hasn't really existed or like adopted big time in the JAMstack just yet.
You know, most static site generators will be able to run in dev mode, but that's really productized and it's mostly for developers to run locally.
And so that's one thing, right? So let's say your brother has that.
You know, they also want to be able to click edit and like hover over a paragraph or over a caption and not double click it and make a change and see what it's like, you know.
And they want to be able to click the publish button without having to know about GitHub or Netlify or Gatsby or whatever, you know.
'Cause they don't care about that. They care about having a fast and secure site perhaps, or maybe they're willing to try a new paradigm, but they need these tools.
And so what we build at Stackbit is something we call the Stackbit Studio, which offers you all of these capabilities in the form of a user experience and a workflow.
You get the live preview, you get the on-page editing.
I don't want to call it WYSIWYG editing coz it's not really, really WYSIWYG editing just yet.
But it's definitely going in that direction.
And it's integrated with a publishing and you can schedule a publish and you can get a link to, you know, share a preview of what you're looking at with a coworker or with a client, right?
So, you know, you can think about this as a, you know, a studio experience or a production environment.
It doesn't reinvent anything product wise. It basically recreates what we've lost by, you know, unbundling the stack, right?
Like when we unbundle the stack, we got all these benefits, right?
Content is here, rendering is here, hosting is here, but how do I work on, I need a developer.
And with the Stackbit Studio, we try to create this experience.
And the most important thing about it, is that it creates a unified experience on the top, which is UI based.
And it's where people like your brother and for people like me and for people like you to happily and efficiently work on these websites.
It's our day-to-day tool to work on JAMstack websites.
But it's powered by Gatsby, Netlify, Contentful, Sanity, GitHub, right?
It's developers control everything underneath.
There's no secret sauce in the sense of like, there's no Stackbit SDK, right?
If you have a JAMstack website, you can connect it and everything will just work magically.
Brian: Yeah, that's intriguing too as well.
And like, it sounds like exactly what I need to pivot my family members into, so if they want to have my free or very, very cheap support work, technical support work, like that's the way I can sort of jump in and sort of manipulate things.
And like, perhaps I don't use the studio, but they use the studio pretty regularly.
Brian: And then I can, I can sort of side swipe or get into the back-end to be able to the "back-end," I guess I would call that.
But to get into work on that. So Stackbit uses the term studio, I'm curious, is this not a CMS?
Ohad: That's a good question. You know, I guess the answer is it depends.
We don't think about it as a CMS, but I think that the term CMS has kind of multiple interpretations.
So if we take a trip down memory lane, right? Historically, and let's say historically in like five to 10 years ago, five to 50 years ago.
Brian: That's so long ago, it's older than this podcast.
Ohad: Old school.
When you said CMS, you were referring to like everything, you know, WordPress is a CMS, Drupal is a CMS, Adobe Experience Manager is a CMS or a web content management system.
It's this place where you expect to be able to work on your website and change content and see what it looks like and hit publish, and maybe do AB testing and maybe do personalization and all of that good stuff, right?
So in that context, I guess we try to pull back the experience that CMSs used to have and bring those into kind of the modern age of the JAMstack because I feel that we've lost a lot of those capabilities and product experiences.
And I think that, that's a lot of what the JAMstack is really going to accelerate with.
But what we clearly aren't is a headless CMS because in the modern age, you know, companies have emerged to focus on storing content and managing content and dealing with schemas and providing enterprise workflows on top of that content and thinking about companies being content first, and you can use this content in a bunch of different places.
You can use it for websites, but you can also use it to power content in your mobile apps and maybe digital signage and maybe digital books and a lot of other things.
So we are definitely not headless CMS and we don't store your content anywhere.
Actually, Stackbit tries not to store any state. So like we try to be stateless because we rely on a Contentful storing your content for you and managing the environments.
Or we rely on, you know, your GitHub repo to store your content and so forth.
We also don't host your website.
You know, like you'll pick Netlify, Vercel, or S3, or Azure static sites or whatnot and we'll integrate with that.
We try to focus on recreating the tool and the experience on top of this open platform, right.
We don't try to replace any of the boxes because we think that the architecture for the JAMstack is really great.
And we think that, I personally think it's created a lot of companies that really excel at doing what they do.
You know, whether it's a static site generator or a headless CMS or the appointment platform, there are companies who do that really well.
I have absolutely no desire to compete with them on that.
I actually want to empower users to be able to enjoy all of the benefits that these companies have created, which I feel are still mostly limited nowadays to developers.
Brian: Yeah, so I'm curious when you mentioned the term, like the phrase unbundling of the web and that the place that we're in today with the JAMstack and like, I'd see things like, when you look at React frameworks, which is like--
If you told me that React frameworks would be a thing when this podcast was started four years ago, I would have be like, ah, no React is a library, it's small, it'll never get bigger than this.
And now we have frameworks on top of React. So I'm curious, now that we have like a lot of these tools discovered.
We got like FONA who's has a nice lightweight and experience for getting your database together and we have these Sanity and all these other headless CMSs that are happening.
Do you envision a space? 'Cause like you like Azure is one of those spaces and AWS is another space where it's a one solution you're sort of locked in.
Tell me do you think there's going to be some sort of aggregate of these technologies, where you could, where you can aggregate all these technologies together.
Or you just make, I don't want to make decisions on databases.
I don't want to make decisions on, you know, CMSs. What I want to do is ship a site.
And if this fits my budget, then I want to choose this path.
So if I'm the designer path, if I'm the marketer path, if I'm this sort of prosumer path, like I imagine, and I say this out loud as not even thinking about the fact that Stackbit probably is, it might be this sort of aggregate of solutions.
But yeah, I'll be quiet and I'll see what your response is.
Ohad: No, I think you hit the nail on the head, you know, I'm not a historian and I'm not going to try and be one, but you know, we're clearly experiencing an unbundling.
And I think these things tend to like, you know, unbundle and rebundle, unbundl and rebundle because like we've unbundled because of, you know, a bunch of different challenges or opportunities.
Now we have websites that are faster and more secure, but you know, we pay the price where, because content is completely separate from, you know, how it's rendered and where it's hosted.
So nobody can give you a proper experience for editing websites.
And so we can create JAMstack websites, but guess what, we can't really compete with what Squarespace or Adobe Experience Manager offers just yet.
Now comes the question, "Who is going to aggregate this?" Or, "Who is going to rebundle this?" And those terms can often be used interchangeably even though they mean slightly different things, but we try to aggregate or rebundle these tools. We don't do this in a way that displaces the tools or replaces them. Basically, create a layer on the top. Or another box, another category of tools for the JAMstack, which orchestrate and offer a consistent UI on top of all of these tools.
And it's because we listened to the people who have a job to be done.
And when you look at the kind of mass scale, when people need to create websites, when companies need to work on websites, most of the time they're not architecting components in different ways.
They're not working on schemas and so most of the time, they need this old school web content management user experience.
At the same time, the developers who make the technical choices about building these websites are developers.
And, you know, we're at a point in time where developers are having more and more influence within companies.
Where developers choose their own tools and the tools that power things that, you know, sometimes marketing will use in other sections and the company will use.
And so, you have to ask yourself, well, what are developers going to choose as the, you know, the website architecture for the next iteration of their company's website when they get asked.
When marketing tells them that they need to create a new website.
You know, I think it's going to be JAMstack, but at the same time, there's going to need to be this product experience, which is the meeting ground between the different skill sets, right?
It's where you and your brother can cooperate together, right?
And, you know, talk the same talk and you push a button and he sees a light bulb go on, right?
And that doesn't really exist just yet with the JAMstack or, you know, it's unfair to say, perhaps it exists, but it's extremely rough around the edges.
And of course you can load up a live preview on your computer, and somehow pipe it to your brother and set it up on her local.
And if he wants to do AB tests, you can perhaps go and provision as another environment for like, oh my God, you know, that's not fun for you because that's not productive work.
That's just tedious repeat work. And it's not fun for your brother, 'cause he's just dependent on you.
And you know, there's a limit to how much he's comfortable to ask you to do work for him.
And it's the exact same thing with a customer and an agency.
It's the exact same thing with a marketer and a developer and a company, right?
If you look at this from a perspective of like low code and no code, like we're not going to replace developers, at least in my opinion.
It's just that the world is creating more and more tools that empower less technical people to do more and free up developers to focus on real interesting problems and creating value as opposed to editing config files and going in and changing strings from marketers and taking a screenshot and like, that's just an example, right?
But that happens everywhere today.
Brian: Yeah, I'd say like the going back to the unbundling thing and also this whole trying to empower the nontechnical folks to also, the handoff to them, non technical folks.
One thing that comes up and we brought this up a few times is WordPress.
And like that the monolithic experience of we all know that WordPress, well, maybe we all don't know this, but WordPress is expensive.
And it's a very thick market of lots of WordPress developers out there who are in agencies as well.
But I wanted to ask too as well, 'cause I saw on Twitter and I read the article of the WordPress.
Was it the CEO had did open letter about JAMstack and said how it was not going to work. And then I saw your response.
Did you want to talk about that letter and talk about the response to the JAMstack and WordPress?
Ohad: Sure, yeah.
I mean, I think what happened is Matt Mullenweg, which is a highly respected persona in the world of the web, is the creator of WordPress or perhaps one of the cocreators of WordPress and also the founder and CEO of Automattic, which is the kind of the company pushing and popularizing WordPress.
So he's responsible both for the open source phenomena that treadly powers 40% of the web, as well as having created perhaps the biggest company in the space of capturing some of that value back.
So, you know, Matt is a obviously super smart and successful guy, perhaps even much more than me.
But at the same time, he's, you know, highly invested in this very particular way that the web works.
He can claim a lot of success because again, around 40% of the web is currently powered by WordPress.
But a WordPress has a lot of challenges. And a lot of people, including myself, have left WordPress and have helped develop ideas like the JAMstack, like headless CMSs, like static site generators.
Not because of anything that Matt or WordPress did, just because things evolve and the world evolves and technology moves forward and a lot of things have happened in the last 10 or 20 years that helped birth the JAMstack. Or I would say, the JAMstack wasn't birthed. It was yanked out of the minds of a lot of smart people who basically continued pushing the envelope and evolving the approach of how we build websites.
And I don't think Matt was so interested in the JAMstack, that he sat and wrote a file piece.
I think he was, you know, kind of like interviewed over email by Richard McManus for read-write web fame.
And, you know, Matt really wholeheartedly defends WordPress and basically thinks that JAMstack is not ready for prime time.
Highly dependent on a lot of different offerings and so forth.
And I think one of the things that he tends to miss, or, you know, one of the challenges with the comparison is you don't really want to compare the JAMstack to WordPress.
Because the JAMstack is an architecture, it's a philosophy. It's let's host most of our website content from a CDN.
Let's generate it every time we change it and not have to rely on servers to run the same code and produce the same thing on every visit.
Let's rely on microservices and APIs. Let's use modern developer tools and workflow.
Let's be, you know, git-based. Let's benefit from the good workflow and so forth and so forth.
And you know, WordPress hasn't really excelled in making core changes and adopting new methodologies for doing things.
And this isn't just, you know, oh, hosting static content from CDN is better or it's like using Git is better.
Like I don't think we need to argue that anymore, you know.
So, you know, if anything, the JAMstack should be compared to the LAMP stack and you know, the merits should be compared there.
And I think that it's the, you know, the JAMstack is definitely the way to go.
And of course the equivalent of WordPress, doesn't exist just yet.
For the JAMstack, it's like we're all working on it really, really hard.
And the rate of progress that we're seeing from all of the different participants is I believe is massive, you know.
Anywhere from efforts like what Stackbit is doing, to rebundle the experience and empower less technical people to do things to the work that, you know, Gatsby and Netlify and Next.js and Vercel are doing for regeneration of websites and partial rebuilds and recognizing perhaps a challenge sometimes with statically generating massive websites with hundreds of thousands of pages or millions of pages.
But the rate of progress happening there is massive.
And, you know, I don't see those challenges as a, you know, culprits of the JAMstack.
I see those as points that need to be addressed and that are being addressed.
And I see the merits of the JAMstack really winning over LAMP in many different ways.
Which again, I am assuming are mainly obvious to most people.
Brian: Yeah, indeed. Yeah, I appreciate you sort of running through that sort of explaining the state around the article and sort of how it was developed in the conversation.
I think it's a conversation that's going to be happening a lot.
And I was like, I guess that's what I was sort of like reaching for and looking for, people might be wanting a WordPress experience, where it's a one step to walk into and have a site and you have a community where you can source WordPress developers pretty easily as well.
And I think we're getting there with JAMstack. Like now we see the JAMstack term being leveraged a lot more regularly.
But also like we love seeing the growth of the ecosystems where we can actually, now no one has to sort of like guess what I'm talking about when I run this podcast.
I guess, what we're talking about, when we say words like headless CMS.
Now we're sort of now reaching the same level of playing field, where we can then now move into like the next level of whatever we're trying to accomplish.
We don't have to rebuild the same stuff that it's already been done.
Ohad: Yeah, I guess what I wouldn't be surprised if Guardian starts covering the JAMstack soon, you know.
Maybe that's the sign that we're done or maybe just getting started. It depends on what perspective you have.
Brian: Yeah, excellent. Yeah, and I saw you, you know, in the chat too.
We didn't even cover the context of how we even know each other as well through Netlify.
But did you want to cover through like your investment in the space?
And like not only are you invested in the point that you have a company.
But your investment in the actual, the space and the future of the JAMstack as well.
Ohad: Yeah, I mean, I love the story of it and it reflects on how I do my work and think about things, which is mainly very organically.
You know, I'm a developer and an entrepreneur. Stackbit is my fourth company.
And, you know, I've done anything from create a bootstrap, self-funded companies and all the way to, you know, selling a company to a larger, you know, public U.S. company and serving on the executive team.
And so I've seen things from different places. What I really love doing is creating and help create.
And I'm very curious. And so, as I mentioned, I went through this personal journey of " discovering" the world of and the need of the opportunity for static sites and headless CMSs and deployment platforms and so forth through my personal journey of my personal website and my friends' websites.
And I remember throughout 2010 and 11 and 12 conversations with multiple friends trying to grasp what is the next iteration going to look like.
And what are the tools going to look like?
And, you know, some of the ideas that we were throwing, I remember with one of my friends, Eran Sandler, which is now the CTO of Peach Finance.
We bounced back and forth the term of like cPanel for domains, or like the next version of cPanel that helps you create new things in your perhaps Stackbit, the site builder and the studio, or like in, you know, it exists today in light of some of those ideas.
But in 2015, I was prototyping a headless CMS experience on top of S3.
So you would store your content in S3 and your entire website in S3 coz that's where my website was.
And I created this kind of like headless experience for editing those sites. Just editing the HTML, no static site generator or anything.
And it was talking to the S3 API. You didn't even need a server for the CMS, if you will.
And as I was developing that, I was telling a couple of friends and I wasn't really trying to build a company or anything, but I was engaging with these ideas.
And you know, the word research is really big because like, I guess you have to be a researcher, but I was playing.
And I bumped into Netlify, when it was just Matt and Chris, the two founders, and perhaps someone who's doing some content writing.
And bumped into their website and clicked in and clicked on the chat. And was like, really love what you guys are doing.
You know, I forgot to mention, but like, in the last 10 years I've also been angel investing, which I feel is not too uncommon for, you know, a random entrepreneur here in the San Francisco Bay Area.
So I'm not special because of that. But I was doing it.
And early investor in if this did that and met Matt and Chris early on and really connected both personally, 'cause they're amazing guys.
But also just connected technically and vision-wise. It's like, we just think about the web and how it's evolving and where it's going in very similar ways.
And we reached it from like slightly different angles, but we all think about it and are passionate about it in a similar way.
So, I was fortunate enough to be able to put together Netlify's seed round of investment and join the board of the company, where I still serve in the capacity as a board member and, you know, Netlify since then has really grown in ways that are hard to describe, you know, it's a phenomenal journey and a phenomenal accomplishment by founders.
And more importantly, by the fantastic employees and talented people who, you know, day in and day out help build this great company.
And so I'm, you know, I never worked at Netlify, but I've been on the sidelines throughout the journey.
And then that's where I think you and I first met, when you joined Netlify to work on developer relations and advocacy.
So I think what was that, was that 2016 or 17?
Brian: Yeah, it would have been 2016. And yeah, I originally joined pretty early on, shortly after they had the content person helping out, who actually was on the first episode of this podcast, Aaron and--
Ohad: Oh, cool.
Brian: Yeah, it's been a wild ride and honestly like even being more nostalgic about this too, and hearing your story.
And I didn't really realize your original introduction.
But yeah, my introduction was similar as well.
I saw Matt speak at Heavybit and saw that he was working on a thing that solved my problem.
So I became an early user of Netlify and then a year later became early employee.
So I'm just super happy to see this the space expand, even beyond Netlify and see that the change of developer and the landscape has now even like been fulfilled, but also bore fruit from other companies and founders and engineers.
And like the open source space has now been shifted a little bit.
When you start talking about front-end space, where now we can have bits and pieces that work interdependently, but also independently as well.
And that this choice and decision for developers is now it's a wonderful experience where you could sort of just take part of the buffet and choose like I'm going to use React here and I'm going to use Netlify here for cell here or whatnot so.
Ohad: Right, and I think I might credit Matt and Chris and everyone else in the ecosystem for not just building great companies, but also helping popularize an approach, which is, you know, open and it's a philosophy.
And you know, a lot of us and more of us are, you know, scribing to it and are excited about it and building companies and open source and experiences around it.
Brian: Excellent. Well, yeah, I appreciate the conversation and I wanted to save some time for picks 'cause we're coming up to time pretty closely.
And so these are JAM picks, picks that keep you going. It could be music, could be food-related.
We have quite a few tech picks obviously on this podcast being a tech podcast.
But if you don't mind, I'll go first. I've got some picks that I'm ready to go.
My first pick is going to be the new mixer I bought because I'm working from home.
If you listen to the podcast more than one episode, you probably heard about my streaming on Twitch.
So I won't mention that, but I just did, but I spot a new mixer. It's a USB mixer that plugs into my window streaming PC, and it gives me a bunch of bells and whistles for recording live streams, as well as podcasts.
Not only this have a sampler, it's got a voice changer, it got effects, it's got a nice like full extended EQ.
And I'm just sort of blown away.
And previously I've always used like things, like Audio Hijack or a Loopback to make all the things route and do proper like exposure for text, especially for a live streaming.
Having a guest on live streams and run that through OBS.
It's a whole other job and it's quite tedious, but also breaks all the time.
So picking up this mixer was to go XLR has been a, it's made my entire experience a breeze.
And I think as far as developer relations goes, like, I think now we're sort of figuring out, there's no more in-person conferences, at least for the near future.
So now most developer relations and advocates have shifted into we'll bring the conference to our office and studios.
So highly recommended if you going to be taking that seriously, either that mixer or something similar.
Make sure the tools that you're going to be literally leveraging every day nine to five, are going to keep up with the demand of the new age, developer advocacy.
I'd pick one more thing, which is, I've also started building up a home gym too as well.
Last year, actually two years ago, my daughter was born and I lost roughly 20 pounds just from having paternal leave and hanging out and paying attention when I was eating.
And I found those 20 pounds during this last six months of quarantine.
So my goal has been since I had to cancel my gym membership because I was a member of the gym that has not been reopened.
I started picking up home equipment and if anybody's seen my space, I have a video on Twitter right now of me showing off my desk base.
I don't have a huge area to work in, but it's also the same area I work out in.
So I've been picking up some bands, but the thing I want to talk about is the base bar, which the base bar is essentially, it's a bar it's for you to do body weight workouts, calisthenics on.
Like, I'm not really into lifting weights anymore.
I used to lift weights like years ago, but I wanted to use some low effort things I can do in between meetings or as I'm like starting my day or ending my day.
So I like to leverage working out as a way to separate working from home to being at home and being with the family.
So that separation is now been introduced through this base bar where I do pull-ups and some way to pull-ups and all these other calisthenics exercises.
Those are my two picks and Ohad feel free if you have any picks for us.
Ohad: Yeah, my pick is a little bit conceptual. You know, I have in the last two months have obsessed on the site a little bit on creating a little DIY kind of work bench and tools storage.
You know, we have a very small, you know, one-car garage and I've just had my 40th birthday. And so I claimed--
Ohad: Section of the wall, thank you. I just claim the section of the wall and it's been like, I really love building things and just DIYing things.
And so my last thing I got was a DEWALT angle grinder, which I've probably not too exciting or new, you know, it's like a lot of angle grinders, but just really have been enjoying going for YouTube and looking at people building their own little tools, storage ideas, and things like that.
And slowly building out my own. And it really helped coz you know, when you customize things, especially when you have a small space, you can really just utilize that space in a much better way.
So like I got, it's funny I ended up getting a utility cart, you know, like almost like a janitorial utility cart made of like this, you know, sturdy plastic and treated like a folding desk on the top of it.
And it fits right behind something I've mounted on the wall. And so like all these things work really nicely for me.
And I really, really like that. So yeah, maybe that's my pick taking the time to, you know, empower yourself to build.
And I guess as builders, we very often just enjoy building tools or the things that help us build.
And we sometimes, we don't even care to do anything with it after.
We just want to build a tool.
Brian: It's the story of all my GitHub repos. Tons of tools with nothing to show for it.
Ohad: Hopefully not. Yeah, but I guess that's my pick.
Brian: Excellent, well, I appreciate the conversation. It was super insightful.
Like you've been around this space for a bit and you felt the pain of not having things like the JAMstack being around.
So, hopefully it's insightful for the listener. Definitely check out Stackbit and check out Ohad on Twitter.
And listeners keep spreading the JAM.