I had hoped to attend Jamstack Conf this year in person in London. Of course, as with most events during current times, it's gone fully virtual. That means greater accessibility but a much later start time, so wins and losses on that front. They're also using a platform called HopIn that I've not come across before, so that should be interesting. Initial thoughts are that I'd love to be able to quickly see a schedule whilst watching the live stream, but the chat and interactivity are great.
As has become the norm by now, I'll be live-tweeting (thanks to Noter Live) and recording thoughts on the blog here. I'll endeavour to tie those together before hitting publish. Here we go! 🚀
(The event started with a keynote from Matt Biilmann; it served as an overview of what the Jamstack is and what Netlify are doing right now. It was a great talk but I didn't feel the need to make any notes. Sorry Matt.)
Laurie Voss: State of the Jamstack Survey Results
Starts with some useful disclaimers around data extrapolation and where their results are actually applicable; I appreciate that. Big takeaways are that the Jamstack is beginning to crop up across a lot of industries and a lot of experience levels i.e. we're seeing widespread adoption, despite most developers being relatively new to the tech stack. Neat.
Really interesting look into team communication channels. Unintended, but their results nicely back up stereotypes of who-talks-to-talks-who. Also, love the title "Mushroom of Sadness" 😂
So 36% of developers are using the Jamstack on enterprise-level software. That's interesting. Not sure I agree with the statement that you "don't need performance if you're only serving 10s of users". I'd say there's more emphasis on making a good experience if you literally know your users, as you'll find out directly if the site is poor.
Looks like the survey failed to reach designers, given that UI design is the second hardest factor. In fact, it feels like their survey fits the stereotype of "developers who are worried by anything that isn't code". Not sure that's a good thing.
Satisfaction scores are calculated by the ratio of people who would like to use a tool more divided by the people who want to use it less. Satisfaction != popularity != quality. As you'd guess, Rust gets many 👍 and PHP gets 👎 The big outliers are that 11ty is utterly loved by a very small userbase whilst Svelte looks like it's coming up in the world. Also a lot of support for Figma, which is great given the general dislike of designing.
People want to ship quickly and Jamstack provides the tools that help them do that.
Harper Reed & Frances Berriman: A Fireside Chat
(I didn't really know what to expect from a "fireside chat" going in. I really enjoyed it, but then the topic of discussion was right up my street and both Harper and Frances were great speakers. FYI quotes are all Harper 🔥)
Harper ran the Obama campaign's tech team. Love his point that you don't get technical support structures when working in politics, you just get budget restrictions. So how do you scale a platform without money? How do you cut back tech needs? Static resources go a long way. But they still needed to make the system consistent across uses, so templating made sense, hence the static rendering.
Politics gives you a clear metric for benchmarking: fundraising and donations. Getting more donations? Things are going well. Getting less? You need to change, now. Static pages turned out to be fast:
It was so fast. Fast to iterate, fast to build, fast to get things done. Fast for the user, too.
Interesting that Harper feels like the increase in tooling options has been a double-edged sword. It's solved some issues that they had and given you great templating languages, ecosystems, and abstractions. But it's also pushed a lot of additional problems down the line and made the barrier to entry much greater. Harper is joking when he says this, but it's also clearly a consideration:
Back in my day, JavaScript was hard, but not this hard!
Frances makes a great point that the web should be equitable and that the build process in terms of Jamstack helps with that goal because it moves a lot of the complexity and leading-edge stuff to the build and that means you can make the output work anywhere.
I don't like building things for just one group of people. I think that's boring!
Server-side rendering makes total sense. Agree with Frances that the client-side shift we're just starting to leave behind was (hopefully) a blip that caused more problems than it solved, even if it did advance the web.
Efficacy is measured in both directions: are the developers able to be productive; are the users able to use it?
Innovation is another word for experimenting, but when you're experimenting with people's government services then that experiment gets murky and messy. You don't want to do that.
Frances agreed and made the valid point that innovation should be considered more of a bad word in technology.
Lightning Launches
David Calavera: Netlify
Given that they already opened the conference with some more information on Netlify Plugins I wasn't sure what they would launch here? Turns out it was related to plugins, but for the specific usecase that's interesting to me: redirects!
The idea behind their new "edge handler" feature is to redesign redirects, letting you run small functions at the edge. An example we went through was getting highly specific localisation information and updating the client as a result. Neat and gives you a lot more options for using redirects with variables and all manner of other things.
Renaud Bressand: Prismic
I've followed Prismic from the shadows for a while, as they always looked like a more interesting take on the CMS-as-a-Service model. Interesting to see that they're very heavily investing in crafting a CMS that works with a component model. Basically, they provide a specific component library that you can import into projects and then a helper function ties it all neatly back together during build, so the text and (to a degree) the layout lives in your CMS. Nice idea, can definitely see some powerful use cases, but it still feels a little clunky (having to manually move IDs around, multi-step page creation etc.).
However, the ease of which Renaud then added an entirely bespoke component to Prismic was neat. One line in the CLI, a little bit of markup, and some Git pushes and voila you have a very flexible templating system. Cool and reminds me a lot of old templating engine CMSs but being headless and therefore fully decoupled (though at this point how decoupled are you really??)
Tom Preston-Werner: RedwoodJS
Okay, extremely cool. I've heard a little bit about RedwoodJS but not really dug into it. It's a full-stack Jamstack framework, which almost feels paradoxical. It runs a React frontend and a GraphQL backend all in one place, with a Prisma database. That means you can package the whole lot into a lambda function and therefore host a fully functioning app on serverless platforms, like Netlify.
Tom demoed a to-do list app with a database using their "cell" component pattern. He set up a dynamic page, with a GraphQL schema that queries the database and returns a given value, with failure and loading states, in almost no time at all. Part of that is some clever CLI generators for creating pages, cells, components etc. Impressive.
Erin Kissane: The COVID Tracking Project – 0 to 2M API Requests in 3 Months
It's the big one! Erin's work on the COVID Tracking Project has been fascinating to vicariously watch and I was really excited to see her. As she puts it, the lack of transparency around testing and the quality of the data being shared in the US has been a major public health failure. The result for her has been to become part of a small team that actively sought to fill that gap, which is heartening; they chose to do so with the Jamstack, and that worked out well, which has been exciting. But, ultimately, the main story is (to quote Erin) a big bummer and there's no way to get around that.
The CDC removed test data on February 29th – that's so early! So Robinson Meyer and Alexis Madrigal (journalists) decided to try and get to the bottom of what that data actually was. They manually went through State-level government websites and literally copied the information they could find into a Google Sheet. Through that, they met Jeff Hammerbacher and, together, continued to update that sheet with whatever data they could find.
So why not a scraper? They had a fleet of them at the start, but the data kept changing, the formats were all different between States, and you needed humans to understand what was useful and what wasn't. Basically, automation would have taken more maintenance than just manually doing the work.
They then began looking at how to make the data accessible, which meant a website. Erin realised early that the website needed to scale, so reached out to Ethan Marcotte and Matt Marquis. Matt threw together a Netlify deploy and they wound up working on the Jamstack. It was fast to deploy and could scale with their needs; it fit.
Of course, they never intended to keep the project running this long, but the CDC continued (continues!) to refuse to publish actual government data, so on they went:
We considered ourselves to be a public data rescue project.
More volunteers began to come forward to fill in the public health data gap. As traction continued to build and journalists continued to use them, they realised that they needed to become a better version of themselves. The redesign was built in Gatsby, content is served from Contentful, and they stuck with Netlify for deployment. Data is still piped through from Google Sheets via their API – that's incredible.
The "extraordinary thing" to Erin was that being given a shoutout by the White House saw their traffic skyrocket, but they remained online and within cost (though she points out that Netlify have covered their hosting costs entirely). It was also as accessible and fast as possible, which the static nature of the Jamstack has really helped with.
She closed on a sombre but utterly valid point:
This work should not have been done by volunteers. It is a failure by the government agencies responsible that it had to be done in this way.
👏👏👏
Q&A
How are they dealing with real-time updates? They aren't. The project's focus is on accuracy. Real-time trackers can't deal with the way States move the data around or change the logic behind the numbers in a meaningful way and can, therefore, lead to misleading information in the short-term until a fix is live. They want the data to be consistent. Errors may still be made, but they are able to catch those quickly and be as transparent as possible about it. They are aware of human errors, but they have double checks on every step.
What would the team change? Nothing really in terms of technical features. They have held back the site to be as barebones as possible so that the focus is on the numbers. The API is the main pull here, so the big changes would all be in making more data available through that, but that relies on more data being released in the first place.
Gatsby has been super solid for us.
🦅 Tweet Threads (Noter appears to have split the thread, not sure why)
Christian Nwamba: Jamstack for Emerging Markets
If it works in Africa, it works everywhere.
In Nigeria, most people access the web through their phone. They do so by buying prepaid SIM cards; the most common is a 15GB a month data limit. When you consider that 15GB a month costs $15 it sounds okay; when you know that 75% of graduates only earn $120 a month, that is a huge percentage of their income. Internet access is a luxury. It's a huge privilege.
Top phones in Africa may include the iPhone, but it also includes brands and makes you will likely never have heard of, like the Gionee P5. These phones can be half the speed of the standard developer's mobile, with massively reduced RAM, so testing on your own device is not enough. Battery is also more important in a country where power cuts are common and your house may not even have grid energy (or energy at all), so sites need to reduce battery use as much as possible.
Websites should be built to be global, because you never know when you're going to be forced down that route. Stack Overflow is the 25th most visited website in Nigeria; the top 20 includes a lot of household US companies like Amazon, Netflix, Google, Facebook, and Instagram. None of these are well optimised for the internet in Africa. Worse still, a lot of African companies (banks, news agencies etc.) use Western code and tools. If those are already slow, then even local websites are slow too.
That's why some of the biggest success stories in Africa use SMS and other "older" technologies that don't rely on the web. Something's wrong there. Well, the Jamstack can help. By building in layers and only sending what's absolutely necessary to the client you can massively increase web performance. Serverless functions enable you to still use dynamic APIs in the background.
No matter what optimisation you make, no matter how small it is, it truly goes a long way to making someone in an emerging market's life better.
Lightning Talks
Jamie Bradley: Managing diabetes with Jamstack
Jamie suffers from Type 1 diabetes, which means he has a monitor on him at all times to keep a reading of glucose levels which then communicates with an insulin release device via Bluetooth. That data can help improve treatment results but the devices are costly, so if you only have access to more basic diabetes treatments (like injection pens) you need to get that data manually using logbooks and personal record keeping.
Jamie wanted to make a technical solution for those who don't have his level of treatment. That needs to be global, secure, accessible, fast, and easy to deploy and host. The solution he came up with was a combination of Sanity, Gatsby, Netlify, and GitHub. The Jamstack is fast, static sites are global, Netlify and GitHub have relatively low barriers for entry and mean you can distribute it using a package manager like Yarn or npm. The app is called HeySugar and it looks great.
Jan van Hellemond: Selling tickets without servers, or frameworks, or cookies
Jan works for an events company, which means managing conference tickets. Their biggest conference, Frontier, was very popular but would sell out quickly and the backend frequently fell over due to demand. It also frequently oversold tickets. So they built a new one, on the Jamstack.
The whole project was built to be as simple as possible. It used Gulp and Nunjucks, so is a fairly old-school stack but allowed for templating etc. Combined with webhooks and a pre-rendered database, they could build a very simple, lean app that did the job well.
A big benefit of the Jamstack is that you can deploy to production at any time, including during peak load. There's nothing that will break in that instance. The worst case is that the build fails and the user never knows.
Ana Rossetto: The business side of the Jamstack
Jamstack technologies are new, so senior stakeholders can have reservations. You need to approach the subject by explaining that step one is picking the right tool. Then explain why Jamstack tech fits their needs. The Jamstack has a wide number of advantages, including security, performance, lower hosting costs, reduced iteration times, and overall flexibility.
Ana's case study is yet another instance of combining Google Sheets API with Gatsby. Really didn't expect to see that today, let alone twice.
Jason Lengstorf: Getting the Most Out of Gatsby (Round Table)
When should you use Gatsby? When you want to use ReactJS and be as performance-conscious as possible.
How can you speed up build times? Don't forget that image compression takes more time the larger the image, so pre-compressing images is still very beneficial. You can also enable parallel tasks, though it takes some setup. Better yet, try out Gatsby build caches/incremental builds. Also, if you're using API requests, don't use await requests unless you absolutely need to; if you can group together using Promise.all().
A/B testing and analytics? Plenty of options for analytics. Fathom and Netlify both offer analytics. The big thing with A/B testing is that you need a huge amount of traffic before the results are meaningful. That doesn't mean don't do it (or that you can't), just that it probably isn't a relevant worry for most sites.
Visual testing? The tool Applitools is great for visual diffing and now has a Netlify plugin. Forces you to visually confirm visual changes to a site, literally page-by-page. Not great for all sites, but where it's super important very powerful.
All other tests? Cypress is great and there's a Netlify plugin for that now too. Just released a video on how to use Cypress for end-to-end testing.
---
Overall, what a fun day. Lots of interesting ideas thrown around and some really great talks. Erin's stood out in terms of how historic her team's efforts have been, but I also really enjoyed Harper and Frances's "fireside chat". Otherwise, I think I was most excited by the RedwoodJS demo in terms of actual tech showcased, which I would not have predicted at the start of the day.
As a conference, there were pros and cons. I would have probably preferred just a little bit more content on technical topics, either in terms of what you can really do with Netlify or seeing people build something specific. A talk like Kent C. Dodds from React Summit springs to mind as the kind of topic which would have been great to see. I understand that a lot of that is covered by workshops, round tables, and other breakout sessions, but for us free users (👋) it felt a little missing. Then again, it was all free, so I probably don't have a leg to stand on.
In terms of the platform choice, I felt like HopIn did a really great job of making you feel connected to other people. The chat worked a lot better than things like Twitter streams do and whilst I didn't make use of the networking "Chatroulette" feature it's a neat idea. I also really liked the way it let you effectively split tracks, but I did find the split rooms for Q&As after the main talk just a bit strange and had me hopping back-and-forth (and also meant I missed the start of one talk by accident). As I mentioned at the top, I'd also love a way to quickly reference a schedule directly from HopIn.
Finally, once again I'd really like conference websites to include contact information for speakers, particularly websites and Twitter links so I can follow them (and make mentioning people in tweet threads easier) 🤔
