Vercel is a cloud platform for deploying Jamstack websites and web services.
Netlify is a hosting and serverless backend platform for web applications.
Milk Video is a tool for turning live video recordings into sharable clips for marketing, sales, and internal education.
- What does "Jamstack" mean to you?
- You talked about having a singular front-end interface with these codebase similarities between the various marketing sites, blog, etc. Imagine trying to build all this pre-Jamstack, what might that have looked like? And what does that singular front-end interface do for you now?
- There's a lot of frameworks and languages that have come and gone that were at one point considered potentially the next big thing. Firebase, for instance, had a similar vision to what Next.js seems to be doing now, and it’s popular, but it hasn’t become a core infrastructure for the web. Do you see Next.js differently? And how do you think about whether it is durable or whether it might be replaced by something else?
- You mentioned Vercel being a commodity product but with good UX and good UI. You guys use Vercel, so I’m interested in hearing what's so useful about it and what's good about the UX? Would you consider switching to Netlify or somewhere else?
- I'd love to hear more about this idea of building APIs that only work with Vercel and the extent to which those might be something that you can't do on Netlify. Can you talk about what those APIs do, and how it might be advantageous to be on Vercel to use them?
- What are the benefits of the end-to-end value chain in something like Vercel?
- One criticism we've heard is that Jamstack and Vercel are great for getting projects up and running, but there may be limitations when you start trying to build fully featured apps. Do you see a point where you would have to move off Vercel onto something like AWS simply because of the demands of what you're building?
- Are there APIs that you insist on using when you build on the Jamstack, or are you more open-ended?
What does "Jamstack" mean to you?
Fundamentally, there's a frontend that's plugged into a backend that often is an external service, as opposed to something that's hosted. From our perspective, having a singular interface, like a front-end interface that has codebase similarities across our public-facing static websites, our actual application, and maybe even our blog or other things -- that's the reason why we heavily leverage Jamstack-based front-end interfaces. Because our application is such a complicated web application, it becomes just easy to use the components that we've developed there for our static application also. In some cases, someone might make a static website in Gatsby or something like that. We've decided to use Next because we're able to use the same components we use for our actual application.
You talked about having a singular front-end interface with these codebase similarities between the various marketing sites, blog, etc. Imagine trying to build all this pre-Jamstack, what might that have looked like? And what does that singular front-end interface do for you now?
These frameworks emerged in response to frontend end users' expectations that applications were going to be faster and update more. And it also had to do with more long-running content on a page, so video actually is a great example. You can't refresh a page if there's a video playing and you need to change things. Or maybe parts of a page would update, like a live social feed, but you don't want other things to update. So with that maturing of the end user's taste and ability to interact with the web and expectations -- and, again, also internet speed improving -- these front-end frameworks became much more mature.
But you had these frameworks appear, like Meteor. It's supposed to be a single endpoint for managing your backend and frontend and whatnot. As these front-end application frameworks got more mature -- and with Facebook and Google really staking their claim, LinkedIn staking their claim on Ember, all this kind of stuff -- then you had a lot more people who wanted to learn these frameworks. For a while, there was this window where it was like every couple of months there was a new framework that came out.
At a certain point, when there was a certain threshold of framework maturity, the number of people who started to use these frameworks grew dramatically. From there, you had new ways of deploying just the frontend, and you also had new tools coming out that catered just to those people. There was Firebase and also a database as a service company called Parse that Facebook bought and eventually open-sourced; Facebook bought it because they used it for Facebook Games or something like that. Essentially, you had these systems that were APIs as a service for storing keys and values -- basically, database entries and whatnot. And then, again, all the onus of needing a backend drifted away.
Then there were also a couple of other things that happened in between. The popularization of Gatsby came out of things like Jekyll, where you would literally write all of your websites in markup language. I haven't talked about markup at all, but it’s a format of just like, “This is a title. This is your body text” -- whatever it is -- and then you run that through some kind of Ruby script or Go script, or maybe there's static builders for Java and stuff like that. I'm sure there are. Those would then generate these static webpages, and then you just deploy a big set of HTML files.
There's a lot of frameworks and languages that have come and gone that were at one point considered potentially the next big thing. Firebase, for instance, had a similar vision to what Next.js seems to be doing now, and it’s popular, but it hasn’t become a core infrastructure for the web. Do you see Next.js differently? And how do you think about whether it is durable or whether it might be replaced by something else?
Good for the Firebase guys -- get that big tech company money. I think there were a couple emerging currents over the last ten years, which were cloud computing, AI and ML, the increase in the number of developers -- like coding becoming a thing everyone should be able to do -- then the emergence of mobile, and the no-code movement.
I would say Firebase fit into a really interesting window where you had programming becoming really popular among consumers and not in a boring “IT”/computer science sense, aligning with mobile technologies really manifesting and Facebook getting really popular. People started to look at technology as a cool thing to do, and consumer tech itself became accessible.
All of that coming together created these new things that didn't exist before, one after another. The exciting thing about Meteor was that Websockets were not really popular for a while and were hard to implement, and they just made it easy. You also see huge funding rounds, which don't make that much sense, like Gatsby. Or a couple of these CMS services, like Prismic or Sanity. Because they're providing a resource that at some level is replacing a backend, they can charge stupid amounts of money for it. They probably have ginormous margins outside of marketing.
So, why is Next popular? Next is popular because React got popular. React got popular, but people couldn't index their websites, so Next solved the problem of React, being able to be rendered to create static websites. At the same time, Gatsby did that at some level, but performance-wise, Next is just way faster. Gatsby is super slow, especially when your websites get too big. I think Gatsby maybe popularized Jamstack as a term, the “m” being markup. Gatsby really took advantage of the patterns that were implemented by Jekyll and some of these other markup rendering things. But they used React, so people working on front-end applications could also have good content management processes and still use version control with GitHub for managing content.
That's another thing I didn't bring up. Version control through Git became popular over the last twenty years, and especially in the last ten years. Mercurial never really became as popularized. People were comfortable FTPing into their servers and just replacing codebases and whatnot for such a long time.
I mentioned cloud computing. For the end user, that means you can deploy your codebase in a pretty standard way. Tools like Heroku made that stupid easy. Netlify is an example of the early deploying of Jamstack tools. Vercel emerged and provided basically what is a commodity but made good UI/UX around it, understanding what the end user needs to do and making that very easy.
When you ask, “What's the next popular thing?” Back-end services like Firebase or Parse became really big, but I think their big picture was more around realtime web. If I understand it correctly, it was just very easy to make backends, not very high performing throughput backends. Firebase is still quite big, even though Google bought them. My interpretation is that Google bought Firebase because they saw a whole category of developers who would eventually become heavy cloud computing customers, but they would have to start somewhere, and the place they would start is key-value store databases, like Mongo-type interfaces.
You mentioned Vercel being a commodity product but with good UX and good UI. You guys use Vercel, so I’m interested in hearing what's so useful about it and what's good about the UX? Would you consider switching to Netlify or somewhere else?
The way that we use Vercel, it's really just a commodity for hosting. We could do it ourselves, but there are little things that become easy. For example, they integrate with GitHub; they build your package; they deploy it; they let you rollback; they let you have previews of different packages, different bundles that are pull requests and whatnot; they manage your environment variables; they manage access between teams. That kind of stuff starts to add up. It's interesting, because five years ago it was very unusual to be able to build a pull request and have a preview branched together. Infrastructure-wise, that was hard to do. Now you take it for granted. We don't even use that feature that much, but just the fact that it's there is nice. Being able to not have to set up Jenkins or some kind of build runner and just have that work is quite nice, relative to how things worked five years ago or probably how things still work at Google or something.
“Would we try something else?” Yeah. There are tools like render.com. There's a number of emerging tools that are trying to simplify infrastructure management. is one that has good publicity around what they do. But they're all pretty much providing the same thing, which is, “Let us take your Git repo. We'll follow the instructions on how to build it. We can detect if it's a React app or Next app or something. Then we'll handle the routing so that it's available.” What's cool about Vercel is they're trying to differentiate themselves by building Next and then building APIs that integrate only with Vercel. That's smart on their side. They're basically creating defensibility for something that is just a commodity. They provide analytics and stuff like that, but my guess is those APIs are technically accessible anywhere else, but because they're building it, they can do these things that other people can't do as quickly.
I'd love to hear more about this idea of building APIs that only work with Vercel and the extent to which those might be something that you can't do on Netlify. Can you talk about what those APIs do, and how it might be advantageous to be on Vercel to use them?
The APIs I can think of on Vercel's side that we use are performance monitoring. They're serving the file, so they can track the logs of the file being served and the corresponding time for files served. At some level they're building out their own API on how those logs are being created based on the actual library of Next itself, tracking the first connection, the last connection, the time for a file to be delivered, bandwidth, that kind of stuff. They simplify it into an equivalent to what Google does with speed testing. They have their own version of that, which is smart. I say it’s a private API because I don't know anyone else who integrates with that, but technically there's no reason why anyone else couldn't. It would be very odd for Next to lock that down unnecessarily. Given time, it would make sense that everyone does that. I think Vercel charges money for the analysis, which is interesting -- no one else can do that if they are proprietary in a sense.
They understand how a designer and a developer work together, how developers work together, how code review happens, what are the priorities in rolling out features. I don't think they have a feature flag system, but I can imagine that's not a bad thing for them to launch hypothetically. They can do this in a very simple way. And it makes sense because developer needs are so prominent and clear.
And there’s one more thing that makes Vercel defensible. Technically, Vercel's hosting, and value, really only comes from the moment that you deploy your code to GitHub, which then is built by Vercel. That value really only comes from that post-deployment phase. Normally, all the hosting providers are missing out on all the development activity that happens when the code is still just on the developer's machine, unless they create a really fancy command-line service or interface -- but even then, there are limits outside of testing. So this is super important: Vercel’s building of Next -- in providing Next as the platform that's hosted as you're doing development -- lets Vercel have this end-to-end value chain, where their development environment is just as valuable as their deployment environment and everything in between. It's a cool thing that they were able to accomplish, and it’s something that Heroku can't do, AWS can't do, Google Cloud isn't doing, even though those are really mature back-end tools. It's not defensible per se, but they're expanding their presence in developers' life cycle in a way that none of these other hosting tools do. It’s counterintuitive but smart on their part.
What are the benefits of the end-to-end value chain in something like Vercel?
Instead, on your development machine you have a developer server where, whenever you make a change, the updates happen in a sub-second timeframe so that you can quickly iterate and see the changes that are happening quickly. Generally, that development environment and production environment look a little bit different, so you are running two different commands: a build command for production and a local development command for the local development. To access the codebase locally when you do that local development environment, you spin up a local server, which you access on your machine. It's technically only accessible on your machine, though there are things that you can do to make your local environment accessible to a remote machine and whatnot.
Going back to your question about, “There's Next, and there was Firebase, and what's popular.” A couple of other things that are sexy that are coming out are Svelte, which is like the anti-React world. Basically, React solved the problem for people who had been doing web development up to then. And people who were coming directly into web development without familiarity with React were basically looking at React, super confused, like “Why are these things the way they are?”
One criticism we've heard is that Jamstack and Vercel are great for getting projects up and running, but there may be limitations when you start trying to build fully featured apps. Do you see a point where you would have to move off Vercel onto something like AWS simply because of the demands of what you're building?
I don't know what the limits are. But if they get past a hundred users, or they want to store multiple data tables -- something that's trivial if you spin up a Laravel instance or a Ruby on Rails application to handle your own application -- then it becomes a problem, because it gets expensive super quick. Something that was cheaper to not have to hire a back-end developer to manage becomes a huge issue. Because now, you're in a situation paying thousands of dollars for something that would be a free MySQL database or something on DigitalOcean.
This is a little tangent here, but you can scale with Vercel, and it's fine. But we're getting to the point where every time we add a new developer, it is a bit expensive. The fact that we have to pay for a new developer seat, which is $40 or $50, doesn't make any sense. So at a certain point, we'll transition. It'll make more sense to just pay to set up Jenkins or one of these build runners and then host our own front-end payloads and AWS. These are such standardized practices that it's an easy thing to do. But I think the criticism to my point is that it's more around the back-end services for Jamstack tools as opposed to the front-end side.
There is a desire for back-end abstraction tools at different parts of the stack. At the most abstracted side, you have these databases for super abstracted no-code tools that just need a backend. A little bit less abstraction is these API services that provide Jamstack interfaces for saving data, accessing it, log in, payment, and infrastructure -- that kind of stuff. The even less abstracted parts are these new things that are just coming out, like a database called PlanetScale. It’s super interesting -- it’s trying to provide highly scalable databases that never hit the limits of Postgres or MySQL. Basically, Amazon's ecosystem as a service, but very specifically around databases like infinite table, infinite column, infinite row that always perform well. Those can be really fucking expensive. But people are willing to move there because they don't have to pay a DevOps person. It becomes a financial trade-off at some level. They don't have to worry about performance as they scale.
We're talking about Jamstack specifically, but the ecosystem for any development environment is the same. Like search -- some people will pay to set up their own Elasticsearch or Solr environment. Other people will pay that French company Algolia to manage their search. Pricewise, it's just totally unreasonable, so freaking expensive to use these things. But at a certain level, it makes sense because you only have so many development resources. Hiring is hard, so it’s good if you don’t have to think about it.
That’s also the reason we use Heroku. Heroku is really expensive, but we don't have to manage our backend, and we can roll back our database. We can scale up services and not have to think about it based on spot demand. There's no thought that goes into that. Paying a couple of thousand bucks a month for what we're getting is probably not a smart idea, but that's a trade-off that at this time we're willing to make, because hiring somebody just to think about that will cost more.
I think the Jamstack ecosystem is ideal for teams in the one-to-five-person size or environment who have no back-end development and no engineering expertise, but who can build front-end things because the feedback loop is fast, and they can learn that. People who are working on more production-level, planet-scale types of things, maybe they're setting themselves up accordingly. Same with Algolia and those types of tools. They may be bigger teams but still don't have a search expert or a DevOps infrastructure expert.
Are there APIs that you insist on using when you build on the Jamstack, or are you more open-ended?
I think we're pretty open-ended. We don't really use that many external infrastructure APIs. The thing we do use is transcription. I love AssemblyAI, just to toot their horn. I don't want to manage keeping a machine learning model up to date, knowing what the best practices are around rendering certain pronouns or numbers or whatnot, or keeping a dictionary of company names and handling that in different languages and accents. If I can pay something to do that, then, boom, I'm going to do that. And if it's cheap and good and dependable and fast, that’s even more reason why.
Video coding -- Mux is a great example. I think as a product offering, they want to have broader appeal for, say, user-generated content companies. Their money comes from enterprise video and enterprise organizations, so our use case maybe doesn't fit their business model, but they want to expand in that direction. As a result of wanting to expand, their product offers opportunities that work within our space.
There are things that are easier to not have to set up, but then, if you avoid setting them up, at some point you'll have to set them up because the cost will get too expensive. And there are other things where you can avoid ever setting them up. You can always pay somebody forever, and that's going to be okay. Because you’re in the sweet spot in where you fit into the way that the external service makes their money, you can get a lot of value and not hit their limits or whatever.
AWS is basically the only thing we have to use: GCP, AWS, Heroku, Vercel. But for external API services, I can't think of anything in particular.
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.