Storyblok with Facundo Giuliani
Facundo Giuliani discusses his transition from backend developer to developer relations engineer at Storyblok, exploring its visual editor and headless CMS approach.
Episode Description
Facundo Giuliani discusses his transition from backend developer to developer relations engineer at Storyblok, exploring its visual editor and headless CMS approach.
Episode Summary
In this episode, Facundo Giuliani shares his journey from a 15-year career as a backend developer to becoming a developer relations engineer at Storyblok, a headless CMS platform. The conversation begins with a discussion of the nuanced differences between developer relations, developer advocacy, and developer experience roles, before diving into how Facundo's interest in the Jamstack led him to explore headless CMSs and ultimately join Storyblok. The hosts and Facundo then explore Storyblok's standout feature — its real-time visual editor — which lets content editors see exactly how their pages will look while editing, solving a major pain point that other headless CMSs often overlook. Facundo explains how developers can use any framework or language they prefer, from Next.js to ASP.NET, while Storyblok handles content delivery through REST or GraphQL APIs. The discussion also touches on Facundo's Smashing Magazine article about migrating legacy jQuery applications to modern component-based architectures, and wraps up with thoughts on the Jamstack's future, including challenges around static site generation performance and the emergence of full-stack frameworks like RedwoodJS and Blitz.js that are pushing the boundaries of what the Jamstack can be.
Chapters
00:00:00 - Introductions and Developer Relations Roles
The episode opens with light banter about Anthony's new apartment before welcoming Facundo Giuliani, a systems engineer based in Buenos Aires who recently transitioned from nearly 15 years of development work into a developer relations engineer role at Storyblok. Facundo describes how his growing passion for content creation and community engagement during his free time eventually led him to pursue this new career path.
The conversation quickly turns to the terminology surrounding developer-facing roles. Facundo distinguishes between developer relations engineering, which focuses on creating content and being the bridge between developers and a product, and developer experience engineering, which centers on building integrations and tools that developers directly use. Anthony notes that these roles are becoming increasingly common and that fractionation of titles reflects the breadth of skills involved.
00:04:22 - Discovering the Jamstack and Joining Storyblok
Facundo traces his path into the Jamstack world, recalling how his earliest web development experiences involved building static pages with tools like Dreamweaver and FrontPage. Learning about the Jamstack felt like a return to those roots, but with far more powerful modern tooling. His exploration of the ecosystem naturally led him to headless CMSs, which separate content management from front-end presentation.
After using Storyblok for personal projects and discovering that the company was hiring a developer relations engineer, Facundo saw the perfect convergence of his interests. He emphasizes the importance of genuinely believing in the product you advocate for, and shares that the role also brought new experiences like working fully remote with an internationally distributed team based out of Austria.
00:10:02 - Storyblok's Visual Editor and Content Editing Experience
Christopher raises the key differentiator he noticed about Storyblok: its real-time visual editor that lets content creators see exactly how their pages will look as they build them. He contrasts this with his own experience using other headless CMSs, where teaching non-developers to work with abstract grid systems and form-based editing was painstaking and unintuitive.
Facundo explains how Storyblok's visual editor works in practice — content editors can modify text, add components, upload and filter images, and rearrange page elements while seeing a live preview of their site. The system links directly to the developer's application, even supporting localhost environments, so no deployment is needed to preview changes. This bridges the gap between the flexibility of headless architecture and the usability of traditional WYSIWYG editors.
00:15:57 - Technical Architecture and Framework Flexibility
Facundo clarifies that Storyblok only hosts the content itself, delivering it via REST or GraphQL APIs, while developers maintain full control over their application code and hosting. The platform provides SDKs for numerous frameworks and languages, including React, Next.js, Vue, Nuxt, Angular, Gatsby, Svelte, Laravel, and even ASP.NET, making it genuinely framework-agnostic.
The discussion covers how Storyblok's "stories" and "blocks" work as organizational concepts — stories represent page-level structures while blocks are nestable components within them. Facundo describes how developers create visual representations of these blocks in their own codebase, allowing content editors to dynamically compose pages using pre-styled components without developer intervention, while also offering the ability to restrict or open up editing permissions as needed.
00:23:25 - Comparisons, Community, and the Vue Ecosystem
Anthony asks how people typically compare Storyblok to other tools, and Facundo draws parallels with Stackbit, which offers a similar visual editing experience combined with template selection and framework choice. Anthony also brings up Tina CMS as another inline editing solution, noting its close integration with Gatsby.
Facundo acknowledges that while Storyblok supports many technologies, there is a particularly strong connection with the Vue.js and Nuxt communities. Storyblok's own front end is built with Vue, and many prominent community members and ambassadors — including well-known Nuxt contributors — actively use and promote the platform. The ambassador program and community collaborations reinforce this relationship, though the platform remains fully accessible to developers working in other ecosystems.
00:27:01 - Migrating from jQuery to Modern Frameworks
Christopher highlights Facundo's Smashing Magazine article about converting a jQuery application to Next.js, curious about the motivation behind pairing two seemingly different technologies. Facundo explains the article originated from a Smashing Magazine pitch about migrating legacy applications to modern frameworks, and evolved into a broader discussion of componentization strategies and incremental migration approaches.
The conversation broadens into a reflection on how many production websites still rely on jQuery and traditional CMSs like WordPress, and how the transition to modern tooling isn't always straightforward. Facundo advocates for headless CMSs as a way to decouple front-end technology choices from content management, allowing teams to adopt new frameworks, serverless functions, and other innovations while improving both developer and user experience without being locked into any single technology stack.
00:33:27 - The Future of Jamstack and Closing Thoughts
Facundo identifies the key challenge facing the Jamstack: making static sites both dynamic enough for great user experiences and practical enough for developers to maintain. He points to innovations like Next.js's incremental static regeneration and Netlify's distributed persistent rendering as promising steps toward faster, more flexible static site generation that doesn't require rebuilding entire sites for every content change.
He also highlights the emergence of full-stack frameworks like RedwoodJS and Blitz.js as a natural evolution — or "mutation" — of Jamstack thinking, where the focus expands to encompass the entire application stack while still prioritizing developer experience. The episode closes with Facundo sharing his contact information and expressing appreciation for the opportunity to appear on a podcast he regularly listens to, noting his enthusiasm for the full-stack Jamstack concept the show promotes.
Transcript
00:00:00 - Christopher Burns
Is that your new apartment, Anthony?
00:00:02 - Anthony Campolo
Yeah, that's the one.
00:00:04 - Christopher Burns
Very nice. It looks very industrial.
00:00:07 - Anthony Campolo
Yeah. I mean, it's functional.
00:00:08 - Christopher Burns
So functional. California. Everything's a square. A blank square. Concrete room.
00:00:14 - Anthony Campolo
That's funny. You sound like my girlfriend. Facundo, welcome to the podcast.
00:00:29 - Facundo Giuliani
Thank you very much for being here.
00:00:31 - Anthony Campolo
Thank you so much. We would love to hear your background, where you work, and what projects you're doing.
00:00:37 - Facundo Giuliani
I live in Buenos Aires, Argentina. I've studied at the university. I'm a systems engineer. I've been working for almost 15 years as a developer, on web development, desktop applications, different stacks, and different technologies. But in the last year or two years, I started to be interested in generating content and sharing content with the community. Based on that, I started to use my free time to create and share content. In the last two months, I've been working as a developer relations engineer at Storyblok, and it's my first non-developer position, my first non-developer job, let's say. So it's kind of a challenge because the things that I was doing these last couple of years in my free time are now the things that I do in my daily job or in my work time. It's super cool experiencing this new challenge.
00:01:34 - Anthony Campolo
I think it's interesting you call it developer relations engineering. This is a slight tweak on what Jason Lengstorf was talking about, where they specifically don't say developer advocacy at Netlify. They say developer experience engineer. So developer relations engineer is one that I don't hear quite as much. Do you think of these different roles as being fluid or hard divisions? Do you define yourself in opposition to some of them, or is it just one big bucket to you?
00:02:00 - Facundo Giuliani
Yeah, probably. Again, I've been working as a developer for a lot of time. This is all kind of new for me. So probably a person that was working for several years in similar positions can notice more real differences between a developer relations engineer, a developer advocate, or developer experience engineer. I'm starting to learn about them. I think the developer relations engineer is more related to being the link between the developers and the product or the company, and trying to offer the point of view of the developer on how to use the services, how to use the products, how to create projects using the different products and the different tools.
The difference that I see, which I don't say that it is the difference or the real difference, but the difference with developer experience engineer that I see, or at least that we have in Storyblok, the company that I work at, is that the developer experience is working more on integrations with other platforms and tools that will be used by the developers. Probably my work is to use those integrations and create content related to those integrations, to create tutorials, to give talks at events and conferences.
So I would say that probably the developer relations is more about generating the content, and the developer experience is more about creating the tools that will be used by the developers and by other people to get advantage of the products and the services.
00:03:34 - Anthony Campolo
Yeah, that's a good breakdown and I usually separate it. Similarly, in my head there's like working on the product, there's creating content to explain the products, and there's interfacing with people using the product. Whatever terms you want to put on those categorizations, I do see that a lot. I think it's because it's such a huge job to do all of those things and it requires various skill sets. So it doesn't make any sense to try and bundle all of that into a single job. That's why we see a bit of this fractionation of slightly different roles with different emphases and different titles, but all circling around similar ideas and ways of working and engaging with community. It's really cool. We've had tons of people who do this kind of work on the podcast, and I do this kind of work, I would say. It's becoming a bigger and bigger thing, and people are hearing about it a lot more.
[00:04:22] I'd like to get into Storyblok itself because we haven't talked about this on the podcast, I think at all. It's a project that I've heard about for a while. I know it's very well known, so I'd love to get the kind of one-on-one and then your history with it and how you got involved with it.
00:04:37 - Facundo Giuliani
As a developer, during these last years, I was working mostly on the backend. I started to use my free time to learn about other technologies or other approaches that I didn't use at my daily job, and I started to read and to learn about the Jamstack. I found that a super interesting approach and a super cool idea because I've been developing for a lot of years. Probably my first approaches to development were creating static websites just for fun or for friends. I had a group of friends and I created our website with pictures, with music, etc., and to do that I used tools like Dreamweaver, probably Microsoft FrontPage. Probably the people that are listening to the podcast don't know what I'm talking about because they are really old tools that didn't survive.
But the idea was that you created static web pages because those were the web pages that we were able to create at that moment. We didn't have JavaScript frameworks or static site generators. They didn't exist at that moment. So the way to create a static website was using FrontPage or coding directly the HTML, JavaScript, and CSS.
What's funny is that JavaScript was not as advanced as it is today. We didn't have the features that we have today in JavaScript, so you weren't capable of doing the things that we are able to do today with JavaScript. At that moment, reading and learning about the Jamstack reminded me of that time, and I felt really interested in the idea of the comeback of the static pages, or the static web pages.
So I started to learn about the Jamstack, to play with the Jamstack, to talk about the Jamstack at different events. I presented talks in different conferences, local meetups in English and in Spanish, my native language, getting into the Jamstack and seeing the workflow and the different tools and services that we have available there.
One of the cool ideas or cool concepts that I found is the idea of the headless CMS. I already knew tools like WordPress or Drupal that I think are super helpful to create websites and pages for people that probably are not super familiar with developer concepts. The idea is to make the job easier for the content editors and the content creators. The concept of a headless CMS is that you are making the job easy for the content editor, but also the developer has the possibility of using the technologies that they want to develop a web application or a website and offer the best experience to the user. I was really interested in reading about that and playing with different alternatives of headless CMS and products.
I came across Storyblok, a product that I've used in the past for side projects, for personal projects. This was like a mix. In the last year, I started to feel like I was enjoying more the task of creating content and sharing content with the community, probably more than my daily work of developing eight hours a day.
Getting that related to the idea of developer relations, developer advocacy, developer experience, those were terms that started to appear more frequently to me when I was getting into it with people that talk about the Jamstack or that share content in different social networks. I started to read about what developer relations is. I started to read about what the tasks are that developer relations engineers do.
Knowing that position, or knowing that those kinds of positions exist in companies, and me enjoying generating content, and me enjoying playing with the Jamstack and reading about the Jamstack, and me enjoying creating projects, following the Jamstack approach, and knowing what the hell a CMS is, when I saw that Storyblok was looking for a developer relations engineer, I said, okay, let's try. That's it. I started with the interviews and I got the position. Now I changed the path of my career from being a developer with almost 15 years of experience to generating content and sharing that with the community. It's something that I really enjoy doing.
Again, what is cool is that I'm doing that about something that I really enjoy doing, that I'm interested in, with a tool that I really like, or I think that it's a good product. I'm talking about a product that I use and I think it's a good product. So I think that's a plus, because if you are going to talk about a certain product or a certain service to the developers or to the community, you have to be convinced that what you are saying is true. You don't want to talk good about something that you don't think is good.
That was an opportunity that appeared there. This is my second month. I started on June 1st, working at Storyblok, and it's a whole new experience, a fully remote company. The company was based in Austria, let's say, but the team members are all around the world and there's no central office. They don't have an office, so the company is fully remote. That's another big and new experience for me, working for a company that doesn't have any physical office, working in an asynchronous way, the communication between the team. It's a good challenge. I'm experiencing a good challenge and I'm enjoying it.
00:10:02 - Christopher Burns
Before we get into Storyblok, I think it's worth talking about what the purpose of Storyblok is. We've already said it's a CMS. I will hold up my hands and say I've never used it, but quickly looking at the website and the documentation, it seems to have one really big key feature that I've seen that CMSs like GraphCMS and Contentful struggle with to a certain extent. Your website, the data that you're trying to put in, is already within a window and you can see it on the website straight away.
To give context to our listeners, I've been building a new website for Everfund, a new marketing website. It took me weeks upon weeks and we're finally in the final stages, with everything in a CMS where my co-founder and other staff members can edit the content without needing me to change anything, build new pages without needing to code anything. That system is completely built from the ground up in something like GraphCMS.
The hardest part of it is teaching them the concept of grids. As a developer, we know grids exist. But then to say, okay, if you want a two-column layout, so an image on the left, paragraph on the right, standard marketing tool on any marketing website, okay, you need to create a grid. You need two columns. Each column needs to be spanned by one. Then you need to write your text on the left grid, and then your right grid needs to be a media block. It's so, so much work just to try and organize and create and to get the CMS side down to the point to allow somebody to then maintain that website, add new content, add new pages without the developer needing to do any more work. It seems like Storyblok helps you do that a lot easier than the way I've done it.
00:12:02 - Facundo Giuliani
Yeah, that's true. I think that probably the key feature of Storyblok is the real-time visual editor that the tool has. When you create your account on the Storyblok site and you start using the application, you can create spaces. Let's say one space is related to one project that you are going to create. It can be a web application or probably a mobile application. That's one of the cool features of all the headless CMS: you can create the content in the backend and you can consume it from everywhere. So you can create multi-channel experiences that you can reuse that information from mobile application and web application and etc.
But if you are working in a web application, the cool part of Storyblok is that you can link an instance of that web application to the backend that the content editors are going to use to create the content, and you will offer them a visual experience of how the content is going to look while they are creating the content. So if you're a content editor, you can go to the Storyblok application and see the home page of your web application. Or if you have a blog site, you can go and create a blog post right from the Storyblok page and see how the blog post is going to look without having to deploy anything, without needing the work from a developer or anything.
You, being the content creator, go to Storyblok and you can start editing visually how the page is going to look. For instance, you have a paragraph, you can edit the text directly from Storyblok. You can add different components to your pages. You can edit the components. You can upload images, edit the images, even apply filters to the images, and you are seeing how the page is going to look while you are editing, without having to deploy anything, without having to edit the production version, without having to create draft stories or draft data of what you are creating. That's not needed. You can link the Storyblok application, which is the backend, to your application, and the content editor can create the content. The developer doesn't need to do anything to show how it's going to look. It's like a real-time experience. And you, as a content creator, feel like you are creating and seeing the page that is going to be live on your site in the future.
00:14:33 - Christopher Burns
This is such an interesting area with CMSs. A lot of these headless CMS have kind of jumped the gun where they've gone so far into the benefits of headless, consumable anywhere, that you forgot about the poor soul who actually needs to write the content later on, after the developer. This sounds like the most controversial thing that I would say.
I've recently had to boot up WordPress for the first time in years and years. I got a handle on their brand new, well I'm sure it's not new anymore, the Gutenberg editor built in React. It was honestly really good for someone who has jaded opinions of WordPress, left it for some years, then came back and used this WYSIWYG editor. It felt so refreshing going to that from a headless CMS where it kind of is blind to a certain extent. You're writing all your stuff in this glorified form. While amazing, it's headless, that can be consumed anywhere. Sometimes you just wish you could see what you're typing as it is being typed.
Storyblok seems like it hits that out of the park. We've talked about the editor. We've talked about its uses. How does the developer use this? Can they still use Next or Gatsby or Vue? Can they still use all the tools like Tailwind that they want? Are you hosting that code now, or is the developer still hosting on something like Vercel or Netlify?
00:15:57 - Facundo Giuliani
From the Storyblok site, the only thing that Storyblok is hosting is the content that you create, and the content is exposed using a REST API or a GraphQL API that you can consume from there. The application itself is all developed by the developers and maintained by the developers on the servers that they want.
For instance, what I was saying before, you link the Storyblok application where you create the content to your application so the content editors can see how the content will look. It is really linking to where your application lives. So you can point Storyblok to a testing environment of your application or even a local environment. You can link Storyblok to your localhost and port 3000, and you can see how the site is going to look.
Storyblok doesn't host your application. It saves and stores all the information and delivers it using the different APIs. What is cool about Storyblok too is that we have different SDKs that you can use for different languages and different frameworks, like Next, Angular, Gatsby.
00:17:06 - Anthony Campolo
I was also scrolling through the front page, and there was a strip of them where it had React, Gatsby, Next, Vue, Gridsome, Nuxt, Svelte, and Laravel, and they're all kind of mixed up. So I saw that as them saying we're framework agnostic, in case you were wondering. I think that's really cool.
00:17:24 - Facundo Giuliani
Exactly. The first article that I wrote on the Storyblok site when I entered the company was a tutorial about how to use Storyblok with your ASP.NET application. I have a really strong background using ASP.NET and Microsoft technologies. When I was a backend developer, I wrote this article. It's very cool because you get the same advantages of using Storyblok and seeing live the content that you are creating as an editor with applications created with ASP.NET that are server-side rendering. That's not to say that you have to use a front-end framework, a JavaScript framework, or a static site generator. You can use it with PHP or Ruby. There are different SDKs that you can use, and if you don't want to use the SDKs that are available, you can consume the content as any other REST API or GraphQL API using your method.
00:18:17 - Anthony Campolo
Can we talk about what a block is? I don't think you've actually defined that yet. That's a specific term within Storyblok.
00:18:23 - Facundo Giuliani
Yeah, that's true. The name comes from story and block. Let's say story. We can relate that to a page, but not necessarily because, as we said, the headless CMS can create content for any channel. But let's say a story would be the structure to create a post page, the home page, the about page. If you are creating an e-commerce platform, your product page would be a story. And then we have the blocks, which are the components that are inside that story. The difference is the blocks are components that are nestable. So you can have components that have components inside of them, and create all the hierarchical structure of components inside your story.
We can say that the main structure, or the main part of how the content is organized in Storyblok, is the story. You will have stories, and then those stories will have components, which are blocks inside of them. But again, the page is the easiest example. You can have stories for the author of your blog post in your blog site. So if you want to create different blog posts and you want to link those posts to authors, you can select them from different stories that you have created in the same space.
00:19:47 - Anthony Campolo
Are there any other important concepts or things you need to explain for people to get Storyblok?
00:19:53 - Facundo Giuliani
Probably the visual editor is the key feature of Storyblok. What's cool about the visual editor is that, for instance, I use Next.js. I'm working with Next.js right now. I'm a big fan of the framework and I enjoy using it. But you can use Next.js or React to create your components in your code, in your application, and you can define the style of those components using the CSS that you want, using Tailwind CSS, for instance.
Using the SDK that Storyblok offers, what you can do is create the representation of the blocks or components that you have in your space in Storyblok, and create the visual representation of them using React. For instance, you can define stories that have dynamic content. You can create a story structure that says this is going to be a page, and I don't know at this moment which kind of components are going to be in this story. That's okay. Storyblok supports that. You can have dynamic stories with dynamic components in them.
The cool part is that using the SDK from Storyblok in your React application, for instance, but it can be in any programming language and any framework because we have SDKs for all of them, you can create a dynamic component in your application and say, okay, as I have the story of type page in my space in Storyblok, I will create the component page in my application, and I will define this style for this page. I will say that this page in my application has dynamic components inside of it.
You can then create other types of components, defined types like image or paragraph or text or headline or teaser. For each one of those components, you can create the visual representation of them saying, okay, for the teaser, for instance, I'm going to use the property name here, the property title. In this other part, I will create this span with this style here. Having all those visual representations, when you are using the visual editor in the site, the content editor can select any component and add them to the stories, and the application itself will add the dynamic components. So it will add the visual representation of them.
So you can really create any kind of page from the visual editor, using all the visual representations that you created in your application with the styles that the developer defined. So if I'm a content editor and I need to create an about page, and I didn't have an about page before, but I say, okay, this about page is going to be a story of type page. As the content is dynamic, I can start adding blocks in that about page and say, okay, I'm adding a paragraph here, a teaser here, an image here with this background, with this text, with this padding, and etc., and you are linking that to the visual representation that you have in your code.
I think that is pretty cool. Again, this is something that you can define and that is available if you want your content editors not to have that dynamism or that independence of creating whatever they want. You can always restrict and say, okay, no, this story will allow only this type of components, this type of fields. You can be as flexible as you want or as strict as you want.
00:23:25 - Anthony Campolo
What projects do you think are similar to Storyblok? I feel like most people, when they work on anything, there's always another thing that people always compare it to. So when you explain Storyblok to people, are they like, oh, it's kind of like this other thing? How do people compare it to other things that they know?
00:23:40 - Facundo Giuliani
I imagine that the first comparison is with other headless CMS. There are a lot of alternatives in the market, a lot of great products that I've used in the past. I really like one product that I've used in the past, and I think that is a very similar concept: Stackbit. I don't know if you have heard about it.
00:23:59 - Anthony Campolo
Yeah. Oh yeah.
00:24:00 - Facundo Giuliani
Stackbit is a platform that allows you to select the framework that you want to use for your page or your website, the headless CMS that you want to use as a backend of your application, and then you have a lot of templates that are available to create your website. You want to create a personal site, you have a template. You want to create a blog, you have a template. You want to create a landing page, you have a template. You select those options. When you are creating your project in Stackbit and selecting that, you enter into a visual editor where you can start editing the page right there inside Stackbit and define how your website is going to look. It's kind of similar.
00:24:43 - Anthony Campolo
Yeah, so I have used Stackbit. That makes a lot of sense. And now I'm thinking of Tina CMS, I think, is another one that was kind of like this, where it was like instantly you just interact with the page and start editing it kind of thing.
00:24:55 - Facundo Giuliani
I didn't use Tina CMS, but I will have to take a look.
00:25:00 - Anthony Campolo
They ended up becoming kind of like the CMS of choice for Gatsby. Even though they developed kind of separately, they ended up integrating fairly heavily, I think. But this was like a year or two ago, so I haven't kept up with it since.
00:25:12 - Facundo Giuliani
It's true that also there are technologies that are very related to some products. For instance, Storyblok has SDKs for different technologies and different programming languages, but I see that many of the projects that are using Storyblok are made with Vue.js or Nuxt because the developers from Storyblok, the team members, work with Vue.js. The front end of Storyblok is done with Vue.js, and there's a lot of collaboration between Storyblok and the Nuxt community, the Vue.js community. A lot of Vue.js contributors are also in contact with Storyblok. They are Storyblok users. There are several people in the social networks that share content related to Nuxt that also use Storyblok.
In fact, Storyblok has its own ambassador program that we are trying to relaunch and to improve, and we have Storyblok ambassadors. Some of these ambassadors are probably well-known people from the community, like Debbie O'Brien, who was in a previous episode of this podcast. She was an ambassador, I think, or a developer advocate.
00:26:35 - Anthony Campolo
Well, she was on the Nuxt team, like fully Nuxt.
00:26:38 - Facundo Giuliani
Exactly, exactly. She did a stream using Storyblok with Samuel, who is the head of the developer relations team at Storyblok. Again, it's like a lot of collaboration between Nuxt and Vue with Storyblok. But again, I use Next.js and I create projects using Next.js and Storyblok, and we have different SDKs and different alternatives for the programming languages to use.
00:27:01 - Christopher Burns
I looked on your personal website. You have your own blog on there, and one article really stood out to me. You probably know which one is going to be. It was your latest article that said converting from jQuery to Next.js. My main question is what spurred you to make that article? Because they're very different things. To me it seems more like from jQuery to JavaScript now, not just necessarily a framework. I'm just really interested to hear your opinions on why you made that piece. It did get republished on Smashing Magazine, was it?
00:27:38 - Facundo Giuliani
Well, that's very funny because the article itself is on the Smashing Magazine site. This was an idea that came up from the Smashing Magazine team because I wrote an article in the past about how to add security to a Next.js application using Auth0. They came up with this idea that they were looking for more Next.js articles, and the original idea was to create an article about how to migrate a legacy application to a Next.js application.
Having in mind a legacy application, everything is cool and you can use the tools that you want or that fit better for you. But having in mind the concept of a legacy application using a traditional CMS, like WordPress, for instance, some ideas came to mind as I started to write. What's one of the concepts that WordPress has, or that it shares with a lot of other sites that probably are not using WordPress? jQuery, for instance. jQuery is a library that was created a long time ago. Many of the benefits or features that jQuery offered at that time are now part of native vanilla JavaScript. Something that probably you weren't able to do using JavaScript in the past, you can do now, and you don't need a library like jQuery.
But besides that, the original idea was to create an article about how to migrate a legacy application to Next.js. So we had some exchange of messages with the Smashing Magazine team. My idea was to think the migration not to Next.js, but probably to React because jQuery is more like a front-end tool that you can use to improve your user interface and your user experience. But Next.js is a more complex concept. When you are using Next.js, you are organizing or creating an application following a different approach and a different paradigm.
The article was like a mix of these ideas on how to migrate a legacy application to a newer one using a library like Next.js, but also how to stop using jQuery features that you can use with vanilla JavaScript and you don't need a library to do that, and how to migrate the concept of your application to a component-based application using React components. In fact, if you read the title of the article, it's kind of catchy because you say, I mean, migrating a jQuery application to Next.js, and you say, but these are different things. But if you go to the article, it's kind of a long article. You will see that in the body of the article, we are talking about different migration strategies. We are talking about how to migrate your application without breaking your current production stage, how to componentize your functionality, and after all, how to get advantage of some features that Next.js offers, like static site generation, server-side generation, and etc. So it's not like a migration from jQuery to Next.js, but it's more like talking about how to componentize your existing legacy application in case that you are wondering about doing that.
00:30:57 - Christopher Burns
I think a lot of us.
00:30:58 - Christopher Burns
Tend to forget that, you know, there's still so many websites out there that run jQuery. I bet if you looked at a typical place like Themeforest, 80% of WordPress themes are still jQuery. Then sometimes you think, okay, we want to move away from jQuery, but then how would I write a WordPress theme in React? Sometimes you think, how do you put those two things together? How do you pull the past out from the future? It just seems sometimes like this bygone era, if you know what I mean. It's like that with so many things. Sometimes we see it even on the backend. If you get so used to using GraphQL, you're like, how do I even do a REST call? What is a REST call? The rate that technology moves is so, so crazy.
00:31:47 - Facundo Giuliani
It's okay. Probably depending on your use case, WordPress is a cool solution. There's no issue with WordPress particularly. What I'm trying to say is that one of the things that I think headless CMS have the advantage is that you are not trying to use any technology for the front end of your application, so you can use whatever you want or whatever fits better for you.
I think that with the evolution or the change of the website and how the websites are done, we forgot important things like the user experience, the cost of maintaining our applications, how fast our sites are, how easy it is for us to maintain our websites or to manage them or to edit them. That's one cool thing that you can have with the headless CMS because you are not tied to use any technology in the front. If you have new frameworks or new technologies or new services like the serverless functions, for instance, you can get advantage of that to get a better developer experience, but also get a better user experience. Probably thinking about the migration to get advantage of that is a good idea.
Again, there's no problem with the traditional CMSs, and depending on the use case, it's probably a good choice if you want to create a small project or if you are familiar with PHP or something like that. But if it's not the best solution for your use case, probably thinking about headless CMS or a migration to a framework like React or Vue, etc., is a good idea to have in mind and to try to investigate more.
00:33:27 - Anthony Campolo
Winding down here. I think you've already touched on some of these things. I'll be curious what you think is coming up in the Jamstack, in the future. What are some things people should be looking out for? What do you think are going to be things that keep pushing the movement forward?
00:33:40 - Facundo Giuliani
One of the challenges that the Jamstack has to face is how to create dynamic experiences, or great user experiences not tied to static sites, or how to make static sites a good experience for the user. That is one of the challenges that I think the Jamstack has to face. On the other hand, there's the developer experience of creating static sites. Nowadays, if you want to create a static website using a static site generator, you have to execute an atomic deployment and generate all the static pages ahead of time that you want to expose, and I think that there are some frameworks and some platforms that are investigating or trying to work around that situation.
For instance, Next.js is offering incremental static regeneration and Netlify, I don't remember exactly the name, but it's offering.
00:34:33 - Anthony Campolo
Distributed persistent rendering.
00:34:35 - Facundo Giuliani
DPR, exactly. They are offering a very similar approach, but without breaking the atomic deployment concept. What I think the Jamstack is going to move to is how to improve the way of creating your website. We all agree that a static web page is the fastest and the best experience that we can offer to the user. Now the question is how we can do that more easily for the developers to maintain, how we can do that in a faster way of generation, or without needing to execute a process that takes minutes to generate the pages, so we can do that probably more frequently, or we can have automatic processes that can build websites and generate static assets faster. I think that the Jamstack is going to move to that area.
On the other hand, one of the things that probably is mutating, or the Jamstack is mutating, is this new concept of the full stack frameworks that are appearing like RedwoodJS or Blitz.js, or these experiences that probably they are not, how to say, strictly Jamstack.
00:35:43 - Anthony Campolo
I like that you call us a mutation.
00:35:45 - Facundo Giuliani
Yes, yes, because they are starting from the concept of the Jamstack, but they are moving to a full stack approach. So I think that's a cool idea and a cool concept at the end. The idea is to offer a great user experience, but also thinking about what's best for the developer, not having to reinvent the wheel, or having an easier way of maintaining your application.
I think that those are ideas that you are thinking on the person that is creating the product. That's great because the frameworks are the tools that are more used in the market, are the ones that the developers feel more comfortable with. So if you are offering a great developer experience, probably your product is going to be more used, even if the page takes three milliseconds more to load than using another framework. So I think that probably creating experiences like RedwoodJS or Blitz.js, they are offering to the developers tools to create great experiences and making the job easier using tools that are really cool for developers.
00:36:51 - Anthony Campolo
That's cool. Well, thank you for coming on to our podcast and making a pitch for us.
00:36:55 - Facundo Giuliani
Yeah, no.
00:36:56 - Anthony Campolo
Appreciate you supporting the ideas of Full Stack Jamstack. It's cool. As we've continued to do this and grow this, people who were totally outside of the Redwood world are like, yeah, I get that. This makes sense. I think this is cool. So it's been really awesome having you on the show and getting your perspective on all this stuff and getting to talk about your projects. Can we get just your contacts, like where you are on the internet, and then where people should go to find Storyblok stuff as well?
00:37:21 - Facundo Giuliani
My personal site is fgiuliani.com, from my first name and my last name. I'm on Twitter. I spend a lot of time on Twitter. I'm Facundo Zurdo with Z. If you want to talk about Storyblok, you can go to my personal site or Twitter. We can talk about that. If not, you can go to the home page of Storyblok, which is storyblok.com. Thank you very much for this opportunity to join the podcast. I'm a listener of the podcast, so speaking on a show that I enjoy listening to is a great experience. Thank you very much. It's an honor being here.