Building on the Jamstack opens doors for lightweight, performant websites — and performance is accessibility! Join us as Salma Alam-Naylor (whitep4nth3r around the web) shows us how the Jamstack empowers web developers to pick the right tool for the job.
More From Salma
- Follow Salma on Twitter
- Watch Salma's streams on Twitch
- Watch Salma's videos on YouTube
- The Claw team
- Join The Claw's Discord server
[00:00:00] Ben: Ooh! Oh, there was a bit of a lag there. Howdy, howdy y'all! Happy Tuesday! Uh… happy Some Antics day, I guess… we are back! Some Antics, for those who don't know, is a weekly show about web accessibility and great user experiences. And today I'm joined by Salma, better known as whitep4nth3r. Salma, hello, welcome to the stream!
[00:00:25] Salma: Howdy, howdy everyone! Howdy… stream-goers! How you doing? I hope we all doing very well. It's Tuesday…. it's… the weather is good here. Actually, you didn't ask that, but I'm gonna tell you. And, uh… life is busy.
[00:00:42] Ben: I, for… I really need to spend more time outside 'cause I don't even really know. Like, I think the weather's good. Actually, Texas weather has been blazing hot as of late. I went to renaissance fair this weekend…
[00:00:55] Salma: oH!
[00:00:56] Ben: … and tons of fun, tons of fun. Blazing hot though. I… a few of my fellow party-goers had to leave early because excess heat being outside too long - no good. Don't recommend… ren' fair - recommend. Texas heat - don't recommend.
[00:01:14] Salma: My colleague Brittney at Netlify actually went to… a similar kind of thing in Michigan… holland, Michigan. They have this like "Dutch fair" with tulips and cloths and Dutch clothes, but also blazing hot. Could not recommend the weather, but could recommend the event. Same thing.
[00:01:34] Ben: Mm-hmm. Um… yeah! So I'm super, super thrilled to have you on… for those who haven't had the chance to meet you, would you like to give yourself an introduction?
[00:01:44] Salma: Yes! My name's Salma, you may know me as whitep4nth3r. Here's me in the chat, right there. I also stream on Twitch. I've been streaming on Twitch for almost two years now, but in the day, in my day job, I'm a staff developer experience engineer at Netlify.
And if you don't know what that means and developer relations and developer advocacy. Basically my job is to be in between the… the middle point between the people who make the product and the people who use the product and to advocate for developers, being able to use the platform as easily and as seamlessly and as enjoyably as possible.
And I get to make cool stuff, get to make cool demos, get to do conferences, get to do all sorts of things like this. And in the past I was a teacher, I was a music teacher. And what I like about this job is that I get to combine my experience of teaching with my experience of tech and put them together and have a good time, basically. That's me.
[00:02:50] Ben: That was good. Yeah, and we're here to talk about the Jamstack. Um… and so maybe the best place to start is kind of the big question to, to set the stage: What is the Jamstack?
[00:03:04] Salma: Okay, this is… this could go on a long tangent, could go on a long, long road, but… the Jamstack has been around as a concept for seven years now. It kind of started emerging with Netlify in 2015. And here's the TL;DR: I'm gonna read out my blog post, right? 'Cause… so I can avoid saying anything nonsensical.
Jamstack is an architectural model centered on serving pre-generated, highly portable static assets, and we'll get to what that means in a minute, from web development platforms, usually via a content delivery network, which is also shortened to CDN. And we can talk about what a CDN is later, if you want.
And, um… so that's it. It's about serving static stuff from a content delivery network… cache that's… and that static stuff is cached in the content delivery network around that Jamstack concept… it can be elevated and enhanced by a wide variety of modern, adjacent development tooling, which I call Jamstack-adjacent technology.
And these are things like serverless functions, edge functions, content management systems, version control integration, API services, software-as-a-services, all the other good fun stuff that can help you, like, bring together different services to make your website or products. So at the core of Jamstack, is that Jamstack isn't about tools or frameworks or services or anything.
It's a way of working and… it's defined by how you build websites rather than the tools with which you choose to build them. And… the reason why it came about, which I think we'll get to this later, is to solve a few of the problems that existed in the webspace in the 2010s and early two thousands.
[00:05:00] Ben: And… and by problems with web development, like, what do you mean? Like, what is Jamstack trying to address there?
[00:05:06] Salma: Okay. So… traditionally… in a traditional kind of web development model, requests for webpages are processed by a managed server. And what that does is… so a managed server receives a request for a webpage from a user, from a browser.
And then in real time, the HTML document is built and bundled up and then sent back to the user's browser. So there's that whole kind of journey of request build, serve, I call it. And then if your webpage is big and complex, if there's a lot of logic in the backend, if there's lots of different jobs that your server needs to do in order to build that HTML…
and if the page request was far away from the origin server, this meant the websites could be really slow… and, resulting in a bad experience for the end user. Because we know as more and more people use the web for everything… a fast experience is key to making sure your websites are… usable, people return to them, you make sales, you grow your business and people can get your information.
So there's the problem of requests being far away and requests taking too long because everything has to be built and bundled up in real time on the server. So Jamstack solved that problem in two ways. Firstly, because Jamstack centers on serving static assets, it means that in order for your static asset to be cached and served from the CDN, it needs to be pre-generated and bundled up at build time, not request time.
So this means, with Jamstack, a server doesn't need to build anything when there's a request sent to the browser. It's um… it's just served. When you get a request it's served from the CDN. And so already it's a bit faster because you are serving a static asset that's ready to serve. But secondly, this whole concept of a CDN… a CDN is a network of distributed servers around the world, in what we call like an edge network.
And they… those network nodes work together to serve the cached content to the user from the closest server location possible. So it's a lot faster, cached content that's pre-generated is being served closer to the user. So that's the first thing… that the problem of slow websites that were generated in real time are now faster because they're served from an edge network and they're pre-generated. No extra work needs to be done.
Another problem that Jamstack was solving is the… the pain of developing on a huge monolithic fullstack tech stack. So before Jamstack, most websites were built using that like an entire full stack framework. It comprises backend server code, frontend templates, databases, everything all in one.
And I'm sure you've… some of you out in the audience have worked like this before. I definitely have, and new product features can take weeks to build, test and release to production. Software upgrades can be risky and difficult to roll back. And also your development environments are really, really difficult to provision.
You need to make sure you've got a database, a mock database from kind of obfuscated data. You need to make sure that you've probably got a number of virtual machines running the whole thing because your computer can't handle it or things like that. I've been there, I've done it. Vagrant and VirtualBox, etc.
And so the way Jamstack solved this problem was that it shifted to a decoupled architecture, which meant that the backend API services, frontend templates, database, and all the other little bits and pieces that you use to make a fully functioning website are separated and streamlined, which meant that developers of different disciplines can develop in parallel, release their own code and go faster. I remember back in the day when I was working at a place that had one of these big monolithic tech stacks, it took six hours once to release two lines of CSS that fixed a bug. And no one wants that anymore. So this whole decoupled thing, Jamstack really, really mainly focuses on the frontend.
All of your pre-generated HTML documents and static assets, Jamstack is kind of centered on that frontend, serve a website, serve HTML documents to the browser. So the thing with Jamstack is that your sites may or may not speak to any number of API services at build time or on the client. But you know, during that build process, Jamstack sites can call out to those APIs to fetch that data to your CMSs or to wherever to fetch that data and already… and build your pages based on that data, cache it, store it, and send it out via a CDN.
And once a Jamstack site is built, it's cached as an immutable deployer. And what that means is that it's saved in that state. So every time you deploy, a whole new bundle of your whole website is created. Not separate different pages that you might change, but your whole website, which means that Jamstack… you can roll back and forward really quickly with no hassle compared to, if you wanted to roll back a big monolithic server, big monolithic application.
I remember, um… I had to… when I was releasing this big monohitic… monothitic… mO-NO-LITHIC application, I had to canary to different servers manually. I had to say: "Right, let's release to that server. Let's release to that server…". And it took hours, and it was scary and painful as a frontend developer.
So Jamstack just takes care of all of that for you with immutable deploys. And what's more, a breaking backend change will not affect your Jamstack site until the next time it's rebuilt. So Jamstack sites are less buggy, more stable, easier to release and roll back and deploy, and you have full ownership of the code.
I have gone on a huge tangent.
[00:11:16] Ben: No, you're great! I… that… that point about like the… like the API and the server, the fact that rolling back is hard. Like, I've definitely — like, that resonates. At my previous role, we had… I was on the frontend team and then we had, like, a sister team that was doing our API stuff.
And once or twice, the API contract had to change in a way that was gonna be a breaking change. And that meant that both the frontend team and the backend team had to just basically, like, hold hands and promise to jump at the right time. And god forbid, there were any bugs…
[00:11:53] Salma: I've been there, yes, I've been there.
[00:11:56] Ben: Yeah, such a… such a pain point. To have a site that's gonna stay up and be alive and be… you know, totally operational, even as the backend that powers its builds changes. That's huge, that's incredible.
[00:12:13] Salma: And there's one more thing that the Jamstack did to solve even more problems. It's… I was just talking to you about how, um… when I was releasing this huge monolithic application, I had to canary to different servers and you know, the servers were on premise, and… there was a specific dedicated DevOps, IT operations team to manage those servers, to manage things like security upgrades, and DNS, and then scaling the availability of those servers when traffic increased…
[00:12:49] Ben: mm-hmm.
[00:12:50] Salma: I remember 'cause it was an eCommerce place, so whenever there was Black Friday or Christmas, they had to do all of these load tests to make sure that the systems and the servers were scaled correctly to accommodate the extra requests.
But with Jamstack, that's all taken care of for you. Your web development platform like Netlify automatically scales when it needs to. Yes, you'll have to pay a little bit more for it, but you don't even need to worry about anything. Plus, you get HTTPS certificates, SSL for free as well, automatically.
And you can even get a site online without buying a domain… with platforms like Netlify. So it made websites faster, developers faster and more happy, and scaling less complicated. And that is the absolute concept…. we've got a raid. WHOA, we've got a huge raid! We've got a HUGE raid! What?!
[00:13:43] Ben: Welcome. Welcome Lana_Lux and friends… sorry, both of us being streamers here. Like I was like waiting for the moment when I could be like: "Ah, yes. Thank you for the… thank you so much for the raid, Lana, it's hugely appreciated. Welcome everyone!
[00:13:55] Salma: Welcome!
[00:13:56] Ben: Salma, do you mind if I give a quick Some Antics pitch before we hop back into Jamstack?
[00:13:59] Salma: Go ahead! You… go ahead!
[00:14:01] Ben: So, Some Antics is a weekly show here: twitch.tv/SomeAnticsDev, where every week I bring on guests from around web development and web design to teach me something about building great user experiences for the web, typically in a hands on way, and typically with a focus on accessibility and/or core web technologies.
Today, we have the one and only whitep4nth3r here to talk about the Jamstack. And we're so, so glad y'all are here. Thank you all for coming through. So…
[00:14:30] Salma: wow! Didn't expect it, let's go! Here I am talking about the Jamstack to all these people. Um… what were we talking about?
[00:14:36] Ben: We were, I mean, just in general, talking about the complexity of like running servers for all this kind of stuff and like, you know, having security policies and, and whatnot. And God forbid the server just go down in general, right?
Because that, that happens. Servers go down and now your frontend is broken because it's actively like calling out to an API that is down, you know? And so now… you know, maybe your frontend was expecting to get a request back, it didn't get back. And maybe if you haven't done your proper error handling, the whole page falls apart, right?
Like every domino in the chain just falls over. If, uh… you know, if you haven't properly handled the API foot guns.
[00:15:20] Salma: Exactly. And, so a lot of people think that Jamstack is a set of tools, a set of frontend frameworks, or a set of APIs and serverless functions. But I wanted to kind of… baseline reiterate that Jamstack is the way you work. Jamstack can use any tools or any services, as long as the core part of what you are building centers on… r.I.P servers, you will be missed… as long as the core part of what you're building centers on serving pre-generated static stuff from a CDN, then you're good to go.
[00:16:45] Ben: Mm-hmm.
[00:16:45] Salma: Jamstack sites don't necessarily need to use jams… "Jamstack."
So it's not a prerequisite. "Mstack," "Markup stack." As long as it's no-managed-service stack, then we're fine. [laughs]
[00:17:37] Ben: But it does seem like in at least the past year or so there have been some aspects of kind of the Jamstack ecosystem that have moved back towards doing some things on a server, or specifically in a serverless way, right?
[00:17:56] Salma: This is what I refer to as Jamstack-adjacent technologies.
[00:18:00] Ben: Okay.
[00:18:00] Salma: Because [clears throat] I think serverless functions and things like that get bundled in with Jamstack because they are services provided by web development platforms, right? So, you know, Netlify gives you serverless functions, you've got Cloudflare, you've got Vercel, etc. etc. etc.
And, because those platforms are so… closely related and fall in the same kind of web development category as static site generators and serving static files. I think erroneously, serverless functions have been called Jamstack, because they kind of come along with a lot of Jamstack sites, but… the core of that is that it's an architectural way of working.
And so using serverless functions is just a way to call a server when you need to. It's not part of that static site build, is it? So yes, your serverless functions might live in the same code repository, but when they are bundled up, at build time, they are not stored in the same way as static HTML sites.
They are not sent to the browser as cached assets, etc. So it's an adjacent technology, this kind of things. And you know, and now we've got a lot of things like edge functions being released as well, which are serverless functions at the edge. So again, serverless functions, but operating at the closest point to the user, which is kind of like the CDN concept crossed with the serverless functions.
So I got— there's a question from W1ngMatt.
[00:19:43] Ben: Yes!
[00:20:44] Ben: Absolutely. And you've recently been… building and rebuilding some projects in Eleventy as of late, right?
[00:20:51] Salma: Yes! So the biggest project I undertook, because of all this work I was doing around the Jamstack, and because of the kind of the investigations I was doing into it and trying to formulate actually what it was in, in my brain.
So this is the Eleventy site now, right? But if I… can I actually send you a link to my Next.js site? One second…
[00:21:53] Ben: yeah!
[00:21:53] Salma: Which I've still got my… I've still got my own… p4nth3rblog.netlify.app. I've still got my old site on… and you'll notice that if you look at the network tab… you need a 3. You need a 3, not an E. There you go.
[00:22:13] Ben: That l33tspeak though.
[00:22:15] Salma: .netlify.app…
[laughs] That l33tspeak, right.
And… let's see you try to get to the network tab. There you go! If you do another refresh now, you'll see them.
[00:22:56] Ben: Yeah.
[00:22:57] Salma: There you go, right…
[00:22:58] Ben: lots of stuff.
[00:22:59] Salma: So all of that stuff, all of that stuff. And, and also because Next.js is a very clever framework, there's a lot of prefetching being done of other roots cuz of the whole single-page application thing and using NextLink.
[00:23:22] Ben: Yeah. I'm noticing here that like we've got your projects page, your talks, page, your FAQs. These are pages we are not currently on and it's already fetched those.
[laughs] it's all the JS Ben has downloaded.
[00:24:16] Ben: Yeah. My computer is… my computer's on a bit of a struggle bus right now, as it turns out, but…
[00:24:24] Salma: too many Panthers on it.
[00:24:26] Ben: That's gotta be it too… too many panthers… we gotta stop with the panther, Salma. Just too many of them. Okay, this is not, actually this, this is my extension that I've got.
[00:24:39] Salma: Yeah, I've got the same thing. So there's just time_elements.js… my CSS file an SVG and whitep4nth3r.com with the HTML document and a favicon and that's it, right.
I, when I first embarked upon this project… I wanted to find the Eleventy way of doing things, because I was so used to the Next.js way of doing things. And actually, there isn't an Eleventy way of doing things. You can do whatever you want with Eleventy as long as it builds, which results in that collection of HTML files in the output folder.
And so what I found when I pivoted to Eleventy, was that: yes, I massively improved the website performance by some ridiculous data points. But I also got back control of what I was shipping to the user and to the browser, which meant that I had more trust in what I was shipping, which meant things were debugged easier, which meant the page weight was so much lighter.
Like for example, here's a bit of a data point for you. Um… the… network requests were reduced from 75 network requests, totalling four megabytes on the Next.js site on the homepage. And then the Eleventy site just makes nine network requests, totaling just 325 kilobytes. And those are purposeful kilobytes that I chose to send to the user.
It also greatly improved my Lighthouse performance scores, no matter what I did with my Next.js site, I couldn't get the performance up on some of the blog posts mainly because one of the… one of the issues that Google Lighthouse was highlighting to me was deep within the Next.js code.
And yes, Next.js is a wonderful tool for big team projects, for big, big products, right? But there's whitep4nth3r.com, it's just a blog site. It's just getting a bit of data from my CMS. Just displaying a bit of stuff about me. I didn't need it to be this like enterprise grade framework that gave me so many different options that Next.js gives you for, you know, incremental static regeneration, which kind of breaks the whole Jamstack static model, even though it's really brilliant and powerful.
You know, I didn't need server side props with Next. I didn't need to server side render anything. I just needed to just… throw out some HTML files on a server, on a CDN and be done with it, right?
[00:28:16] Ben: Mm-hmm.
[00:28:16] Salma: And so this is the whole point of… of this stream is about picking the right tool for the job. I think some of us… it's great to experiment, right? And, as anyone who knows me, I will always encourage you to build stuff, to learn things. But, so I built, those are stuff with Next.js. And I learned that actually, it's not always good to reach for straight away, because you don't necessarily need it.
And so now what I… I mean, also I've always tried to install as few dependencies as possible to, you know, when, when I'm building something on stream and someone says: "Oh, you get a package off NPM for that". I prefer not to, because I don't want the burden of that package that needs to be maintained and updated and upgraded.
And so, the less you use, the more power you have to being total control of what you are choosing to ship to the browser…
[00:29:14] Ben: mm-hmm.
[00:29:15] Salma: … and I think, we'll get onto this later, but it makes it absolutely imperative to performance and accessibility as well. Not just end user accessibility, but developer accessibility as well.
[00:29:53] Ben: Prince! Yes, Prince is in the house! Good to see you, Prince, always love having you here… yeah, and like…
[00:30:00] Salma: and sorry, I just wanna, I just wanna comment on what W1ngMatt said. The freedom Eleventy provides, made it super confusing for me at first. Me too! I was like, what's the Eleventy way of doing it? How do I do this in Eleventy?
And it's just like: "Salma, do whatever you want". And the freedom and the control…
[00:30:16] Ben: mm-hmm.
[00:30:17] Salma: … is actually really… it helps you… people say this about Eleventy, but it's true. It helps you become a better developer, but not because it's a framework that's the next big thing. It's because at the core of Eleventy is just web standards, shipping HTML, staying honest, staying humble and staying cool.
[00:30:39] Ben: So, I'm… big fan of Eleventy over here. But you know, Eleventy isn't, you know, the entirety of what the Jamstack is. Like when you're building a site, how do you know kind of what tools are going to fit for that site? You know, Eleventy is not a fit for every site out there. So how, how do you handle that evaluation?
[00:31:02] Salma: Great question! Now, the thing with the Jamstack is that you don't have to make all of your decisions straight away. And I know Stephanie Eckles says this… all the time, and so I'm kind of paraphrasing Steph. You can start as small as you need to on the Jamstack. If you… want to just start your proof of concept or your new blog site with a single HTML page on the Jamstack, you can push it up to Netlify or wherever, and it will be there.
You can start. The smallest point possible and expand as you go. So for example, with, with a monolithic tech stack of yesteryear, you couldn't start all over again. If you'd made the wrong framework choice, it would be a huge, huge, huge undertaking to rewrite everything from scratch. But because Jamstack is decoupled, you could start with maybe a selection of three tools, this CMS, or that database, or that authentication service.
And if one of those isn't working for you, just switch one out for the other. You don't have to switch out everything. And so… again, the answer is always: it depends. How do you know which tools to use? You try, and if it doesn't work, you try another one. And the good thing is that it's easy to switch it out and try another one over and over again because of the decoupled architecture.
[00:32:55] Ben: And I think that really ties to what you were talking about with like the developer ergonomics and developer accessibility. Like, we've all been in like the situations where like you have to use a very specific conglomeration of tooling, because for whatever reason, that's just the stack. And if those tools are quite nice to each other, you know, like, yeah, it's… it's a painful experience. It's miserable, right? And so to be able to just like, kind of swap things out and make some matches, hugely, hugely enabling.
[00:33:28] Salma: Absolutely, absolutely! And you know, it… you've probably, all of you in this chat have been there where you have gone to a new job, or you have inherited something where the tech stack was so intertwined with each other.
And even if, as a good developer, you wanna make progress. You wanna push forward, you wanna pitch something new that's a bit more modern and innovative, there's just no time or budget to switch. So you have to live with these old, old rickety things that you can't move from. And developers, you know, developers don't like that. You know, the developers I've worked with, they wanna try new things, they wanna move forward, they wanna break free.
And especially like you said before, backend the frontend, developers don't necessarily want to hold hands with each other all the time, because they want to be able to move faster and move independently without breaking things so much. So the… this kind of, it's a decoupled… the way of working the decoupled architecture, I have had such better times with than the older way of working.
[00:34:31] Ben: Mm-hmm. You touched on briefly, and I'd love to just like, kind of revisit… you touched on briefly the intersection between performance and accessibility, and a lot… like, oftentimes on your streams and in podcasts appearances you've been on, you've mentioned that, in your mind, performance is accessibility. Would you talk about what that means for you?
Chances are that, that content's not gonna get to that device in any kind of timely manner, therefore that person will not be able to access that content. And I talk about this in a talk that I wrote last year and did a couple of times, which was called "How to prevent the collapse of society by building an accessible web".
And the premise around this is that we are living in a zombie apocalypse. All monitors and screens are broken, and the internet is slow 3G. But everyone needs to be able to get content to their ears, or wherever in order to learn how to fight the zombies and save their lives. They need to get life-saving information over a slow internet on a screen that you can't really see.
And so yes, there's the whole kind of assistive technology undertones to that. But also, I've tried to put people in the shoes of everyone needs accessibility. Everyone needs to get that content in order to save each other's lives and survive the zombie apocalypse.
So if you can't get content quickly, you are doing your user a disservice, because somebody might need to get life saving information at any one time, right? And if your website, if your… if your website that tells you how to save someone's life, when you notice someone on the street in a particular way, right?
If your website takes 10 seconds to load, that's 10 seconds that you could be saving that person's life on the street, and that's accessibility, that's access to content, it's access to knowledge and access to potentially… it's… it's a dire, dark use-case, but it's access to saving lives. Really, if you think about it like that.
And so that's why performance is accessibility because the faster your sites are, the more performant your sites are, the easier your sites are to use and load by your device. The more accessible your content is, and you know, if we're talking about capitalism, the more sales you'll make, the faster you'll grow etc.
[00:37:44] Ben: Absolutely. So, in that vein, like, what are… jamstack sites… or I guess what can Jamstack tooling and the ecosystem… like what can we do to better enable that going forward?
[00:38:00] Salma: This is a tricky question, because there are a myriad frameworks out there, and we've already touched on Next.js, which is a great framework that gives you a lot, right? A lot for free and open source… but because frameworks are gen… are often so intertwined with the services that come along with them. Sometimes it's not really in, I haven't seen, I don't wanna sound political in this, but it looks like, and a lot of the time, these frameworks… in the framework's remit is not accessibility-first and performance-first. I mean, there's a lot that say they're performance-first, right? I haven't made enough investigations to kind of rank them or anything, but we know as… like, I don't wanna call out Next.js here, but… and I know there's a reason for this, but for example… when you do Create Next App, there is no HTML "lang" attribute on the
<html> tag, which you need for accessibility, right? So it's within the developer's own space to create that custom document JS file that goes in the repo in the pages folder to bootstrap that
<html> tag with the "lang" attribute on. So… the bottom line that I wanna get across here is that I don't think frameworks can solve that problem of performance to accessibility, accessibility to performance.
And it's a big shame because if they could…
[00:39:42] Ben: Mm-hmm.
[00:39:43] Salma: …then wouldn't that make the web a better place for everybody else? Unfortunately, during my web travels and everything that I've done… I think it falls on developers to really evangelize for that if for one of a better word and advocate for that and educate themselves on how best that fits in their context.
And, um… it's a shame. But it's a bit like how I'm sure developers are out there, right? You've been in development teams and you are building a website for a client and you say, oh, but we need to do XYZ in order to make this accessible for ABC. And then a product manager or leadership says: "Sorry, not in budget. We can't do that, we just need to ship, ship, ship".
And so you see, like, developers feel like the underdogs in that situation, because I know so many developers I've worked with them who are committed to creating these 100% accessible experiences as far as they can, but there's no budget, there's no time. And I feel like that's kind of mirrored in the frontend framework space as well. I wonder if there could one day be an accessibility-first framework.
[00:41:52] Ben: Absolutely. And I think as you were describing, you know, even things like Next.js, not by default, including the "lang" attribute, it seems to me like, at least what I'm hearing is that… it would be nice if these frameworks could provide more sensible defaults. Like, one of my favorite metaphors is the one of the pit of success…. and just like, make it really easy to do the right thing even by accident….
[00:42:19] Salma: [whispering] Yes!
[00:42:20] Ben: …. but it also doesn't seem like you're necessarily bought into the notion that a framework can always guarantee the pit of success.
Frameworks and automated tools cannot do that. Not even AI can really do that, right? And I think, so that's probably like by design! If…
It's absolutely more than screen readers. It's more than color contrast. It's more than performance. It's a combination of everything that I think only humans can solve. And… if frameworks did claim to solve all of those accessibility problems, people would get lazy. Developers would get lazy and, you know, there are… there are a variety of different conditions and disabilities and, and stuff that are changing all the time.
And Your Customer Base Is Changing All the Time. and So to Automate That and Be Lazy and Think: "It's taken care of, I've done it, it's accessible, boss, done it". It's… it takes the human element away and we have to stay human with accessibility, because we are making things accessible for humans.
[00:44:43] Ben: I love that so much. That… I was enraptured the whole time, that was incredible! Yeah, so… we're getting close-ish to the end. We've got… amazing how time flies by, really, honestly. But one of the things I wanted to ask too is: what is something that you're really excited about over the next year or so in the Jamstack? Like what's, what's got you fired up and excited.
[00:45:13] Salma: It really is just seeing what people can create with as little as possible, because I think we went through a bit of a honeymoon period with frameworks, like in… I mean, frameworks like Next.js I was gonna say, but like, sometimes you forget in this little industry's sphere that we've got that Next.js is still like relatively new.
Some of these frameworks are still very… you know, Remix is very new. SolidJS is very new, all of these things, right? So we forget that not, like, a billion people are using it. But I think in our little Twitter industry sphere, or whatever, um… there's a lot of people who reached for things like Next.js for everything like I did last year.
Yes, let's sober up and… let's see what people can do without it and… and see how powerful HTML can be, because actually HTML, like, is pretty flipping powerful. Like for example, like I released a blog post a, a few weeks ago about creating an HTML-only accordion using the HTML details tag. There are so many HTML tags that I have not yet explored and the power, the native power in them is amazing.
Let's go back to basics. Let's take off the makeup. Let's, just see ourselves what we are and be human about it and embrace the web. That's what I was gonna talk about. I didn't wanna like, um, Shout about Netlify too much in this little Jamstack stream.
But, this is one of the things that Netlify is focusing on with using Deno for edge functions, so rather than Node. So Dino is a runtime, web runtime built on… open standards, right? It's open source
[00:49:05] Ben: Mm-hmm.
But at the same time, at the end of the day, we're all just building things that are gonna be displayed in a browser, and the browser can only do so much. But you can also do so much to ensure that that experience for the people who experience it, are having the best possible experience possible. [laughs] And you could be innovative with that.
[00:49:56] Ben: Mm-hmm.
[00:49:57] Salma: You don't need to use all this fancy stuff. And so I'm looking forward to… like, the positioning of the Jamstack being this architectural model where it's static-first, build-first, make it fast, make it simple… and have fun with it at the same time.
[00:50:13] Ben: Absolutely! That really gets to the end of any of the questions I had.
So I wanted to open this up for the chat. If y'all have any questions for Salma, I would love to see them. I'm sure Salma would be thrilled to answer.
[00:50:27] Salma: Let's go!
[00:50:29] Ben: If you get… we got a comment in here about… astro's approach, um… as well…
[00:50:35] Salma: bholmesdev is here to tell us all about it!
[00:50:39] Ben: Mm-hmm.
[00:50:40] Salma: Yeah, that's also true of Astro as well. No JS by default, so I think there's a lot of… that's the kind of, there's two levels of bandwagon, right? There's the "ship no JS by default, let's make it simple, back to the web," and also "How much can we give you in one framework?" But the problem is like, if you want your framework to be adopted… then you need to provide a wide variety…
that's the kind of mindset. You need to provide a wide variety of functionality for more and more people to be able to use it. And so… that's the thing. It's a hard…, it's a hard balancing act. Do you give the people what they want or do you sta… do you stand firm and say: no, let's just prioritize the web, you know, web standards and helping you build stuff in a better way, you know,
[00:51:39] Ben: Absolutely… not seeing any more questions at the moment. Um… yeah, uh…
[00:51:53] Salma: ben, I wanna ask you a question! I wanna ask you a question!
Yeah, let's do that, let's do that! Yeah!
So, tell me about your experience on the Jamstack. You say you like the Jamstack, but like what's your journey, what's your experience? How have you found it and where do you wanna go from here?
[00:52:06] Ben: Hey, that's a fantastic question. And actually for me, so it, it's interesting to me that you've kind of brought up Next.js, is that the thing that you were working with almost, uh… you know, like, that was what you needed to do for your work, right? And for me, my… journey actually came… it was also from the React ecosystem. My last role was a React-exclusive role. But in my free time, I was building things with Gatsby. I had a little portfolio site that was, you know, it was actually, that was… I had a portfolio and a blog site for whatever reason, I wasn't merging the two, but I had the portfolio that was just shipping, just straight up React.
And then I had a blog site that was using Gatsby, and I found myself like… with, with especially the, the Gatsby site, like struggling against the toolchain, it felt like every few months when I needed to like come back to it and publish a new article, I personally was struggling a lot with… you know, all the dependencies seemed broken all of a sudden, right?
My pipelines weren't passing. That was a struggle I had… and it felt like every time I was adding on to my site, I was, you know, fighting with my own… my own personal hell that I had built for myself. It's like, seemed like, right? And not to diss Gatsby, right? I think that… you know, it definitely has a use-case.
It just wasn't for me and my blog. I just, I really struggled with it. I didn't quite agree with its opinions. But, you know, it seemed like React needed to be the system. I was… I needed to be writing in. It was about then that I discovered Eleventy via Andy Bell's "Learn Eleventy From Scratch" course.
And I think that really set me on, um… it was very freeing for me because… it was, like… a lot of the things that I had been struggling with, the opinions I had clashed with Gatsby on. It was, it was freeing to see that there was a system I could use that didn't need those. One of those opinions that Gatsby has, for instance, is… you will… it, your website needs a single-page application router.
I know Marcy Sutton did a lot of fantastic work in making the Gatsby router as accessible as possible, but I still don't think that single-page application routing is… as accessible as just inter-page, like downloading a new document routing. So that wasn't an opinion I really agreed with. And it was just nice to be able to get like back to those fundamentals as well.
And since then I've been kind of on the Eleventy journey, just trying all the new features, stuff like that. Just seeing kind of what I can do. Not that it's gonna meet every use case, but…
[00:54:54] Salma: exactly! And that's the thing to be mindful of as well, is that I think we can sometimes get into a bit of a pattern like I did last year. "Oh, I need to start a new project, so I'll use Next.js, 'cause I know how to use it," or "I'll use this 'cause I know how to use it." "Oh, I've done this before, so I'll copy and paste my boilerplate and do it again." And while it's actually a little bit more difficult to get started with a new tool, you need to weigh up your options, because not one tool can be the right thing for everything, which is the whole point of this it's that use the right tool for the job. Do some research, ask around, asking the community, try something. And if it's not working out for you, then change it again.
whitep4nth3r.com is actually in its third iteration. I started first with Svelte and Sapper. Then I moved to Next.js and Contentful, and then I moved to Eleventy and Contentful. And so it might change again, if I feel like it. I mean, I really don't wanna do another… another migration again, but… maybe there will be a case for it as the project and my blog develops, right? And that's the thing with the Jamstack. You can pick and choose and switch in and switch out whenever you need
[00:56:09] Ben: Mm-hmm, absolutely! Alright, I'm gonna move on to this one question. Uh… chat?
[00:56:15] Salma: I'll vamp. Let's do a little dance!
[00:56:20] Ben: Yeah, absolutely! In the meantime, would you like to talk about where people can find you and what you… what you're doing?
[00:56:28] Salma: Okay. Yeah, so if you joined in the raid after I introduced myself, my name is Salma and I am a staff developer experience engineer at Netlify. If you wanna know what Netlify is, you can go to netlify.com. If you wanna find out everything about me, you can go to whitep4nth3r.com. And I stream on Twitch. You can find me on Twitch if you just click on my profile or you can… there you go! There's a little shoutout. I am all over the Internet, I write blog posts, I stream, I do podcasts, I create videos. I've also been experimenting with creating silly TikTok. So if TikTok is your bag, go and find me on TikTok, and I am hanging out on a stream near you, building stuff, learning things, and loving what I do.
And I always love getting more people in my Discord as well, 'cause we've got some great, like… um… [singing] Discord, don't you do… got some tech help channels. We've got a great group of people in there who are so welcoming, so warm…
[00:57:40] Ben: mm-hmm.
[00:57:40] Salma: … so inclusive. And if you ever wanna talk about tech or come and post some memes, then welcome in, come on in. That is me!
[00:57:50] Ben: I'm going to heartily endorse both the streams and the Discord… I earnestly wish I could make more of your streams, but unfortunately time zones just means…
[00:58:00] Salma: time zones!
[00:58:00] Ben: Like, you're starting at like four in the morning for me. And, you know, I'm waking up at like eight and you're wrapping up it just doesn't quite line up all the time, but…
[00:58:10] Salma: and you're streaming at bedtime for me, and I'm all shiny and sweaty. [laughs]
[00:58:15] Ben: I'm so sorry. Thank you so much, by the way, for coming on! I really do appreciate it. And y'all please do join the Claw Discord. It is a wonderful place, I've enjoyed every conversation I've had there.
Um… and absolutely just please go follow Salma all the places. Salma, thank you so much for joining the stream and talking about Jamstack today!
[00:58:36] Salma: Thank you so much!
[00:58:38] Ben: I hope you had a great time chat. I hope y'all had a great time. We're actually… so, stick around by the way, we are gonna find someone to raid. But, next week I've got Adrian Roselli coming on. Adrian… first of all, is maybe one of the people whose writings I've been most influenced by accessibility-wise.
He has a series called "Underengineered", where he builds common interface components, like complex interface components, the simplest HTML-first-most approach. And so he's gonna be hopping on, we're gonna be doing some of that. So that's next Tuesday… so follow the channel if you want more of this kind of stuff. And yeah, it's been great having y'all!
[00:59:20] Salma: Thank you, Ben! I've had a great time. You've all been so lovely. It's great that we got a raid. And I loved talking about Jamstack with you. It was… the time flew, so thanks so much for being such a wonderful host!
[00:59:30] Ben: Thank you so much. Y'all, have a good one! Bye!